ut
>> that is not what you mean?
>
> I meant doc build after the binary is made.
>
>> I regularly run "make doc" with -j4 without issues.
>
> I used to make docs with -j7 succesfully but it always surprises me
> how the _first_ time it _never_ succeeds. That's
build uses lilypond, which is generated by the build
process, so you first have to do "make" before doing "make doc". But
that is not what you mean?
I meant doc build after the binary is made.
I regularly run "make doc" with -j4 without issues.
I used to make docs
On Mon, Mar 9, 2020 at 9:07 PM Francisco Vila wrote:
> >> Sorry if it's in CG already, I could be wrong, but Doc build is not
> >> multi-thread safe, first time at least. It uses files generated by the
> >> build process itself.
> >>
> >> Right?
well, the doc build uses lilypond, which is generat
El 9/3/20 a las 20:41, David Kastrup escribió:
Francisco Vila writes:
Sorry if it's in CG already, I could be wrong, but Doc build is not
multi-thread safe, first time at least. It uses files generated by the
build process itself.
Right?
I tend to do
make clean test-clean doc-clean
CPU_COU
Francisco Vila writes:
> Sorry if it's in CG already, I could be wrong, but Doc build is not
> multi-thread safe, first time at least. It uses files generated by the
> build process itself.
>
> Right?
I tend to do
make clean test-clean doc-clean
CPU_COUNT=9 make -j9 && CPU_COUNT=9 make -j9 tes
Sorry if it's in CG already, I could be wrong, but Doc build is not
multi-thread safe, first time at least. It uses files generated by the
build process itself.
Right?
--
Francisco Vila, Ph.D. - Badajoz (Spain)
paconet.org , lilypond.es
> my third attempt to make R\fermata work (after
> https://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00069.html
> and
> https://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00079.html)
> seems to be successful:
> https://sourceforge.net/p/testlilyissues/issues/5511/
Great!
> O
Hi list,
my third attempt to make R\fermata work (after
https://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00069.html
and
https://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00079.html)
seems to be successful:
https://sourceforge.net/p/testlilyissues/issues/5511/
One of
Am 06.04.19 um 01:49 schrieb Kieren MacMillan:
Hi Werner,
Would this be of interest for LilyPond?
https://developers.google.com/season-of-docs/docs/project-ideas
It would be *very* valuable for OpenLilyLib… =)
Indeed, but I don't think this program is suitable for that ...
If
Le 05/04/2019 à 20:46, Werner LEMBERG a écrit :
Would this be of interest for LilyPond?
This might help us going forward and profit from the evolution of
texinfo, as well as recover the use of lilypond-doc.po that vanished
with GDP.
Cheers,
Jean-Charles
_
Hi Werner,
> Would this be of interest for LilyPond?
> https://developers.google.com/season-of-docs/docs/project-ideas
It would be *very* valuable for OpenLilyLib… =)
Cheers,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ em
Would this be of interest for LilyPond?
https://developers.google.com/season-of-docs/docs/project-ideas
Improving the documentation would certainly be quite valuable. Given
that we use the texinfo format, we could respond to the TeX Users
Group's call for projects (thus CCing
Am 26.12.18 um 11:51 schrieb pkx1...@runbox.com:
Yes but I would add the snippet first to the NR as a patch (i.e. via
../snippets/new/..) and put it through review that way; then worry about
the LSR 'website' later as the LSR is not independent the doc build
process.
I already added the sn
Hello Malte,
On 25/12/2018 12:09, Malte Meyn wrote:
Hi list,
for documentation of restNumberThreshold
(https://sourceforge.net/p/testlilyissues/issues/5251/) I made a
snippet (http://lsr.di.unimi.it/LSR/Item?id=1078) that I would like to
add to the NR. IIUC, the snippet now needs to be revie
Hi list,
for documentation of restNumberThreshold
(https://sourceforge.net/p/testlilyissues/issues/5251/) I made a snippet
(http://lsr.di.unimi.it/LSR/Item?id=1078) that I would like to add to
the NR. IIUC, the snippet now needs to be reviewed and then I can add it
to git and upload a patch
Hello,
On Tue, 3 Jul 2018 11:05:32 +0200, Francisco Vila wrote:
> On 30/06/18 21:33, Federico Bruni wrote:
> >Hi Simon
> >There's already an open issue about this request. Opened by me, IIRC.
> >I also suggested to move the language selection from the footer to the
> >header of e
On 30/06/18 21:33, Federico Bruni wrote:
>Hi Simon
>There's already an open issue about this request. Opened by me, IIRC.
>I also suggested to move the language selection from the footer to the
>header of each page. In another issue..
>It's all in the tracker. We miss someone wi
On 30.06.2018 21:33, Federico Bruni wrote:
Hi Simon
There's already an open issue about this request. Opened by me, IIRC.
I also suggested to move the language selection from the footer to the
header of each page. In another issue..
It's all in the tracker. We miss someone willing to work on
Hi Simon
There's already an open issue about this request. Opened by me, IIRC.
I also suggested to move the language selection from the footer to the
header of each page. In another issue..
It's all in the tracker. We miss someone willing to work on it.
__
Simon Albrecht writes:
> Hello everybody,
>
> Bernhard Kleine has pointed out that while it has been problematic for
> years already to use e.g. the German version of the docs, because the
> translation hasn’t been updated in a long time and many new features
> are missing,
Hello everybody,
Bernhard Kleine has pointed out that while it has been problematic for
years already to use e.g. the German version of the docs, because the
translation hasn’t been updated in a long time and many new features are
missing, the German docs do not make any hint of that
Hello Karl,
On Fri, 8 Sep 2017 18:47:56 +
Karlin High wrote:
> Back in June, I was typing up some Aiken-heads music for a client. We
> ran into a problem shown in the attached PNG and LY files, where
> white-head notes end up too dark at lower staff sizes. The problem was
> resolved by us
On 9/8/17 12:47 PM, "lilypond-devel on behalf of Karlin High"
wrote:
>
>a snippet for the LSR,
>a reference in the documentation, perhaps under NR 1.1.4 Shape note heads,
>adding a feature to LilyPond, the command \aikenHeadsThin
>
>Any preference from the developers? I've read some of the contri
Back in June, I was typing up some Aiken-heads music for a client. We
ran into a problem shown in the attached PNG and LY files, where
white-head notes end up too dark at lower staff sizes. The problem was
resolved by using thin-variant Aiken heads. However, arriving at that
solution was a litt
On 2016-12-30 22:04, Jay Anderson wrote:
In response to this thread:
https://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00679.html
I'm attempting to build lilypond.
Hi Jay,
thanks for looking into this.
When building locally (an older version of mint linux) [...]
Sorry, I have no
On Fri, 30 Dec 2016 15:07:24 -0700
Jay Anderson wrote:
> On Fri, Dec 30, 2016 at 2:28 PM, Phil Holmes
> wrote:
> > Just for clarity. RAM or disk?
>
> In the VM:
> - Disk: 14gb (4.2gb used).
> - Memory: 4gb (after increasing from 2gb)
>
> I started re-running the doc build about an hour ago.
On Fri, Dec 30, 2016 at 2:28 PM, Phil Holmes wrote:
> Just for clarity. RAM or disk?
In the VM:
- Disk: 14gb (4.2gb used).
- Memory: 4gb (after increasing from 2gb)
I started re-running the doc build about an hour ago. Neither disk nor
memory seem to be in danger of being used up.
-Jay
__
- Original Message -
From: "Jay Anderson"
To: "lilypond-devel"
Sent: Friday, December 30, 2016 9:04 PM
Subject: Building issues (lilypond and docs)
Moving on from that I tried using lilydev and it builds fine in the
virtual machine, but when attempting `make doc
In response to this thread:
https://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00679.html
I'm attempting to build lilypond.
When building locally (an older version of mint linux) it ends with:
make[1]: Entering directory `/home/jay/programming/lilypond/build/mf'
mkdir -p ./out
touch ./ou
Am 09.04.2016 um 15:27 schrieb Phil Holmes:
> - Original Message - From: "Urs Liska"
> To:
> Sent: Thursday, April 07, 2016 7:11 AM
> Subject: Re: Code examples in docs
>
>
>>
>>
>> Am 07.04.2016 um 07:54 schrieb Urs Liska:
>>>
- Original Message -
From: "Urs Liska"
To:
Sent: Thursday, April 07, 2016 7:11 AM
Subject: Re: Code examples in docs
Am 07.04.2016 um 07:54 schrieb Urs Liska:
Am 07.04.2016 um 07:50 schrieb Noeck:
Hi Urs,
a very uneducated guess: Could it be that the html page
Weitergeleitete Nachricht
Betreff:Re: Code examples in docs
Datum: Sat, 9 Apr 2016 12:56:12 +0100
Von:James
An: Urs Liska
Hello Urs
On 09/04/16 12:27, Urs Liska wrote:
>
> Am 9. April 2016 12:56:42 MESZ, schrieb James :
>> Urs,
>>
On 4/7/16 4:54 PM, "Urs Liska" wrote:
>
>So it is really strange, I'm completely at a loss to find out where to
>start looking further ...
Have you worked your way through Phil's notes at
http://lilypond.org/doc/v2.19/Documentation/contributor/the-function-of-mak
e-doc
Carl
__
finally found out where the code in book_html.py actually leads to.
With some brute force I took care of replacing the snippet and image
with a paragraph that I could then grep in the rendered docs. And it
ended up exclusively in the lilypond-book regtests.
So obviously the book_XXX.py fi
Am 07.04.2016 um 12:11 schrieb David Kastrup:
> David Kastrup writes:
>
>> Carl Sorensen writes:
>>
>>> What about if you delete python/out and redo make doc?
>>>
>>> Just wondering if there's something wrong with the build script that
>>> python/out isn't properly recreated when python/*.py ch
David Kastrup writes:
> Carl Sorensen writes:
>
>> What about if you delete python/out and redo make doc?
>>
>> Just wondering if there's something wrong with the build script that
>> python/out isn't properly recreated when python/*.py changes. In my
>> setup, python/*.py is not executable, bu
Carl Sorensen writes:
> What about if you delete python/out and redo make doc?
>
> Just wondering if there's something wrong with the build script that
> python/out isn't properly recreated when python/*.py changes. In my
> setup, python/*.py is not executable, but python/out/*.py is. So make i
On 4/7/16 12:11 AM, "lilypond-devel-bounces+c_sorensen=byu@gnu.org on
behalf of Urs Liska" wrote:
>
>
>However, when *deleting* the .py and .pyc files an error was triggered,
>when lilypond-book tries to import book_html.
>
>Looking further into it I realized:
>- book_base keeps an array with
ed is the code that wraps the source code of
>> any LilyPond snippet in the docs in
>> ...image
>>
>> However, modifying this didn't seem to have any effect, so I even went
>> brute force up to emptying the complete file. Still make doc works
>>
Am 07.04.2016 um 07:54 schrieb Urs Liska:
>
> Am 07.04.2016 um 07:50 schrieb Noeck:
>> Hi Urs,
>>
>> a very uneducated guess: Could it be that the html pages are only
>> generated if the input has changed and as you change the generating code
>> and not the doc-input, the generation is skipped? I
Urs Liska writes:
> Hm, I'm puzzled.
>
> I must say that this file and particularly
> BookHTMLOutputFormat.snippet_output() looks like it's exactly the code
> I'm looking for. What I need is the code that wraps the source code of
> any LilyPond snippet in the d
Am 07.04.2016 um 07:50 schrieb Noeck:
> Hi Urs,
>
> a very uneducated guess: Could it be that the html pages are only
> generated if the input has changed and as you change the generating code
> and not the doc-input, the generation is skipped? It is still strange
> that it works if you empty the
Hi Urs,
a very uneducated guess: Could it be that the html pages are only
generated if the input has changed and as you change the generating code
and not the doc-input, the generation is skipped? It is still strange
that it works if you empty the file.
Cheers,
Joram
>>> Hi,
>>>
>>> can someone tell me where I should look for code that generates code
>>> examples in the HTML docs?
>> I assume you mean the texi/latex code that takes the snippet and puts it
>> into the document as a code fragment?
>>
>> I thi
e that generates code
>> examples in the HTML docs?
>
> I assume you mean the texi/latex code that takes the snippet and puts it
> into the document as a code fragment?
>
> I think it may be in python/book_html.py, but I'm not 100% sure.
Thanks, that looks indeed promising.
On 4/5/16 5:09 PM, "lilypond-devel-bounces+c_sorensen=byu@gnu.org on
behalf of Urs Liska" wrote:
>Hi,
>
>can someone tell me where I should look for code that generates code
>examples in the HTML docs?
I assume you mean the texi/latex code that takes the snippe
On 06.04.2016 01:09, Urs Liska wrote:
Hi,
can someone tell me where I should look for code that generates code examples
in the HTML docs?
There are links on the pictures, aren’t they?
Best, Simon
___
lilypond-devel mailing list
lilypond-devel
Hi,
can someone tell me where I should look for code that generates code examples
in the HTML docs?
Thanks
Urs
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Many thanks.
https://codereview.appspot.com/287240043/diff/1/Documentation/included/compile.itexi
File Documentation/included/compile.itexi (right):
https://codereview.appspot.com/287240043/diff/1/Documentation/included/compile.itexi#newcode232
Documentation/included/compile.itexi:232: asterisk
Will presently upload a diff incorporating the work of Keith after
applying the points made in review.
https://codereview.appspot.com/239250043/diff/20001/Documentation/learning/common-notation.itely
File Documentation/learning/common-notation.itely (left):
https://codereview.appspot.com/239250
On 2015/05/28 05:13:48, Keith wrote:
On 2015/05/26 16:21:48, dak wrote:
>
> The script had about 90% coverage or so and working over Learning
manually to
> make it consistent makes sense. I think we can live with incomplete
coverage
> elsewhere.
I completed (I'm pretty sure) the conversio
' {} mixed with \relative{} used to explain a tricky
interaction with expanding chords was too much for my brain to keep
track of.
Description:
Docs: clean up after \relative conversion
Please review this at https://codereview.appspot.com/239250043/
Affected files (+109, -109 lines):
https://codereview.appspot.com/239250043/diff/20001/Documentation/learning/common-notation.itely
File Documentation/learning/common-notation.itely (left):
https://codereview.appspot.com/239250043/diff/20001/Documentation/learning/common-notation.itely#oldcode1184
Documentation/learning/common-no
Apart from a really trivial nitpick, LGTM
(but I haven't checked if anything has been missed)
Trevor
https://codereview.appspot.com/239250043/diff/1/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
https://codereview.appspot.com/239250043/diff/1/Document
, these are all in rather esoteric sections and
probably quite well-hidden from new users.
Trevor
Description:
Docs: Issue 4181: Expose \stemUp and \stemDown predefs less
in LM Tweaking output
- change some examples to use \slurUp etc rather than \stemUp
- give an example showing the use of the
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/
1 - 100 of 1125 matches
Mail list logo
