Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

Ken Sharp <[email protected]> Tue, 19 Sep 2017 10:33:49 +0100
Newsgroups gmane.comp.printing.ghostscript.devel,gmane.comp.gnu.lilypond.devel
Message-ID <[email protected]>
At 20:38 18/09/2017 +0200, David Kastrup wrote:

> > And if you have multiple subsets, badly named (eg OpenOffice output)
> > then you get a final PDF file where some of the text is missing or
> > garbled.
>
>So?  Nobody forces anybody to use that option.

The point is rather that if you don't use the object numbers, then you get 
incorrect output.


> > And your point is what ?
>
>That we are talking about functionality that is considered useful?

Which is indeed useful information. But that wasn't what was provided, just 
a bunch of links. Knut's later email presented that point of view much 
better (from my point of view) .


>I think "slightly smaller" was something like a factor of 10.  We are
>talking about files including literally thousands if not ten thousands
>of graphics (manuals close to a thousand pages with lots of graphic
>output included).

Which just takes me right back to 'don't create your PDF files like that then'.

If a file of that complexity suffers so much from a superfluity of fonts, 
then you should really do something about not including the entire font 
multiple times.


The 'feature' that everyone is referring to here is not, and never was, a 
feature. It was an unintended consequence of a limitation in the way that 
Ghostscript's PDF interpreter works. In short, you were taking advantage of 
a bug.

That limitation was actually potentially quite severe and could cause 
incorrect output, and if that did occur there was no way to tell without 
closely proof-reading the output.

Given the on-going complaints about that bug we did eventually come up with 
a solution. We were worried that the solution would prove worse than the 
original disease, so we preserved a means to restore the original 
behaviour. Over time it became apparent that the solution is, in fact, robust.

Since we now have an apparently good solution to the problem and that 
preserving the means to restore the old behaviour does add (in however 
small a way) to the complexity of the interpreter, I removed that option.

I've covered this in more detail in my reply to Knut. I also said that I 
welcomed the other replies on the subject. It *is* useful to know that the 
old (flawed) behaviour is important to you all.

Stating this clearly, rather than simply providing a bunch of URLs to pages 
which document how to *use* the flawed implementation, is useful information.

As I have also said a number of times, the old behaviour has a flaw, and 
its entirely possible that you will trip over it, in which case, there is 
no further help we can offer, the solution to that problem is to use the 
current behaviour, which you don't like.

I do feel that creating the pages in this fashion is less than ideal and 
you would probably be well advised to seek a different way of working.



As I have said (repeatedly now) I will discuss this with the other 
developers, and the input (especially from Knut's mail) will be taken into 
account.



             Ken Sharp