My sample gsbug.eps shows the character "O" in an outline font with PaintType 2 and StrokeWidth 30. I created a PDF by gs -dNOPAUSE -q -dBATCH -dEPSCrop -sDEVICE=pdfwrite -dCompatibilityLevel=1 .4 -sOutputFile=gsbug_54.pdf gsbug.eps The result was o. k. with GS 8.54. The file gsbug_63.pdf was created by GS 8.63. Here the stroke width is only a tenth of the original.
Created attachment 4490 [details] gsbug.eps original EPS
Created attachment 4491 [details] gsbug_54.pdf created by GS 8.54
Created attachment 4492 [details] gsbug_63.pdf created by GS 8.63
Looks like this changed in r8518: r8518 | ken | 2008-02-07 01:33:22 -0800 (Thu, 07 Feb 2008) | 38 lines Fix (pdfwrite): problems with unusual PDF text rendering modes.
Thanks Marcos, I knew what caused it in this case. Its all part of the same issue, text rendering modes which use stroke+fill. The intention is to fix this by preserving it in the graphics state, its on my 'to do' list. This, and a number of related issues, should all be fixed by the same thing.
Some further information: It appears the r8518 change fixed a lot of the nightly regression files. For example in 045-01.ps the characters in the fifth "cshOw" in the first test block shows up as filled in r8517 but as outlined in r8518. Initially I thought that this was a regression, but sending 045-01.ps to an Adobe PostScript laser printer prints the text as an outline. BTW, this change was not picked up on the nightly regressions on peeves. Apparently the checking of pdfwrite on peeves is and has been broken for some time (I discovered this while in the process of moving the nightly regressions to my iMac, which did find the changes).
Hi Marcos, thanks for looking further, in fact I knew the behaviour of these files had changed. The old code basically didn't work with Tr 3 (text render mode 3, stroke + fill), which is why I've been unwilling to unravel rev 8518. I know there are still problems with the code (in fact I hinted at this in the submission log) but its generally better than it was. I do still intend to work on a better fix for this, as soon as I get some time. I'm sorry (to all involved) for the slow response....
I looked at this issue again, and in fact it is not (directly) related to the text rendering mode issue. The Tr is important though , because we have to convert PaintType 0 fonts into regular fonts, but use 'Tr 1'. It turns out the calculation of the StrokeWidth wasn't good enough under some conditions (I have very few test files for this). This should now be fixed in revision 9178: http://ghostscript.com/pipermail/gs-cvs/2008-October/008752.html