In some EPS files, the text is garbled when viewed with Ghostscript, but appears correctly when a PDF is produced by either Ghostscript or Acrobat Distiller.
Created attachment 5511 [details] EPS-with-garbled-text
Created attachment 5512 [details] PDF-with-good-text PDF made with Ghostscript from the EPS with garbled text. Text appears correctly.
Hmm, try opening the 'good' PDF with Acrobat 7 instead of Acrobat 9, the result is identical to the GS result with the original EPS. That is assuming that the complaint is really about the fact that the glyphs are mis-positioned rather than 'garbled' (which suggests the wrong glyphs being rendered to me). I think this may really be Alex's problem, not mine but I'll take a look first, its possible its the matrix of the descendant CIDfont that's wrong or being wrongly applied. I think there's another open issue around for that one somewhere.
Looks like it is indeed the descendant font's FontMatrix, if I modify the descendant font matrix from: /FontMatrix [0.488281 0 0 0.488281 0 0] def To: /FontMatrix [1 0 0 1 0 0] def Then other Rips get the same answer as Ghostscript. This looks to be related to issue #690724, which is also related to CIDFont descendant fonts and their FontMatrix entries (or lack thereof and default substitution).
> That is assuming that the complaint is really about the fact that the glyphs are > mis-positioned rather than 'garbled' Easiest to decide is if the client provides a screenshot - on windows, ALT-PRTSC (the "print-screen" near the top right hand corner of the keyboard) copies the screen of the current application to the clipboard, which can then be pasted into MSWord or one of the accessory imaging apps, PRTSC itself wihout ALT copies the whole desktop.
Created attachment 5561 [details] gs-ignores-fdarrays-fontmatrix.ps Okay, I tried to minimize the PS code and found some weird gs behavior, but I couldn't exactly reproduce the case happening in EPS-with-garbled-text.eps. This CID font (UEQGCC+Helvetica-OV-TEQGCC) has been designed in 2048x2048 space. CID font has a FontMatrix [0.001 0 0 0.001 0 0] and FDArray pseudo font has one of [0.488281 0 0 0.488281 0 0]. I left only CID 0 glyph. It has TrueType-style .notdef char - square or Tofu whatever you call it. This rectangle has (66,0)-(1232,1469) bounding box in character space. A character width is 1298. I observed following problems by running attached file. In this file, the font has been scaled to 204.8 pt, so the CID 0 should have bounding box (0,6.6)-(123.2,146.9) and width of 129.8. - When gs performs glyphshow, it ignores FDArray pseudo font's FontMatrix. The glyph was displayed 2.048 times larger. - Gs ignores FDArray pseudo font's FontMatrix when calculating character width. It always returns about 265.8304, which is 2.048 times larger than what it should be (129.8). EPS-with-garbled-text.eps didn't use glyphshow. Instead, it uses xyshow and the result suggests it is ignoring FDArray pseudo font's FontMatrix somehow. There must be something else also affecting which I didn't see yet. But I believe above behavior has strong connection with this issue.
Created attachment 5578 [details] gs-ignores-fdarrays-fontmatrix2.ps EPS-with-garbled-text.eps was redefining xyshow with cshow. And gs ignores FDArray font's FontMatrix under cshow too. To sum up, I see three problems here. - Gs ignores FDArray font's FontMatrix when painting under glyphshow. - Gs ignores FDArray font's FontMatrix when painting under cshow. - Gs ignores FDArray font's FontMatrix when calculating character width.
There ware two revisions have connections with this issue. Rev. 3247 and rev. 5613. Rev. 3247: Oct 31 2002: Fix: For Type9 fonts (CIDFontType 0 with Type 1 or Type 2 leaf fonts), the leaf's FontMatrix was being ignored. Bug #576591. Rev. 5613: Jan 10 2005: Fix : CDevProc|Metrics|Metrics2 did not work with CIDFontType 0 (continued 2). Bug #687832. I think the rev. 3247 was incomplete, and missed the glyphshow and cshow cases. I think the author of rev. 5613 was misunderstanding CID Font spec, this change led the character width problem. This is my proposal to fix them. Rev. 3247 added the concatenation of FDArray font's FontMatrix at the beginning of the function show_state_setup(). This works if the CIDFont has been using as descendant of composite font with CMap mapping FMapType. However, if the CIDFont itself is the currnetfont, they are not concatenated (font stack (fstack) is not used in this case). This is the case when glyphshow or cshow is running. Fix 1) show_state_setup() needs to concatenate FDArray's FontMatrix when currentfont is a CIDFont. There is one more issue. Rev. 3247 code uses 'penum->fstack.items[penum->fstack.depth].index' as FDArray index, but it is not. It contains always zero, nobody sets it currently. I believe FDArray index can be obtained by calling gs_font_cid0.cidata.glyph_data() with gs_glyph. To make this work: Fix 2) gs_type0_next_char_glyph() must keep track of CIDFont's FDArray index by calling gs_font_cid0.cidata.glyph_data() for each character, and when it has changed, it should return 1 (font change), so that show_proceed() can call show_state_setup() to recalculate FontMatrix. I think it should save FDArray index number in 'fstack.items[fdepth].index', so the current rev. 3247 code can detect it as font change. Fix 3) In addition to Fix 1, show_state_setup() need to call gs_font_cid0.cidata.glyph_data() to get FDArray index to obtain appropriate FontMatrix to concatenate, when the current font is a CIDFont. To tell the truth I hate to call it from here, because calling this function from here and from gs_type0_next_char_glyph() is out of balance. I think we should fix having two currentfont variables ('current_font' and 'fstack', three if we count 'pgs->font') in gs_show_enum, but we may leave it as future enhancement for the moment. The code added by rev. 5613 intentionally cancels FDArray font's FontMatrix in set_char_width(). This is causing the character width problem. Here is a comment left in this function. /* We must not convert advance width with a CID font leaf's FontMatrix, because CDevProc is attached to the CID font rather than to its leaf. But show_state_setup sets CTM with the leaf's matrix. Compensate it here with inverse FontMatrix of the leaf. ( We would like to do without an inverse transform, but we don't like to extend general gs_state or gs_show_enum for this particular reason. ) */ The author's perception is wrong. CDevProc (or Metrics or Metrics2) must be run under FDArray font's FontMatix. If it has problems, I believe that the running context is the one has failure. We must cancel this change but doing this makes bug #687832 back in life. Fix 4) Cancel the change done in rev. 5613 for the function set_char_width(). Fix 5) Re-open the bug #687832 and find appropriate fix. I performed quick partial test for this fixing proposal, with hope of it would fix bug #690724 too, but it didn't. Bug #690724 need to be evaluated further more.
> There is one more issue. Rev. 3247 code uses > 'penum->fstack.items[penum->fstack.depth].index' as > FDArray index, but it is not. It contains always zero, nobody sets it > currently. I'm not sure this is the case. The macro 'select_descendant' directly sets the index member. This macro is called from (and only from) gs_type0_next_char_glyph, which seems to cover your point 2 as well. I'm also reasonably sure I've seen the code in pdfwrite use this index as a trigger for a font change, and seen it work. I do agree that the revision 5613 looks incorrect, and I think you should revert that and then revisit #687832. Is it possible that extending the fix in revision 3247 to cover cshow and glyphshow by concatenating the parent CIDFont's FontMatrix would fix the issue in #687832 ? I haven't looked at these problems in detail, so its possible I'm talking rubbish of course.
> > There is one more issue.  Rev. 3247 code uses > > 'penum->fstack.items[penum->fstack.depth].index' as > > FDArray index, but it is not.  It contains always zero, nobody sets it > > currently.   > > I'm not sure this is the case. The macro 'select_descendant' directly sets the > index member. This macro is called from (and only from) > gs_type0_next_char_glyph, which seems to cover your point 2 as well. I'm also > reasonably sure I've seen the code in pdfwrite use this index as a trigger for a > font change, and seen it work. Oh yes. My explanation wasn't enough. The macro 'select_descendant' sets this index correctly for any composite fonts, but this macro is not called for base fonts. Since CIDFonts are the base fonts, it just keeps its initial valude (0) for them. > Is it possible that extending the fix in revision > 3247 to cover cshow and glyphshow by concatenating the parent CIDFont's > FontMatrix would fix the issue in #687832 ? It may be possible but I wouldn't bet on it.
I was misunderstanding the meaning of 'fstack.items[n].index', and I need to change it to achieve this fix. I am going to discuss it on gs_devel.
Created attachment 5720 [details] b690834_p1.patch I proposed the meaning of 'fstack.items[n].index' in gs-devel in thread '[gs-devel] Proposal for changing semantics of gx_font_stack_item_t::index (bug #690834)', no one expressed opposition. This is a patch to change. Currently, the 'index' member is used to describe a 'font number' of this font in parent composite font. This patch changes it to describe a 'font number' of descendant font. In a short, It moves fstack.items[n].index to fstack.items[n-1].index, to make a room for FDArray index for CIDFonts in fstack.items[fstack.depth].index. Revision 3247 and 5613 already have assumed fstack.items[fstack.depth].index was an FDArray index. This patch does not solve the problem itself, but prepare to solve it.
Created attachment 5721 [details] TestFDArrayMatrix.ps I have never seen CIDFonts that has non-uniform FontMatrices for each FDArray fonts in my life. To ensure that fixed code handles FDArray's FontMatrices right, I wrote a test program. This small PS code defines a CIDFont with four glyphs, CID 0 to 3. Each glyphs belongs to different FDArray font and they have different FontMatrix. CID 0 and 2 draws 1x1 square, 1 and 3 draws same square slanted 12 degrees. Each FDArray fonts' FontMatrices are: FDArray[0] (CID 0) = [1 0 0 1 0 0] FDArray[1] (CID 1) = [1 0 .2126 1 0 0] FDArray[2] (CID 2) = [1 0 0 1 0 -120] FDArray[3] (CID 3) = [1 0 .2126 1 0 -120] I also found that current FDArray FontMatrix concatenation code multiplies it from wrong direction (it should be multiplied from left). I will fix it in comming patch too.
Created attachment 5735 [details] b690834_p3.patch This is a patch to solve this problem. This is a patch I posted in gs-devel ([gs-devel] Need opinions for fixing bug #690834), plus Ken's suggestion. This works as it solves this bug, but also has several minus points. 1) gs_font_cid0.cidata.glyph_data() is called at least twice for each CID. This is inefficient. 2) CID 0 (.notdef) fallback logic is distributed into three functions, one in psi and two in base. 3) Current CID 0 fallback logic does not handle errors correctly. Some errors should be risen immediately before falling back to CID 0. (I didn't do this because I didn't want to distribute complex code three places apart in a system.) 4) Applying this patch makes bug #687832 go back in life. As Ken suggested in gs-devel, No. 1, 2 and 3 can be enhancement for the future, but 4 may open a bunch of headaches in the field. I will not commit this patch until I finish bug #687832.
The patch b690834_p3.patch is committed in rev. 10603. Closing. I will write a test file that combines gs-ignores-fdarrays-fontmatrix2.ps and TestFDArrayMatrix.ps and add it to our test suite.
Created attachment 5867 [details] Bug690834.ps Created a better test file. I would like Marcos to incorporate it in future regression test.
tests_private/comparefiles/Bug690834.ps was created in rev. 3244.
r10603 was incomplete. Please use r10722 (PostScript code fix) and r10973 (Makefile change) together.
Changing customer bugs that have been resolved more than a year ago to closed.