Bug 689038 - GS doesn't display T42 font correctly.
Summary: GS doesn't display T42 font correctly.
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: master
Hardware: PC Linux
: P2 normal
Assignee: leonardo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-08 03:22 UTC by Han-Wen Nienhuys
Modified: 2008-12-19 08:31 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
triggering PS file. (516.55 KB, application/postscript)
2007-01-08 03:23 UTC, Han-Wen Nienhuys
Details
DejaVuLGCSansMono font, from FC6 (137.04 KB, application/x-tar)
2007-01-08 03:24 UTC, Han-Wen Nienhuys
Details
patch.txt (4.03 KB, patch)
2007-04-24 11:24 UTC, leonardo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Han-Wen Nienhuys 2007-01-08 03:22:57 UTC
Hi,

See the attached file y.ps. It contains DejaVuLGCSansMono.ttf (attached, stock
fedora core 6), embedded as a type42 font.  Rendering it with GS 8.55 and HEAD
shows an exclamation mark at each space.  This is a regression, as 8.15 did
render correctly.  It looks like  an off-by one, since exclam is next to space
in the TTF font.


For some more background, see  lilypond bug #224, 

http://code.google.com/p/lilypond/issues/detail?id=224&can=2&q=
Comment 1 Han-Wen Nienhuys 2007-01-08 03:23:33 UTC
Created attachment 2670 [details]
triggering PS file.
Comment 2 Han-Wen Nienhuys 2007-01-08 03:24:18 UTC
Created attachment 2671 [details]
DejaVuLGCSansMono font, from FC6
Comment 3 Han-Wen Nienhuys 2007-01-08 03:27:24 UTC
this bug was triggered in GS rev 7581
Comment 4 Marcos H. Woehrmann 2007-01-08 20:32:02 UTC
A quick test shows that this file worked up until r5707 at which point a change made by Ray in lib/
gs_ttf.ps to sort the 'loca' table causes gs to crash.  Later revisions fix the crash, but cause the file to be 
rendered incorrectly.
Comment 5 SaGS 2007-01-09 05:14:55 UTC
Please see bug #688971 comment #7 point (F) for an explanation, and the patch 
attached there for the fix. Although not directly related to the performance 
problem mentioned in that report, I noticed and fixed the defect reported here 
because it appeared in some part of the code I needed to modify.
Comment 6 leonardo 2007-04-23 16:30:11 UTC
Regarding to Comment #7 :

I believe that the suggested patch was never tested with the test case of this 
bug. It fails with invalidfont, because the glyph index 57 points to a 4-
bytes 'loca' element, which is broken in 'sfnts' array into 2 parts. Revisions 
before 7877 do not fail, rather they perform some wrong computations with 
considering gs_error_invalidfont as a glyph offset. They occasionally produce a 
good rendering because the glyph index 57 is not used in the document.
Comment 7 leonardo 2007-04-23 16:30:47 UTC
Sorry I meant Comment #5.
Comment 8 leonardo 2007-04-23 17:29:14 UTC
I was wrong when saying that the suggested patch was not tested with this bug. 
The revision 7877 fails because I inserted 

+	if (psortary[loca_size - 1].glyph_offset > glyph_size)
+	    return_error(gs_error_invalidfont);

into the suggested patch F. It could succeed without this insertion (rather 
some computations are still wrong and the success is occasional). Thus I 
withdrow my remark about "never tested". Sorry for being puzzled with so many 
wrong patches (see  bug #688971).
Comment 9 SaGS 2007-04-24 03:00:35 UTC
I did check the sample at the time I posted comment #5, and I checked it again 
now. TRUNK rev 7872 displays "!" instead of space, as reported. TRUNK rev 
7872 + my attachment #2913 [details] (bug #688971 (E)) + my patch for bug #688971 (F) 
(essentially from attachment #2878 [details]) fixes the issue. Command line 
was "gswin32c infile.ps". In this situation, I don't see the purpose of 
comment #6 .. #8.

True, more work may be needed to handle Type 42 fonts with unsorted 'loca', 
(see bug # 688971 comment #35, paragraph starting with "The objection is 
invalid. gstype42.c ..."). But that's not strictly connected to 
substituting " " -> "!".
Comment 10 leonardo 2007-04-24 10:08:49 UTC
Regarding Comment #9 : rather the suggested patch allows to ge a correct 
rendering, it doesn't provide a correct algorithm, and doesn't fix the real 
reason for the wrong behavior. The real reason is a 4-bytes loca element broken 
into 2 parts in sfnts. With the broken element the function get_glyph_offset 
returns gs_error_invalidfont, which then is misinterpreted as a huge glyph 
index, which then misinterpreted as an unsorted loca. The SaGS's patch is not 
related to this problem. Instead that the patch hides the problem for a 
particular test case. One can easy create another test case, which gives 
VMerror with the patch applied. Therefore it can't be accepted as a fix for 
this bug. 
Comment 11 leonardo 2007-04-24 11:24:49 UTC
Created attachment 2918 [details]
patch.txt

A patch being tested.
Comment 12 leonardo 2007-04-24 21:12:27 UTC
Fixed with rev 7881.
Patch to HEAD :
http://ghostscript.com/pipermail/gs-cvs/2007-April/007464.html
Comment 13 Werner Lemberg 2007-04-25 21:52:15 UTC
You write in

  http://ghostscript.com/pipermail/gs-cvs/2007-April/007464.html


> The Type 42 specification reads that 'sfnts' strings must not break TT tables.
> Exactly, "the strings must begin at TrueType table boundaries, or
> at individual glyph boundaries within the glyf table".
> However the test case is another example when a 3d party software 
> "LilyPond 2.11.10" doesn't follow this constraint. 

I don't understand this.  lilypond has packed the *whole* font into a single
\sfnts string (in the triggering PS file attached to this bug report)!  How
can thus lilypond violate this constraint?  In case the problem is really
related to the code generated by lilypond, please advise how to improve.

Comment 14 leonardo 2007-04-26 12:09:59 UTC
Regarding Copmment #13 : 

It reads :

[beg quote]
lilypond has packed the *whole* font into a single \sfnts string (in the 
triggering PS file attached to this bug report)!
[end quote]

This statement is wrong. To prove that please open the attached file with a 
plain text editor and search for '>'. There are 4 occurances inside sfnts array 
at lines 1848, 3669, 5490, 7404. Thus sfnts array includes 4 strings.
Comment 15 Werner Lemberg 2007-04-26 12:42:27 UTC
Oops!  I was confused apparently :-)