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=
Created attachment 2670 [details] triggering PS file.
Created attachment 2671 [details] DejaVuLGCSansMono font, from FC6
this bug was triggered in GS rev 7581
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.
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.
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.
Sorry I meant Comment #5.
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).
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 " " -> "!".
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.
Created attachment 2918 [details] patch.txt A patch being tested.
Fixed with rev 7881. Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2007-April/007464.html
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.
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.
Oops! I was confused apparently :-)