Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[David Kastrup]

Ken Sharp <address@hidden> writes:

> At 07:01 22/09/2017 +0900, Masamichi Hosoda wrote:
>
>>If there is a full font embedded (non-subset) PDF,
>>does the bigpdfs trick work effectively?
>
> Its still, in my opinion, a risky thing to do. However, if the font
> were fully embedded, you wouldn't need to use Ghostscript and the
> PDFDontUseFontObjectNum bug approach (which is the risky part).

Well, if we could delay the embedding, I'd not be particularly sad:
"make doc" currently(?) eats up more than 3Gb which is sort of
ridiculous.  The intermediate PDFs for lilypond-book are arranged in
some "database" and not really externalized, so if they don't work on
their own, this isn't a showstopper.  Generating the images is usually
done by a limited number of LilyPond jobs (depending on the number of
processors available), each of them converting hundreds of input files
into corresponding PDF files.  It would be conceivable to at least keep
some sort of font identifier consistent in a single job.  Embedding a
font 10 times (for 10 graphics-generating jobs) seems at least better
than embedding it hundreds of times.

At any rate, any such strategy could not be implemented and tested in
short time, so if in the mean time the font merging expedient would stay
available for some time, it would make things a lot smoother for us.

> The Font and FontDescriptor dictionaries might not be possible to
> remove, so the effect wouldn't be quite as good as the current
> approach, but these dictionaries run to a few tens or at most a few
> hundred bytes. The FontFile streams are where most of the space is
> going, and those would be possible to remove, if they were truly
> duplicates.

We are not really striving for "optimum" rather than "better than awful"
regarding the resulting file sizes.  This seems like being close enough.

-- 
David Kastrup