[Top][All Lists]

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

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

From: David Kastrup
Subject: Re: Ghostscript/GhostPDL 9.22 Release Candidate 1
Date: Fri, 22 Sep 2017 10:23:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Ken Sharp <address@hidden> writes:

> At 00:41 22/09/2017 +0200, David Kastrup wrote:
>> > Or, even so, should we take other methods (e.g. using non-embedded PDFs)?
>>If we figure out a working alternative, we should take it.  The current
>>set of Ghostscript bugs in 9.22 is still a bit in flux, so it's not
>>clear yet which alternative actually could work.
>>Is that a reasonable summary of the current state, Ken?
> I'd say so, yes. I can't think of a reasonable alternative right at
> the moment, which will yield the same or at least similar output file
> size.


> I've no idea why they aren't fully embedded but I'd have to guess its
> because they are CFF outlines, we don't see a lot of those. So it
> smells like a bug. I will look at it, as soon as I get some time, but
> its not likely to be a change we'll put into 9.22 given the state of
> the release cycle. In fact, realistically, its unlikely I'll even get
> the time to look at it before the release is complete.

If it's a conceivable part of a good longterm strategy: I think our
fonts are generated via Fontforge starting with a METAFONT (or
METAPOST?) font description, so it's conceivable that if other font
formats would generally be better supported by toolchains in general
that we could possibly tell Fontforge to generate other formats.

I have very little clue of what is involved here, and circumnavigating a
possibly temporary Ghostscript bug alone would likely not be enough of
an incentive for investing that work.  It would really depend on the
quality of general support (mostly in the Free Software world) that we
could count on whether format/technology changes make sense here.

David Kastrup

reply via email to

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