>> While it is rather innocuous in this particular case it might be >> extremely frustrating for beginners to find out why LilyPond does >> this. > > I'm not sure I follow your thought process. What is it that you > worry would be confusing to beginners? Genuine question. Is it > something about accidental replacements specifically, or just text > replacements generally?
The latter. > For that reason, default text replacements should only be added if > we expect that essentially every user will be happy with them. As with many assumptions I'm sure that this is not always true, especially because the text representation forms of accidentals have different metrics to whatever glyphs are used in the wild and thus can potentially change the layout in unexpected ways. > My personal view is that replacing Unicode accidentals with the text > accidentals of the current music font would probably be a sensible > default behavior. I agree, but... > I've long felt that it was surprising and frustrating to find that > Unicode accidentals fall back on a totally different font than that > used for other text or music (and one which typically looks worse, > and that looks different on different OSes). ... this problem exists for *any* glyph not contained in the current text font. > I guess I should add that I can see one use case where the > replacements might be unwanted, and that is when a text font is used > that specifically contains nice looking accidentals, such as > Nepomuk. That is a use case that should be supported, but IMO it > shouldn't take precedence over the behavior with default fonts. I think that exactly this use case should stay as the default. So: I still ask you to submit your example to the LSR – irrespective of whether we are going to change the current default of LilyPond (but note that the LSR runs version 2.24, meaning that you need slightly different code to get decent output, I reckon). If you are brave you might also contribute similar code to the NR :-) * An updated LSR for 2.25.xx should be added to `Documentation/snippets/new`. * A call to `scripts/auxiliar/makelsr -N -D` adds it to `Documentation/snippets`. * You can than add the snippet to the appropriate `@snippets` section. Werner
