At 07:48 19/09/2017 +0200, Knut Petersen wrote:
I understand why the default behavior of ghostscript changed. But could
anyone who advocates to remove the PDFDontUseFontObjectNum be so kind to
give a clear explanation why keeping it would be a bad idea?
We have, literally, hundreds of command line options. Its hard to remember
them all, let alone keep them all straight, and its quite impossible to
test any significant fraction of them.
Every time we make any change to Ghostscript its possible that we break one
or more pieces of functionality, quite accidentally, simply because we
aren't aware of the existence of that functionality.
As time goes on and we add more and more complexity, the chances that any
given change will break some existing feature rises significantly. It takes
longer for developers who do know of the existence of these features to
make changes, and the changed code runs at a performance penalty because it
needs to do extra checking or employ more complex logic.
Note that we have a query from a commercial customer opened last week about
why the latest version of Ghostscript's PDF interpreter runs more slowly
than two versions back so this is not a theoretical consideration.
So at every release I look for ways to reduce the clutter, discarding
features intended to restore old behaviour in the event of a fault in new
behaviour is an obvious target. Such code is only ever intended to be
temporary, the additional checking of flags in multiple places, and
multiple times in the course of a program does impact performance and its
very likely that such fallback code will get broken, because its *never*
tested.
I have already said I will discuss this with the other developers before
making a final decision. It is, obviously, useful to know that people are
using this behaviour and we will take that into consideration.
In that regard I do welcome the reasoned emails, such as this one, from
additional users. I didn't enjoy the follow up email from the original
reporter; its not like I said 'tough' or anything, I said I would discuss
it internally right from the start.
Ken Sharp
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
