Currently cidfmap allows users to specify a path to font files when we use a TrueType font for substitution. However, regular CIDFonts are technically only found if they are in Resource/CIDFont. This is a limitation, especially when the resources are built into the rom file system, as they are by default. It would be better if a custom cidfmap could point to disk files which contain CIDFonts, just as fontmap.GS can. Note! The limitation above is less severe than it first appears. It transpires that, when searching for resources (CIDFotns at least) Ghostscript also searches any paths specified with -I. So if we specify a -I/custom as a location for our cidfmap, then GS will also look for CIDFonts in /custom/CIDFont. We believe this is also the case for other resource types. Since we must use -I to include the custom cidfmap this makes it comparatively easy to install the CIDFonts. However it does potentially lead to multiple copies of the font so it would still be better to be able to specify a path for the font file.
Added the customer information and set the priority. The customer is wondering if we have an eta for this issue.
(In reply to comment #1) > Added the customer information and set the priority. The customer is wondering > if we have an eta for this issue. This isn't a customer bug. As far as I'm aware we supplied a solution to the customer, they need to use the -I switch. While investigating the issue I noted that while TrueType fonts referenced from the cidfmap file can be given a path and filename, real CIDFonts cannot and must be present in %resource%CIDFonts. This seems an unreasonable limitation, and allowing the option of a path name seems like a useful addition, so this is a future enhancement. As such there is no ETA for it, no. I've cleared the customer field and returned the importance to P4. If the customer still has a problem we should investigate that.
This is a customer bug, for customer. I'm not sure if Chris is the correct person for this, but the customer issue is thus: The customer is using COMPILE_INIT=1 with the 9.04 release. There are no CIDFont fonts in the %rom%Resource/CIDFont directory. Prior to using COMPILE_INITS=1, if their customers (the end users) wanted to add CIDFonts, they would be told to put them in the disk based Resource/CIDFont directory. These would then be usable for PostScript and PDF applications. The fonts are NOT TT fonts, and are not 'normal' fonts, so the CIDFont loading machinery only searches the single path given by the GenericResourceDir concatenated with the string "CIDFont/" for the font requested by findresource. The -I switch doesn't help as this can be used to establish LIBPATH paths, and may cause a different GenericResourceDir to be assigned, but then ALL of the other Resource categories will be searched for there (such as CMap files) and unless the ENTIRE set of files in all of the Resource categories are copied there. Otherwise the other Resources will not be found. What is needed is one of: 1) A solution specific to CIDFonts -- such as allowing a string to set the path for a particular CIDFont, e.g., /WadaGo-Bold (c:/Resource/CIDFont/WadaGo-Bold) ; This is similar to what is allowed in the Fontmap. or 2) A mechanism to allow more than a single directory to be searched for the Resources. Previous proposals have been to allow a list of paths with some separator as with the -I switch (a character appropriate for the operating system (":" on Unix systems, "," on VMS systems, and ";" on MS Windows systems). This latter approach would require that the subdirectory be named CIDFont, but would also allow the ADDITION of other Resource categories such as CMap, ColorSpace, Enciding, etc.
OK, I've gotten to the bottom of why my testing didn't agree with Ken's. IF the first -I path of the options contains the string 'Resource', then the logic (which probably should be fixed) will set the default GenericResourceDir to the portion of the path up to the end of the string Resource with a trailing '/'. Examples are: default GenericResourceDir -Ic:/mypath/Resource c:/mypath/Resource/ -Ic:/mypath/Resourcex c:/mypath/Resource/ -Ic:/mypath/Resourcex/CIDFont c:/mypath/Resource/ -Ic:/mypath/xResourcex c:/mypath/xResource/ Quite strange. It comes under the category of 'workaround' of this peculiar bahavior, but all one has to do is avoid the string 'Resource' anywhwere in the first path on the LIBPATH list (the first -I option) -OR- specifically set the Resource directory using -sGenericResourceDir=___ (with COMPILE_INITS=1 this should be -sGenericResourceDir=%rom%Resource/ Then the GenericResourceDir doesn't get messed up, AND the CIDFonts on the -I path _will_ get searched for the the CIDFont of the given name.
Ken thinks that the approach (1) (allowing paths for cidfonts would still be nice, so re-opening as P4 enh (no longer a customer issue). The modification in gs_cidcm.ps is probably not too hard to detect 'stringtype' records and then use that string as the path / filename similar to what the Fontmap logic allows. I agree this *would be nice*.
Implemented in: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=16aebf