lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1


From: Ken Sharp
Subject: Re: Ghostscript/GhostPDL 9.22 Release Candidate 1
Date: Tue, 19 Sep 2017 10:33:49 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]