Bug 624711

Summary: gs takes a long time to render simple documents
Product: [Fedora] Fedora Reporter: Horst H. von Brand <vonbrand>
Component: ghostscriptAssignee: Tim Waugh <twaugh>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 15CC: twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-26 09:32:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A file showing the problem
none
A file generated by enscript none

Description Horst H. von Brand 2010-08-17 14:38:19 UTC
Created attachment 439133 [details]
A file showing the problem

Description of problem:
I ran into a problem with evince on a PostScript file generated by mpage (attached). Digging deeper, it seems to me that gs is trying to find fonts that the document itself defines. My understanding of PostScript is rather limited, so I'd like somebody really conversant with the language to confirm this.

The PostScript file says:

  %%DocumentFonts: Courier Times-Bold

I understand this to mean that are the (only?) external fonts to load/use, and those are standard PS fonts, no problem.

Later on:

  /Courier /OurCharSet charvec ReEncodeSmall
  /textfont /OurCharSet findfont 11 scalefont def
  /textfontbold /OurCharSet-Bold findfont 11 scalefont def

I read this (together with lots of stuff I only understand half of) to mean that the document is defining its own fonts named OurCharSet and OurCharSet-Bold. But running gs on it gives:


  $ gs /tmp/copia.c.ps 
  GPL Ghostscript 8.71 (2010-02-10)
  Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
  This software comes with NO WARRANTY: see the file PUBLIC for details.
  Can't find (or can't open) font file /usr/share/ghostscript/8.71/Resource  /Font/NimbusMonL-Regu.
  Can't find (or can't open) font file NimbusMonL-Regu.
  Can't find (or can't open) font file /usr/share/ghostscript/8.71/Resource/Font/NimbusMonL-Regu.
  Can't find (or can't open) font file NimbusMonL-Regu.
  Querying operating system for font files...
  Loading NimbusMonL-Regu font from /usr/share/fonts/default/Type1/n022003l.pfb... 3854456 2438755 6339260 4004644 1 done.
  Can't find (or can't open) font file /usr/share/ghostscript/8.71/Resource/Font/OurCharSet-Bold.
  Can't find (or can't open) font file OurCharSet-Bold.
  Didn't find this font on the system!
  Substituting font Helvetica-Bold for OurCharSet-Bold.
  Loading NimbusSanL-Bold font from /usr/share/fonts/default/Type1/n019004l.pfb... 3956000 2548879 6339260 4014428 1 done.
  Loading NimbusRomNo9L-Medi font from /usr/share/fonts/default/Type1/n021004l.pfb... 4131920 2726164 6339260 4016039 1 done.

This is patent nonsense, the fonts OurCharSet and OurCharSet-Bold shouldn't be searched for at all. Besides, going on a wild chase for fonts that are standard is weird...

Version-Release number of selected component (if applicable):
ghostscript-8.71-11.fc15.x86_64

How reproducible:


Steps to Reproduce:
1. gs copia.c.ps
2.
3.
  
Actual results:
Font search discussed above

Expected results:
- Standard fonts shouln't take so many steps to find
- Fonts defined in the document should not be searched for

Additional info:

Comment 1 Horst H. von Brand 2010-08-17 15:16:30 UTC
Created attachment 439138 [details]
A file generated by enscript

This file takes a _very_ long time to display, again it seems to look all over the place for standard fonts.

$ gs /tmp/CyA.ps 
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Can't find (or can't open) font file /usr/share/ghostscript/8.71/Resource/Font/NimbusMonL-Bold.
Can't find (or can't open) font file NimbusMonL-Bold.
Can't find (or can't open) font file /usr/share/ghostscript/8.71/Resource/Font/NimbusMonL-Bold.
Can't find (or can't open) font file NimbusMonL-Bold.
Querying operating system for font files...
Loading NimbusMonL-Bold font from /usr/share/fonts/default/Type1/n022004l.pfb... 3862920 2458763 6351844 4156804 1 done.
Loading NimbusMonL-Regu font from /usr/share/fonts/default/Type1/n022003l.pfb... 4006784 2599136 6351844 4162583 1 done.
>>showpage, press <return> to continue<<

Comment 2 Tim Waugh 2010-08-17 15:37:17 UTC
These messages:

(In reply to comment #1)
> Can't find (or can't open) font file
> /usr/share/ghostscript/8.71/Resource/Font/NimbusMonL-Bold.
> Can't find (or can't open) font file NimbusMonL-Bold.
> Can't find (or can't open) font file
> /usr/share/ghostscript/8.71/Resource/Font/NimbusMonL-Bold.
> Can't find (or can't open) font file NimbusMonL-Bold.
> Querying operating system for font files...
> Loading NimbusMonL-Bold font from
> /usr/share/fonts/default/Type1/n022004l.pfb... 3862920 2458763 6351844 4156804
> 1 done.
> Loading NimbusMonL-Regu font from
> /usr/share/fonts/default/Type1/n022003l.pfb... 4006784 2599136 6351844 4162583
> 1 done.

are normal, and a consequence of the way fontconfig support is implemented in ghostscript.  Firstly, it checks to see if the fonts are installed as part of the ghostscript installation; if that fails, and we expect it to on Fedora, it falls back to performing a fontconfig query.  The failing check is (or ought to be) very fast: just a stat() call is necessary.

As for your OurCharSet fonts, I'm not sure at the moment but hopefully will have some time to look closer in the next few weeks.

Comment 3 Horst H. von Brand 2010-08-23 01:30:24 UTC
My principal problem is that gs takes a _long_ time to render even simple documents.

Comment 4 Tim Waugh 2010-09-02 15:45:13 UTC
How long is long?  On a Red Hat Enterprise Linux 6 Alpha machine here running ghostscript-8.70 it takes 0.4s:

$ time gs -dNOPAUSE -dBATCH CyA.ps >/dev/null

real	0m0.403s
user	0m0.259s
sys	0m0.056s

For F-13 running under KVM on the same machine I get "real 0.630s" after running it a few times to make sure the cache is hot.

Same with F-14 Alpha running under KVM.

Comment 5 Horst H. von Brand 2010-09-21 01:08:24 UTC
Here rawhide x86_64, ghostscript-8.71-16.fc15.x86_64

First time around with the supplied copia.c.ps:

real	0m52.360s
user	0m1.175s
sys	0m1.395s

Second time:

real	0m1.307s
user	0m0.865s
sys	0m0.307s

The "first time around" is mostly _the_ time I see, I don't futz around with PS much.

Comment 6 Jan Kurik 2015-12-22 11:34:07 UTC
This bug is currently assigned to an unsupported release. If you think this bug is still valid and should remain open, please re-assign it to a supported release (F22, F23) or to rawhide.

Bugs which will be assigned to an unsupported release are going to be closed as EOL (End Of Life) on January 26th, 2016.