Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[Ken Sharp]

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
> savings.

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.


                Ken