[Top][All Lists]

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

Re: [gs-devel] Ghostscript/GhostPDL 9.22 Release Candidate 1

From: Ken Sharp
Subject: Re: [gs-devel] Ghostscript/GhostPDL 9.22 Release Candidate 1
Date: Tue, 19 Sep 2017 09:54:58 +0100

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

reply via email to

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