[Top][All Lists]

[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 17:25:33 +0100

At 17:35 19/09/2017 +0200, David Kastrup wrote:

TeX is designed for the problem of creating documents and all current
TeX engines offer ways of including externally created inclusions in a
graphic format.  And Ghostscript, far from being a general purpose
program, is designed for executing PostScript code and producing
printable renditions, even if its PDF writer has been created quite
later than its original PostScript interpreting core.

Yes, but as you pointed out previously, PostScript *is* a programming language, and while its primarily aimed at producing printed output, you don't have to use it that way. It is an interpreter for a general-purpose language.

You can even write typesetting packages in it, I've seen them <shudder>

Which makes it pretty general to my mind. And indeed, if you want to, you could write the tool I described in PostScript. I think it would be an exercise for a masochist, and I certainly don't plan to, but its possible.

> Assuming that you are using TeX throughout for your documentation,
> then it seems to me that you should be creating your final document by
> appending the various TeX documents together and then producing a
> final PDF, instead of appending multiple PDF files.

This is a misconception of our document creation process.

Well, that's hardly surprising, since I have no experience of it. :-)

  There is only
a single TeX document (actually a Texinfo document), but interspersed
with the main text it includes example output from several thousands of
individual LilyPond runs.  LilyPond's current native output format for
this purpose is PostScript which is converted to PDF using pdftops
(namely, Ghostscript).  Those PDF files are inserted into the final PDF
file while it is being generated by a TeX engine from the Texinfo input.

But the Lilypond output can't be where the multiple fonts are coming from (unless things have changed) because Lilypond doesn't have this problem. It has other problems but not that one. Perhaps I'm still misunderstanding, I thought the problem was PDF documents produced from TeX.

So you could use EPS instead, or just stick with PDF.

> Presumably you want to show some parts of Lilypond as well,

Not "as well": this is actually the principal problem.  All the rest is
a single document, consequently not having a lot of font overhead.

OK well that wasn't previously clear, I had assumed the problem was TeX PDF files, not Lilypond ones. I also was under the impression there were many TeX PDF files being assembled, not a single file.

I am not into the details here (Masamichi-san?), but this font merging
of the included files is _exactly_ responsible for the reported space

Last time I looked at Lilypond output it was because it uses glyphshow throughout, which means that Ghostscript synthesises fonts for it. I haven't seen a case where it uses normal fonts. Which is why I thought it couldn't be the problem.

I've never seen Lilypond code that didn't use glyphshow.

It's assuming a different problem than the one we are dealing with.  So
obviously my attempts at explanation have been assuming too much prior
knowledge, putting us on different pages and talking about different
problems.  I apologize for wasting your time in that manner: we may well
disagree about how to best solve LilyPond's problems, but we should be
actually talking about the same problems for this to mean anything.

Yeah I'm afraid we've been talking at cross-purposes, mostly because what little I do know about Lilypond has been limited to the files I've been presented with in bug reports. Clearly they don't show the full range of possibilities.

So it seems like you don't have much choice, though not disabling subsetting when creating the PDF files would make some savings, probably quite signifcant, but I can't tell without seeing some examples of the PDF files in question.

While I have agreed to talk about this with the other developers, I still think you are potentially getting into a future situation where you will end up with incorrect final output by assuming that all fonts with the same name are the same font. Worse still, you won't find out until after you've produced the document and someone finds the error.

My solution for that would be to find or create a tool to remove the duplicates, and I really don't think you want to be doing that with Ghostscript.

Its not a terribly complex task but it would be time consuming to write it, and require a decent working knowledge of the basics of PDF. It might make a little Google summer of code project if you support that.

As I said in response to william Bader, while it would be possible in your case to do a simplified tool, I think a more general font de-duplication tool would be better, as it would guard against future changes in your workflow and would be something of general use.


reply via email to

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