Knut,
author Knut Petersen
Thu, 8 Jan 2015 18:00:44 + (18:00 +)
committer James Lowe
Sat, 31 Jan 2015 12:57:08 + (12:57 +)
commit cd5b559ab016dad5100eab3105218df94ab9f402
Thanks for your work.
James
https://codereview.appspot.com/194090043/
___
Am 30.01.2015 um 09:57 schrieb Werner LEMBERG:
Die erzeugten PDF-Dateien sind sehr viel größer als normal (aufgrund
der schwachen oder fehlenden Schriftartenoptimierung). Wenn jedoch
zwei oder mehr PDF-Dateien mittels pdftex, xetex oder luatex
eingebunden werden, können sie mit Ghostscript nach
> Die erzeugten PDF-Dateien sind sehr viel größer als normal (aufgrund
> der schwachen oder fehlenden Schriftartenoptimierung). Wenn jedoch
> zwei oder mehr PDF-Dateien mittels pdftex, xetex oder luatex
> eingebunden werden, können sie mit Ghostscript nachbearbeitet werden
> (die Fontdaten werden
Am 29.01.2015 um 19:44 schrieb pkx1...@gmail.com:
Can someone give me the translation in German for:
"PDF files generated will be much larger than normal (due to little or
no font optimization). However, if two or more PDF files are included
within pdftex, xetex or luatex documents they can then
Can someone give me the translation in German for:
"PDF files generated will be much larger than normal (due to little or
no font optimization). However, if two or more PDF files are included
within pdftex, xetex or luatex documents they can then be processed
further via ghostscript (merging dupl
Patch on countdown for Jan 29th
https://codereview.appspot.com/194090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Ah, nice! I wasn't aware of this script. Thanks for mentioning it.
https://codereview.appspot.com/194090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2015/01/24 14:10:46, J_lowe wrote:
On 2015/01/20 22:41:38, http://wl_gnu.org wrote:
> >> In case of doubt, the formatting produced by Emacs is the one we
> >> follow.
> >
> > Can you point me to some pages that explain this on the web?
>
> Well, I can describe what I do: I simply load the Sche
On 2015/01/20 22:41:38, wl_gnu.org wrote:
>> In case of doubt, the formatting produced by Emacs is the one we
>> follow.
>
> Can you point me to some pages that explain this on the web?
Well, I can describe what I do: I simply load the Scheme file into
emacs, which automatically selects Scheme
Thanks to all
https://codereview.appspot.com/194090043/diff/40001/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/40001/Documentation/de/usage/running.itely#newcode160
Documentation/de/usage/running.itely:160:
On Tue, 20 Jan 2015 13:19:26 -0800, wrote:
https://codereview.appspot.com/194090043/diff/20001/ps/encodingdefs.ps#newcode8
ps/encodingdefs.ps:8: /LilyNoteHeadEncoding [
On 2015/01/18 06:33:02, Keith wrote:
This is a little different from "FetaNoteheadsEncoding" in
'mf/out/feta-noteheads11.enc'
>> In case of doubt, the formatting produced by Emacs is the one we
>> follow.
>
> Can you point me to some pages that explain this on the web?
Well, I can describe what I do: I simply load the Scheme file into
emacs, which automatically selects Scheme mode. Then I press the tab
key line per li
Thank *you* for your hard work. Here's the next round of comments.
https://codereview.appspot.com/194090043/diff/40001/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/40001/Documentation/de/usage/running.itel
Thanks for your patience.
https://codereview.appspot.com/194090043/diff/20001/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/20001/Documentation/de/usage/running.itely#newcode166
Documentation/de/usage/runn
On 2015/01/11 20:13:29, lemzwerg wrote:
Thanks for your help and assistance!
> > For better orientation, please reformat this to have a fixed
number
> > of entries per line (I suggest 4 items),
>
> I did 3 items maximum and kept things within the line length.
Basically, this is fine. How
I have not yet used LilyPond with TeX, so I have no opinion.
I looked up the history:
Use of PostScript glyphshow, rather than show, for all characters seems
to have started with
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=c3d6497157576dc0d4ae77c44978d54e7a212074
after some
> So do I go ahead and continue helping Knut with this patch?
I suggest yes. And thanks in advance for helping :-)
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Knut Petersen 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 font merging. But
we
pro
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 spar
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:
>> >
>> >> Ghostscri
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 mak
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 whe
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, no
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 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 lot
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 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 m
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 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
iterati
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 https://code
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 a
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 alternative is to make Lilypond natively produce
On 2015/01/14 08:42:27, lemzwerg wrote:
Knut, *your* patch set has this, but James's version (in patch set 2)
misses it.
Yes that's true. I thought this was a 'lost in translation' error. So we
have:
+Generate really big pdf files with as less as possible
+optimization of font data.
b
Knut, *your* patch set has this, but James's version (in patch set 2)
misses it.
https://codereview.appspot.com/194090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 14.01.2015 08:15, lemzw...@googlemail.com wrote:
Hmm. I can't find in your description that `--bigpdfs' creates *big*
output files that get later reduced to small one by running ghostscript
again.
https://codereview.appspot.com/194090043/
No? Have a look at the patch sent to lilypond-deve
Hmm. I can't find in your description that `--bigpdfs' creates *big*
output files that get later reduced to small one by running ghostscript
again.
https://codereview.appspot.com/194090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https:
On 2015/01/12 08:52:02, lemzwerg wrote:
I don't object to the name! I only state that the option's name
doesn't have an
explanation in the English documentation, and I think it would be good
if it
gets added.
Knut already did and I 'rewrote' this (as per the stated summary of
patch #2).
D
I don't object to the name! I only state that the option's name doesn't
have an explanation in the English documentation, and I think it would
be good if it gets added.
https://codereview.appspot.com/194090043/
___
lilypond-devel mailing list
lilypond
On 12.01.2015 06:56, lemzw...@googlemail.com wrote:
https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely
File Documentation/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely#newcode187
Documentatio
https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely
File Documentation/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely#newcode187
Documentation/usage/running.itely:187: font data which can make
s
On 2015/01/11 20:13:46, lemzwerg wrote:
https://codereview.appspot.com/194090043/diff/20001/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/20001/Documentation/de/usage/running.itely#newcode160
Documentatio
https://codereview.appspot.com/194090043/diff/20001/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/20001/Documentation/de/usage/running.itely#newcode160
Documentation/de/usage/running.itely:160: pdftex-, xetex
Thanks for your help and assistance!
> For better orientation, please reformat this to have a fixed number
> of entries per line (I suggest 4 items),
I did 3 items maximum and kept things within the line length.
Basically, this is fine. However, three is incommensurable to 16, ...
Werner
Thanks
https://codereview.appspot.com/194090043/diff/1/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/1/Documentation/de/usage/running.itely#newcode160
Documentation/de/usage/running.itely:160: pdftex-, xetex
LGTM, thanks! I only have some minor comments regarding improved
legibility of the source code.
https://codereview.appspot.com/194090043/diff/1/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/1/Documentation/
The English Documentation is not very well written - which I completely
understand of course - so once this patch has passed all the tests, and
because I have the patch file (as I am managing this patch for Knut), I
will re-do the English documentation.
As I cannot speak German I won't touch that
Reviewers: knut_petersen_t-online.de,
Message:
Added Knut as I 'own' this patch while it is being reviewed.
James
Description:
Reduce size of PDF files when inc. in *TeX docs
Issue 4251
This changes the way lilypond uses fonts to draw glyphs.
It avoids to used glyphshow for all emmentaler gl
47 matches
Mail list logo
