The attached file all exhibit differences between the Ghostscript font renderer (r11070) and FreeType (r11073). For each file I will attach the original file and a screen shot that compares the output from r11070, r11073, and Adobe Acrobat 9.3.2, in that order. Unless otherwise noted the Ghostscript files were processed with the command line: bin/gs -sDEVICE=ppmraw -r300 -o test.ppm ./input.ps_or_pdf
Bug687698.ps looks like missing TTF hinting. At the moment the Freetype code in our SVN is the default configuration with only a "minimal" bytecode interpreter enabled (avoiding the patent contentious operations) - this is even more hobbled than the equivalent code in the GS internal TTF code. I'll confirm this for sure tomorrow, but this one should be resolved when we enable the full bytecode hinting. The really visible differences in Bug689757.pdf are probably due to using the TTF notdef, rather than the Postscript one. The others will need a bit more investigation.
bug687044.ps works Ok when compared to Ghostscript as a PostScript file. I notice that the PNG is actually Bug687044.ps.pdf so I assume this is because the PostScript file has been converted to PDF, and then the comparison is against the PDF file. I suspect that somehow different outlines are being generated for the stroke and fill here. Could you post the PDF file please ?
As I thought, Bug687698.ps is the missing TTF hinting in the currently committed Freetype code. In fact, all but Bug689757.pdf and 067a_unc-stroke.pdf seem to due to the missing hinting. Which raises the question: do we enable the TTF byte code interpreter in our SVN copy of FT, or do we stick to the original plan, and wait for Werner to do so in the official FT repos? Bug689757.pdf is using the TTF notdef (hollow rectangle) rather than the PS notdef (non-marking). 067a_unc-stroke.pdf is a little odd: but both Ken and I reckon the font has been naively converted from fill-only outlines, to strokes outlines, and that always has unpredictable results.
(In reply to comment #16) > bug687044.ps works Ok when compared to Ghostscript as a PostScript file. > > I notice that the PNG is actually Bug687044.ps.pdf so I assume this is because > the PostScript file has been converted to PDF, and then the comparison is > against the PDF file. > > I suspect that somehow different outlines are being generated for the stroke > and fill here. Could you post the PDF file please ? The instructions for generating the PDF are given in Comment #15:
Bug689970.pdf is interesting. The misshapen glyphs are the usual TrueType hinting I believe, certainly they look better (U, n, h) in the hinted version. The dots are actual glyphs in the original PDF file. They don't seem to be /.notdef and they are present in the hinted version as well, so this bears some investigation. Bug 688372 the font(s) are missing, several multi-byte fonts in fact. These are substituted with Courier and the encoding is obviously slightly different. Given that failing to include the relevant Far Eastern fonts is going to produce incorrect output (which is why the HEAD doesn't match the Acrobat display either of course) I don't think its worth worrying about exactly how the output is incorrect. Bug688807.pdf the outlines are separately drawn from the text, and are drawn as paths. You can see a similar effect as you zoom in and out in Acrobat, the black outlines jump around with respect to the fills. I thought I'd fixed type1-ce1_setcurrentpoint, and I thought that it had been adopted in FreeType. Need to check this one again. zero-length-font.pdf is interesting and looks like a problem (though what you get if you include a zero length font is somewhat debatable). However we substitute for Helvetica, its odd that some of the text goes AWOL. test-setweightvector.ps the capital M is too wide, other than that the rendering matches the Acrobat output at 300 dpi more closely than HEAD. Need to see why the M is rendered too wide. I suspect Multiple Master fonts may not be well tested with FreeType. GS_stroke_error.pdf is a real problem, and its clearly been a problem for GS in the past (which is why we have the file). The tick (check mark to Americans) is in a font described as type 1, but named MSTT... which suggests it is, or was a TrueType font. I haven't tested the files that require conversion to PDF with pdfwrite before rendering, yet.
revision 11124 should fix the problems with type1-ce1_setcurrentpoint.ps
revision 11220 should address the problem with zero-length-font.pdf which was a combination of procedures instead of CharStrings in a type 1 font, and a value not being restored after being overwritten as part of SEAC handling.
revision 11232 is believed to sole the problem of crashing/non-deterministic behaviour with shadowtext.eps. The rendering behaviour is due to the way the file is constructed, and the pdfwrite output, not really a FreeType issue. The original file is a Quark document which uses the Quark Q font to achieve the drop shadow effect. This works by constructing a type 3 font which draws the type 1 glyphs multiple times, sometimes with fill and sometimes with stroke. pdfwrite ends up creating this as a type 3 font which strokes a path, and a type 1 font. The problem is that the path and the filled text are not precisely the same (because the path was generated from the stroked text and different interpreters get different results). This is also exacerbated by resolution, which can lead to small positional differences. For me rendering the file at higher resolution minimises or removes the effect. If this is a problem its really a pdfwrite issue, but I think it would take significant effort to improve this.
I think I'm going to have to move on to other things. Here's a summary of my findings: bug687698.ps - TT hinting bug687812.ps - TT hinting bug687901.ps - TT hinting bug689757.pdf - Use of real TT /.notdef. 067a_unc-stroke.pdf - filled font converted to stroked. bug688372.ps - fonts missing, not incorrect. bug688807.pdf - similar to shadowtext, the outlines are separately drawn, same effect observed in Acrobat. type1-ce1_setcurrentpoint.ps - fixed in revision 11124 zero-length-font.pdf - fixed in revision 11220 ShadowText.eps - not incorrect, caused by t3 font conversion bug687044.ps (convert to PDF) - Quark T3 font problem, could be pdfwrite bug688796a.eps (convert to PDF) - Quark T3 font problem. Both the preceding PDF files do not display 'correctly' in Acrobat 9, so there is obviously some problem with the pdfwrite output. bug687845.ps (convert to PDF) - bug689970.pdf - GS_Stroke_error.pdf - These three seem to be genuine problems.
bug689757.pdf (and several other "notdef" uses) fixed in revision 11364. The FAPI code will now honour the -dRENDERTTNOTDEF parameter.
bug687845.ps (convert to PDF) - given that rendering the PS directly produces reasonable results, and the pdfwrite output displays incorrectly in every other interpreter, I suggest this is another issue with FAPI showing up a pdfwrite problem.
bug689970.pdf and GS_Stroke_error.pdf (along with a number of other regression tests) are resolved with revision: 11365
The remaining issues are specific to pdfwrite, so now have their own bug: 691383 The non-pdfwrite issues are all resolved as of revision 11365.