Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 18:05 26/09/2017 +0200, Knut Petersen wrote: Just to be absolutely certain; the lack of PDFDontUseFontObjectNum is no longer a showstopper for you ? We do not need PDFDontUseFontObjectNum any longer. It's removal is not a showstopper. Thanks for the confirmation! We've run across a

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 11:24 25/09/2017 +0200, Knut Petersen wrote: Thanks to the ghostscript community for your great tool and your patience! Just to be absolutely certain; the lack of PDFDontUseFontObjectNum is no longer a showstopper for you ? We're planning to do a second release candidate 'real soon now'

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 19:12 23/09/2017 +0200, Knut Petersen wrote: For a recent ghostscript without the PDFDontUseFontObjectNum only the combination of lilyponds --bigpdfs with -dgs-never-embed-fonts gives the desired result. The necessity for the extractpdfmark utility has not changed - use it if you link to

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 02:35 23/09/2017 +0900, Masamichi Hosoda wrote: > Converting to TeX format would probably work, but apparently there > were problems with that. > > Is there some other approach available ? There is a method of using font non-embedded PDF. In my experiment, it seems to work fine except

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 10:12 22/09/2017 +0200, David Kastrup wrote: 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,

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 10:23 22/09/2017 +0200, David Kastrup wrote: 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

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

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

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

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

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 21:43 21/09/2017 +0900, Masamichi Hosoda wrote: We use the following command to convert from EPS to PDF. $ gs -dSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -dSubsetFonts=false -sDEVICE=pdfwrite -dAutoRotatePages=/None -sOutputFile=filename.pdf -c.setpdfwrite

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 14:43 21/09/2017 +0200, Knut Petersen wrote: The fonts in the pdfs are identical fonts constructed by ghostscript on the fly, I think it was Ken Sharp who explained to me some years ago that the term "subset" is wrong ;-) Well, sort of, they aren't identical though, they are all

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 18:50 20/09/2017 +0200, David Kastrup wrote: Did you get to see the PostScript files before conversion with pstopdf? Would being able to generate those differently make a difference? I'm pretty sure Knut sent me everything, really everything. Not that I can use it all, but its nice to

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 14:57 20/09/2017 +0200, Knut Petersen wrote: I sent a collection of files to Ken. Well, my idea doesn't work with your font, because (I think) its an OTF font. I had hoped it would be possible to create the PDF files with *no* fonts embedded at all, then have Ghostscript embed them just

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 22:30 19/09/2017 +0200, Knut Petersen wrote: What happens if you include several "final" pdfs in a *TeX document? If you include several pdfs generated as described above in a *TeX-generated pdf, all fonts from the lilypond pdfs are included. Probably all are different. If you feed

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

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

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 15:11 19/09/2017 +, William Bader wrote: >It would be possible to write a tool which could reliably detect identical fonts in a PDF file, There are already libraries that can read PDFs into a data structure and then write a new PDF, for example, pdfsizeopt in python, poppler

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 16:29 19/09/2017 +0200, Werner LEMBERG wrote: This is next to impossible. lilypond has knowledge for good music typography, while TeX has knowledge for good text typography. I read your suggestion that lilypond should do everything, i.e., both text and music layout, but this won't happen,

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 15:44 19/09/2017 +0200, David Kastrup wrote: Are there any example documents with thousands of pages and ten thousands of PDF inclusions one could look at? I would suggest that the fact you want to 'include' tens of thousands of PDF files to be the problem, really. I appreciate you are

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 13:42 19/09/2017 +0200, David Kastrup wrote: So the mechanisms mostly out of our own control are Ghostscript in its ps2pdf facility, various TeX engines when including lots of ps2pdf-generated PDF files into a main document. To me this is where the problem lies, PDF is good as a terminal

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 11:33 19/09/2017 +0200, David Kastrup wrote: The question is what the complaint should be, namely what LilyPond does wrong. Producing large comprehensive manuals using TeX including lots of example images generated using the same fonts? Ah, you need to be careful talking about 'images'

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

do feel that creating the pages in this fashion is less than ideal and you would probably be well advised to seek a different way of working. As I have said (repeatedly now) I will discuss this with the other developers, and the input (especially from Knut's mail) will be taken into account.

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

would discuss it internally right from the start. Ken Sharp ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

At 17:27 18/09/2017 -0700, Perry Hutchison wrote: Masamichi Hosoda wrote: > >>It seems that `-dPDFDontUseFontObjectNum` option does not work. ... > There is a tool for using this method of removing duplicate fonts. > https://www.ctan.org/pkg/extractpdfmark >

Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

At 20:38 18/09/2017 +0200, David Kastrup wrote: I think "slightly smaller" was something like a factor of 10. We are talking about files including literally thousands if not ten thousands of graphics (manuals close to a thousand pages with lots of graphic output included). Then maybe you

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

At 00:31 19/09/2017 +0900, Masamichi Hosoda wrote: When you create a PDF document using something like a TeX system you may include many small PDF files in the main PDF file. It is common for each of the small PDF files to use the same fonts. If the small PDF files contain embedded full font