Right now, only
```
figuredBassFormatter = #format-bass-figure
```
is set in the definition of `Score` (in file `engraver-init.ly`).
Listening to Jean I think it's best to move all other figured bass
context properties to that location, too. These properties are
figuredBassLargeNumberAlignm
>> These properties are
>>
>>figuredBassLargeNumberAlignment (default: CENTER)
>>figuredBassAlterationDirection (default: #f)
>>figuredBassPlusDirection (default: #f)
>>
>> There will be one more (`figuredBassPlusStrokedAlist`) that I need for
>> my new figured bass symbols in MR 1460..
> Two pages in an NR appendix.
OK.
> Can you force them to face each other?
I think so, yes, with some TeX trickery.
Werner
Two days ago I've updated my openSUSE box, which now comes with gs
9.56.1 – previously, I had gs 9.54.0. This new gs version uses a
brand-new PDF engine written in C, replacing the old one written in
PostScript.
Building the LilyPond documentation I wondered why the new output file
size of `nota
>> In case you are forced to use 9.56.1, add `-dNEWPDF=false` to the
>> gs command line options (in file `Documentation/GNUmakefile`) to
>> make gs use the old PDF engine, which produces good results.
>
> So this is about the post-processing step with extractpdfmark + gs,
> right?
Yes – I always
> GregorianTranscriptionStaff currently shows a time signature. Is
> that desirable?
As discussed in
https://gitlab.com/lilypond/lilypond/-/merge_requests/1515#note_1045453533
I think it makes sense to have time signatures if you transcribe
polyphonic music that uses Gregorian chant notatio
Two weeks ago Dan asked the following:
>> Can you force them to face each other?
>
> I think so, yes, with some TeX trickery.
I've now had a closer look. Currently, LilyPond's PDF documentation
is created in single-side mode, i.e., the page numbers are always in
the upper right corner. It is
> While the typesetting probably could use left-facing and
> right-facing pages more intentionally, I have never really had any
> problems with the existing layout.
Well, it's not about the existing layout – even if we are going to use
double-sided formatting, it wouldn't change much (besides som
>> Well, it's not about the existing layout – even if we are going to
>> use double-sided formatting, it wouldn't change much (besides some
>> shifts in page numbering). The thing is that only in double-sided
>> mode I can easily arrange the documentation to make the visual
>> index appear on fac
>> !1525 Divisio_engraver - Dan Eble
>> https://gitlab.com/lilypond/lilypond/-/merge_requests/1525
>
> Those with an interest in ancient music, please take note. I don't
> want you thinking of me next time you are singing Psalm 94.
:-) It would be nice to see larger real-world examples types
> If I build the docs I use 'extractpdfmark' as well. In the light of
> this thread I tried ghostscript self-compiled from their most recent
> master, giving me 9.57.0. [...]
>
> [compilation time] is insane.
I also noticed a slower documentation build with ghostscript's new PDF
engine, but not
> "Hymn template"
> https://lsr.di.unimi.it/LSR/Item?id=703
>
> I don't see any way to find the author of a snippet.
Alas, this information is not in the LSR database dump. The only
information I can extract is
id_owner_usr: 69
Sebastiano, would there be a way to contact the person who is
as
>> {
>> c'1
>> \mark \default
>> \repeat segno 2 {
>> c'1
>> }
>> }
> The marks that \repeat segno creates are intended to identify points
> of repetition and departure for performance. Having one of those, I
> do not understand why one would want to identify the same point with
> a
> - Variants of font glyphs: Werner, is this still relevant?
Yes.
Werner
>> OK. Does it sound better to use "nonce" for the semi-deprecated
>> feature as you say, or actually for the new feature? Is it clearer
>> than "ad-hoc"? ("nonce" is a word that I learnt today.)
>
> Or maybe \textMark and \textEndMark? I'm not sure.
I prefer `\textMark` over 'ad-hoc' or 'nonce
> If you add back some margins, you will see that there is a bar
> number on the left of the system, which is out of the page when
> margins are removed, but nevertheless takes vertical space. Add
>
> \layout {
> \context {
> \Score
> \remove Bar_number_engraver
> }
> }
That's it, tha
> I see that CaesuraScript is highlighted differently than other grob
> names in this text:
>
> \override Score.Script.color = ...
> \override Score.MultiMesaureRestScript.color = ...
> \override Score.CaesuraScript.color = ...
>
> Can I do something to address this? TIA.
Well, fi
Look at the documention of `\with-url` in the PDF version of the NR:
The link in the included snippet (to 'lilypond.org') doesn't work.
This is a limitation of pdfTeX (or XeTeX), which drops all links and
annotations for included PDF files.
Masamichi-san, is it possible to extend `extractpdfmark`
> As with the Java part of `pax`, it may be possible to extract
> annotations from PDFs with a C/C++ program. But, it looks like
> `latex-pax` is adding the extracted annotations to the PDF using
> `pax.sty`. The `pax.sty` is for LaTeX, and it looks like it is for
> pdfLaTeX only. It would be
>> I've tried some more and probably developed an understanding of
>> what's happening - I will post on the upstream issue later. For our
>> use case, however, we can "cheat" a bit because we statically link
>> both bdwgc and libguile;
>> https://gitlab.com/lilypond/lilypond/-/merge_requests/1627
I've noticed in the NR that stuff like `\foo` isn't always coloured as
expected (i.e., `\foo` isn't always bold). Attached are two examples
from the NR.
I wonder whether it makes sense to always embolden stuff starting with
`\` (except in a string). This might even include `\1` and friends.
>> I've noticed in the NR that stuff like `\foo` isn't always coloured
>> as expected (i.e., `\foo` isn't always bold). Attached are two
>> examples from the NR.
>>
>> I wonder whether it makes sense to always embolden stuff starting
>> with `\` (except in a string). This might even include `\1` a
> \open is lexed as Token.Name.Builtin.Articulation, which the PDF
> style in book_highlight.py explicitly doesn't make bold:
>
>
> # A custom black-and-white style designed for the PDF documentation.
> pdf_styles = {
> Token: "",
> Token.Whitespace: "",
> Token.Text: "",
> Token
In the end of July I wrote:
> Two days ago I've updated my openSUSE box, which now comes with gs
> 9.56.1 – previously, I had gs 9.54.0. This new gs version uses a
> brand-new PDF engine written in C, replacing the old one written in
> PostScript.
>
> Building the LilyPond documentation I wonde
> If you run this on master:
>
> perl scripts/auxiliar/makelsr.pl --new
>
> you get
>
> $ git diff --stat
> Documentation/snippets/accordion-register-symbols.ly | 2 +-
>
> [...]
>
> There are \version changes for snippets that come from new; they
> seem to change from \version "2.23.12" to \ve
> [...] I wonder if there should be a way not to introduce unrelated
> changes in an MR. Right now, if I change one line in a snippet in
> new/, the MR diff will be cluttered by all those version updates.
> Or am I expected to only commit the relevant files anyway?
The latter, because...
> IIRC,
I've just submitted
https://gitlab.com/lilypond/lilypond/-/merge_requests/1643
to improve `makelsr.pl`. Running CI for this MR is a waste of
resources because this script is not part of the normal build and test
cycle – we could add `[skip ci]` to avoid that. Shall I do that for
this commit
>> [...] – we could add `[skip ci]` to avoid that. Shall I do that
>> for this commit and similar ones in the future?
>
> Can you make it so that it'll skip CI in the initial MR upload and
> in subsequent iterations, but still spawn a pipeline when merging?
Is this possible? AFAIK, there is onl
> Documentation/snippets/how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-2.ly
>
> is still there. Yet it doesn't have the doc tag anymore.
There is still a file with this name in `snippets/new`...
Werner
Look at section 3.1.10, 'BaloonText'
https://lilypond.org/doc/v2.23/Documentation/internals-big-page.html#balloontext
We still have
break-visibility (vector): #
...
Is there any chance to have this improved before the release? Being
modest, just stripping `/build/out/...` would alrea
>> We still have
>>
>>break-visibility (vector): #>/build/out/share/lilypond/current/scm/lily/output-lib.scm:2973:0
>>(grob)>
>>
>>...
>
> Sounds like https://gitlab.com/lilypond/lilypond/-/issues/6312
Yeah, it does.
Werner
>> I think we should branch now. What do others think?
>
> Needless to say that I agree, but as you witnessed nobody else
> bothers to reply.
Sorry, I got the impression that we already made a decision to do so.
For the record, I also agree.
> Discussions on MRs opened during the weekend also s
> There are two dimensions here: First, I personally think it doesn't
> make sense to create a stable branch from a random commit. It
> doesn't have to be perfect, but it should fulfill some basic
> criteria of "stable". This is best tested after a development
> release, which is what the origi
>> Honestly, I think that your criteria for creating pre-release of
>> 2.24 are too rigid. As far as I can see, doing a 2.23.80 release
>> *right now* is the way to go.
>
> Fine, if you disagree with the plan laid out in August, I invite you
> to volunteer taking care of the releases and the rel
> So how about the following plan:
>
> !1510 could perhaps be merged faster than usual for an MR on Review,
> !e.g. on Saturday (it has already been reviewed and the latest
> !update was minor changes, I tried a different approach but it was
> !too complex so I eventually went back to the previo
> Is that OK with everyone?
+1
Werner
> Wednesday, October 12: Branch stable/2.24 unless we get some serious
> problem reports for 2.23.14
>
> [ branch is frozen, no new features or syntax changes; master is
> bumped to 2.25.0 and is open again for development; I will pick
> fixes into the stable branch; translation work continues o
> \column \override #'(font-name . "Arial Bold") {
>D A F♯ D A D
> }
Using `font-name` is 'absolute', that is, it overrides any LilyPond
font switching mechanism. This means that `\number` doesn't work.
There are two solutions: Either set up a font tree so that you can use
standard command
> The page
>
> https://lilypond.org/doc/v2.23/Documentation/notation/writing-text.html#text-marks
>
> is missing some backslashes in the box [...]
>
> I don't immediately see what this discrepancy could be caused by,
> apart from a bug or limitation of texi2html 1.82.
>
> Can this be worked aro
> The LSR is advertised as being released under the public domain.
> [...]
>
> The following exceptions apply:
>
> * It does not apply to input files (contained in the directory
> tree Documentation/snippets/); these are in the public domain.
> [...]
>
> So far, so good. However, take
>> You just don't become the copyright owner of the code, i.e., the
>> copyright header in the source repository should give the name of
>> the original author.
>
> I have to correct myself. This is not correct, since copyright
> doesn't exist for something in the public domain (as opposed to
>
>> BTW, the term 'public domain' is problematic in Europe, since this
>> US law construct doesn't necessarily mean the same in all
>> countries, in particular not in Germany.[*]
>>
>> Maybe it should be changed to CC0
>> (https://creativecommons.org/publicdomain/zero/1.0/deed) for
>> further con
> I propose a documentation change so that the actual colours are
> shown in the manual, to make it easier for users to make colour
> choices for their notation. [...] Note that I would probably keep
> the colour names written in black, for readability, and then add
> something like squares sho
>> I propose a documentation change so that the actual colours are
>> shown in the manual, to make it easier for users to make colour
>> choices for their notation. [...] Note that I would probably keep
>> the colour names written in black, for readability, and then add
>> something like square
>> You just have to "escape" it, like in texidocs:
>>
>> @code{\\textMark} et @code{\\textEndMark}
>>
>>
>> I'll prepare a MR later today for text.itely.
>
> If I do that, the backslash does appear in HTML, but there are two
> backslashes in the PDF.
We could define a macro `@bscode`, to be use
>> We could define a macro `@bscode`, to be used in `@warning` only. Add
>> the following to `common-macros.itely`
>>
>> ```
>> @macro bscode{TEXT}
>> @code{\\\TEXT\}
>> @end macro
>> ```
>
> Honestly, if there isn't a way to fix @warning globally, I think it
> is simpler just not to use it her
> [...] In Sphinx, this is just a matter of reading the LilyPond input
> in a Python extension and inserting the output at that point, as is
> already done in
>
> https://pypi.org/project/sphinxcontrib-lilypond/
> or the alternative
> https://github.com/sphinx-notes/lilypond
>
> Which means tha
Please have a look at the attached image; it's taken from the LM,
chapter 3.1.4. As can be seen, `_` and `-` are bold, and `^` isn't.
Is it possible to make `_` and `-` bold only if used as articulation
(i.e., *after* `[_^-]`)?
Werner
Please have a look at the attached image, taken from the LM section
3.4.1. As can be seen, the second variable ('cello') is bold, while
the first one ('violin') isn't. Can this be fixed?
Werner
> The problem is that "violin" is also the name of a clef: [...]
Ah, yes, thanks. Will fix the example.
> [...] in general the Pygments lexer would have to be far smarter in
> order to distinguish cases where a particular word is used as a
> user-defined name vs. those where it should be highlig
> With the start-afresh approach for lilypond-texi2html.init, it seems
> to me the first thing that would be needed is a regtest or Minimal
> Working Example of sorts: A concise texinfo file calling for each
> feature or function needing equivalent replication in the upgrade.
>
> Once the target
While working on the LM I see the following example in section 4.1.3:
```
\new Staff {
\relative {
r4 g'8 g c4 c8 d |
e4 r8
<<
{ f8 c c }
\new Staff { f8 f c }
>>
r4 |
}
}
```
I now wonder why the last two notes of the temporary (lower) staff
don't have a beam
>> Please have a look at the attached image; it's taken from the LM,
>> chapter 3.1.4. As can be seen, `_` and `-` are bold, and `^`
>> isn't. Is it possible to make `_` and `-` bold only if used as
>> articulation (i.e., *after* `[_^-]`)?
>
> The relevant part of the output generated by lilypon
>> While working on the LM I see the following example in section 4.1.3:
>> ```
>> \new Staff {
>> \relative {
>> r4 g'8 g c4 c8 d |
>> e4 r8
>> <<
>> { f8 c c }
>> \new Staff { f8 f c }
>> >>
>> r4 |
>> }
>> }
>> ```
>> I now wonder why the last two notes of the
>> ```
>> c''4-3 e-5 b-2 a-1
>> ```
>>
>> which Pygments translates to
>>
>> ```
>> @t{c''} @t{4} @t{-3} @t{e} @t{-5} @t{b} @t{-2} @t{a} @t{-1}
>> ```
>>
>> that is, the `-` is not typeset in bold.
>
> Because "-3" could just as well be a number rather than a fingering,
> and it's hard to guess.
>
>> With your changes to figured bass in 2.23.12, this snippet no
>> longer has the '+' centered below '7':
>>
>> \version "2.23.11"
>>
>> \new FiguredBass {
>> \figuremode {
>> <7 _\+>
>> }
>> }
Yep. For correct alignment of figured-bass glyphs, the columns are
now left-aligned.
>> Do y
> I also checked in my book « Théorie de la musique » by A. Danhauser
> (1994 version) where you can find the attached table (page 130) in
> which you will see the + appearing in other chords too (all related
> to the leading-tone)
Interesting, never seen that before.
> [...] it would be nice to
>> [...] it would be nice to have a direct way to enter it and some
>> examples in the documentation.
>
> Of course. Will have a look soon.
See
https://gitlab.com/lilypond/lilypond/-/merge_requests/1727
Werner
> 1. Review and merge the fix this weekend and release 2.23.81, hoping
>that it doesn't break text replacements in other ways. Assuming
>things go well, we could still have the final 2.24.0 in early
>December.
>
> 2. Release 2.23.81 without the fix and instead review it
>properly.
> We are happy to announce the release of LilyPond 2.23.81. This is
> the second release candidate towards the next stable version 2.24.0
> expected in December. Please test your scores with this version and
> report back the experience as well as any problems you encounter.
> Please refer to the
Consider this input.
```
\version "2.23.81"
#(define-markup-command (strut layout props)
()
#:properties ((baseline-skip))
(ly:make-stencil ""
empty-interval
(cons (* -0.3 baseline-skip)
(* 0.7 baseline-skip
{
\ove
>> Why is the vertical extent of the strut ignored?
>
> Because side positioning is primarily based on (vertical) skylines,
> not extents.
Thanks. What is the reasoning behind this? For me, this behaviour is
unexpected.
Werner
Why is the vertical extent of the strut ignored?
>>>
>>> Because side positioning is primarily based on (vertical)
>>> skylines, not extents.
>>
>> Thanks. What is the reasoning behind this? For me, this behaviour
>> is unexpected.
>
> By the way, this is one reason why \strut is not such
>> However, the longer I think about struts – even `\vspace` is
>> nothing else than a vertical strut! – the more I believe that there
>> is a conceptual problem in LilyPond: There is a 'typesetting mode'
>> where vertical struts have an effect (like the problem originally
>> reported in 'lilypond
>> What I suggest is that zero-width/zero-height objects
>> *are* taken in account for computing the skylines.
>
> What makes your (redefined) \strut not taken into account [...] is
> caused by the "" stencil expression, which LilyPond never gives
> skylines to
Ah, thanks.
> It is completely u
> You did see the code I posted that would do what you asked for?
Sorry, no, I missed it. Thanks!
Werner
> Put yourself in the shoes of LilyPond trying to compute the skylines
> of this stencil:
>
> (ly:make-stencil "" empty-interval '(-0.3 . 0.7))
>
> According to you, the skyline should be a zero-width spike. At
> which horizontal coordinate is this spike? Any value would be
> legitimate.
Well
> A stencil has an X extent, a Y extent and a stencil expression
> (Scheme list). That's all.
>
> Think of it in another way. If LilyPond gave non-empty skylines to
> stencils with empty extents, a grob with its stencil set to
> #empty-stencil would stop taking no space. Instead, it would take
>
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
>> 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 und
>> 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 pipeline
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
>> 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
> th
> 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 wa
> 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` scr
>> 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 tod
>> 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
>> 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.
>
> Ye
>> 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.
>
> Ye
> 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,
>> 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 d
> 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 ma
>> 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 .
> 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
>> !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
>> 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
> 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:
> https://gitlab.com
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 for
> 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
>> 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
>> 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 :-)
> How
>> 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 f
>> 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 s
>>> 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
>> 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 b
> 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
> colo
>>> 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 0.39215686274509803
> 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
> 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 t
>> 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 suggested
1001 - 1100 of 3522 matches
Mail list logo
