Originally reported by: mencious@users.sourceforge.net We are making Quark's exported EPS file conversion Software. But There are many problems with CID fonts on Ghostscript PS interperter. The CID font type characters are disappeared when this characters are applied Quark's virtual BOLD or OUTLINE font effect. Maybe,This bug is caused from CID(FontType=9) and custom fonts(FontType=0) conversion confliction. Quark's exported EPS files have custom fonts for virtual font property(Bold,outline, etc.). For testing this situation I have attached testing file. 4 eps files : TestEnglishNormalFonts.eps TestEnglishVirtualBoldFonts.eps TestKoreanNormalFonts.eps TestKoreanVirtualBoldFonts.eps CMAP file : CMAP.zip CID font : Munhwa-Bold
Comment originally by mencious@users.sourceforge.net Logged In: YES user_id=658548 You can download testing file from http://www.officero.com/testb.zip
Comment originally by jackiem@users.sourceforge.net Logged In: YES user_id=206537 I'm not sure what version of Ghostscript you are using or how you are processing the file. Running the files through the display device, each one shows a big "OK" at the top. I didn't get an error on any of the four eps files. Perhaps you can send a PNG of what they are supposed to look like? Could you let us know the commandline you are using to process the files, and what version of Ghostscript you are using? I tested with gs8.00.
Comment originally by mencious@users.sourceforge.net Logged In: YES user_id=658548 All versions of Ghostscript have this bug. And, This bug is occurred just when CID font is used together with Quark EPS file. When this bug is occurred then any text in eps are disappeared. If you add font "Munhwa-Bold" and CMAP files on your GS folder then Ghostscript interpreter(any version) do not draw any text in "TestKoreanVirtualBoldFonts.eps", You can not see "OK"(bold type)
Comment originally by mpsuzuki@users.sourceforge.net Logged In: YES user_id=153564 Possibly what I say is no more than a repeat of your first report, sorry. I think boldizer of Quark assumes that Korean fonts are provided as OCF (FontType == 0 && FMapType < 9).In fact, Acrobat Distiller (I installed Munhwa-Bold manually) provides Munhwa-Bold-KSCpc-EUC-H as FMapType 6 OCF (although installed resources are CMap and CIDFont), and bolden "OK" was shown. Within a few days, I will report if I use Ghostscript with Korean font in OCF format, how the rendering goes. However, I'm afraid that pdfwriter will be confused by OCF font. Regards mpsuzuki
Comment originally by mpsuzuki@users.sourceforge.net Logged In: YES user_id=153564 Again nothing more than your first report, sorry. When I use real OCF (collecting Type1 fonts), the Quark's boldizer works well, but doesn't work with CIDFonts even if it's wrapped in OCF format. The boldizer defines /BuildChar procedure which prints 4 times (with small offsets) per "character": aslike O, O, O, O, and, K, K, K, K. If the boldizer finds composite font, it decompose it until non-composite font (e.g., Type1 for real OCF, Type9 for CMapped-CIDFont), and defines /BuildChar into atomic base fonts. So, boldized CIDFont has /BuildChar in descendant Type9 font. This /BuildChar receives the character by stringtype object with 1-byte length. But Ghostscript expects Type9 font is rendered by /BuildGlyph procedure receiving the character by intergertype object (of CID). By this inconsistency, Ghostscript thinks "unrecognizable string is passed to Type9 font, i have to render by CID=0". I will check more about the usage of /BuildChar and /BuildGlyph, and how Distiller does. Regards, mpsuzuki
Comment originally by mpsuzuki@users.sourceforge.net Logged In: YES user_id=153564 strangely, Distiller can render bolden "OK" even if /Munhwa- Bold-KSCpc-EUC-H is defined as CMapped-CIDFont. now i think Distiller (and other Adobe PS renderers too?) provides undocumented OCF emulation feature to work with such PS data. In attached debug_TestKoreanVirtualBoldFont.ps, i define Type9-Munhwa-Bold-KSCpc-EUC-H without OCF emulation, and inserted a few hooks to trace show, stringwidth, charpath operators. Distiller passes ascii string (OK, or, O, or K) to these operators when the current font is not-yet-CMapped FontType9. According to PostScript spec., bare FontType9 CIDFont has no info to decode strings to CID numbers, so charpath, stringwidth, show should fail. But, Distiller executes such operations successfully. If I comment out operation that should fails, Distiller draws nothing - aslike Ghostscript. However, yet i could not write minimum example - successful operation of string with bare CIDFont is not always.
Created attachment 77 [details] testb.zip
I confirm ther problem with TestKoreanVirtualBoldFonts.eps with gs8_13 and CVS HEAD with display device, only when the CID font Munhwa-Bold and a CMap KSCpc- EUC-H are added to Resource - it doesn't dosplay the text "OK". Other tests do display "OK". I didn't test other GS versions.
Created attachment 754 [details] TestKoreanVirtualBoldFonts-.eps Attaching a modified test, which I used to compare the behavior of GS and CPSI. First I can see that the value of the variable z7 appears different. made it same with inserting PaintType 0 into the CID font definition. Proabbly Adobe inserts it when loading the CID font, but need to check for sure. /BuildChar was patched with "pop 5 % mlc" but it appears not longer important after adding PaintType. The 5th procedure in bcar was patched to understand what happens in there. I can see that it applies 'show' to a CID font. never know that it is allowed, and trying to run a special test with CPSI got a failure. However it appears running with no failure if the CID font is same as a subfont of a "surrounding" 'show'. The difference is that in this case CPSI does paint glyphs, and GS does not. Replacing the CID font with Courier got glyphs painted. However I'm unclear how CPSI decodes char codes to CIDs in this case. From all above I conclude that OCF compatibility isn't relevant.
Created attachment 758 [details] An experimental patch The attached experimental patch correctly paints the original TestKoreanVirtualBoldFonts.eps . However I don't know what Adobe manual allows it and how to build the encoding properly. I don't think that this patch to be applied as it is, bacause it modifies the font. It only defines a compatible logics.
I close this bug with "WONTFIX", since we have no idea how to fix it correctly. Since noone could bring an useful info in 2 years, the problem doesn't look practical.
Reopen bug since the customer bug 687845 looks as a similar problem. In that case the document is generated with PScript5.dll Version 5.2.2 .
Well, at last I found that behavior in PLRM3 section 5.11 page 389 : Under special conditions, a CID can be used when the descendant is a Type 3 base font. The font’s BuildGlyph or BuildChar procedure is invoked to render a character whose code is the last byte originally extracted from the show string. If this procedure executes setfont to establish a CIDFont as the current font and then executes a show operation on a string consisting of just that character code, the code is ignored; instead, the CID determined by the earlier CMap mapping is used to look up the glyph in the CIDFont. This special case exists for compatibility with applications that substitute Type 3 fonts for base fonts in a composite font hierarchy to achieve certain special effects.
See also the bug 687875.
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2004-December/005135.html Patch to GS_8_1X : http://ghostscript.com/pipermail/gs-cvs/2004-December/005136.html
*** Bug 687845 has been marked as a duplicate of this bug. ***
*** Bug 687847 has been marked as a duplicate of this bug. ***