Re: Midi2ly + Absolute Mode doesnt work

[Werner LEMBERG]

> I looked a bit into it and it seems that it's an oversight when
> moving on to Python 3. In line 204, the division should be an
> integer division (note the double slash):
> 
> o = self.pitch // 12 - 4
> 
> https://github.com/lilypond/lilypond/blob/master/scripts/midi2ly.py#L204

Thanks!  Can you please create a Merge Request for that?


Werner

Re: musicxml2ly incorrect duration syntax

[Werner LEMBERG]

> Sorry, I should have said that I was using 2.25.12, which I
> considered fairly new and didn't bother to download a newer one.

For `musicxml2ly`, it really makes a difference, since I'm working on
it almost constantly the last few months.


Werenr

Re: musicxml2ly incorrect duration syntax

[Werner LEMBERG]

> Converting the attached .musicxml file to .ly via musicxml2ly
> produces r4*9.0 in voice P3, which LilyPond doesn't like and says
> syntax error, unexpected REAL

You don't say which version you use...

Please try the current development snapshot (i.e., 2.25.21), which has
this fixed.  BTW, to get decent output you must add a 'senza misura'
signature at the beginning of the piece (no idea how to do that in
MusicScore, though).


Werner

Re: Staff lines do not extend to key/time signature after last bar line

[Werner LEMBERG]

> If a key or time signature appears at the very end of a voice, right
> after a barline the staff lines do not extend beyond that barline.
> The key or time signature seems to be floating in empty space.
> Doesn't look nice.  [...]

Thanks for the report.  I've tried to locate this problem in our bug
database but I wasn't able to find something related, so please submit
a new issue at

  https://gitlab.com/lilypond/lilypond/-/issues

(and please include images also).


Werner

Re: Issues in man pages of lilypond

[Werner LEMBERG]

> Regarding this sentence - in a man page it simply does not make
> sense, even if I'm not a native speaker either.

Ah, yes, you are right, I didn't think about the transformation to a
man page.  I agree, the sentence should be massaged by `help2man`.

Funnily, even `help2man.1` has

```
--help   print this help, then exit
```

Maybe it makes sense to open feature requests for `help2man` that
addresses your concerns.


Werner

Re: Issues in man pages of lilypond

[Werner LEMBERG]

>> > Man page: abc2ly.1
>> > Issue:this help → a help screen
>> > 
>> > "show this help and exit"
>> 
>> What you suggest is not what GNU programs like `rm`, `ls`, or `dir`
>> do.  I'm not going to change it for this reason.
> 
> Ok. This again is a limitation of help2man.

No, it is not – in this case I'm simply following what prominent GNU
programs do (since LilyPond is a GNU project, too).  I'm not a native
speaker (ich bin Wiener :-) and I trust that the US-maintainers of
those packages know what they do.


Werner

Re: Issues in man pages of lilypond

[Werner LEMBERG]

Hello Helge,


thanks for the report.

> Man page: abc2ly.1
> Issue 1:  abc2ly → B

I presume that you are talking about `abc2ly` not printed as bold in
the `DESCRIPTION` section of the man page.

We are using `help2man` (version 1.47.4, but the latest one, 1.49.3,
gives the same results for this issue), and this is what we get.

> Issue 2:  The link is no longer correct?
> http://abcnotation.com/wiki/abc:standard

This is already fixed in the development version of LilyPond.

> Man page: abc2ly.1
> Issue:this help → a help screen
> 
> "show this help and exit"

What you suggest is not what GNU programs like `rm`, `ls`, or `dir`
do.  I'm not going to change it for this reason.

> --
> Man page: abc2ly.1
> Issue:bug-lilypond@gnu.org → E<.MT 
> bug-lilypond@gnu.org>bug-lilyp...@gnu.orge<.ME>
> 
> "Report bugs via bug-lilypond@gnu.org"

Again, this seems to be a shortcoming (or a lacking feature) of
`help2man`.  Since we don't massage its output, this won't be fixed in
LilyPond.


Werner

Re: musicxml2ly unitialised variable

[Werner LEMBERG]

> Further research is required.

In MuseScore 4 (and I guess in MuseScore 3, too) you can select the
the output format while saving the file (i.e., selecting the proper
file name extension).  You have to select 'MusicXML'.  This output
file should then be readable by `musicxml2ly` (with some hiccups here
and there which I try to slowly improve).  Does this work for you?

It is a known fact that there is no round-trip compatibility available
for MusicXML.  This means that there will *always* be some loss of
information during export.  Note also that, AFAIK, MuseScore is better
at exporting MusicXML than reading it.  This is true even with the
most recent versions.


Werner

Re: musicxml2ly unitialised variable

[Werner LEMBERG]

> I am converting a PDF to XML with Musescore and then trying to
> import it into Lilypond.  The original PDF is not the most
> marvellous, but this fails at the import stage with an "Unbound
> local variable" error.

Your `score.xml` file is not a valid MusicXML file: It contains stuff
like

```
4/4
```

but the `` element only accepts decimal values (and integers
are preferred according to the MusicXML specification).

It actually looks like this file is what MuseScore uses internally for
storing its data (it starts with a `` tag).  This doesn't
work with `musicxml2ly`; you have to explicitly *export* to MusicXML.

Maybe you've attached the wrong file to the bug report?


Werner

Re: Slurring individual notes in chords bug at staff sizes < 20

[Werner LEMBERG]

> NR 1.3.2 on slurs
>  gives
> this [...]
>
> With the docs' default staff size, this produces good output: [...]
> 
> But a bug appears if the global staff size is set to any value less
> than 20.  [...]
>
> Looking through the tracker, it's possible this is a clue for #5616
> Slurring individual notes in chords yields ugly results
> . It's also
> possible this is a separate bug.

AFAICS, this is a separate bug.  Please add it to the tracker (and
thanks in advance for doing it).


Werner

Re: musicxml2ly: direction element (words+dashes) wrongly converted to markup with trillspan

[Werner LEMBERG]

> I have a musicxml export from Musescore where I have added a
> crescendo line “cresc. _ _ _ _ _ _ “ spanning several notes.
> 
> When converting that musicxml to ly (musicxml2ly 2.24.3) it will be
> rendered as a trill with span: [...]

Please try the current development version of LilyPond instead; it
renders your example just fine (rendering with `lilypond` will show
warnings, but these warnings are LilyPond bugs and can be ignored for
your test file).


Werner

\version "2.25.20"
% automatically converted by musicxml2ly from xml-test.xml
\pointAndClickOff

\header {
}

\layout {
  \context {
\Staff
printKeyCancellation = ##f
  }
  \context {
\Score
autoBeaming = ##f
  }
}

PartPOneVoiceOne = \relative f'' {
  \clef "treble" \time 4/4 \key c \major \once \set crescendoText = \markup
  \normal-text \fontsize #-0.793 \italic "cresc." \once \set crescendoSpanner =
  #'text <>^\< f4 f4 f4 f4 <>\! }

PartPOneVoiceFive = \relative f'' {
  \clef "treble" \time 4/4 \key c \major f1 }


% The score definition
\score {
  <<
\new PianoStaff <<
  \set PianoStaff.instrumentName = "Klavier"
  \context Staff = "1" <<
\mergeDifferentlyDottedOn
\mergeDifferentlyHeadedOn
\context Voice = "PartPOneVoiceOne" {
  \PartPOneVoiceOne
}
  >>
  \context Staff = "2" <<
\mergeDifferentlyDottedOn
\mergeDifferentlyHeadedOn
\context Voice = "PartPOneVoiceFive" {
  \PartPOneVoiceFive
}
  >>
>>
  >>
  \layout {}
  % To create MIDI output, uncomment the following line:
  % \midi { \tempo 4 = 100 }
}

Re: Segmentation fault

[Werner LEMBERG]

>The following example consistently triggers a core dump. Apparently
>it's an old bug, I tried older versions back to 2.20 with the same
>result.
> 
>\version "2.25.18"
>\relative c'' {
>\stopStaff
><< { b4 s a8 b16 cis b8. a16 } \\ { d,8 cis'16 d e16 d, e fis g4 } >> |
>}

Confirmed, please file an issue.


Werner

Re: Wrong custos direction handling in tied notes

[Werner LEMBERG]

> %%% A custos shows where the next note will be and is placed at the
> %%% end of a staff.  It usually works fine.
> %%% 
> %%% But, the custos should point up when the second note on the next
> %%% staff is higher than the first.  This doesn't happen if the last
> %%% note is tied to the first note on the next staff.

Your code shows the opposite, right?  The custos points up because of
the tie, but the second note on the second staff is lower.

> Suggested fix: a command like \custosUp to manually set or adjust
> the direction of the custos.

You can define this by yourself, see attached example.  Do you have to
one or more real-world scores where custodes are combined with ties?


Werner
\version "2.24.3" 

custosDown = \override Staff.Custos.neutral-position = -100
custosUp = \override Staff.Custos.neutral-position = 100

{
  \custosUp
  a'1 ~ \break
  a'
  g
}

{
  \custosDown
  a'1 ~ \break
  a'
  g
}

\layout { 
  \context { 
\Staff 
\consists Custos_engraver 
\override Custos.style = #'mensural 
  } 
} 

\paper {
  line-width = 50\mm
}

Re: \compressEmptyMeasures wrong position

[Werner LEMBERG]

Hello Dietmar,


> Abhängig von layout-set-staff-size gibt es Fehler in der
> Darstellung.  [...]


Thanks for the report, which I've registered as

  https://gitlab.com/lilypond/lilypond/-/issues/6732


   Grüße aus Kufstein

 Werner

Re: Notation Reference bug

[Werner LEMBERG]

> consisting of root and fifth". Thus the modifier column should
> contain only "nothing", [...]
>
> In addition, the output column for the last two entries should be
> modified to add the chord names: [...]

Thanks for the report, this is now

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2382


Werner

Re: Improbable offset for stencil

[Werner LEMBERG]

> Does the (bug?) report I sent get a ticket in
> https://gitlab.com/lilypond/lilypond/-/issues ?

Not yet, I was busy, sorry.

> I ran your suggested - "branch regression test":
>   [@master, test-baseline, bytecode, @MyBranch, bytecode, check]
> Indeed lots of regtests failures.
> 
> Another fix attempt is attached.

Thanks!  Please submit a Merge Request, if possible; this allows other
people to have a look.

> If I knew how to debug Scheme code, I might have come with a finer
> solution.

Assuming you want to know the value of Scheme expression `foo`, you
might insert `(ly:message "foo: ~a" foo)` into the Scheme code to get
relevant output on the console.  Then do `make bytecode`, then run
your test code.  For playing around with LilyPond's Scheme engine you
might also try the sandbox:

```
rlwrap /out/bin/lilypond scheme-sandbox
```

(Using the external `rlwrap` program makes working on the sandbox
command line *much* more comfortable.)

> To my surprise, also (attached)
> build/input/regression/midi/out/midi.diff Could it be that I missed
> something in the "branch regression test" ?

I don't know what's going on, sorry.  But looking at the version diffs
(2.25.0 vs. 2.14.0) the problem seems to be elsewhere with running the
test suite, so for the moment, I believe, you can ignore those MIDI
tests.


Werner

Re: musicxml2ly fails on line 824 -> dirty fix

[Werner LEMBERG]

> I'm surprised by your answer as with 2.24.3 there is a clear error
> and with the fix I proposed the output is usable (also far from
> being perfect).

Please define 'usable': I've tried to execute `musicxml2ly` from
version 2.24.3 on your input file, and I couldn't process the output
`.ly` file because it was incomplete.  Do you get something better?

For the last few months I'm almost exclusively working on
`musicxml2ly`.  The code you mention (to handle tuplets), and for
which you provided a suggested fix, has been completely rewritten to
support nested tuplets...

Can you retry XML export with a current MuseScore version?


Werner

Re: musicxml2ly fails on line 824 -> dirty fix

[Werner LEMBERG]

> Hello, I have a file for which `musicxml2ly` fails, because in line
> 824 variable `i2` is `None`.  Changing line 824 from `if i1 > i2:`
> to `if not i2 or i1 > i2:` fixed my issue.
> 
> I'm sorry, but I don't have time to investigate this issue more
> (just went in "don't think, fix it mode"). I can't guarantee that
> the file I worked on is correctly formed. Nevertheless, I pass you
> the information. I can send the file on request.
> 
> Thanks again for making Lilypond !

Élie sent me the file privately.

Using the current git version of `musicxml2ly` I couldn't repeat the
problem; there is no error.  However, there are a very large number of
warnings – and the output is completely unusable.

The XML file was created with MuseScore 3.2.3.  I then tried to open
the file with MuseScore 4.2.3, and it failed because the XML file is
invalid (it happens quite often that MuseScore cannot read XML files
that it produces itself):

  Fatal error: line 83, column 18: Content of element duration does
  not match its type definition: Double content does not match the
  minExclusive facet..

The invalid XML code is

```xml

  
C
4

  0
  ...
```

The value of `` must always be a positive number; value 0 is
not allowed.  This is just the first of many other notes in this XML
file that have a zero duration.  In other words, this file cannot be
handled correctly.  Perhaps you should try a newer MuseScore version
and check whether it produces valid XML...


Werner

Re: \staffHighlight with tempo indication and whole bar rest incorrect

[Werner LEMBERG]

Hello Thomas,


sorry for the late reply.

> "\staffHighlight" does not work properly if there is a tempo marking
> and a whole bar rest in the first bar.

This is now registered in our bug database.

  https://gitlab.com/lilypond/lilypond/-/issues/6730


Werner

Re: Improbable offset for stencil

[Werner LEMBERG]

> programming error: Improbable offset for stencil: -inf staff space
> [...]
> Also attached is a log and a suggested fix.

Thanks for the report.  Your suggested fix essentially undoes commit
6ac913499ad6 (from 2013) and unfortunately it makes many regtests
results worse.

You might run `make bytecode` followed by `make test-baseline` on
'master', then applying your change, then running `make bytecode`
followed by `make check` to create `out/test-restuls/index.html`,
which you can visit in your browser and which shows you all regtest
differences.


Werner

Re: musicxml2ly fails on line 824 -> dirty fix

[Werner LEMBERG]

> Hello, I have a file for which `musicxml2ly` fails, because in line 824
> variable `i2` is `None`.

Which LilyPond version?  And yes, please provide the input file for
testing (you might send it privately to me if necessary).


Werner

Re: 2.25.15: Interpreting music: infinite loop (fatal error: intlog2 with negative argument: 0)

[Werner LEMBERG]

> On my Linux machine with 2.25.16, that file nondeterministically
> compiles, segfaults, or triggers a floating point exception. No time
> to investigate more, though.

Trevor, please open an issue!


Werner

Re: Documentation improvement suggestion: << >>

[Werner LEMBERG]

> In order to figure out what this means, here's what I tried: [...]

You missed one important step, namely to look up the Learning Manual (LM):

  https://lilypond.org/doc/v2.24/Documentation/learning/index.html

The index there already contains entries for `<< ... >>` and friends.

> The notation reference is huge but that's OK because it's generally
> good at letting me learn syntax on an as-needed basis.

Uh, oh, this is not the intended use of the Notation Reference (NR)!
You should *really* start with the LM.

> But in the case of << >> I'm not sure how I could have looked this
> up, short of reading the entire manual cover-to-cover.  The
> reference manual uses << >> in examples 73 times before finally
> describing (on page 213) what it means.

Well, yes, it is expected to know the syntax if you look up stuff in
the NR...  Anyway it is a known problem that some stuff in the LM is
missing in the NR.

> I guess this is a long-winded way of saying that I think << >>
> should be in the index.

Done.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2359


Werner

Re: Tremolo stem with ledger lines

[Werner LEMBERG]

> I would like to suggest to edit the appearance of the tremolo beams
>  for notes with ledger lines. At the moment the stem is too short,
>  so the tremolo beams are too close to the notehead.  (Lilypond
>  2.25.13)

I suggest that you look up our bug database before reporting an issue.
A quick search for 'tremolo' at

  https://gitlab.com/lilypond/lilypond/-/issues

eventually yields

  https://gitlab.com/lilypond/lilypond/-/issues/734

which is, AFAICS, exactly the problem you report.  (BTW, images were
missing in your e-mail.)

> Or is there a quick way to fix that?

Right now you can only manually adjust the vertical position of the
tremolo beams.


Werner

Re: Fix aclocal.m4 fontforge version detection

[Werner LEMBERG]

> I am forwarding this bug report here:
> 
> https://bugs.gentoo.org/913928

Thanks for the report!  I've fixed the problem with the FontForge
version and with the non-portable `test` options.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2301


Werner

Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.

[Werner LEMBERG]

>> In contrast to Jean, I have a different point of view.  I think it
>> would be *very* valuable to have documentation strings of *all*
>> functions that might be useful in the long run
> 
> Oh, that's also my point of view — it *would* be very valuable.
> Just... IMO not realistic. It already took me weeks to write the
> extending-lilypond guide (not counting the effort to understand the
> code base in the first place). "rg '```\{func\}' | wc -l" tells me
> that currently 76 functions are documented in the guide, so the
> multiplier to get more usable documentation for all functions that
> are already documented is already ~10, and there are the
> undocumented ones also.

I'm very grateful for your work (and I should eventually have a closer
look whether some of the documentation can be ported to the IR)!
However, you probably did a systematic approach to the functions as
needed for the guide – this is something I don't suggest here.
Instead, I plead that interested users who stumble upon insufficient
documentation should be encouraged to provide patches *for whatever
they are interested in*.  No need for being thorough; even the
smallest breadcrumbs are potentially useful for all users.


Werner

Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.

[Werner LEMBERG]

> The naming of lilypond scheme functions can be really unintuitive
> sometimes.  At the very least, the internals reference could use
> some major extensions making clear what the functions do and how,
> with examples.  Via [1], it would have been impossible for me to
> understand what scorify-music does or that I need this function over
> ly:make-score.  Am I missing some other place where this is already
> documented in more detail?

In contrast to Jean, I have a different point of view.  I think it
would be *very* valuable to have documentation strings of *all*
functions that might be useful in the long run (of course, it is
debatable which functions these are exactly).  A lot of code is
written in Guile and C++, which is sometimes very hard to read for
non-C++ programmers.  So...

> If not, I'd be happy to start investing my time to contribute to the
> Internals reference documentation, especially Section 4 "Scheme
> functions".  In addition to better explanatory texts this section
> could benefit from more crosslinks and examples - or maybe the
> examples should be in a different (new) section to keep this
> reference concise.  I'd be happy to discuss this further.

... I'm very grateful for your offer.

> As a start, here are my suggestions for the two functions in
> question: [...]

Thanks, see

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2294

> If someone else is already working improving this Section, you may
> let me know - I'd love to join in.

You will be mostly a lone fighter, sorry :-|  

> Otherwise, as my understanding of the internals is still
> fragmentary, I'd need some help getting things right.  I could just
> continue to send improvement suggestions as mentioned in [2] to this
> mailinglist (or lilypond-devel?) and someone corrects me if I get
> things wrong? Or is someone willing to "proofread" some suggestions
> of mine in advance so I do not add too much noise to the
> mailinglists?  I could also give larger-scale structural improvement
> suggestion as a start for debate if you would consider this
> appropriate from a "newbie" to the mailinglists.

I think the best way to contribute is to get an account on GitLab,
clone the 'lilypond' git repository and submit Merging Requests,
closely following the formatting of other documentation strings.  All
documentation that goes into the IR uses Texinfo syntax.

And yes, larger-scale stuff should be discussed first on
'lilypond-devel'.


 Werner

Re: Glossary: "simile mark" and German translation "Faulenzer"

[Werner LEMBERG]

> A suggestion for the Glossary in the documentation since I just
> learned that percent repeats are called "Faulenzer" in colloquial
> German after I had sought the word in vain in the Lilypond glossary
> and documentation. Or two suggestions, really.  [...]

Thanks, this is now part of a merge request, see

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2291


 Werner

Re: Failure of convert-ly to run

[Werner LEMBERG]

> I have a file for which convert-ly crashes.  [...]
>
> It seems to be fixed by changing line 2152 of convertrules.py by
> putting the second argument as a raw string:
>
> ```
> s = re.sub(r'''((\\"|})\s*){''', r'\2 \\line {', s)
> ```

Thanks for the report!

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2289


 Werner

Re: Incorrectly-placed slur when hide-tied-accidental-after-break sometimes

[Werner LEMBERG]

> In the following example, when a note has a slur and a tie and
> hide-tied-accidental-after-break is enabled, the slur is incorrectly
> placed when another staff has many accidentals.

Thanks for the report.  However, I don't think the problem is
especially related to accidentals; it's rather one of the many cases
where LilyPond's automatic tie and slur positioning algorithm makes
bad choices – there are plenty of issues already registered in our bug
tracker, some of them older than 15 years and still unresolved, alas.
Just look up the labels 'ties' and 'slurs'.

Note that you get almost the same bad results in your example if you
omit 'hide-tied-accidental-after-break'.  Similarly, the results are
differently bad if you omit the accidentals altogether.

```
\version "2.25.13"

<<
  \new Staff {
\override Tie.color = #red
\override Accidental.hide-tied-accidental-after-break = ##t
cis''1~( \break 1)
  }
  \new Staff {
R1 1
  }
>>

<<
  \new Staff {
\override Tie.color = #red
cis''1~( \break 1)
  }
  \new Staff {
R1 1
  }
>>

<<
  \new Staff {
\override Tie.color = #red
c''1~( \break 1)
  }
  \new Staff {
R1 1
  }
>>
```


Werner

Re: Chord names collide with span bar

[Werner LEMBERG]

>> Since I don't have experience with chord names I ask users who need
>> this feature to check whether it works as expected in general.
> 
> It works like a charm in my source!  Thanks for researching this.

:-)

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2281


 Werner

Re: Chord names collide with span bar

[Werner LEMBERG]

>>> I remembered that you can add the Bar_engraver to ChordNames.
>>> Making them transparent so they do not visually interfere with the
>>> SpanBar, but they still take up space.
>>
>> Nice!  This begs the question whether we have a real bug or 'just'
>> insufficient documentation...
>
> I was thinking about commands like \textLengthOn.  Would there be
> value in providing a more consistent way to handle this use case
> without having to manually do what I did?  It feels a little bit
> hacky to be instantiating transparent BarLines.  I could see an LSR
> snippet being created to demonstrate the technique, but would we
> want it in the docs?

I think I've found the real fix for the problem.  Suddenly remembering
that we already have the `Span_bar_stub_engraver` to handle exactly
such situations I wondered why it works for lyrics but not for chord
names.  Comparing the definitions of the two contexts in
`engraver-init.ly` I found out that the `Pure_from_neighbor_engraver`
was missing, and adding it seems to do the trick.


```
\version "2.25.13"

\layout {
  \context {
\ChordNames
\consists Pure_from_neighbor_engraver
  }
}

\score {
  \new GrandStaff <<
\new Staff \relative { c''4 c c c | c c c c }
\new ChordNames \chordmode { c2. q8. des16:maj9 | q1 }
\new Staff { \improvisationOn b'4 4 4 8. 16~ | 4 4 4 4 }
  >>
}
```


Since I don't have experience with chord names I ask users who need
this feature to check whether it works as expected in general.


Werner

Re: Chord names collide with span bar

[Werner LEMBERG]

> Oh, I think I found another option:
>
> 
> \version "2.25.13"
>
> #(ly:set-option 'debug-skylines #t)
> \layout {
>   \context { \Score
> \override NonMusicalPaperColumn.show-horizontal-skylines = ##t
>   }
>   \context { \ChordNames
> \consists "Bar_engraver"
> \override BarLine.bar-extent = #'(0 . 1)
> \override BarLine.transparent = ##t
>   }
> }
>
> \score {
>   \new GrandStaff <<
> \new Staff \relative { c''4 c c c | c c c c }
> \new ChordNames \chordmode { c2. q8. des16:maj9 | q1 }
> \new Staff { \improvisationOn b'4 4 4 8. 16~ | 4 4 4 4 }
>   >>
> }
> 
>
> I remembered that you can add the Bar_engraver to ChordNames.
> Making them transparent so they do not visually interfere with the
> SpanBar, but they still take up space.

Nice!  This begs the question whether we have a real bug or 'just'
insufficient documentation...


Werner

Re: Chord names collide with span bar

[Werner LEMBERG]

>> Aaron, please file an issue, referring to this e-mail thread.
> 
> First time creating an issue, so hopefully this is up to snuff.

Thanks a lot!

> Added: https://gitlab.com/lilypond/lilypond/-/issues/6703
> 
> By the by, I do not appear to have permissions for setting labels,
> but I think this issue would qualify for the "Ugly" tag.

I've just set appropriate tags.


Werner

Re: Chord names collide with span bar

[Werner LEMBERG]

>> In some situations, chord names collide with the span bar of a
>> Grand or Piano Staff.  Here is an example:  [...]
> 
> [...] Still sounds like a defect of some sort, as the default
> behavior should probably be handling things.

Aaron, please file an issue, referring to this e-mail thread.


Werner

Re: Distance between top margin and title text in 25.2.+

[Werner LEMBERG]

> [...] I don't understand why the default is not "0".  Space is rare
> and you often can't waste it, especially not in the title.

If you look at *any* score from a good publisher like Henle you can
see that there is plenty of whitespace around the music *and* the text
– for good reasons, since it increases legibitily enormously.

There might be exceptional situations to reduce the space.  However,
the new values are *much* better defaults IMHO.


Werner

Re: Distance between top margin and title text in 25.2.+

[Werner LEMBERG]

> I don't know if this is a bug, but with the very latest Lilypond
> versions (2.25.+) the distance between the top margin and the title
> text does not match the value I specified, in this case 5
> millimeters.  [...]

Have you looked into the 'changes' file from LilyPond?  The first
entry for the 2.25.x series is

  Margins are now wider by default following the general layout of
  several publishers (and the recommendations of Elaine Gould).

  In order to switch back to the previous settings (e.g., to keep the
  same layout when upgrading an existing score to version 2.25.14),
  add the following code:

  ```
  \paper {
top-margin = 5\mm
bottom-margin = 10\mm
top-system-spacing.basic-distance = 1
top-markup-spacing.basic-distance = 0
left-margin = 10\mm
right-margin = 10\mm
inner-margin = 10\mm
outer-margin = 20\mm
binding-offset = 0\mm
  }
  ```

It seems to me that you should adjust the `top-markup-spacing` value
in your settings.


Werner

Re: lilypond-book loglevel

[Werner LEMBERG]

> lilypond-book accepts --loglevel=WARN, but not --loglevel=WARNING.
> 
> I think WARN is for lilypond, not lilypond-book (according to the
> documentation), so maybe just misdocumented?

Indeed, it is incorrectly documented; it should be 'WARN' everywhere.
Note that the `lilypond` binary is less restrictive than the scripts;
it also accepts 'warning' or 'WARNING_FOOBAR' as possible values since
only the first few characters are checked, ignoring the case.
However, it is best to stick with the standard uppercase values.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2265

Thanks for the report!


 Werner

Re: Snippets omission

[Werner LEMBERG]

> Snippets manual, MIDI chapter, Staff.midiInstrument list omits "guitar
> harmonics" between "distorted guitar" and "acoustic bass" (position
> 32).

Thanks for report; fixed in LSR #338, and the next import will fix it
in the LilyPond documentation.


Werner

Re: partCombine Issues Warnings When Divisi Begins Within Tied Notes

[Werner LEMBERG]

Hello Chris,


sorry for the late reply.

> Issuing a \partCombineApart between two tied notes results in a
> warning that the tie is unterminated and omits the tie from the
> printed score.  Printing the top part by itself creates the tie
> without issues.
> 
> Omitting the tie from the top part as a workaround moves the divisi
> notation backwards one note to include the first tied note.

Alas, this is a fundamental limitation of LilyPond: The part-combiner
uses different voices for single and combined parts, and currently
there is no way to have ties between voices.  I can imagine that the
part-combiner becomes more sophisticated to identify such situations
emitting a work-around; however, I don't know whether this is
possible.

Please file an issue in LilyPond's bug tracker at

  https://gitlab.com/lilypond/lilypond/-/issues

so that it is not forgotten.


Werner

Re: Imprecise font scaling

[Werner LEMBERG]

> I personally lacked this information on the page "1.8.2 Formatting
> text – Selecting font and font size", mainly the fact that
> text-font-size is in pt (as defined in other sections).

https://gitlab.com/lilypond/lilypond/-/merge_requests/2258


Werner

Re: Imprecise font scaling

[Werner LEMBERG]

> This is perhaps not the best place to discuss that, but thinking
> about it, I don't understand why text-font-size is dimensionless
> (when it actually does have a dimension).  Wouldn't text-font-size =
> 12 \pt be more intuitive (and, at the same time, allowing also other
> units)?

This is due to history.  I agree that it would be better if it had a
dimension attached to it.


Werner

Re: Imprecise font scaling

[Werner LEMBERG]

>> However, 2 * 3.86523438 = 7.73046876 != 7.73242188.

> I'm quite sure this is because of
>
>  int pango_size = static_cast (
>     std::lround (static_cast (requested_size) * PANGO_SCALE));
>
>
> in lily/font-select.cc, which we cannot really do anything about,
> because the Pango API
>
> https://docs.gtk.org/Pango/method.FontDescription.set_size.html
>
> expects an integer size scaled by PANGO_SCALE, which is 1024. That
> is, we are limited to a precision of 1/1024 points on the font size.

Shall we document this somehow?


Werner

Re: bug-reporting instructions need clarification

[Werner LEMBERG]

>> I think that postings by non-subscribers may go through moderation,
>> so they have a delay, sometimes considerable, before they appear
>> and require some manual interaction.
> 
> My last reply showed up in the email archive
> (https://lists.gnu.org/r/bug-lilypond/2024-02/msg6.html) within
> three minutes of my sending it, so either that turnaround time was
> an aberration, or your supposition is incorrect.

This remark is true for first-time posters; you were apparently lucky
that one of the (human) moderators of `bug-lilypond` found some spare
time at the right moment.  Follow-up replies, on the other hand, come
through without further moderation – at least I think this is the
case, but I'm not sure.


Werner

Re: old \alternative-syntax in documentation

[Werner LEMBERG]

>> The issue affects all of the other translations:
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.ca.html
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.de.html
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.es.html
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.it.html
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.ja.html

The French translation is usually up to date.


   Werner

Re: Warnings during make

[Werner LEMBERG]

> main.cc:641:23: warning: loop variable 'keyval' creates a copy from
> type 'const std::pair,
> std::__cxx11::basic_string >' [-Wrange-loop-construct]
>   641 |   for (const auto keyval : init_scheme_variables_global)
>   |   ^~
> main.cc:641:23: note: use reference type to prevent copying
>   641 |   for (const auto keyval : init_scheme_variables_global)
>   |   ^~
>   |   &

Thanks for the report.  The fixes suggested by the compiler are now
this MR.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2250


Werner

Re: MMRests cause weirdness following \cadenzaOff

[Werner LEMBERG]

> I've been wrestling with this mystery for some hours.  I've finally
> found how to trigger it. The multimeasure rest causes the
> duplication of the rests in the display in previous measures.  A
> non-multimeasure rest does not result in the weird duplication.  If
> this is a known issue I missed the notice.

It's a bug, now filed as

  https://gitlab.com/lilypond/lilypond/-/issues/6692

Thanks for the report.


Werner

Re: Melody bars are out of sync after tie into first alternative and added lyrics

[Werner LEMBERG]

> Here you can find a
> preview: 
> https://www.schott-music.com/de/preview/viewer/index/?idx=NTI0Mjcx&idy=524271&dl=0
> 
> Voice tenor bar 9 to 10 into first alternative it is bound, were as
> from bar 9 to 13 (page 2) it isn't.  It is officially published by
> SCHOTT Music, so I think its correct...

Well, this is simply bad typography – or an error.  You should write
to Schott Music complaining about this.

If I start a tie, I *have* to have an end of the tie!  Just imagine
that the seconda volta starts on the next page – you hold the note and
as soon as you turn the page you discover that holding it is
incorrect, and it's too late to re-articulate the new syllable.

My conclusion: LilyPond's documentation is correct.


Werner

Re: PDF hyperlinks pointing to internal LilyPond code

[Werner LEMBERG]

>> > The hyperlinks of both the acciaccatura and the appoggiatura
>> > slurs point to ly/grace-init.ly, which is kind of logical, but
>> > also confusing from a user perspective.
>>
>> I think this a bug, so please open an issue.
>
> I apologise.

Why?


Werner

Re: PDF hyperlinks pointing to internal LilyPond code

[Werner LEMBERG]

> I would like to hear your opinions on this one:
> 
>  snip
> \version "2.25.10"
> 
> { \acciaccatura { c'8 } d'4 }
> { \appoggiatura { c'8 } d'4 }
> 
> 
> The hyperlinks of both the acciaccatura and the appoggiatura slurs
> point to ly/grace-init.ly, which is kind of logical, but also
> confusing from a user perspective.

I think this a bug, so please open an issue.


Werner

Re: Melody bars are out of sync after tie into first alternative and added lyrics

[Werner LEMBERG]

> There might be a small misunderstanding in "When a note is tied over
> into two or more alternative endings [...]" this is also needed if
> the tie goes only into the first alternative as well [...]

>From a logical point of view you either have no tie, or you have a tie
that goes into *all* alternative endings.  In other words, 'a tie that
goes only into the first alternative' is incorrect.  If you have such
a situation you should consider changing where the alternatives
actually start.

Maybe there is a misunderstanding on my side, so please provide an
example (with an image) that illustrates what you mean.


Werner

Re: Lilypond installation

[Werner LEMBERG]

> I'm in the middle of a clean installation on a mac with Sonoma
> 14.1.2 with an M2 chip.  The instructions have been incomplete and
> have varied significantly from the screenshots on the website.

Please give more details.  AFAIK, none of the developers are (mainly)
working on a Mac, and I'm not sure whether our Mac people have Sonoma
and/or an M2.

> After I gave up with the tarball,

Theoretically, if all prerequisites are fulfilled, it should work.
What problems did you experience?  Again, we need more details, both
to help you and to update the build instructions if necessary.

> I installed MacPorts which had some issues (beyond your control) to
> use that installer, and it appears I've finished, but the list of
> notes is extensive and I thought I'd share that with you.  [...]

You can ignore all of them, they are not relevant, AFAIK.  The only
issue with the 'lilypond' and 'lilypond-devel' bundles from MacPorts
is what Jean has mentioned:

  https://trac.macports.org/ticket/67026

Essentially, you have to install the fonts from

  
https://github.com/ArtifexSoftware/urw-base35-fonts/archive/refs/tags/20200910.tar.gz

together with some fonts from TeXLive
(`texgyre{cursor,heros,schola}-*.otf`) to a place where FontConfig
finds them (I guess `~/.fonts` should work).


Werner

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

[Werner LEMBERG]

> Also, I'm pretty sure that the intent of FcChar8* in Fontconfig is
> to represent UTF-8 so this is probably worthy of a bug report to the
> Fontconfig people?

Indeed.  To do so it would be helpful to check the output of `fc-list`
(ideally with proper patterns to make the result more similar to
LilyPond's output).  Nathan, since you sit at the 'source' of the
problem, please also send a report to the FontConfig people if your
time allows it.

  https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues


Werner

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

[Werner LEMBERG]

> I can confirm that replacing
>
> scm_write_line (ly_string2scm (str), port);
>
> with
>
> scm_c_write (port, str.c_str (), str.length ());
>
> fixes the issue on my end.  I’d be happy to make a merge request for
> this.

I've updated

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2231

accordingly.


Werner

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

[Werner LEMBERG]

> Thanks for making the merge request. Unfortunately, it didn’t fix
> the issue, although it really seems like it should have.

Thanks for the testing it and the detailed analysis.  I've changed the
status of the Merge Request to 'draft'.

> I’m starting to think this may be a bug in Guile.

Can you make your example code generic and report it to the Guile
people?

> When I use a conversion strategy of 'substitute, the conversion
> works as expected (with a � where the encoding issue occurs).  When
> I use the default strategy ('error, presumably), LilyPond outputs:
> [...]

How shall we proceed?


Werner

Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info

[Werner LEMBERG]

> On macOS Ventura v13.6.3 (and almost certainly other versions), the
> string produced when using -dshow-available-fonts need not be
> encoded as UTF-8.

Thanks, should be fixed with this MR:

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2231

Out of interest: Which font shows this behaviour?

I suggest you contact the FontConfig people and report the issue, too;
assuming that the font is valid it should be possible to convert the
non-UTF8 data to UTF8.


Werner

Re: Ugly ties in chord clusters

[Werner LEMBERG]

[Pressing 'reply-all' in my e-mail program converted
'bug-lilypond@gnu.org' into a strange address, thus resending.]

>In dense chord clusters, ties sometimes fail to keep at least one
>staff space away from each other.
>
> \version "2.24.2"
> \relative {
>   \override Score.SpacingSpanner.shortest-duration-space = #3
>   ~ q
> }

Looks like a variant of issue #2368

  https://gitlab.com/lilypond/lilypond/-/issues/2368


 Werner

Re: NoteNames does not properly understand German note names

[Werner LEMBERG]

> \language "deutsch"
> 
> \new NoteNames { b1 }

Already reported as issue #6305, AFAICS.

  https://gitlab.com/lilypond/lilypond/-/issues/6305


Werner

Re: Vertical spacing is broken when \change Staff and \showStaffSwitch on \pageBreak

[Werner LEMBERG]

> here is example of this bug: [...]
>
> The problem occurs only if the \showStaffSwitch command is found.

Yes, this is a bug.  Thanks for the report; filed as

  https://gitlab.com/lilypond/lilypond/-/issues/6684


Werner

Re: Duration dots are badly arranged

[Werner LEMBERG]

> I found bug in arrangement duration dots in a specific case: [...]

There is no bug.  Using `\hideNotes` only makes note heads (and dots)
invisible, but they are still positioned.  You should rather try
something like the following.

```tex
\version "2.24.3"

\new PianoStaff <<
  \new Staff = "1" <<
\new Voice \relative a' {
  \voiceOne a2 g4 c
}
\new Voice \relative e' {
  \voiceTwo e2. g4
}
  >>
  \new Staff = "2" <<
\new Voice \relative c' {
  \clef bass
  \voiceOne \change Staff = "1"
  \once \stemDown
  c2.
  \showStaffSwitch
  \unHideNotes \change Staff = "2"
  c4
}
\new Voice \relative a, {
  \voiceTwo a4. b8 c4 e
}
  >>
>>
```


  Werner

Re: subtitle moves notes off staff lines

[Werner LEMBERG]

> I've noticed at times lilypond produces notes that are not exactly on or
> between the staff lines. I boiled it down to the attached minimum
> example, which shows a D flat that looks floated up about half way to E
> flat. However, if you comment out the header subtitle, the note lands
> precisely on D flat.

Please show a zoomed-in image (PNG) of what you get.  For me, your
attached PDF looks just fine with my PDF viewer on a GNU/Linux box.


Werner

Re: The CSS of some webpages is misaligned

[Werner LEMBERG]

> For example on https://lilypond.org/tiny-examples.html you get the
> following page, with the start of the text not readable.

It's actually

  https://lilypond.org/bug-reports.html

Thanks for the report.  I'm quite sure that this is an artifact of
changing from the ancient `texi2html` version to a recent `texi2any`,
and this page was missed during inspection whether everything is OK.

I've opened

  https://gitlab.com/lilypond/lilypond/-/issues/6682

for tracking.


Werner

Re: Compilation problem

[Werner LEMBERG]

> When I compile a lilypond file I get the following error: [...]

This is due to an upgrade of homebrew to ghostscript 10.02.1, which
removed a function used by LilyPond.

  https://gitlab.com/lilypond/lilypond/-/issues/6675

We already have a fix, but until this is out I suggest to use the
binary we provide, and that you can download from

  https://lilypond.org/download.html

Re: [v2.24.2, v2.25.9] Compilation to PDF fails with Ghostscript 10.02.1

[Werner LEMBERG]

> This bug was not observed with Ghostscript 10.02.0.

Thanks, filed as

  https://gitlab.com/lilypond/lilypond/-/issues/6675


Werner

Re: Missing_one1h_for bassoon_woodwind_diagram

[Werner LEMBERG]

> Many thanks. The patch works fine.

Thanks for testing.  This is now

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2093


Werner

Re: Missing_one1h_for bassoon_woodwind_diagram

[Werner LEMBERG]

> The attached snippet provides the basic layout of the bassoon
> diagram.

Thanks.  Note that this can be done easier on the command line with

```
lilypond -e="(print-keys-verbose 'bassoon (current-output-port))" > bassoon-keys
```

> For one (left index finger) there must be more possibilities. At
> least one1h should be available.  But one1q and one3q with all
> combinations with T or F (similar to two (middle finger)).  I did
> not see a ring at this hole ever.

Please try the patch below (or change the file manually) and report
back whether this is sufficient.


Werner


==


--- display-woodwind-diagrams.scm.orig  2023-07-22 14:00:54.734583384 +0200
+++ display-woodwind-diagrams.scm   2023-08-21 18:30:00.208824010 +0200
@@ -1362,7 +1362,7 @@
   . ((offset . ,(assoc-get 'one 
CENTRAL-COLUMN-HOLE-PLACEMENTS))
  (stencil . ,ring-column-circle-stencil)
  (text? . #f)
- (complexity . trill)))
+ (complexity . covered)))
  (two
   . ((offset . ,(assoc-get 'two 
CENTRAL-COLUMN-HOLE-PLACEMENTS))
  (stencil . ,ring-column-circle-stencil)

Re: Missing_one1h_for bassoon_woodwind_diagram

[Werner LEMBERG]

> For the woodwind diagram of the bassoon the half open hole is
> missing for one (one1h).  You ay refer
> to https://davidawells.com/resources/fingering-charts/.

Please be more specific and show/describe *exactly* what is missing or
not working, ideally together with a (possibly non-working) minimal
example.  None of the developers is a bassoon player AFAIK.


Werner

Re: Faulty extra beam with manual beam and cross-staff stems

[Werner LEMBERG]

> And no, this is pretty far from perfect and could also benefit from
> being made clear in the NR.

What do you want to have where exactly?


Werner

Re: Crash in 2.25.4

[Werner LEMBERG]

> So Pango is apparently requesting a font with colored glyphs from
> Fontconfig...

A bug?


Werner

Re: Crash in 2.25.4 Solved

[Werner LEMBERG]

> Following your suggestion, Werner, I tried the test file with the
> cairo back end, and it worked as expected.

Great, please send me the created PDF for further analysis – just to
be sure :-)

> I then deleted the Noto Color Emoji font (synaptic also deleted
> texlive fonts extra links), and retried the test file. Again, it
> worked as expected.

Really?  I would rather expect that the digits are still taken from
another fallback font.  Please send me the created PDF for further
analysis, too.


Werner

Re: Crash in 2.25.4

[Werner LEMBERG]

Colin,


>> All this comes about as I'm thinking of getting back to
>> some documentation work, and wanted to compile docs locally. I'll
>> still keep that goal in mind.
>>
>> If you can still reproduce the problem after this cleaning, could
>> you run
>>
>> ```
>> FC_DEBUG=2025 build/out/bin/lilypond --verbose --ps test_file.ly >
>> fclog.log 2> lilylog.log
>> ```
>>
>> and send the three resulting files, `test_file.ps`, `fclog.log` and
>> `lilylog.log`?
>
> The requested files are attached as an archive, as two of them are
> rather large.

(1) You have the font 'Noto Color Emoji' installed on your system (the
new one, with scalable glyphs using the 'COLR' v1 format).  Say
`fc-list | less` to find out where it is located.  This font
format is not supported by GhostScript – such a font cannot be
meaningfully embedded in a PS or PDF file.

(2) For some reason, the digits in the tagline string are taken from
`Noto Color Emoji` instead of `C059-Roman`, which is used for
everything else in the tagline (see the end of your
`Non-Musical.ps` file).

I think item (1) happens because 'Noto Color Emoji' is set up as a
fallback font on your OS.

Regarding (2) I'm not sure where exactly the problem lies (i.e.,
whether it is a LilyPond or a Pango issue).  However, if you use the
current LilyPond developer version, this should be fixed: LilyPond and
Pango no longer use glyph names but glyph indices for communication.

BTW: Have you checked whether the Cairo backend works for you?

```
lilypond -dbackend=cairo ...
```

Perhaps we should disable color fonts similarly to variation fonts, at
least for now (and later on for the PS backend only).  Such a change
could be backported to the 2.24 series.


 Werner

Re: Crash in 2.25.4

[Werner LEMBERG]

> ran make successfully, got carried away and may have shot myself in
> the foot by running sudo make install.

You should actually do

```
make bytecode
sudo make install-bytecode
```

Without installing the Guile bytecode, LilyPond is slooow.


Werner

Re: convert-ly 2.25.3 problem

[Werner LEMBERG]

> Thanks for reporting. Werner, can you take a look please? It appears
> that 4494a12ec8d3408981b26f4dc4040e2f985da06f breaks `convert-ly -`
> to read stdin (on Windows).

https://gitlab.com/lilypond/lilypond/-/merge_requests/1948


Werner

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

[Werner LEMBERG]

>> However none of the staff types dan suggested will do what I could
>> previously do. Gregorian divisiones not supported on modern staffs
>> is a reasonable closure for this as a bug however I've previously
>> been able to use the gregorian divisions on a 'normal staff' so
>> from my pov this is a regression.
> 
> Does either of these suit your purpose?  [...]

The whole issue probably warrants an improvement of the documentation,
helping users in the transition to the new syntax.

Grant, assuming that Dan's code in his last reply fits your needs, can
you suggest a better wording (in the 'v2.25' documentation)?


Werner

Re: Baroque NoteHeads won't merge without \new Voice

[Werner LEMBERG]

>> Thank you so much for the speedy and clear response. I didn't
>> consider that it was because the notehead styles were different!
>> Glad for the understanding.
> 
> Maybe there'd be a way for the implementation to check for the same
> glyph instead?  For styles with considerable overlap of glyphs, that
> may be a more appropriate choice?
> 
> Or isn't there actual glyph overlap?

For the Emmentaler fonts, there are overlaps in the used glyphs,
AFAIK.  However, this might be different for other SMuFL fonts.  (I
haven't actually checked, though.)


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: IR badly formated in html

[Werner LEMBERG]

Hello John,


> Is this a fix of a magnitude that someone with less technical
> expertise could accomplish? I would volunteer to prepare the MR, if
> it would help more than get in your way.

Sorry, I saw your e-mail too late – I have already pushed an MR :-)

  https://gitlab.com/lilypond/lilypond/-/merge_requests/1296

And yes, this would have been easy to fix for people with less
technical expertise.


Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: IR badly formated in html

[Werner LEMBERG]

>> Please enclose the first argument of `@defun` with @code{...}, like
>> this:
>>
>>@defun @code{foo-bar::@/baz} bar? bar bar
> 
> Thanks for the fix proposal; whom are you talking to with "Please"?

You, of course :-)

I will prepare a MR to fix that.


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: IR badly formated in html

[Werner LEMBERG]

> Looks like this comes from the use of "@/", which has been
> introduced with
> 
> commit 1f3a6cdc25ab978589fb01894dce34d7d6c1e972
> Author: Werner Lemberg 
> Date:   Sun Aug 8 15:51:29 2021 +0200
> 
> doc: Avoid overlong index entries in generated documentation
> 
> Insert `@/` after `::` in function names.  Only PDF output is
> affected.
> 
> 
> Werner, thoughts?

Sigh.  A bug with our antique `texi2html`, not present in current
texinfo's `texi2any --html`...

Please enclose the first argument of `@defun` with @code{...}, like
this:

  @defun @code{foo-bar::@/baz} bar? bar bar

According to my tests this workaround succeeds with `texi2html` 1.82;
it also fixes the index entry and is still valid HTML (inspite of
` ... ` in the generated index data).  The
PDF output is unchanged.


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: possible documentation bugs

[Werner LEMBERG]

> "The collection of staves (staff), two or more, as used for writing
> down keyboard, chamber, choral, or orchestral music; a section of
> the score spanning the width of a single page."
> 
> This seems to imply the word has two meanings,

Yes.

> but I think in the context of Lilypond, it has only one.

Yes.

> Should it say "a collection of staves that span the width of a
> single page"?  (Is that what a "system" means?)

No.  It's the other definition.  I'm about to add this sentence:

  For LilyPond, a system is a collection of staves.

> It's not in the technical glossary, either.

I will add an entry.

> Also, there is no entry for "spanner" (also no simple index entry,
> and not in the technical glossary, either).  It does have a section
> to itself, for those bright enough to use the table of contents, but
> the index entries only point to it in a fairly indirect way.

Will add that, too.


 Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: possible documentation bugs

[Werner LEMBERG]

Hello Tom,


> I wonder if the "system" entry in the glossary might be enhanced by
> including the lilypond-specific definition.  [...]
> 
> Also, there is no entry for "spanner" [...]

thanks for the report; I will take care of this soon.


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Persian accidentals look ugly

[Werner LEMBERG]

Hello Kees,


> Sori and Koron look OK.

Good to hear.

> persian.ly (written by me) was updated on the mailinglist a few
> months ago so use different fonts.  Further updates to make it work
> with whatever you guys are doing now should be easy but not
> something I know how to do.

Do you have a link?  I think updating is rather straightforward if I
have something to start with.

> I have bookshelves of Persian music and can scan in some good
> looking examples if that would help in any way.  Let me know.

Thanks for the offer; right now I don't need that, I believe.

> The slanted lines in the sori look a bit too thick to me as well,
> but the lilypond design referred to above already looks as good or
> better than any I have seen in print.

My solution of having rather thick slanted lines in the sori glyph is
based on the assumption that originally it was a sharp accidental
where the two beams now form a wedge instead of being parallel.  This
is at least the impression I get if I look at Vaziri's handwritten
documents.

> Nice to get this done after such a long time!

:-)


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Persian accidentals look ugly

[Werner LEMBERG]

12½ years earlier I wrote:

>> Persian accidentals (korn, sori) don't look very nice.  [...]
> 
> Thanks.  I've added your report to the bug database (issue #738).

Now something happened :-) Please have a look at

  https://gitlab.com/lilypond/lilypond/-/merge_requests/1047


 Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: What is the point of bug-lilypond?

[Werner LEMBERG]

>> After having opened a few GitLab issues in response to bug reports
>> on bug-lilypond, I find James extraordinarily patient for having
>> done this over the years.  However, I don't get the value in this
>> system compared to letting people creating issues on GitLab
>> directly.  When we transfer an issue to GitLab, it's usually just
>> pasting the text from the email report.
> 
> No it is more than that.

There are two point of views.  Some people (for example, the HarfBuzz
developers) don't want e-mail on their mailing list; they prefer that
users open issues for both user questions and bug reports.  I guess
this works because HarfBuzz is a very specialized library, not to be
used by Joe User but by developers who already know how good bug
reports should look like.

The other point of view is that bug reports should be collected in a
database, being correctly tagged and as concise and compact as
possible.  I agree with James that it makes sense to parse and filter
reports in advance to achieve that, so I'm on his side.

>> Right now, bug reports often take a week to be acknowledged,

Well, yes.  Not a big problem IMHO.

>> So how about retiring bug-lilypond and directing to GitLab instead?
>> Tickets can be triaged there, closing invalid ones, adding a
>> minimal example if not present, perhaps changing the title.  The
>> requirement from the same page of GNU guidelines,
> 
> I don't see the difference between triaging GitLab vs triaging Bug
> apart from the fact that it is very easy to use bug-list interface
> to track email threads - it's so easy to spot of something on the
> bug list has had a reply or not.  [...]

Since James is doing most of the work, I think we should do what he
prefers.  This doesn't prevent other developers to chime in and help
with handling bug reports.  And frequent *and experienced* bug
reporters should be told to directly use the bug tracker.


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Lyric alignment bug with markup

[Werner LEMBERG]

>> Ah, that's kind of what I was fearing.  Obviously (at least I hope
>> it was obvious; maybe it wasn't) I was trying to format an entire
>> group of lyrics, and having to markup each word was both tedious
>> and ugly.   In my use case, it looks like \override
>> LyricText.font-size and \override LyricText.font-shape work quite
>> well.
>>
>> It doesn't appear that any of this is covered in the documentation
>> - is wanting to format entire verses/groups of lyrics not a common
>> use case, or would that be something helpful to add?
> 
> It is mentioned in the documentation around fonts:
> 
> http://lilypond.org/doc/v2.23/Documentation/notation/fonts#font-families

Justin, could you suggest an index entry (or whatever) that would have
you enabled to find the necessary information?


Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Garbage copied from PDF when using certain fonts

[Werner LEMBERG]

>> I've looked up the cairo bug tracker but couldn't find something
>> related to copy-and-paste of CID-keyed fonts.  Masamichi-san, could
>> you submit an issue there so that this gets fixed eventually?  I
>> guess this would be beneficial for other projects, too.
> 
> In my experiment, Cairo without LilyPond does not generate garbled
> characters.  It seems to be a LilyPond issue instead of a Cairo
> issue.  Here's a python-cairo sample that works fine.  [...]

I can conform that this small script generates a PDF where
copy-and-paste works as expected (I have cairo version 1.16.0
installed on my GNU/Linux system).  Looking into the uncompressed
version of PDF (created with `pdftk`) I see that it contains proper
ToUnicode cmaps for the two fonts.

Does `-dbackend=cairo` pass markup strings directly to Cairo?  


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Garbage copied from PDF when using certain fonts

[Werner LEMBERG]

>>> The problem does not appear if the cairo backend is used, see
>>> https://gitlab.com/lilypond/lilypond/-/merge_requests/853.
>> 
>> This is good news!
> 
> When copying and pasting from a PDF generated using cairo backend,
> some characters turned into similar but different characters.  The
> characters are garbled in both AJ1 and AI0 fonts.  If you use ps
> backend, characters by the AJ1 font are not garbled.  [...]

I've looked up the cairo bug tracker but couldn't find something
related to copy-and-paste of CID-keyed fonts.  Masamichi-san, could
you submit an issue there so that this gets fixed eventually?  I guess
this would be beneficial for other projects, too.


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Garbage copied from PDF when using certain fonts

[Werner LEMBERG]

>> When using certain fonts (in my case, Noto CJK, both pan-CJK and
>> subset versions), the output looks right but when copied from the
>> generated PDF file, everything becomes garbage.  [...]
>
> The problem does not appear if the cairo backend is used, see
> https://gitlab.com/lilypond/lilypond/-/merge_requests/853.

This is good news!


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Garbage copied from PDF when using certain fonts

[Werner LEMBERG]

>> AFAICS, to make copy and paste work for CID fonts it is necessary
>> to add a ToUnicode map.  We don't do that currently.  [This is
>> probably worth an entry in our issues database.]

This is now issue #6162.

  https://gitlab.com/lilypond/lilypond/-/issues/6162


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Garbage copied from PDF when using certain fonts

[Werner LEMBERG]

> When using certain fonts (in my case, Noto CJK, both pan-CJK and
> subset versions), the output looks right but when copied from the
> generated PDF file, everything becomes garbage.  [...]

Confirmed.

> It seems to be all about CID. Maybe related to Issue #6058?

Yes and no.  The fix for #6058 was to make CID fonts display correctly
at all.  AFAICS, to make copy and paste work for CID fonts it is
necessary to add a ToUnicode map.  We don't do that currently.  [This
is probably worth an entry in our issues database.]  Masamichi-san,
please correct me if I am wrong.

As a temporary solution, use a TTF version of this Noto font.  For
testing purposes, I've downloaded the font in question from

  
https://gitlab.erudit.org/erudit/portail/eruditorg/-/blob/master/eruditorg/static/fonts/Noto/NotoSerifCJKsc-Regular.ttf

This makes copy and paste work just fine.  Another advantage is that
the output file is only 0.2MByte (probably due to good subsetting
capabilities of ghostscript 9.54 on my GNU/Linux box); using the
CID-keyed font the output file is 1.1 MByte.


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: svg font problems

[Werner LEMBERG]

> Processing `../repeat-volta.ly'
> Parsing...
> Interpreting music...[8]
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> fatal error: cannot find SVG font #f

The font problem is issue #3809: the volta number is given as

  1.–3.

and LilyPond tries to take the `–` character from font
`c059-roman.svg`, without consulting FontConfig as a possible
replacement.

  https://gitlab.com/lilypond/lilypond/-/issues/3809


Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: svg font problems

[Werner LEMBERG]

[Changing your e-mail address to 'knupero', which is your preferred
 one without problems, IIRC]

> [...] here's one hint for the volta-spec-once.ly problem:
> Roboto-Regular is (on my current system) a font without a glyph
> table.

You mean the font doesn't have a 'glyf' table, right?  Then you
obviously have `Roboto-Regular.otf` – this font comes with a 'CFF '
table instead.  AFAIK, LilyPond supports such OpenType fonts just
fine.

> That meant that I had to write special code for my cairo backend,
> [...]

What exactly do you mean with 'special code'?

> and we know that handling of this special case is far from optimal
> in the postscript backend (eg -dgs-load-fonts is unusable).  ft2
> gives virtual uni[0-9a-f]* glyph names to pass the unicode value,

Hmm.  My version of `Roboto-Regular.otf` (2.00, 2019-12-11) actually
has glyph names.

> and we would need to translate those to unicode and use the ps show
> operator for a better solution in the postscript backend.

It's not clear to me what exactly the problem is.  Please elaborate.


Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: script stack order regression

[Werner LEMBERG]

>> I don't think LilyPond guarantees a particular order of events
>> occuring at the same moment, but I agree that wrapping them should
>> not change the order.  An issue has been created to track this
> 
> But the regression test script-stack-order.ly is quite explicit
> about the order being guaranteed.

This is the trivial case.  The problematic case are constructs like

  << { ... } { ... } ... >>

and similar things.


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Incorrectly Formatted Tables, web.pdf

[Werner LEMBERG]

>> I recently downloaded Lilypond v2.23, and with it the big
>> documentation manual, web.pdf.
> 
> I think web.pdf is not really a priority with respect to formatting,
> as the name suggests you should just view the web page at
> lilypond.org.

+1


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \center-column broken

[Werner LEMBERG]

> Inkscape works very well to convert PDFs to SVG, but if we expect
> our users to do that, then it's debatable whether we should have an
> SVG backend at all.

I agree.  However, my SVG knowledge is very small; this means I'm not
qualified to make any decisions.

> (I mean this seriously: the SVG backend has its own bugs that are
> hard to fix; we have no way, currently, to regtest it; and we could
> get LilyPond to call inkscape itself where it is available and SVG
> is the specified backend; just a thought...)

Please raise these topics on the 'lilypond-devel' mailing list!
'bug-lilypond' is probably the wrong one.

It probably also makes sense to file issues in the tracker.


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \center-column broken

[Werner LEMBERG]

> How about hosting the fonts on www.lilypond.org and referencing them
> in the @font-face definition?

I think this is not a good idea.

* LilyPond fonts change from version to version, quite often in a
  backwards-incompatible way.  Hosting them for SVG access would
  enforce us to completely revise how fonts are named and accessed –
  and versioned.  To a certain extent this will become better if the
  transition to SMuFL is done, but it still complicates things.

* It would be necessary to serve subsetted fonts, too; otherwise, the
  internet bandwidth would be far too large.  LilyPond has zero
  support for that.

* Contrary to fonts, hinting does not make sense for most musical
  glyphs.  In other words, the benefit of accessing LilyPond graphical
  objects (grobs) as real glyphs in fonts is zero.

* Serving non-musical fonts would be definitely out of scope for
  'lilypond.org'.

What exactly do you want to achieve?  What kind of SVGs do you need?
In previous e-mails I mentioned two solutions how SVGs could be
improved:

* using inkscape's option `-T` to convert glyphs to outlines
* conversion from PDF to SVG with inkscape

Doesn't this suffice?


Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \center-column broken

[Werner LEMBERG]

>> IMHO, this is as good (or as bad) as a default as 'serif'.  If you
>> want SVG images to be similar to, say, PDF output, you have
>>
>>* to exactly specify which font you want to use for text, and
>>* to convert glyphs to paths, for example, by postprocessing
>>  LilyPond's output SVG file with inkscape's `-T` option.
> 
> Could we possibly offer the option to embed the fonts inside of the
> SVG file [...]

This is a non-trivial issue.  It's rather straightforward to embed
fonts into an SVG file using

  
@font-face {
  font-family: 'foobar';
  src: url(data: application/font-woff2;
   charset = utf-8;
   base64, d09GMgABAA70AA8AGF ...)
   format('woff2'),
  font-weight: normal;
  font-style: normal;
}
  

The tricky part, however, is font subsetting to make the SVG files
small.  IMHO, this is outside of LilyPond's scope.

Another possibility is creating a PDF with LilyPond, then loading it
into inkscape, which can automatically convert all fonts to paths.
This way, you get SVGs that are identical to the PDFs – I think this
is good enough for having scalable images on web pages and the like.


Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \center-column broken

[Werner LEMBERG]

> But what is the difference between _\markup and -\markup?

Alas, this is missing in the notation index.[*]

In general, if you use `-` before an object (attached to a note),
LilyPond uses a vertical default position.  If you use `^` or `_`
instead, the object's vertical position is forced to be above or
below, respectively.


Werner


[*] To be added with merge request #651

  https://gitlab.com/lilypond/lilypond/-/merge_requests/651

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \center-column broken

[Werner LEMBERG]

> With 2.18, I see this instead:
> 
>    font-family="Century Schoolbook L"
>   font-weight="bold"
>   font-size="6.9848"
>   text-anchor="start"
>   fill="currentColor">
> 
> 
> 

IMHO, this is as good (or as bad) as a default as 'serif'.  If you
want SVG images to be similar to, say, PDF output, you have

  * to exactly specify which font you want to use for text, and
  * to convert glyphs to paths, for example, by postprocessing
LilyPond's output SVG file with inkscape's `-T` option.


 Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \center-column broken

[Werner LEMBERG]

> I had seen the "-" operator before but could not find it in
> LilyPond's docs.

If you look into the index, you can find it in the notation reference
(NR):

  
http://lilypond.org/doc/v2.23/Documentation/notation/expressive-marks-attached-to-notes#index-_002d


 Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: emmentaler*.otf not usable in JAVA application

[Werner LEMBERG]

> Probable reason: The fullname property (Vorzeigename) of the fonts
> is set to Untitled-1, it should be the same as the name property:
> 
> The following two changes fixed the problem for me: [...]

Thanks for the patch, which is now registered as a merge request.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/650


Werner

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond