>> Nope, IIRC. Only warnings that 'font foo is too large to be included
>> as a subfont' or something similar.
>
> I've just tried to compile 2.20 and I get those same Page xx message
> back then.
Hmm.
> Go check out b39b2e652 for instance (that is the 2.20 'bump welcome'
> commit that Phil do
> extractpdfmark not tex
>
> (I assume that comment was a typo?)
Yes.
> anyway with it installed you will get those messages, without you
> won't (or at least I did not).
>
> and it has been a thing for me for a lot longer than 3 weeks.
Well, as reported, I didn't get those page messages sin
> You haven't yet confirmed that if you 'remove/uninstall'
> extractpdfmark you do NOT get the messages, only that you have it
> installed and you get them - which is expected.
Sorry for being imprecise. I have *always* `extractpdfmark`
installed, and since a long time (a few months) I *never*
> May I ask what you use the image-less info files for? Supporting
> them is one of the warts in the doc build, and I suspect they cater
> to a just small minority of our users.
Well, I personally use it for quickly checking the NR and the IR, but
this is of course not of much relevance.
On the
> Emmentaler's flag glyphs are minimal: they deliberately don't
> overwrite a stem's tip, only overlapping with the stem in a thin,
> rectangular area [...]
>
> However, SMuFL expects scoring programs to use plain rectangle primitives
> for drawing stems. With this in mind, Bravura's flags cove
>> After the big #84 change (i.e., commit 82d72b747) I now see that
>> `.info` files are no longer built if I say `make all` – note I'm
>> talking about `.info` files without images.
>
> Not intentional, see
> https://gitlab.com/lilypond/lilypond/-/merge_requests/306
The fix is incomplete, as I'
>> The fix is incomplete, as I've just found out: `make install`
>> doesn't install the info files. I looked a bit at the code but I
>> couldn't find out where the target is missing...
>
> I understand you personally want to build some info files quickly
> for browsing, but what use are info fil
[lilypond e16a5ec 2020-Aug-06]
Look at the following code.
\relative c'' {
f2 \breathe |
g2 \breathe }
As the attached images show, the breathing sign *sometimes* collides
with accidentals. Looks like a bug. If you agree I'll add it to the
tracker.
Any idea how to circumvent tha
>> >> The fix is incomplete, as I've just found out:
>
> IMHO it would have been better to actually test the fix before
> accepting and short-tracking it.
I *did* test it, but without installation. In other words, the
short-tracking was OK.
>> BTW, had you mentioned that !84 removed 'naked' i
> As the attached images show, the breathing sign *sometimes* collides
> with accidentals. Looks like a bug.
Attached I've added some more tests. LilyPond's behaviour
w.r.t. accidentals looks very erratical...
Werner
\paper {
indent = 0
ragged-right = ##t
}
\relative c'' {
\omit Sc
>> As the attached images show, the breathing sign *sometimes*
>> collides with accidentals. Looks like a bug. If you agree I'll
>> add it to the tracker.
>>
>> Any idea how to circumvent that?
>
> Adjusting the vertical bounds of the BreathingSign appears to help:
>
>
> \relative c'' {
>
>> Look at the following code.
>>
>> \relative c'' {
>> f2 \breathe |
>> g2 \breathe }
>>
>> As the attached images show, the breathing sign *sometimes*
>> collides with accidentals. Looks like a bug. If you agree I'll
>> add it to the tracker.
>
> the breathing sign is non-musical,
>> Attached I've added some more tests. LilyPond's behaviour
>> w.r.t. accidentals looks very erratical...
>
> Is this another manifestation of that age-old dotted rest problem
> that plagued the reg tests for years that was fixed end of last year
> (but I forget by who - Thomas?) where the dot w
Compare this:
{ f'!8[-> f'-> f'-> f'->] }
with this:
dashLarger = \tweak font-size #-1.2 \accent
{ f'!8[-> f'-> f'-> f'->] }
I consider the output of the second case much better – I don't like
the vertical offset of the accent if a natural is present.
What edition was the model for the
>> > the breathing sign is non-musical, and the accidental is musical,
>> > so this should be prevented by the skyline distancing. It would
>> > be interesting to see what lily thinks the skylines look like.
>>
>> Here it is.
>>
> these are the skylines for vertical spacing. You need the ones for
> Could https://gitlab.com/lilypond/lilypond/-/issues/1006 be what
> you’re looking for?
It is, thanks!
Werner
Hello Owen,
> That said, once I begin finalizing, what would that entail? I'd
> imagine something like the following:
>
>- First, I'd look at all the TODO's I've left myself and try to
> resolve them as best I can.
It depends. Some TODOs certainly need a very large amount of time a
Folks,
look at this example:
{ 2\glissando }
Due to the flat, the lower glissando line is far too short. I
consider this a bug.
LilyPond already provides the `end-on-accidental` property (which is
set to #t by default). For chords, however, this should be only
applied to glissando lines
>> { 2\glissando }
>>
>> Due to the flat, the lower glissando line is far too short.
>>
>> beyond my capabilities right now. Is there a solution to
>> circumvent this temporarily?
>
>
> \version "2.20.0"
>
> {
> \override Glissando.before-line-breaking =
> #(lambda (grob)
> (le
> Here is a theoretically better version of the code, along with an
> improved test case so that the slopes are more easily compared:
Aaron, you are a wizard! My deepest respects for your Scheme skills.
Thanks a lot! Again, this deserves to become a lilypond snippet.
By the way, do you agree
> By the way, do you agree that this is a bug in LilyPond?
I just want to mention that Aaron's solution doesn't work in general
if more than two notes are involved in the chord. For a good
solution, the horizontal skylines of the involved chords have to be
taken into account; the lengths of the
>> What edition was the model for the large horizontal size of the
>> accent glyph?
>
> Not sure; maybe one of my horn study books by Mueller. But it was an
> early glyph, so it may need tweaking.
OK, thanks. Reducing the size of the accent glyph (both vertically
and horizontally) is a rather
>> >> What edition was the model for the large horizontal size of the
>> >> accent glyph?
>> >
>> > Not sure; maybe one of my horn study books by Mueller. But it was an
>> > early glyph, so it may need tweaking.
>>
>> OK, thanks. Reducing the size of the accent glyph (both vertically
>> and horizo
Compiling the documentation (using commit 1a64f012b from today) with
make doc VERBOSE=1
I get zillions of warnings from gs, all of them in the form
Can't find (or can't open) font file
/usr/share/ghostscript/9.52/Resource/Font//usr/share/gh.
All such lines are immediately followed by
> Compiling the documentation (using commit 1a64f012b from today) with
>
> make doc VERBOSE=1
>
> I get zillions of warnings from gs, all of them in the form
>
> Can't find (or can't open) font file
> /usr/share/ghostscript/9.52/Resource/Font//usr/share/gh.
Forgot to mention that I ha
>> I get zillions of warnings from gs, all of them in the form
>>
>> Can't find (or can't open) font file
>> /usr/share/ghostscript/9.52/Resource/Font//usr/share/gh.
>>
>> All such lines are immediately followed by
>>
>> Loading Emmentaler-XX font from
>> .../lilypond.compiled/out-fon
Hello Owen,
great progress, as usual!
> This week, I encoded the rest of the Feta glyphs, giving them SMuFL
> names and alternate/ligature information. Only Parmesan is left
> without SMuFL names for the time being.
I wonder whether it is possible to improve legibility: Could you
modify the c
IIRC we talked about setting up automatic updates of
https://github.com/lilypond/lilypond
but it seems this is still missing. Is there any progress?
I've just updated it manually.
Werner
>> IIRC we talked about setting up automatic updates of
>>
>> https://github.com/lilypond/lilypond
>>
>> but it seems this is still missing. Is there any progress?
>
> If somebody grants me access to the repo, I can easily add a deploy
> key with write access and setup mirroring from GitLab.
>> git remote update
>> git push --mirror g...@github.com:lilypond/lilypond.git
>
> Definitely add --prune to "git remote update" to remove branches
> that ceased to exist on the remote.
OK, done.
> In general, I would not run the mirroring from a real working copy
> of the repository becaus
>> If I go to
>> http://lilypond.org/doc/v2.21/Documentation/notation/index.html and
>> click any of the links, I get a page in Spanish, which I'm not.
>>
>> Anyone know why?
>
> Probably because your parents weren't Spanish.
:-)
Werner
> I've reordered and rebased my code, and it is now up to date with
> the current master. I've just published the new branch to GitLab as
> dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only
> nine commits now, instead of over a hundred, and they're ordered in
> a way that's ho
>> At the same time, I'll write docs for my work. I figure I'll make
>> nine documentation commits, one for each code change commit.
Hmm. Maybe I've misunderstood you. What's actually missing are
documentation strings *within* the commits. For example, the commit
Add smufl data to feta gl
> I've reordered and rebased my code, and it is now up to date with
> the current master. I've just published the new branch to GitLab as
> dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only
> nine commits now, instead of over a hundred, and they're ordered in
> a way that's hope
>> Werner (and the community in general), is backwards compatibility
>> important enough that I should try to take care of it before the
>> deadline?
>
> I think backwards compatibility is important enough that we should
> probably have it before merging the code into master.
Exactly. However,
> Ah! It looks like the issue is in line 12 of palm-mute.ly:
>
> e8^\markup { \musicglyph "noteheads.u2do" = palm mute }
>
> Here, \musicglyph is looking for noteheads.u2do, which I combined
> with .d2do to make .s2do. Changing the string to "noteheads.s2do"
> makes this regression test wor
> So, glyphnames.json.txt would look like this?
>
> glyphnames.json, created by Daniel Spreadbury, was retrieved from
> https://github.com/w3c/smufl on DD Mon . It is licensed under
> the W3C Community Contributor License Agreement and the W3C Final
> Specification Agreement.
Looks
> I meant re-committing my first commit with the fix, then rebasing
> the dev/lamb/GSoC-2020-final branch on top of it to keep my history
> pretty.
In general, this is the ideal solution, since it cleans up your
branch. However, ...
> Would you rather I just made a new commit?
... if tweaking
> Here's another stab at glyphnames.json.txt, given all this new information:
>
> glyphnames.json is a part of the Standard Music Font Layout
> (SMuFL) specification, version 1.3. It was retrieved from
> https://github.com/w3c/smufl on 29 Aug 2020, and is licensed under
> the W3C Final
>> > \alternative {
>> > { c1 }
>> > 1
>> > { d1 }
>> > 1
>> >}
>> >
>> > Which would be interpretted as: the 1st, 2nd, and 4th endings are c,
>> > and the 3nd ending is d.
>>
>> That is already valid syntax and makes the first and second
>> alternative c1 and the third and fourth al
It seems to me that not a single file in
input/regression/lilypond-book
gets processed during `make doc`. Has this ever worked?
Werner
>> It seems to me that not a single file in
>>
>> input/regression/lilypond-book
>>
>> gets processed during `make doc`. Has this ever worked?
>
> Apparently 2.14 had some content:
> http://lilypond.org/doc/v2.14/input/regression/lilypond-book/collated-files.pdf
> (later versions are empty
>> OK, but we don't have unit-testing for this directory either, right?
>
> `make test` / `make check`?
Yes.
> Why would you use `make doc` for that?
I wouldn't.
Werner
>> >> OK, but we don't have unit-testing for this directory either,
>> >> right?
>
> And that descends into input/regression/lilypond-book:
> https://gitlab.com/lilypond/lilypond/-/jobs/715114070#L88
OK, thanks, missed that, but...
> So where's the problem?
... it doesn't do a comparison agains
>> ... it doesn't do a comparison against correct input.
>
> The lilypond-book directory tests features of lilypond-book, but it
> doesn't any real comparison. Meaningful comparison would be to compare
> PDF files (after processing with LaTeX) across versions,
I disagree. There are two issues th
To make good doc builds of LilyPond it would be important IMHO to have
all necessary fonts included in the docker images.
Here's a list of 'foreign' fonts (or font families) that are not
correctly set up currently. In particular, I think we should avoid
non-free fonts for demonstration purposes,
> Am Sonntag, den 06.09.2020, 17:52 +0200 schrieb Werner LEMBERG:
>> To make good doc builds of LilyPond it would be important IMHO to
>> have all necessary fonts included in the docker images.
>
> Are these really important to ensure that the documentation is
> builda
> We're talking about different objectives here: CI is concerned
> *that* something can be built, but the *what* is discarded on
> success.
Understood now, thanks. However, I still think it simplifies
debugging if the right fonts *are* in the docker image.
> So everything added but not needed
directory, the binaries in `/usr/local/bin` are up to
date):
PYTHONPATH=.../lilypond/python:$PATHONPATH \
python3 .../lilypond/scripts/auxiliar/makelsr.py \
-p /usr/local/bin \
-s .../lilypond
# lsr-snippets.pl
#
# Written 2019-2020 by Wern
> Here is an updated version of my `lsr-snippets.pl` script, [...]
And another update handling `%LSR` comments that must be filtered out.
Completely undocumented, of course...
Werner
# lsr-snippets.pl
#
# Written 2019-2020 by Werner Lemb
>> OK. Could you please send me the list of available fonts in the
>> docker image?
>
> Get it with
> $ docker run --rm -ti
> registry.gitlab.com/lilypond/lilypond/ci/ubuntu-16.04:20200829 $cmd
>
> Attached is the full output of fc-list,
Thanks a lot! I think that we can easily adjust the
> I don't see that in the current stage of upheaval of both internals and
> build system and infrastructure, there is a point in freezing off some
> half-baked intermediate state that hasn't seen significant exposure to
> extensive testing.
+1 It's too early IMHO. Let's wait at laest a month.
>> > I don't see that in the current stage of upheaval of both
>> > internals and build system and infrastructure, there is a point
>> > in freezing off some half-baked intermediate state that hasn't
>> > seen significant exposure to extensive testing.
>>
>> +1 It's too early IMHO. Let's wait
>> This is not my proposal anymore to just branch, but Han-Wen's idea
>> of having a freeze of 3-4 weeks before branching.
>
> For me, a freeze can only start if we agree that nothing fundamental
> has to be changed or added. IMHO, we are far away from such a
> state.
What we can start, howeve
>> [...] if I delete a PDF file, say, `notation.pdf`, right now it
>> gets *not* rebuilt!
>
> The new documentation build has much more accurate dependency
> tracking, so if you want to rebuild notation.pdf, you can just say
> so:
>
> make out=www out-www/en/notation.pdf
Aah, I tried without `
>> > make out=www out-www/en/notation.pdf
>>
>> Aah, I tried without `out=www`. This incantation is good enough for
>> me, thanks. No further action needed.
>
> Actually that's the same as before, no?
No. Previously, `notation.pdf` was a first-class target: If you
deleted it, a call to `mak
> What puzzles me a bit is the magnitude of changes from autopep8 - I
> thought this tool was run in August? Maybe I'm missing something;
> FWIW I used the invocation "autopep8 -ia --ignore=E402" as
> documented in CG.
>
> Thoughts, objections? Should I exclude running autopep8?
I was told from
Despite Gould's “incorrect” verdict, here is an example from an old UE
edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
over clef changes *do* happen and make sense sometimes...
I still think that LilyPond should support that, handling the tie like
a slur in this case.
W
>>> The notes d♯ to e♭ have different pitches in the staff notation
>>> system, which cannot express E12 enharmonic equivalents, so this
>>> is slur. So it should be a slur that looks like slur.
I disagree. For all practical purposes in standard classical music,
enharmonic equivalents *do* sound
>> It is common, for example, for a composer to write D sharp for some
>> instruments and E flat for others.
>
> A composer should write so that it becomes easy for the musician to
> perform, otherwise they will have to edit the score, which costs
> time and money. The musicians then listens to
[git 9c3803fba4960b4afa63baeb50201a0cfa48f8f1]
I've just built the whole documentation, and I get a strange string
replacement in Appendix A of the NR (from file
`markup-list-commands.texi`), see attached image.
As far as I remember, this didn't happen previously. Is it possible
that this code
>> what was the last version in which this was seen working as
>> expected?
For me, three weeks ago.
> Probably never did but people got lucky.
Yes, it looks like that.
Werner
>> [...], I believe it would be reasonable to create a stable branch
>> and start picking fixes into that as needed. Before diving into the
>> details, I'd first like to know if there's still disagreement on
>> this starting point? If so, I'd love to hear how to move forward
>
> I'm fine with creat
> Did a make doc with updated texinfo.tex today and compared the pdfs
> against master. The result is uploaded here:
> https://drive.google.com/drive/folders/1czVl2glLVoQiUOLu1mvnWh9hozivaPuC?usp=sharing
>
> Green is master, red is current texinfo.tex from the Savannah repo.
> I did have a look
>> It seems that we have to check the settings of LilyPond's texinfo
>> setup. As a test, I compiled the attached document, and I get the
>> expected (good) formatting of the URL [the sample is taken from the
>> NR (around page 233)] with the latest `texinfo.tex` version.
> I cannot reproduce th
> Number 1:
>
>> **\nonstopmode \input ./http.texinfo
>> (./http.texinfo (/home/wl/bug/texinfo.tex
>> Loading texinfo [version 2019-02-16.14]:
>
> Number 2:
>> **\nonstopmode \input ./http.texinfo
>> (./http.texinfo (/home/wl/bug/texinfo.tex
>> Loading texinfo [version 2020-06-25.17]:
>
> How do
> We could restore the old behaviour with a hack like
>
> @tex
> \gdef\urefallowbreak{%
> \allowbreak
> }
> @end tex
>
> in common-macros.itexi, I did not test this with the complete docs,
> at least with your test example it does work, though.
I've just written an e-mail to 'bug-texinfo'. Let'
> we're using both `@url` and `@uref` commands in our documentation,
> the overwhelming majority is `@uref`.
>
> michael] ~/lilypond/Documentation/en (master)]> git grep '@url' | wc
> -l
> 9
> michael] ~/lilypond/Documentation/en (master)]> git grep '@uref' | wc
> -l
> 622
>
> The functionality
[lilypond git 647e127c07a794d087c5e39bf23c0d4a7d66a957 from Oct. 6th]
Folks,
can someone please explain to me why the following code
{
\compressEmptyMeasures
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 | \break
R4*120 | \break
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 |
c'4 4
Folks,
some time ago I reported font problems in the documentation (this is,
using fonts that are either not optimal, or not freely available).
The basic question is which route we should go.
* Reduce the number of extra fonts as much as possible to not increase
the size of the documentation
>> [for Japanese] → Source Han Serif
>
> For Japanese fonts, I suggest HaranoAji.
> It is the default Japanese font from TeX Live 2020.
>
> https://www.ctan.org/pkg/haranoaji
OK, thanks for the suggestion.
Werner
>> * Reduce the number of extra fonts as much as possible to not
>> increase the size of the documentation additionally. [Not much a
>> problem I think since most fonts will be subsetted by
>> ghostscript.]
>
> I'd prefer to focus on fonts that are widely available. DejaVu and
> Libertine a
>>> [for Japanese] → Source Han Serif
>>
>> For Japanese fonts, I suggest HaranoAji.
>> It is the default Japanese font from TeX Live 2020.
>>
>> https://www.ctan.org/pkg/haranoaji
>
> OK, thanks for the suggestion.
After some thinking I'm not sure whether HaranoAji is the best
s
> Added to the tracker as
> https://gitlab.com/lilypond/lilypond/-/issues/6057.
Thanks.
> For the future, maybe this kind of quirks can be reported there
> directly (which would save them from the risk of getting lost under
> the volume of email).
Well, in most cases it's just my own clumsines
> If I understand correctly, LilyPond needs to find the HaranoAji
> font, but Ghostscript does not need to find it.
OK.
> In Texinfo PDF building, you don't need Japanese fonts if only the
> included figure PDFs use the Japanese fonts.
Yes.
> If you want to use Japanese characters in the text
[lilypond dcd531b0f, gs 9.52]
Processing the following sample code
\paper {
#(define fonts
(set-global-fonts
#:roman "Source Han Serif TW"
#:sans "sans-serif"
#:typewriter "monospace"
))
}
\markup { "ろ" } % This is character U+308D.
causes the attach
> If this is indeed a bug [...]
It definitely is.
> could you please open an issue at GitLab?
Done:
https://gitlab.com/lilypond/lilypond/-/issues/6058
Werner
> If I understand correctly, "Source Han Serif TW" is one of
> "Region-specific Subset OTFs". They are subset fonts, so CID !=
> GID.
>
> "Language-specific OTFs" (e.g. "Source Han Serif TC") are not subset
> fonts, so CID==GID. I think these non-subset fonts would be fine.
Maybe your analysis
>> If I understand correctly, "Source Han Serif TW" is one of
>> "Region-specific Subset OTFs". They are subset fonts, so CID !=
>> GID.
>>
>> "Language-specific OTFs" (e.g. "Source Han Serif TC") are not subset
>> fonts, so CID==GID. I think these non-subset fonts would be fine.
>
> Maybe you
> do you think this can be solved within LilyPond? Otherwise I could
> add a service to FreeType so that function `cff_charset_cid_to_gindex`
> (in FreeType's file `src/cff/cffload.c`) gets a public API...[*]
Silly me! FreeType already offers the necessary functionality (see
`ftcid.h`):
FT_
> Silly me! FreeType already offers the necessary functionality (see
> `ftcid.h`):
>
> FT_Get_CID_Is_Internally_CID_Keyed
> FT_Get_CID_From_Glyph_Index
>
> I'll prepare a fix.
Here it is:
https://gitlab.com/lilypond/lilypond/-/merge_requests/474
Please test!
Werner
> See new diffs against master here:
> https://drive.google.com/drive/folders/1czVl2glLVoQiUOLu1mvnWh9hozivaPuC?usp=sharing
>
> I don't know. Some bad examples are gone, while new ones appeared.
Yes. It looks as if the URL code needs new implementation. Gavin's
work-around appears to be too f
[I took the liberty to forward this e-mail to the list. Please write
to the list whenever possible! There you will often get help almost
immediately; additionally, the knowledge base is much broader.]
Hello Damien,
> Are you the developer of LilyPond?
No, I'm not. The original authors are
> I will be the first responder and say that, of the options in the
> pdf, I think Gould is the most appropriate.
Yep.
Werner
> I appreciate that you have given a nuanced response. Practically
> speaking, the vast majority of scores only have bar numbers at the
> beginning of a line, so I will simplistically categorise your response
> as in favour of keeping LilyPond's current behaviour.
I would very much like that Lily
> This discussion/development/enhancement — which is happening just
> after a thread on the FB group about centred measure numbers — has
> made me wonder if it’s possible to roll measure-centred measure
> numbers into the actual BarNumber code [instead of forcing people to
> (ab)use MeasureCounter
> I'd like to present a first workable version of 'make check' for use
> in our CI pipelines. I've pushed the necessary commits to my
> personal fork and created two merge requests to demonstrate the
> results: [...]
This looks very nice, thanks! I don't know enough about the inner
workings of
Hello Kyle,
> I am a US grad student interested in the Lilypond "google summer of
> code" program.
Great!
> I am wondering if the program will run this year,
Probably yes, but...
> and if so which projects will need work
This older list
http://lilypond.org/google-summer-of-code.html
mi
>> xdvipdfmx:fatal: Unable to find TFM file "latt1095".
>
> I noticed the same some time ago, in fact it also occurred with GUB
> during one of the releases. My *guess* is that there is a race
> between multiple texi2pdf invocations that produce the file if it's
> not there. I think this wa
>> AFAIK, the TFM files (and even the master MF files) for the
>> Cyrillic LA font family are created on the fly. What about
>> explicitly creating them as a make prerequisite?
>>
>> mktextfm latt1095
>> mktextfm larm1095
>
> If this is possible, we should certainly do this.
Could you plea
>>> What about explicitly creating them as a make prerequisite?
>>
>> If this is possible, we should certainly do this.
Something like the attached (untested) patch should do.
Werner
diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile
index fbc4692c63..eba1d3ac48 100644
---
>> > But please generate the files in the build directory by
>> > specifying --destdir (and use them from there), putting things in
>> > a cache directory located in the user's $HOME directory is IMHO a
>> > very poor default choice...
>>
>> Why? IMHO those two TFM files are to be handled *exact
>> Something like the attached (untested) patch should do.
>
> Please don't defeat all recent cleanups of the build system by
> putting the same code in there three times, that's bad for
> maintenance reasons. [...]
Done.
https://gitlab.com/lilypond/lilypond/-/merge_requests/520
Werne
>> I strongly disagree. It's definitely not LilyPond's job to decide
>> where the TeX system stores its internal files. In other words,
>> the build infracture has to adjust this, to be handled outside of
>> LilyPond.
>
> Should this part of the font setup be baked into the Docker image?
I do
>>> Should this part of the font setup be baked into the Docker image?
>>
>> I don't know enough about Docker images to decide that. In case
>> the Docker's `$HOME` directory can be easily deleted on a clean-up,
>> nothing needs to be changed IMHO. Otherwise it is trivial to set
>> the `$TEXMFVA
>> Similarly, I have to regenerate various `.map` files by calling
>> `updmap-user` to integrate my private fonts into TeX.
>
> Maybe my use-cases are restricted in that I don't switch away from
> some of the most-commonly used fonts, but having many local user
> fonts is on the other extreme of t
> it's been three weeks since 2.21.80 as the first release candidate
> for the next stable 2.22.0 and there were no (valid) reports about
> bugs that are new in that version compared to 2.20 (as far as I'm
> aware). That said, I'd still like to propose that we release
> 2.21.81 as the second and
Hello Knut,
Welcome back!
> This patch allows to use transparency when creating PDF files.
Nice stuff, thanks!
Werner
> while preparing a patch, I couldn't build the docs on my local branch
> for unknown reasons.
At the beginning of `internals.texi2pdf.log`:
{finger
/home/hermann/lilypond-git/build/Documentation/out-www/en/internals.texi:1659:
Paragraph ended before @var was complete.
>> At the beginning of `internals.texi2pdf.log`:
>>
>> {finger
>>
>> /home/hermann/lilypond-git/build/Documentation/out-www/en/internals.texi:1659:
>> Paragraph ended before @var was complete.
>>
>> @par
>> l.1659
>>
>> I guess you missed a `@`...
>>
>>
>> Wer
401 - 500 of 3549 matches
Mail list logo
