Created attachment 14449 [details] PDF consisting 2 pages When the file 2Pages.pdf is converted to PS (ps2write), Adobe Distiller 11/DC produces output which looks not correct. The error can be seen on the second page (2Pages.gs922.pdf). GS9.22 was called like: gs -sDEVICE=eps2write -sOutputFile=2Pages.gs922.ps 2Pages.pdf Adobe Distiller handles PS output deriving from GS 9.21 correctly.
Created attachment 14450 [details] PostScript generated with GS 9.22
Created attachment 14451 [details] PDF generated by Distiller DC from 2Pages.gs922.ps
You can't be using the supplied command line (comment #0). eps2write produces EPS files, and EPS files cannot be multi-page. It looks to me like you are producing PostScript files using ps2write. I'm not at all certain that I see evidence for a bug in ps2write here. Certainly a change in behaviour, but it looks rather more like it exposes a bug in Distiller, than our bug. The PostScript file can be converted back to a correct PDF file by Ghostscript, and it renders correctly using both Ghostscript and another PostScript interpreter. Looking at the output from the two PostScript files (9.21 and 9.22), Distiller has for some reason re-encoded the text, and used a different spacing scheme, eg: [(rstellung der E)136.8(ahresJerbrauchsabrechnungen v)-45.9(017 wird 2)228(h)0(r Wasserzähler und sI)-228.1(fern JI)-228.1(rhanden 2)228(h)0(r o)- previously: (für die Erstellung der Jahresverbrauchsabrechnungen 2017 wird Ihr Wasserzähler und sofern vorhanden Ihr Nebenzähler durch )Tj The text in the original PostScript files is the same for both pages, and both versions of Ghostscript. Looks to me like Distiller is trying some kind of optimisation or something, deciding the two fonts are identical or something. In any event its making an incorrect decision. I'll look into it when I have time, but right now this looks rather more like an Adobe bug than ours.
Yes, You are right. I used actually the commandline with "-sDEVICE=ps2write". Sorry for confusion.
The change in behaviour is caused by this commit : 6cae884b66944318c34e17992c628a246dda18aa Which was implemented due to your previous bug report : https://bugs.ghostscript.com/show_bug.cgi?id=697376 While I can understand that Adobe Acrobat Distiller might emit a differently spaced output string when the horizontal metrics are created by us (instead of copied from the original font) I cannot see any justification for altering the character codes in the second string, especially since we are now copying the original metrics. Ghostscritp produces a perfectly acceptable PDF file from our output PostScritp file, as does another PDF 'distiller' from a manufacturer using a different code base from both Ghostscript and Adobe. The PostScript works properly when rendered by three different PostScript interpreters. It does also seem rather strange to be taking a PDF, producing PostScript and then re-creating a PDF file. Not only is that inefficient, it is likely to introduce errors and a loss of quality, since PostScript cannot represent fully the PDF imaging model. In short, I can't see anything here to indicate a bug in Ghostscript's output rather than Adobe's Distiller, so I'm closing this. If you can find a real reason why Distiller is doing this I might attempt to address it, but likely the only long term solution is to the TrueType subsetting code rewrite which has been on my TODO list for a very long time.
In the meantime we have answer from Adobe. >> Looks to me like Distiller is trying some kind of optimisation or something, deciding the two fonts are identical or something. In any event its making an incorrect decision. You are right. Optimization of type42 fonts is done by Adobe (Distiller) when checksums of the cmap tables are equal ! This heuristic procedure is founded of performance reasons. In our case the checksums always are 0x00000000. Hence Distiller interprets 0x00000000 as a valid checksum, it puts fonts together - wrong decision. Unfortunately there is no distiller option in order to deactivate the type42 optimisation. >> If you can find a real reason why Distiller is doing this I might attempt to address it, ... So, is it possible to assign computed checksums to the tables of type42 fonts in order to achive the advantages of optimized fonts ?
(In reply to Reiner Saalfrank from comment #6) > Optimization of type42 fonts is done by Adobe (Distiller) when checksums of > the cmap tables are equal ! > This heuristic procedure is founded of performance reasons. > In our case the checksums always are 0x00000000. Hence Distiller interprets > 0x00000000 as a valid checksum, it puts fonts together - wrong decision. > > Unfortunately there is no distiller option in order to deactivate the type42 > optimisation. Well, seems to me that's a bug in Distiller, you should probably report it to Adobe as such. > >> If you can find a real reason why Distiller is doing this I might attempt to address it, ... > So, is it possible to assign computed checksums to the tables of type42 > fonts in order to achive the advantages of optimized fonts ? Possible ? Yes, but it will have to wait until I have the free time to rewrite the TrueType font embedding code, which won't be any time soon. Since this isn't an actual bug in what we are doing, I'm moving this to an enhancement. When I get round to rewriting the TrueType code this should serve as a reminder. You can, of course, produce a sensible PDF file by sending the PostScript to Ghostscript and the pdfwrite device.
Created attachment 20409 [details] PostScript generated with GS 9.54 There are some changes in generated fonts and pages are now enclosed in save-restore. Reiner, please check this file.
(In reply to Peter Cherepanov from comment #8) > Created attachment 20409 [details] > PostScript generated with GS 9.54 > > There are some changes in generated fonts But we still don't generate checksums for the tables Distiller wants us to, so this will not affect the problem. > and pages are now enclosed in > save-restore. Reiner, please check this file. Since its the font that's the problem, this won't have any effect either. I know what the problem is, I know how to fix it, but its part of rewriting the TrueType font emission code, which is a long term project currently not being worked on.
Created attachment 20416 [details] PDF generated by Distiller 2017 from gs954.ps
I tried to distill gs954.ps with Acrobat 2017 (V 17.*) and Acrobat DC (V 20.*). Both versions were able to create pdf with seems to be ok. May be, it will result in pdf with unoptimized fonts, but created layout is correct. By the way: I wish you a happy new year.