Traditionally, i.e. with GPL versions before GS 8.63, the GS_LIB registry setting described a 3-parts sequence of paths such as: [INSTALLDIR]gs\gs8.63\lib;[INSTALLDIR]gs\fonts;[INSTALLDIR]gs\gs8.63\Resource According to the Changes.htm document -- as I understand it -- the "Fonts" and "Resource" entries are no longer of interest because of a changed compilation argument. So, why does the installer still write a string with three parts if two of them are now redundant? "gs863w32.exe" neither install a "Fonts" nor a "Resource" subdirectory as the previous versions. However, the installer still write those entries as part of the GS_LIB registry entry. Is there any particular reason for that? Would it be OK to omit paths for the "Fonts" and "Resource" subdirectories (in a re-built MSI installer package) in the GS_LIB registry entry? Best regards / Med venlig hilsen Jacob Schäffer | Chief Developer Paradis Allé 22, Ramløse DK-3200 Helsinge, Denmark Phone: +45 4439 4400 Email: js@grafikhuset.dk Web: www.grafikhuset.net
The current settings after installing GS 8.64 on Windows are . ; C:\Program Files\gs\gs8.64\lib ; C:\Program Files\gs\fonts ; C:/Windows/fonts ; %rom%Resource/Init/ ; %rom%lib/ ; c:/gs/gs8.64/Resource/Init ; c:/gs/gs8.64/lib ; c:/gs/gs8.64/Resource/Font ; c:/gs/fonts The only ones that are really needed are the two %rom% items. The two including "\Program Files" are added by the installer. These are not required. The ones including "c:/gs" are set within GS at compile time. They need to be set to something, but that directory usually doesn't exist. The set could perhaps be simplified. Even though the fonts are resources are compiled into the executable, it is still possible to override fonts by putting a Fontmap file in the first listed lib directory, and fonts in any of the directories.
> The ones including "c:/gs" are set within GS at compile time. They need > to be set to something, but that directory usually doesn't exist. > The set could perhaps be simplified. I attached a patch to bug #689040 comment #2 that removes the need for hard- coding GS_LIB_DEFAULT at build time. I used this occasion to simplify that part if init files are compiled in: in this case there’s no ‘Resource\’ directory on disk, so ‘Resource\Init’ and ‘Resource\Fonts’ may be omitted.
I am reviewing the patch on 689040 and will deal with this one at the same time if the issue is resolved by that patch. Thanks, SaGS
*** Bug 690580 has been marked as a duplicate of this bug. ***
I looked into the possibility of not setting ‘GS_LIB’ at all in the Windows installer, assuming the ‘GS_LIB_DEFAULT part’ is fixed (i.e. points to the correct directories where Ghostscript is installed, not to ‘C:\gs’). Here is what I noticed: - Except ‘C:\WINDOWS\Fonts’, directories added by default to ‘GS_LIB’ are (will be) a subset of those in (the corrected) ‘GS_LIB_DEFAULT’. So, in general ‘GS_LIB’ could remain empty, or contain only the Windows fonts directory. - Without the ‘%rom%’ device, there’s absolute no need to repeat directories in ‘GS_LIB’ and ‘GS_LIB_DEFAULT’. - With the ‘%rom%’ device included, the difference is that ‘GS_LIB’ directories are searched before those in ‘%rom%’, while ‘GS_LIB_DEFAULT’ ones are searched after it, so files in ‘%rom%’ mask files in ‘GS_LIB_DEFAULT’, but don't mask those in ‘GS_LIB’. ‘%rom%lib/’ is empty (unless customizing ‘EXTRA_INIT_FILES’). Files in ‘%rom%Resource/Init/’ don’t duplicate filenames in directories installed (or expected to be created/ customized by the installer or the user) on disk, with 2 exceptions: ‘Fontmap’ and ‘cidfmap’. - ‘Fontmap’ is not a problem, because Ghostscript reads ALL ‘Fontmap’s found on the libpath. - However, Ghostscript reads only the 1st ‘cidfmap’ found, so the empty one in ‘%rom%Resource/Init/’ makes inaccessible any ‘cidfmap’ in one of the ‘GS_LIB_DEFAULT’ directories, unless that directory is also part of ‘GS_LIB’. What I suggest is to change the handling of ‘cidfmap’ to be similar to ‘Fontmap’: take into account all files with this name found on the libpath, not only the 1st one. This eliminates the need to set ‘GS_LIB’, and I think it’s a good idea anyway. I’ll attach a patch. About ‘C:\WINDOWS\Fonts’: I don’t really see what’s the purpose of adding this to GS_LIB. ‘Fontmap[.GS]’ does not cite any fonts found there. Font file names in the ‘cidfmap’ generated by the installer use absolute paths. As I understand it, Ghostscript does NOT looks for files that appear to be fonts, to load them, in ‘GS_LIB’, but in ‘GS_FONTPATH’. It does look into GS_LIB for font files, but only files with names matching a requested PS font name, in particular files without a ttf/ ttc/ otf/ pfb extension. So, for the installer, I suggest it not to set ‘GS_LIB’ at all. It’s useful for it to set ‘GS_FONTPATH’ to the Windows fonts directory, so all installed fonts to be directly usable.
Created attachment 5210 [details] Suggested patch: load all cidfmap files found on the libpath. Look for, and load, all files named ‘cidfmap’ found on the libpath, not just the 1st one, similar to what is done for ‘Fontmap’. The empty ‘cidfmap’ in ‘%rom%Resource/Init/’ won’t mask anymore an eventual ‘cidfmap’ found in a directory from ‘GS_LIB_DEFAULT’. Note that handling duplicate keys is not exactly the same as for ‘Fontmap’: - Similar to ‘Fontmap’, a record in a file found later on the libpath overrides a record with the same key found earlier on the libpath. - Different from ‘Fontmap’, if there are 2 records with the same key in the same file, the earlier record takes precedence. This is the existing behavior; for backward compatibility, I didn’t change it.
I'd like Alex to review the patch to the Resource/Init files. I agree that removing C:/Windows/Fonts from the LIBPATH makes sense. It is not going to help at all. As far as setting the default GS_FONTPATH to C:/Windows/Fonts, this is _NOT_ a good idea since users that have LOTS of fonts (like me) will see delays before font substitution is performed for unknown fonts. On my 2GHz laptop with 1,642 font files in that directory, it takes 5 seconds to find 1,337 fonts that GS can use. The problem is both opening and reading a large number of files, AND doing it with PostScript code. What is needed if we want to use the fonts on C:/Windows/Fonts (or ANY GS_FONTPATH with lots of fonts) efficiently is to create a Fontmap when scanning the GS_FONTPATH paths and add this Fontmap to the 'persistent cache', then load the persistent cache Fontmap automatically, and NOT scan the GS_FONTPATH if there is a persistent cache entry created from a a GS_FONTPATH path. Alternatively, we could hook in the 'native font' machinery to Windows so that we would just query the OS about a font's availability, avoiding the GS_FONTPATH scan altogether.
We have written a Windows NT service wrapper around the GS DLL (32 bit version) and a custom, very fast spool-file reader that feed this NT Service. Currently this "system" is running with a custom version of GS 8.64 (re-packed for silent deployment as a MSI package) on approx. 200 Windows 2003 servers in a data center providing a variety of custom PDF creation services for approx. 4000 users in 15 different smaller banks. I developed the NT Service wrapper, the spool-file reader and created the MSI package. A 5-8 seconds delay for caching fonts is not an issue in this environment *IF* true multi-threading was possible *AND* we wasn't forced to close and unload the GS DLL for each job. However, we need to do that since a single error with negative exit code cause havoc and -- in practise -- require GS to be completely refreshed. Hence, if GS has to be loaded for each new job such a delay would be a disaster. I'm willing to invest some time in this issue, so if you need me to test anything I'd be happy to assist. I have a quite qualified Windows test environment handy. Best regards / Med venlig hilsen Jacob Schäffer | Chief Developer Paradis Allé 22, Ramløse DK-3200 Helsinge, Denmark Phone: +45 4439 4400 Email: js@grafikhuset.dk Web: www.grafikhuset.net
I can see that the installer for 8.70 still set a font path in the GS_LIB setting. If the mentioned patches are applied, is there a specific reason to keep it alive? Best regards / Med venlig hilsen Jacob Schäffer | Chief Developer Paradis Allé 22, Ramløse DK-3200 Helsinge, Denmark Phone: +45 4439 4400 Email: js@grafikhuset.dk Web: www.grafikhuset.net
Assigning to Alex to review the patch of comment #6 (the attachment). Note that the GS_LIB_DEFAULT=%rom%Resource macro to the make will defeat any search paths (other than the COMPILE_INITS=1 %rom% files) but the Windows installer may still add some search paths. Since extra search paths where the file doesn't exist don't cause much performance problem, and no other problems that we know of, we aren't likely to change the dwinst.cpp Windows installer.
This particular bug seems to have wandered off the original topic and it is somewhat difficult now for me to figure out what is going on. However, I don't think that the installer has the various problems listed here any more (the bug is now nearly 5 years old). I have several recent versions of GS installed on my Windows PC and I don't have any GS_LIB or GS_LIBPATH environment variables and I can't find any GS_ entries in my registry. I'd like Chris to check this for me though. The thread then goes on to proposing an enhancement to allow multiple cidfmap files. I'm not at all certain this is terribly useful, although as noted it does permit the simple usage of an external cidfmap without setting -I. This is also Chris' area, so I'm going to assign this to him for consideration.
These registry values are no longer set with the change to the nsis installer.