The cidfmap included below causes a failure when loading the fonts like this : /Ryumin-Light /CIDFont findresource The cidfmap file is : /Ryumin-Light << /FileType /TrueType /Path (C:/Windows/Fonts/KozGoPro- Light.otf) /SubfontID 0 /CSI [(Japan1) 2] >> ; /GothicBBB-Medium << /FileType /TrueType /Path (C:/Windows/Fonts/KozGoPro- Medium.otf) /SubfontID 0 /CSI [(Japan1) 2] >> ; The fonts may be found inj attachments 4427, 4428 to bug 689893. Runnin g with -dTTFDEBUG one can see that the fonts don't include a TT data. They include a CFF instead. zbuildfont11 fails in ln 304 due to file_table_pos is not an array.
Passing to Alex because the problem is is Resource/Init/gs_ttf.ps . With this OTF it must create FontType 9 rather than FontType 11.
Bumping the prioority because I believe it is important. Our Support may edit it.
Leo, what would you prefer: extend the cidfmap syntax or auto-detect the font type ?
Well now I see : the cidfmap record requires True Type (i.e. FontType 11) and the font supplies a CID font (font Type 9). The bottom of the problkem is : when the cidfmap syntax was developed there were not TT-like fonts that supply a CFF. I think the right resolution for the test case is to print error message. I think the right way is to specify /FileType /OpenType and then recognize what font type does it supply.
This looks like it should be assigned to the font group.
*** Bug 695989 has been marked as a duplicate of this bug. ***
These fonts still cannot be loaded.