[gs-bugs] [Bug 698731] - Ghostscript - Adobe Distiller can't handle fonts correctly when PS derives from GS 9.22 (ps2write)

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698731

Bug ID: 698731
Summary: Adobe Distiller can't handle fonts correctly when PS
derives from GS 9.22 (ps2write)
Product: Ghostscript
Version: 9.22
Hardware: PC
OS: Windows 7
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: PS Writer
Assignee: ***@artifex.com
Reporter: ***@datev.de
QA Contact: gs-***@ghostscript.com
Word Size: ---

Created attachment 14449
--> http://bugs.ghostscript.com/attachment.cgi?id=14449&action=edit
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.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698731

--- Comment #1 from Reiner Saalfrank <***@datev.de> ---
Created attachment 14450
--> http://bugs.ghostscript.com/attachment.cgi?id=14450&action=edit
PostScript generated with GS 9.22

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698731

--- Comment #2 from Reiner Saalfrank <***@datev.de> ---
Created attachment 14451
--> http://bugs.ghostscript.com/attachment.cgi?id=14451&action=edit
PDF generated by Distiller DC from 2Pages.gs922.ps

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698731

--- Comment #3 from Ken Sharp <***@artifex.com> ---
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.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698731

--- Comment #4 from Reiner Saalfrank <***@datev.de> ---
Yes, You are right.

I used actually the commandline with "-sDEVICE=ps2write".
Sorry for confusion.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698731

Ken Sharp <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Ken Sharp <***@artifex.com> ---
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.