On 15.01.2015 17:01, d...@gnu.org wrote:
PDFTeX apparently does merge subsetted fonts,
Which version?
so I don't think we should
need to include the complete fonts in order to get font merging. But we
probably should work with coding vectors so that we can use identical
font names, just
Knut Petersen knut_peter...@t-online.de writes:
On 15.01.2015 17:01, d...@gnu.org wrote:
PDFTeX apparently does merge subsetted fonts,
Which version?
Those versions having the \pdfincludedcopyfonts setting?
so I don't think we should
need to include the complete fonts in order to get
On 15.01.2015 14:47, d...@gnu.org wrote:
On 2015/01/15 13:18:46, Knut_Petersen_t-online.de wrote:
On 15.01.2015 13:15, mailto:d...@gnu.org wrote:
On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote:
Ghostscript does the font merging.
Any idea whether something could be done to make
On 2015/01/15 15:06:06, Knut_Petersen_t-online.de wrote:
On 15.01.2015 14:47, mailto:d...@gnu.org wrote:
On 2015/01/15 13:18:46, Knut_Petersen_t-online.de wrote:
On 15.01.2015 13:15, mailto:d...@gnu.org wrote:
On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote:
Ghostscript does the
On 2015/01/15 07:08:33, lemzwerg wrote:
David's concerns are very specific to the Lilypond documentation, not
covering
the general case. Many programs simply can't process PS output at
all, so the
suggestion to collect PS data that gets reduced later on is not
applicable.
The only valid
On 15.01.2015 10:45, d...@gnu.org wrote:
Reliable? If I remember correctly, the tool used for combining the
fonts (ppdfsizeopt.py)
Ghostscript does the font merging.
fails on the PDF files from PDFLaTeX, so there
must be an additional iteration through GhostScript. This additional
On 15.01.2015 12:49, lemzw...@googlemail.com wrote:
The hyperlink issue is not related to the --bigpdf option (since it is a
bug in ghostscript), so I don't think that this is a showstopper.
Well, it means that the code currently cannot be used to build lilyponds
own documentation.
cu,
Knut
On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote:
On 15.01.2015 10:45, mailto:d...@gnu.org wrote:
Reliable? If I remember correctly, the tool used for combining the
fonts (ppdfsizeopt.py)
Ghostscript does the font merging.
Ok.
BTW: All this has been documented in the commit
On 15.01.2015 13:15, d...@gnu.org wrote:
On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote:
Ghostscript does the font merging.
Any idea whether something could be done to make PDFTeX do the font
merging instead when including all the PDF files?
No, not really. That would require a
Well, we get a large size reduction even if we don't use pdfsizeopt!
Using this program is an extra bonus but not mandatory. And you are
right, I hope that Péter fixes the reported issues, provided someone is
going to add them to the bug tracker (which hasn't happened yet, looking
at
On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote:
On 15.01.2015 10:45, mailto:d...@gnu.org wrote:
Reliable? If I remember correctly, the tool used for combining the
fonts (ppdfsizeopt.py)
Ghostscript does the font merging.
Any idea whether something could be done to make PDFTeX
On 15/01/15 13:18, Knut Petersen wrote:
On 15.01.2015 13:15, d...@gnu.org wrote:
On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote:
Ghostscript does the font merging.
Any idea whether something could be done to make PDFTeX do the font
merging instead when including all the PDF files?
On 2015/01/15 13:18:46, Knut_Petersen_t-online.de wrote:
On 15.01.2015 13:15, mailto:d...@gnu.org wrote:
On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote:
Ghostscript does the font merging.
Any idea whether something could be done to make PDFTeX do the font
merging instead when
On 15.01.2015 13:12, d...@gnu.org wrote:
If external hyperlinks from our documentation PDF to other files stop
working, we cannot make this the default way of building our
documentation.
Indeed. Building lilypond with --bigpdfs enabled by default is a good
test for that code, nothing more,
14 matches
Mail list logo
