>> I'll soon file a bug report for GS regarding the size issue.
>
> This is now
>
> https://bugs.ghostscript.com/show_bug.cgi?id=706316
And the answer is a devastating 'you were taking advantage of a
limitation in the old PDF interpreter, not a feature [...] And no
possibility of
> I'll soon file a bug report for GS regarding the size issue.
This is now
https://bugs.ghostscript.com/show_bug.cgi?id=706316
Werner
>> Hmm. Just to be sure it makes probably sense to also check whether
>> the Emmentaler OTFs are identical in the binary and documentation
>> builds...
>
> How can I check for this?
You disassemble the fonts with `ttx` from 'fonttools' and compare the
created XML files.
Thanks for the OTF,
> It seems that with the versions of Pango/Fontconfig in this Docker
> image, the backslash character, which doesn't exist in Emmentaler,
> causes a fallback text font to be used, which obviously defeats the
> Emmentaler OTF feature that causes "9" and "\" to be combined
> specially.
Hmm. Just
Have a look at
https://lilypond.org/doc/v2.24/Documentation/notation/font
and check the example for `\figured-bass`, which is wrong. If I
compile this with a current lilypond binary, I get correct output (see
attached image). I also get this if I build the documentation by
myself on my
> Therefore, the proposal here is to add librsvg as a dependency to
> LilyPond. The transitive dependencies it pulls in are libxml2,
> GdkPixbuf, and libjpeg (the latter for GdkPixbuf).
Your proposal sounds good to me.
> * If so, how do we manage the transition? Do we make them optional
>
> I'm around (Adam Good) and though I worked on the turkish-makam.ly file and
> Turkish makam is most my specialty, I'd be happy to look at any ly file you
> may be working on currently and give my thoughts or thumbs up.
Great! Please have a look at Amir's merge request.
> You may want to look at whether
> https://lsr.di.unimi.it/LSR/Item?id=1076 can/should be updated now
> that 2.24 supports some of the glyphs shown.
Hmm. The first five glyphs in the snippet are now part of the
Emmentaler font, but the next eight are not. Actually, I have never
seen such
> Please ignore this; I forgot that there is a difference between a
> syntax change and missing capabilities in newer versions.
s/newer/older/
Werner
> From `convert-ly --help`:
>
> ```
> -d, --diff-version-update
> only update \version number if file is modified
> ```
>
> What do you think of adding this to `makelsr.pl`? Or is there an
> mandatory reason that all snippets are always tagged with the most
> recent
>From `convert-ly --help`:
```
-d, --diff-version-update
only update \version number if file is modified
```
What do you think of adding this to `makelsr.pl`? Or is there an
mandatory reason that all snippets are always tagged with the most
recent development version?
>> > As final step we need to delete the ones from
>> > /Documentation/snippets/new and commit the new state, I would be
>> > very thankful if someone else could do so.
>>
>> I can help with that.
>
> Did I understand correctly, you volunteered to do the final steps,
> i.e.
> (1) Delete all
>> What exactly is your argument for *not* going to version 3.x in
>> that case?
>
> [...] Since this doesn't break backward compatibility, I don't
> think we need a major version bump.
IMHO, a major version bump should also be used if something changes
fundamentally, regardless whether it is
> Let me add a combination here: Ghostscript 10.01.0 built from
> current git (commit 462efa959) yields 28MB with extractpdfmark and
> working links (AFAICT), without changes to LilyPond. The reason is
> likely
>
> [...] I don't see an immediate connection between the new PDF
> interpreter and file size increase (this is what "perfectly fine"
> was referring to).
Too much info is floating around, so here is a table that shows the
various possibilities we are currently investigating.
* Everything is based
>> On the other hand, GS's new PDF engine no longer contains a PS
>> interpreter; it is possible that `extractpdfmark` doesn't work
>> anymore, and we have to find something new...
>
> This is wrong, or at least the new PDF *interpreter* (which is, in
> my understanding, not to be confused with
>> Indeed, but the manuals as a whole, in all languages, get also
>> distributed, and there it *does* make a significant difference
>> IMHO: Right now, the PDFs in `lilypond-2.24.0-documentation.tar.xz`
>> (which has a size of 170MByte) need 144MByte in total
>> (uncompressed). Multiply the
>> The only thing I would like to convince the Cairo people is to add
>> a mode to produce PDFs with font references instead of embedding –
>> and subsetting – fonts. My Cairo knowledge is zero; maybe this is
>> already possible?
>
> This makes no sense to me as a Cairo feature. Such PDF
>> We could then get rid of Ghostscript completely.
Mhmm, please ignore this sentence, it doesn't make sense.
> So, to be clear, in your opinion, solving this is a requirement
> before we drop the old PS backend?
Well, 'dropping the old PS backend' is something we should do very
carefully.
> And again, it's not like the NR PDF was unusable when it was
> ~35 MB in LilyPond 2.18.
>
> What alternative would you propose?
In the next days I will investigate how to get small PDFs with the new
PDF engine of Ghostscript, reporting problems to the maintainers.
Let's see what this will
>> Honestly, a fourfold size increase is not something that I would
>> call 'acceptable'.
>
> Upstream might need some convincing.
>
> Ghostscript's Ken Sharp in 2017:
>
> "When we have customers wanting to send us 125GB files I have to say
> that a concern over file sizes in the few megabytes
>> The idea is that you compile all snippets with references to fonts
>> only but not with actual fonts. This allows Ghostscript to analyze
>> and squeeze the fonts of all included PDFs globally; as an example,
>> the NR then has only a few dozen (subsetted) fonts instead of about
>> 4500.
>
>
> Should slurs require Stem_engraver?
>
> No: https://gitlab.com/lilypond/lilypond/-/issues/3760#note_339794300
> Yes:
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1800#note_1227831830
>
> I'm looking for some input from old-timers to help decide this so I
> can avoid wasting more
> With extractpdfmark
> ===
>
> PS backend:
>
> 4,8M Documentation/out-www/en/notation.pdf
FYI: Using a recent GS version with its new PDF backend, the size gets
larger than 20MByte. I guess this is a bug, and I will soon report
this to the GS people so that it gets fixed
> * outdated: cs (last update by Pavel in 2012; some passages copied
> from German manual!), nl (last update by Jan in 2012)
>
> Especially the last category is bad and I would like to propose that
> we delete these translations; I think it is better to have the
> community use the English
>> Oh, the files in `new` are not what I'm concerned about. It's
>> rather running `convert-ly` on all other snippets in the LSR...
>
> Once LSR runs 2.24.0 Sebastiano gets a tarball with them and inserts
> the snippets.
OK, thanks. So he can actually do a mass import.
Werner
> But come on, you don't need to be experts to discover code
> duplication. [...]
Right now, you are only ranting. This doesn't help anybody. Please
provide a patch or series of patches (ideally, as an Merge Request)
that we can discuss further. Everyhing else is pointless, as far as I
can
>> Ideally, there would be a git repository to which we can actually
>> push the new files (to retain the editing history), and a script
>> that regenerates the database automatically – and vice versa.
>
> Werner, actually it's less work than expected.
> Currently /Documentations/snippets/new
> Here the next one: What's html for @@code@{TupletBracket@}
> ?
Are you talking about
`it/texidocs/controlling-tuplet-bracket-visibility.texidoc`? There,
`@@code@{TupletBracket@}` is wrong; it should be
`@code{TupletBracket}` instead.
The HTML equivalent to `@code{TupletBracket}` is
> I could do (in the description)
>
> (1) fa
> (2) fa
> (3) 'fa'
>
> What do you recommend?
Assuming that people are going to translate this I would do (1).
Werner
> What are the html equivalents of @qq{…} and @q{…}?
There is no stand-alone equivalent to `@q`. If you write
```
foo
```
it gets converted by `pandoc` to
```
``foo''
```
which `makelsr.pl` in turn converts to `@qq{foo}`.
You get
```
`foo'
```
only for the inner quote environment if you
Hallo Harm,
a Happy New Year to you and all other LilyPonders!
> In our doc-strings we sometimes have @tie{} to get an unbreakable
> space. As lsr-editor I need similar for html. Is the
> correct equivalent?
Yes. Note that U+00A0 would also work.
> Will correctly be transformed to
While
https://lilypond.org/development.html
mentions the CG, it is missing from
https://lilypond.org/manuals.html
Is this intentional? Since the CG contains the build instructions it
might be useful for 2.24 too, especially for package maintainers...
Werner
>> new contributions with (I'm sorry but thats the truth) bad quality
>> over proven ones, that have been existing since 2008 at least, have
>> been included into lilypond without questioning its purpose
>
> (1) Take the specialist's proposal at face value, beyond obvious and
> immediate
> Lateron, when LSR runs 2.24.0, we need to insert all snippets from
> /Documentation/snippets/new. This is tedious, any help would be
> great.
Sebastiano, if we send you an archive with all updated snippets: Do
you have a possibility to mass-import them into the database?
Submitting them one
> We are happy to announce the release of LilyPond 2.25.0, the start
> of the next development cycle. [...]
Thanks for doing a new release, and Merry Xmas!
Werner
> And thank you Jonas for the release work.
Hear, hear!
Werner
> My pit players sometimes have to play, in the same piece, five or
> more instruments of different transposition (e.g., flute, Alto Sax,
> Tenor Sax, Bb clarinet, Eb clarinet) — breaking every piece down
> into multiple chunks is not only inefficient, time-consuming, and
> error-prone from a
>> Please show (images of) typical examples of what you want to see.
>> I can imagine that such a feature would be worth adding.
Do you want this?
```
\version "2.23.14"
global = {
%% v1
\key c \major
s1*4
\bar "||"
%% v2
\key d \major
s1*4
\bar "|."
}
%% NOTE:
> %% PART (TRANSPOSED)
> %% What’s the least amount of work required
> %% to make this transposed part, with correct key signature?
It's not clear to me what exactly the output should look like. Please
show an image or some pseudo notation.
Werner
> Will that handle the automatic switching of key signatures, etc.?
No.
> As someone who writes multi-instrumentalist parts [for musical pit
> orchestras], this has been a low-grade PITA for almost 20 years — it
> would be really great if we could use this “deprecation” moment[um]
> to figure
> I also realized that I forgot to send a draft release announcement
> text, which I originally wanted to share during the weekend. I went
> with the standard text, copying from the previous stable release:
> [...]
LGTM, thanks!
Werner
> Well, somehow I failed to make the obvious test: this also triggers
> the issue:
>
> \version "2.25.0"
>
> \markup \override #'(font-name . "Noto Sans Bold") "ABC"
>
>
>
> Does that reproduce it for you (after installing the Noto fonts if
> not already installed)?
>
`lilypond
>> *Theoretically*, this fixes the issue.
>
> I still don't understand how this MR helps.
>
> Say I am running 2.25.0 which has this fix, but I have 2.25.1
> installed globally. It will predictably make 2.25.0 use the font
> files from 2.25.1 because they have a higher version. Or am I
>
> Then, the two font files, one from 2.23.7 and the good one from
> 2.23.10, are conflicting under the name "Emmentaler 11" for being
> embedded in the PS file. [...]
Could you try to apply the effects of
https://gitlab.com/lilypond/lilypond/-/merge_requests/1758
to the two problematic
>> What about adding
>>
>> ```
>> .../lilypond/XX.YY.ZZ/fonts/otf
>> ```
>>
>> at the top of `00-lilypond-fonts.conf`? According to the
>> maintainer of FontConfig, first directory gets served first, and
>> the `00-*` file is read before anything else.
>
> I already tried this and it didn't
>> Masamichi-san, can you advise a solution? Would it be possible and
>> would make it sense to add a directory specifier to
>> `00-lilypond-fonts.conf`?
>
> I didn't find a way to do it in the configuration file directly,
> [...]
What about adding
```
.../lilypond/XX.YY.ZZ/fonts/otf
```
at
> The question is, do we consider this a problem important enough to
> not release 2.24.0?
IMHO, this is not important enough to delay 2.24.0.
Werner
>> "/usr/share/fonts/lilypond/emmentaler-20.otf" <<<== Whoops
>
> Yes, whoops!
>
>> I don't even understand how that can work. How is Fontconfig finding
>> the Emmentaler fonts in the LilyPond package?
I think
https://gitlab.com/lilypond/lilypond/-/merge_requests/1758
will help in the
> OK, I have found something that looks bad on my system, although I
> can't reproduce Lukas' problem: for me, this:
>
> ```
> \version "2.23.82"
>
> \markup
> $(markup-lambda (layout props x) (markup?)
> (let ((stil (interpret-markup layout props x)))
> (pretty-print (ly:stencil-expr
> \markup \override #'(font-name . "Nonexistent Bold") "ABC"
>
> With 2.22, this compiles without warning, and the resulting PDF
> contains the font "DejaVuSans-Bold" (according to pdffonts).
>
> With 2.23.82, it gives me
>
> GNU LilyPond 2.23.82 (running Guile 2.2)
> Processing
> In any case, here are images again as attachments. They don't look
> like Werner's.
Assuming that you run under GNU/Linux: Try to recreate all FontConfig
files with `fc-cache --really-force` (probably as a superuser, too).
I sometimes got issues with that.
Werner
> if I do
>
> \version "2.23.82"
>
> \new FiguredBass \figuremode {
> <6> <_+> <_-> <_!>
> }
>
> I get:
>
> As soon as I do
>
> \version "2.23.82"
>
> \new FiguredBass \figuremode {
> <6> <_+> <_-> <_!> <6!>
> }
>
> this becomes
Image missing.
> I'm pretty sure this is not how it's
> Until Sunday, December 11th:
> - merge https://gitlab.com/lilypond/lilypond/-/merge_requests/1710 and
> other release preparations (VERSION, convert-ly rule, something else?)
> - backport the remaining "safe" changes (currently !1747, one commit
> from !1751, !1752)
> - finish translated
> ```
> blabla @lilycode{\relative { c'2 e }} blabla
> ```
>
> Example 2:
>
> ```
> blabla
>
> @lilycode
> \relative { c'2 e {
> @end lilycode
> ```
>
> While the use for the block command version (`@lilycode ... @end
> lilycode`) should be clear, the main question is what policy we are
>
>> Since the whole LilyPond code string is under the control of
>> `lilypond-book`, I thought of inserting `@/` automatically. I
>> would also insert `@tie{}` after `^[^ ] ` and before ` [^ ]$` to
>> avoid a single character at the beginning or end of a line in the
>> output.
>>
>> I've also
>> I suggest to apply `@lilycode` only if highlighting has some useful
>> effects, which means that in most cases it should be rather *not*
>> used because inline code is very short.
>
> AFAICT, the argument to inline @lilycode will always be a longer
> code sample, which in the current scheme
Folks,
in MR !1753
https://gitlab.com/lilypond/lilypond/-/merge_requests/1753
I've extended `lilypond-book` to highlight LilyPond code snippets,
without producing actual LilyPond output. Because it uses Pygments,
code snippets are also highlighted (more or less) correctly if the
code is
>> What concerns me most is the non-portability of locale names, for
>> example 'fr_FR', 'fr.UTF-8', 'fr_FR.utf8', 'fr_FR.UTF-8', or
>> 'French_France.65001'.
>
> I thought locales were already standardised ...
>
> languagecode underscore countrycode dot characterset
This is the theory, yes.
> As shown by https://gitlab.com/lilypond/lilypond/-/issues/6463,
> Guile regular expressions are a trap when it comes to Unicode.
> Under a non-Unicode locale, characters that can't be expressed in
> the locale encoding get converted to "?", both in the pattern and
> the search string, before
> [...] locales are not small and easy but quite heavy instead – the
> `/usr/lib/locale` directory on my openSUSE GNU/Linux box provides
> 494 locales and has a whopping size of 227MByte, mainly for
> collation and character type information. Normally, you won't get a
> single locale as a
> Is it sustainable to build a 2D dictionary keyed by platform and a
> name of our choosing for the locale to use as a map and fill it
> gradually as we discover new holes?
Well, I will eventually build on the wisdom of other guys, in
particular the people from the 'gnulib' library, who deal
> I'd have thought au jour d'ui 227MB qualifies as small, no? It's
> averaging at 500kB/package which is bigger than I thought (I'd have
> thought more like 50k tops, tbh) but it seems like it'd be a
> relatively manageable size for a one-off setup...
For me, it's a big package. However, I
> Question: I would have thought locales would be a) largely present,
> b) small and easy to install as dependencies, like many other
> dependencies we have (and substantially less prone to change than
> any software dependency)
>
> Where does the concern with locales not being available on a
> Indeed, I didn't find a Perl library that would support locales
> without them being present on the system. However, all of
>
> https://perldoc.perl.org/Unicode::Collate (Perl)
> https://github.com/jtauber/pyuca (Python)
> https://docs.rs/unicode-collation/0.0.1/unicode_collation/ (Rust)
>
> Am I understanding it correctly that with this plus the already
> merged https://gitlab.com/lilypond/lilypond/-/merge_requests/1715,
> we don't need the Autoconf UTF-8 locale searching stuff anymore, at
> least for now?
Correct. I've already cleaned up all index entries in previous
commits
> It is the doc autogeneration infrastructure that is not correctly
> writing the NR appendix files as UTF-8. It should be using
> set-port-encoding!.
Will you submit a MR?
Werner
Date: Mon, 28 Nov 2022 09:18:25 +0100
>> `texindex` is just one part of the problem.[*] We also need a UTF-8
>> locale for both `makeinfo` and `lilypond-book` – without it, the
>> output for both PDF and HTML is simply wrong. My standard example
>> is the incorrect display of the degree sign in
>> What I'm now working on are macros for `configure.ac` to find a
>> UTF-8 locale, which is important for the documentation generation
>> in the long run. [...]
>
> Phooey, that sounds complicated. I wonder if it would not take just
> as much time to reimplement texindex in Perl, as
> What is the state of this discussion? Werner, what is your opinion
> on using LuaTeX exclusively now that this point has been cleared up?
For me, this is OK. What I'm now working on are macros for
`configure.ac` to find a UTF-8 locale, which is important for the
documentation generation in
> Why the difference in value? Red is 10% off, green more like 30%?
Different standards (terminal colors vs. X11/CSS): identical names but
different colours.
Werner
>>> lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkred
>>> color.scm: (darkred 0.54509803921568623 0 0)
>>> output-lib.scm:(define-public darkred '(0.5 0.0 0.0))
>>>
>>> lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkgreen
>>> color.scm: (darkgreen 0
> Yes indeed (I suspect red gets parsed to #'red, no?). I never took
> the time to find out what's happening there behind the scenes, but
> as a frequent user of the colors "darkred" and "darkgreen", I'm a
> bit nervous about:
>
> lukas@Aquarium:~/git/lilypond/scm(master)$ git grep darkred
>
>> OK, thanks. I wonder how the heuristics could be improved. Given
>> that a lyric hyphen must be preceded by whitespace, while normally
>> `--` as an articulation is following a non-whitespace character,
>> maybe a look-behind assertion for the latter would help? Something
>> similar could
>>> Are there still cases where `#` is mandatory for numbers?
>>> Otherwise the documentation could be updated to remove all `#`.
>>
>> Yes, there are: In markup, for example.
>>
>> \markup \fontsize 3 Hi
>>
>> is still illegal.
OK, but where exactly is this documented? Is this missing, or am I
>> However,
>>
>> \musicFunction 4
>>
>> could be an integer or a duration, and
>>
>> \musicFunction -4
>>
>> could be an integer or a fingering, depending on how musicFunction
>> is defined, [...]
>
> Thanks, I didn't think of music functions.
In the NR, most such functions have its argument
>> Why not. If you want to be even more precise on what you want to
>> match:
>>
>> -\d+|((\d+|\\breve|\\longa)\.*)
>
> if someone really wants to touch that, please note that \maxima too
> is a duration.
Indeed, this is missing. I will add this to my work that will
eventually result in a PR
>> The thing is that the regular expressions match both LilyPond and
>> Scheme syntax.
>
> Uh? No they don’t, look at SchemeLexer and its horrendous regexes to
> parse numbers (also written by yours truly).
Thanks for the correction; this makes adjusting the regular
expressions simpler :-)
>
>> Note that at the time this regex is active, numbers are taken care
>> of.
>
> Floats are, integers not.
OK, but shouldn't this be rather
```
(-?\d+|\\longa|\\breve)\.*
```
then?
Werner
> well -3 seems to be matching it, (say in a-3, I'm aware this is a
> fingering/articulation mark, not a duration). It appears to be an
> attempt to match a signed integer followed by zero or more dots.
The thing is that the regular expressions match both LilyPond and
Scheme syntax.
> It sucks
Looking into `lilypond.py` (in `pygments.zip`), I wonder what exactly
this regex does:
```
# Integer, or duration with optional augmentation dots. We have no
# way to distinguish these, so we highlight them all as numbers.
(r"-?(\d+|\\longa|\\breve)\.*", Token.Number),
```
What is `-?` good
> Which brings me to my second point, that I share Jean's concern and
> the reasoning about supporting three TeX engines and appreciated him
> asking if we could drop support for some as pretty much the first
> comment on the merge request, less than a day after it was posted:
>
>> The problem is the startup time of luatex. For processing our more
>> than 1000 small snippets that are embedded in the final
>> documentation (as PDF files), this sums up.
>
> Why would the snippets cause multiple startups of luatex?
Oops, brain fart, I mixed it up ghostscript. Sorry for
>> !1734 Resurrect banana commas - Werner Lemberg
>> https://gitlab.com/lilypond/lilypond/-/merge_requests/1734
>
> Heh, "banana". But seriously, many thanks for the quick fix,
> Werner!
:-) Someone on the list (or in a MR/bug issue) used this word for the
sha
> I'd say that for a 80-100page document it's maybe somewhere between
> 50% and twice as slow. Still it's a several seconds build that
> becomes more several seconds. I'm not sure it crosses important
> workflow thresholds [1], it certainly didn't in my own use.
The problem is the startup time
>> The thing is: Something might happen if I'm not available, for
>> whatever reasons. It definitely *is* a high maintenance cost if a
>> single developer is responsible...
>
> But that's true of any one feature: I build you a nice template
> library to do in and you find a bug
> while I'm .
> Sorry, luatex is like 10yrs old, what's the need for xetex again?
Some issues that potentially speak against using luatex:
* LuaTeX's OpenType support is still in flux and sometimes buggy. The
future is probably luatex-hb, using the 'HarfBuzz' library for
OpenType font handling.
* The
>> build problems are fixed by developers, not users, sometimes very
>> painfully, and using time that they could spend on other tasks.
>
> If Werner's change breaks the build, surely he'll be the first one
> to argue it's on him to fix it (possibly with help to learn how
> tonfix whatever he
> Note that I personally haven’t objected to declaring LuaTeX
> supported. I do object to keeping XeTeX in that case.
To clarify what Jean wants if he mentions 'maintenance burden': We are
talking about a potential change checking for all three TeX variants
in the `configure` script, or rather,
>> There are a bunch of LaTeX packages that only work with a specific
>> TeX engine, and which need special input code for that. For
>> example, `fontspec` (with its excellent OpenType support) only
>> works with XeTeX and luatex. Or think of 'lyluatex', which
>> obviously needs luatex.
>
>
>> There are a bunch of LaTeX packages that only work with a specific
>> TeX engine, and which need special input code for that. For
>> example, `fontspec` (with its excellent OpenType support) only
>> works with XeTeX and luatex. Or think of 'lyluatex', which
>> obviously needs luatex.
>
>
>> in LaTeX, there are *really* differences depending on the engine.
>
> Oh, really? Color me surprised. Are there tools other than build
> systems that read those environment variables? And users set them
> globally, in spite of the incompatibilities that exist between the
> TeX engines?
There
>> Luatex would be the final engine to support.
>
> [...] I see no reason to assume that there won't be yet another
> engine (LuaTeX is already the fourth, if I count correctly),
Jonas, please don't think absolute, think *relative*! If I say
'final', *of course* I mean the engines available
> On the other hand, most contributors (except those who want to
> fine-tune the typography, i.e. basically you, Werner) will want the
> doc build to be as fast as possible, so I'm not fond of using it by
> default.
OK. I will adapt my patch accordingly and remove luatex from the
`configure`
> Luatex is always available with modern tex distros (say at least 5
> yrs probably more). In fact pdftex _is_ luatex...
??? Definitely not.
```
> pdftex --version
pdfTeX 3.141592653-2.6-1.40.24 (TeX Live 2022)
kpathsea version 6.3.4
Copyright 2022 Han The Thanh (pdfTeX) et al.
There is NO
>> In https://gitlab.com/lilypond/lilypond/-/merge_requests/1714 I
>> suggest that we prefer luatex for building the documentation. What
>> do people think?
>
> What I'm missing here is the bigger picture: Are we going to
> continue adding support and switching between TeX engines one after
>
In https://gitlab.com/lilypond/lilypond/-/merge_requests/1714 I
suggest that we prefer luatex for building the documentation. What do
people think?
The main advantage of using luatex is complete microtype support; this
was activated recently in `texinfo.tex`, and XeTeX doesn't support it
in its
>> Looking into
>>
>> https://gitlab.com/lilypond/lilypond/-/pipelines
>>
>> I see that for every merge I do, two pipelines are executed.
>> Apparently, this doesn't happen for Jean. What am I doing wrong?
>
> Nothing. There is one pipeline on the merge request to test it,
> then one
>> It would be necessary to add another property to stencils, say, an
>> 'active' flag, so that they can be intentionally taken out of a
>> skyline.
>
> YAGNI. Just use ly:stencil-outline.
OK.
> Are you mindful that ly:make-stencil is a low-level function? If you
> use it, you need to have an
Looking into
https://gitlab.com/lilypond/lilypond/-/pipelines
I see that for every merge I do, two pipelines are executed.
Apparently, this doesn't happen for Jean. What am I doing wrong?
Note that I simply press the 'Rebase' button followed by 'Merge if
rebase succeeds'.
Werner
201 - 300 of 3179 matches
Mail list logo
