Summary: | fonts reloaded for each page (performance issue) | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | f.kintzel |
Component: | PDF Interpreter | Assignee: | Alex Cherepanov <alex> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | christinedelight.top85, ken.sharp |
Priority: | P4 | ||
Version: | 8.61 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Customer: | Word Size: | --- | |
Attachments: | pdf with not-embedded fonts |
Description
f.kintzel
2008-04-01 08:03:03 UTC
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. |