When processing the attached file (no_embed.pdf) with a custom output device, GS reloads fonts for every page. The same happens when using the nullpage-device. It's not really a bug but I'd like to circumvent this for performance reasons. The PDF uses 2 fonts (TrueType) that are not embedded. Only entrys in the fontmap are: /F0 /ArialMT ; /F1 /TimesNewRomanPS-BoldMT ; Fontpath is c:\windows\fonts The printout is: Processing pages 1 through 3. Page 1 Can't find (or can't open) font file ghostscript-8.61\Resource/Font/ArialMT. Can't find (or can't open) font file ArialMT. Can't find (or can't open) font file ghostscript-8.61\Resource/Font/ArialMT. Can't find (or can't open) font file ArialMT. Scanning c:\windows\fonts for fonts... 248 files, 110 scanned, 107 new fonts. Loading ArialMT font from c:\windows\fonts/arial.ttf... 3393540 2016005 2993984 1557820 3 done. Loading TimesNewRomanPS-BoldMT font from c:\windows\fonts/timesbd.ttf... 3393540 2019425 3576076 2105584 3 done. Page 2 Loading ArialMT font from c:\windows\fonts/arial.ttf... 3453828 2092441 3062004 1754876 3 done. Loading TimesNewRomanPS-BoldMT font from c:\windows\fonts/timesbd.ttf... 3453828 2092689 3490500 2100060 3 done. Page 3 Loading ArialMT font from c:\windows\fonts/arial.ttf... 3146372 1037547 3062004 1756898 3 done. Loading TimesNewRomanPS-BoldMT font from c:\windows\fonts/timesbd.ttf... 3146372 1037795 3470404 2099354 3 done.
Created attachment 3912 [details] pdf with not-embedded fonts
Please attach a PDF that corresponds to the description. The output shows: Artifex Ghostscript 8.62 (2008-02-29) Copyright (C) 2008 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 3. Page 1 Scanning c:/windows/fonts for fonts... 273 files, 105 scanned, 94 new fonts. Substituting font Helvetica for F0. Loading NimbusSanL-Regu font from /fonts/n019003l.pfb... 3396924 1954948 11389848 10096694 3 done. Substituting font Helvetica for F1. >>showpage, press <return> to continue<< Page 2 Substituting font Helvetica for F0. Substituting font Helvetica for F1. >>showpage, press <return> to continue<< Page 3 Substituting font Helvetica for F0. Substituting font Helvetica for F1. >>showpage, press <return> to continue<< -------------------------------------------------------------------------------- and the output from -dPDFDEBUG shows: BT /R8 9.96 Tf %Resolving: [13 0] << /R10 10 0 R /R8 8 0 R >> endobj %Resolving: [8 0] << /BaseFont /F0 /FontDescriptor 9 0 R /Type /Font /FirstChar 1 /LastChar 8 /Widths [ 667 556 222 278 278 556 556 556 ] /Encoding 25 0 R /Subtype /TrueType >> endobj %Resolving: [9 0] << /Type /FontDescriptor /FontName /F0 /FontBBox [ 0 -12 625 728 ] /Flags 4 /Ascent 728 /CapHeight 728 /Descent -12 /ItalicAngle 0 /StemV 93 /MissingWidth 750 >> endobj Scanning c:/windows/fonts for fonts... 273 files, 105 scanned, 94 new fonts. %Resolving: [9 0] Substituting font Helvetica for F0. Loading NimbusSanL-Regu font from /fonts/n019003l.pfb... 3396924 1955060 11389848 10098006 3 done. %Resolving: [9 0] -------------------------------------------------------------------------------- From the first log, you can see that "NimbusSanL-Regu" is only loaded once.
Ah, so the fonts used make the difference. You substitute the uknown F0/F1 with Helvetica, with maps to n019003l.pfb (shipped with gs). My fontmap: /F0 /ArialMT ; /F1 /TimesNewRomanPS-BoldMT ; --> both fonts are mapped to windows-truetype fonts. Please clear your fontmap and include only these entrys: /F0 (c:/windows/fonts/arial.ttf) ; /F1 (n019003l.pfb) ; I get: Processing pages 1 through 3. Page 1 Loading F0 font from c:/windows/fonts/arial.ttf... 2491656 947882 3316604 195979 0 3 done. Using ArialMT font for F0. Loading F1 font from C:\Programme\gs\fonts/n019003l.pfb... 2508344 1033252 34051 12 2035436 3 done. Using NimbusSanL-Regu font for F1. Page 2 Loading F0 font from c:/windows/fonts/arial.ttf... 2508344 1034358 3364896 19681 96 3 done. Using ArialMT font for F0. Page 3 Loading F0 font from c:/windows/fonts/arial.ttf... 2508344 1034966 3364896 19698 96 3 done. So F0 is reloaded every page while F1 is not.
This is probably a result of some recent changes in the way TT fonts are kept in the cache (or not). Assigning to Alex since he has been 'fixing' stuff in this area. Since this does impact performance, it probably should be treated as a bug.
The observed inefficiency is not a recent regression. All versions since 8.54 load the fonts multiple times. Earlier versions cannot interpret the PDF file at all. My Fomtmap.GS in the current directory: /F0 /ArialMT ; /F1 /TimesNewRomanPS-BoldMT ; My command line: gswin32c -dNOPAUSE -dBATCH -sFONTPATH=c:/winnt/fonts foo.pdf
PDF interpreter processes every page in the save-restore context. So the font caching in the PDF interpreter cannot span pages. Fonts can be also cached on the PostScript interpreter level. Fonts loaded in the local memory are purged from memory the same way as they are purged from the PDF cache. Global fonts stay in the cache for the duration of the job. Type 1 fonts bundled with Ghostscript are global. The fonts found in the search path are local. PDF interpreter runs OK without the per-page save. With some caution external fonts may be loaded into global memory. I'd like to discuss with other developers how to proceed.
This seems pretty easy to resolve. I sure don't see what harm it would cause to load _ALL_ fonts into global VM (and thus isolate them from save/restore) as we do with Type 1 fonts. Eliminating the special test for Type 1 in Resource/Init/gs_fonts.ps seems easy (tagged with >>>> below): % If LOCALFONTS isn't set, load the font into local or global % VM according to FontType; if LOCALFONTS is set, load the font % into the current VM, which is what Adobe printers (but not % DPS or CPSI) do. LOCALFONTS { false } { /setglobal where } ifelse >>>> { pop /FontType .findfontvalue { 1 eq } { false } ifelse ... /.setglobal .systemvar exec } Adding Ken to the cc list to comment.
Ray's approach works and passes regression test but the benefits are small. The time difference in running all regression files on nullpage device is below the noise level. (< 0.1%). Global fonts will increase memory usage, which may be significant on embedded systems.
I've seen (rare!) real world files which expect fonts to obey save and restore, so loading all fonts into global VM would be a problem for those files. Given that Alex's testing shows little difference I don't think we should do this. I'm slightly surprised we haven't come across problems by loading fonts into VM based on the font type.
Since benefits of loading fonts to global VM are small and there was no interest in this topic for a few years, I'm closing this bug report.