Re: GSoC 2020: SMuFL glyph name to index lookup
It seems to me that if you are going to use SMuFL fonts, you're either going to have to completely rewrite every lilypond glyph-name lookup (which should probably be phase 3 of the project) or you're going to have to have a lilypond-glyph-name-to-smufl-code-point lookup. If I were doing it as part of a staged approach, I'd do the SMuFL code point lookup. Whether the lilypond-glyph-name-to-smufl-code-point lookup has an intermediate step of smufl-glyph-name probably doesn't matter to me, at least for now. It will be less efficient, but I'd be shocked if you could measure the difference in process time. Most of our time is spent doing layout, not looking up glyphs. It seems to me like you'll want to have a lilypond-glyph-name to smufl-glyph-name table created anyway, because you're going to have to make the changes to smufl-glyph-name in the code (or else hardcode the code points, but you seem to think they are possible to change, so we shouldn't do that). So I don't think the work to make the lilypond to smufl glyph name lookup is wasted work. But I think these are mostly stylistic decisions, and there's not much in the way of objective criteria that says one way or another is better. So do what you think best, IMO. Thanks, Carl On 5/27/20, 6:48 PM, "lilypond-devel on behalf of Owen Lamb" wrote: Hi all, I do believe I've finally tracked down the place where lilypond glyph names are turned into character codes: Open_type_font::name_to_index. I can add a ternary operator here based on whether the Open_type_font is_smufl (a new property that, in the future, should be detected and set when the font is initialized), and hook it into a new function which returns the correct code point based on the SMuFL specification. Now, I could take a few different routes with this. On one hand, I could replace every instance of the lilypond glyph naming system (i.e. clefs.G) with the SMuFL one (i.e. gClef). This would mean every user would need to learn the new vocabulary if they want to reference glyphs in their scheme code. (There's also the question of what to do about glyphs in LilyPond that don't have a counterpart in SMuFL, which I plan to research anyway.) On the other hand, I could keep the current LilyPond naming system, hand-writing a dictionary that translates LilyPond names straight into SMuFL code points. This would retain a bit of nonstandardness, which might annoy future developers, with the benefit of keeping my changes largely inconsequential to the seasoned user. On the third hand (I suppose it's a three-handed monster, oh well), I could write multiple lookup functions--one to map lilypond name to SMuFL-name, and another to map SMuFL-name to code point. This would make updating to new versions of SMuFL especially easy, and keep end user experience the same, but the lookup time would be twice as long, making performance suffer. So, the way I see it, I have to sacrifice either backwards-compatibility, full standardization, or performance. What do you all think I should go for? Is there something I missed? Thanks, Owen
Re: GSoC 2020: SMuFL glyph name to index lookup
> It seems to me that if you are going to use SMuFL fonts, you're > either going to have to completely rewrite every lilypond glyph-name > lookup (which should probably be phase 3 of the project) or you're > going to have to have a lilypond-glyph-name-to-smufl-code-point > lookup. To decide whether LilyPond completely abandons the current glyph names by replacing them with the SMuFL mnemonics is something the LilyPond community has to decide. Using `convert-ly`, this could be easily done. However, I don't know whether this makes sense. > It seems to me like you'll want to have a lilypond-glyph-name to > smufl-glyph-name table created anyway, because you're going to have > to make the changes to smufl-glyph-name in the code (or else > hardcode the code points, but you seem to think they are possible to > change, so we shouldn't do that). No, they don't change. SMuFL might deprecate code points in favour of new solutions, but no code points get removed. Werner
Re: GSoC 2020: SMuFL glyph name to index lookup
> I do believe I've finally tracked down the place where lilypond > glyph names are turned into character codes: > Open_type_font::name_to_index. I can add a ternary operator here > based on whether the Open_type_font is_smufl (a new property that, > in the future, should be detected and set when the font is > initialized), and hook it into a new function which returns the > correct code point based on the SMuFL specification. I think there is a fundamental misunderstanding. Bravura is an OpenType font, and the only intended communication with such fonts is via character code values and *not* glyph names. It is a technical detail that LilyPond primarily communicates with OTF fonts via glyph names: this is necessary only because LilyPond natively emits PostScript code, which predates the invention of OpenType and thus doesn't use character codes. > Now, I could take a few different routes with this. > > On one hand, I could replace every instance of the lilypond glyph > naming system (i.e. clefs.G) with the SMuFL one (i.e. gClef). But the glyph name 'gClef' is internal to the Bravura font specification! It is just an aid for the font developer to have something mnemonic. Glyph names that are visible to clients (this is, being part of the font file itself) are normally of the form 'uni' or 'uX', with '' and 'X' four-digit and five-digit uppercase hexadecimal values, respectively; this is recommended by the Adobe Glyph List Specification for New Fonts, obeyed by virtually all fonts today. https://github.com/adobe-type-tools/agl-aglfn/ If a font developer decides to use funny glyph names like 'MyVeryCheesyGeeClef' in the OpenType font: well, this *is* possible (but non-standard, of course), and today, with recent applications, such a font should work out of the box because only character codes are of importance. Instead, the route must be as follows. (1) Create a mapping from LilyPond glyph names to SMuFL character codes (which usually are in the Unicode's PUA). This is a static table since SMuFL has stabilized; if a new SMuFL version gets released, this table has to be updated within LilyPond. (2) Convert the character code resulting from (1) to the font's glyph index and proceed as usual. Only (1) is missing currently, AFAICS. It has to be investigated whether this mapping is one to one; I can imagine that some glyphs in LilyPond map to more than a single glyph in SMuFL and vice versa. > This would mean every user would need to learn the new vocabulary if > they want to reference glyphs in their scheme code. Definitely not :-) However, I can imagine that LilyPond provides an option to *also* allow Bravura glyph names (or maybe instead; I don't have an opinion here) for `\musicGlyph`. > (There's also the question of what to do about glyphs in LilyPond > that don't have a counterpart in SMuFL, which I plan to research > anyway.) This is the tricky part, I guess. > On the other hand, I could keep the current LilyPond naming system, > hand-writing a dictionary that translates LilyPond names straight into > SMuFL code points. Exactly. > This would retain a bit of nonstandardness, ... Not at all, IMHO. > ... which might annoy future developers, with the benefit of keeping > my changes largely inconsequential to the seasoned user. Again: Having an option to allow SMuFL glyph names is very useful, but it is not the right way to communicate with fonts following the SMuFL standard. > On the third hand (I suppose it's a three-handed monster, oh well), > I could write multiple lookup functions--one to map lilypond name to > SMuFL-name, and another to map SMuFL-name to code point. Rather not. > So, the way I see it, I have to sacrifice either > backwards-compatibility, full standardization, or performance. Fortunately, there's nothing to sacrifice :-) Werner
Re: new procedure with GitLab CI
On May 27, 2020, at 21:03, David Kastrup wrote: > > Dan Eble writes: >> I wonder how the rest of you feel about having another developer click >> the buttons to rebase and merge your MRs? > > If you refer to me doing that on Han-Wen's merge request, he actually I had no idea. I just noticed that there are still some patches on "Push" and no pipelines running. At such a time, I could start one, but I wouldn't want to be a pest. > I don't think it would be a good idea to start a pipeline on somebody > else's merge request without having an indication that they were going > to follow through with "Patch_push": Patch_push indicates no objections > from foreign review, but the responsibility for starting the final > pipeline/merge should really lie with the original submitter. What if we (by convention) reserve Approval as a way for the submitter to indicate this, so that anyone who sees an Approved MR with the Patch::push label is free to trigger the merge? — Dan
Re: new procedure with GitLab CI
Dan Eble writes: > On May 27, 2020, at 07:16, David Kastrup wrote: >> >> Now that we have the first "please get in line" merge that isn't >> actually to any degree unusual, I get the suspicion that my previous >> alternative proposal of pushing to a CI-less staging branch that then >> uses CI to get to master will eventually become a reality. > > I wasn't much bothered by this round of merging. > > I wonder how the rest of you feel about having another developer click > the buttons to rebase and merge your MRs? If you refer to me doing that on Han-Wen's merge request, he actually started his pipeline (with merge-to-master-when-finished) shortly after mine and it ended up not being allowed to push because of requiring a rebase after my merge request went through. So when I saw that I caused his intended merge to fail (or rather, that he had not checked whether my earlier started pipeline was a merging one), I restarted his pipeline as a "courtesy" since the rebase was a trivial one. So it's not as much that I as "another developer clicked the buttons to rebase and merge his MRs" rather than that I forced GitLab to complete his explicit order. For a trivial rebase, I don't see much wrong here but of course others may see this as taking too much of a liberty here. > Maybe we could adopt a convention that if you would object to that, > you configure your MR so that you are the only one who is allowed to > merge; and if you don't do that, then anyone who comes by at a time no > pipelines are running would be free to start one. — Dan I don't think it would be a good idea to start a pipeline on somebody else's merge request without having an indication that they were going to follow through with "Patch_push": Patch_push indicates no objections from foreign review, but the responsibility for starting the final pipeline/merge should really lie with the original submitter. In this case, Han-Wen already made the decision but GitLab did not complete it. And the patched area was not related to mine, either. -- David Kastrup
GSoC 2020: SMuFL glyph name to index lookup
Hi all, I do believe I've finally tracked down the place where lilypond glyph names are turned into character codes: Open_type_font::name_to_index. I can add a ternary operator here based on whether the Open_type_font is_smufl (a new property that, in the future, should be detected and set when the font is initialized), and hook it into a new function which returns the correct code point based on the SMuFL specification. Now, I could take a few different routes with this. On one hand, I could replace every instance of the lilypond glyph naming system (i.e. clefs.G) with the SMuFL one (i.e. gClef). This would mean every user would need to learn the new vocabulary if they want to reference glyphs in their scheme code. (There's also the question of what to do about glyphs in LilyPond that don't have a counterpart in SMuFL, which I plan to research anyway.) On the other hand, I could keep the current LilyPond naming system, hand-writing a dictionary that translates LilyPond names straight into SMuFL code points. This would retain a bit of nonstandardness, which might annoy future developers, with the benefit of keeping my changes largely inconsequential to the seasoned user. On the third hand (I suppose it's a three-handed monster, oh well), I could write multiple lookup functions--one to map lilypond name to SMuFL-name, and another to map SMuFL-name to code point. This would make updating to new versions of SMuFL especially easy, and keep end user experience the same, but the lookup time would be twice as long, making performance suffer. So, the way I see it, I have to sacrifice either backwards-compatibility, full standardization, or performance. What do you all think I should go for? Is there something I missed? Thanks, Owen
Re: GSoC 2020 update
Ah! And of course, soon after I ask, I find that the point is moot. I'm sticking Bravura deep in the build/out directory where the font files are, which of course is already ignored by git. Thank you and sorry for the trouble! --Owen On Wed, May 27, 2020 at 2:36 PM Werner LEMBERG wrote: > > > ... as long as we don't intend to ship Bravura along with LilyPond > > I'd say it shouldn't be added to the repository. Except if it's > > necessary to get your work tested (maybe one day you'll habe a merge > > request that won't work without a real SMuFL font ...). > > I second that. If we are ever going to add it to lilypond's git > repository I think the right time is just before merging the GSoC > stuff. Until then... > > > To keep something local to your computer it's better not to use the > > .gitignore file but .git/info/exclude - which does the same but > > without itself being committed. > > ... this is probably the simplest way to go. > > > Werner >
Re: new procedure with GitLab CI
On May 27, 2020, at 07:16, David Kastrup wrote: > > Now that we have the first "please get in line" merge that isn't > actually to any degree unusual, I get the suspicion that my previous > alternative proposal of pushing to a CI-less staging branch that then > uses CI to get to master will eventually become a reality. I wasn't much bothered by this round of merging. I wonder how the rest of you feel about having another developer click the buttons to rebase and merge your MRs? Maybe we could adopt a convention that if you would object to that, you configure your MR so that you are the only one who is allowed to merge; and if you don't do that, then anyone who comes by at a time no pipelines are running would be free to start one. — Dan
GitLab CI: warning about C059-BdIta.otf
Dear Jonas, I noticed in the log of test and documentation builds in GitLab CI the following message: WARNING: build/out/share/lilypond/current/fonts/otf/C059-BdIta.otf: chmod build/out/share/lilypond/current/fonts/otf/C059-BdIta.otf: no such file or directory (suppressing repeats) Is it expected? Best wishes. Davide
Re: GSoC 2020 update
> ... as long as we don't intend to ship Bravura along with LilyPond > I'd say it shouldn't be added to the repository. Except if it's > necessary to get your work tested (maybe one day you'll habe a merge > request that won't work without a real SMuFL font ...). I second that. If we are ever going to add it to lilypond's git repository I think the right time is just before merging the GSoC stuff. Until then... > To keep something local to your computer it's better not to use the > .gitignore file but .git/info/exclude - which does the same but > without itself being committed. ... this is probably the simplest way to go. Werner
Re: GSoC 2020 update
Hi Owen! Am 27. Mai 2020 22:58:19 MESZ schrieb Owen Lamb : >Hi all! > >I pushed the new dev/lamb/GSoC-2020 branch to origin yesterday, and it >appears to be visible on GitLab. I haven't committed anything new yet, >but >I will soon. I'll push any commits I make at the end of each work day. > >I plan to give updates regularly every Friday. So far I have been >investigating open-type-font.cc as an entrypoint for changing the >encoding, >but I'll have a more detailed report then. > >I have a couple questions in the meantime: > >I plan to temporarily add the Bravura font to my lilypond branch for >testing SMuFL throughout the summer. Is there any legal reason not to No. Bravura has very avöctively been developed and promoted to be an open font. It may be shared along with the usual license stuff, but ... >(or >at least to .gitignore it so it only appears on my machine)? ... as long as we don't intend to ship Bravura along with LilyPond I'd say it shouldn't be added to the repository. Except if it's necessary to get your work tested (maybe one day you'll habe a merge request that won't work without a real SMuFL font ...). To keep something local to your computer it's better not to use the .gitignore file but .git/info/exclude - which does the same but without itself being committed. Best Urs It appears >to >be licensed under OFL 1.1, just like Feta, but I'd just like to make >sure >I'm not accidentally breaking any laws as I work publicly. > >This next one is a minor annoyance and probably a C++ newbie question, >but >my IDE (VS Code, chosen for comfort) is reporting "a >dynamically-initialized local static variable is not allowed inside of >a >statement expression" about a million times throughout the .cc files, >whenever particular #define'd macros, e.g. ly_symbol2scm or >get_property, >are referenced. From what I know, macros aren't dynamically >initialized, >are they? Does anyone know why this might be happening? This doesn't >seem >to affect compilation, so I can easily ignore the red squiggly lines, >but >if there's a way to get rid of them, I'm all ears. > >And, of course, if you have any comments or suggestions about anything >else, please let me know! > >Thanks, >Owen -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
GSoC 2020 update
Hi all! I pushed the new dev/lamb/GSoC-2020 branch to origin yesterday, and it appears to be visible on GitLab. I haven't committed anything new yet, but I will soon. I'll push any commits I make at the end of each work day. I plan to give updates regularly every Friday. So far I have been investigating open-type-font.cc as an entrypoint for changing the encoding, but I'll have a more detailed report then. I have a couple questions in the meantime: I plan to temporarily add the Bravura font to my lilypond branch for testing SMuFL throughout the summer. Is there any legal reason not to (or at least to .gitignore it so it only appears on my machine)? It appears to be licensed under OFL 1.1, just like Feta, but I'd just like to make sure I'm not accidentally breaking any laws as I work publicly. This next one is a minor annoyance and probably a C++ newbie question, but my IDE (VS Code, chosen for comfort) is reporting "a dynamically-initialized local static variable is not allowed inside of a statement expression" about a million times throughout the .cc files, whenever particular #define'd macros, e.g. ly_symbol2scm or get_property, are referenced. From what I know, macros aren't dynamically initialized, are they? Does anyone know why this might be happening? This doesn't seem to affect compilation, so I can easily ignore the red squiggly lines, but if there's a way to get rid of them, I'm all ears. And, of course, if you have any comments or suggestions about anything else, please let me know! Thanks, Owen
Re: new procedure with GitLab CI
Jonas Hahnfeld writes: > Am Mittwoch, den 27.05.2020, 12:17 +0200 schrieb Valentin Villenave: >> On 5/27/20, Jonas Hahnfeld wrote: >> > We do want to have the pipeline on the commit before it is merged >> > because this replaces patchy. >> >> Well, that’s absolutely crucial at the MR review stage. But after >> passing the review and countdown process, the need for CI >> testing decreases. So an option to bypass the pipeline when we reach >> the “rebase & merge” stage wouldn’t necessarily be harmful. > > [added the part of the second email] > > This would be radically different from the old setup: Push to staging, > wait for patchy to test. I agree that not bunching stuff together is > different, but no testing at all isn't an alternative IMHO. Now that we have the first "please get in line" merge that isn't actually to any degree unusual, I get the suspicion that my previous alternative proposal of pushing to a CI-less staging branch that then uses CI to get to master will eventually become a reality. The main question is then rather whether this should be optional (in which case someone needs to be responsible for rebasing the collected staging when something got to master directly) or mandatory after all. >> > The only limitation is that all MRs are >> > checked individually. >> >> Not only individually, but sequentially. And with no automatic queue >> for rebasing, everything has to be done manually: checking whether >> something’s already running somewhere; waiting until that gets merged; >> then triggering the rebase/CI while hoping nobody else has been doing >> the same at the same moment. >> >> That’s not merely a limitation, that’s a PITA. Is there a way we >> could at least get the rebase part done within the pipeline? i.e. >> “rebase and launch pipeline and merge when the pipeline is done” or >> something like that? > > No, "rebase" is currently manual (with "merge when pipeline succeeds" > being automatic). This has been clearly communicated, sorry if you > missed that. Well, the point of a working mechanism is that nothing needs to get communicated by side channels. Of course, we aren't there yet since we are still figuring out our usage patterns for Gitlab. > Jonas > -- David Kastrup
Re: helping with testing resources
Dear Jonas, Il giorno sab 23 mag 2020 alle ore 20:01 Jonas Hahnfeld ha scritto: > If you have spare hardware and / or want to help with CI testing, this > is easy to setup with GitLab. I have setup my laptop for GitLab's CI (of course you already know it). A question which may be interesting also to other people: what happens if I suspend or switch off my laptop during a build? Will the merge request be marked as failed or will another build be scheduled in another runner? These days I'm working from home, so I can keep the laptop active as needed, but when I start going to the office again I'll need to suspend/switch off the laptop for commuting. Best wishes. Davide
Re: new procedure with GitLab CI
Am Mittwoch, den 27.05.2020, 12:17 +0200 schrieb Valentin Villenave: > On 5/27/20, Jonas Hahnfeld wrote: > > We do want to have the pipeline on the commit before it is merged > > because this replaces patchy. > > Well, that’s absolutely crucial at the MR review stage. But after > passing the review and countdown process, the need for CI > testing decreases. So an option to bypass the pipeline when we reach > the “rebase & merge” stage wouldn’t necessarily be harmful. [added the part of the second email] This would be radically different from the old setup: Push to staging, wait for patchy to test. I agree that not bunching stuff together is different, but no testing at all isn't an alternative IMHO. > > The only limitation is that all MRs are > > checked individually. > > Not only individually, but sequentially. And with no automatic queue > for rebasing, everything has to be done manually: checking whether > something’s already running somewhere; waiting until that gets merged; > then triggering the rebase/CI while hoping nobody else has been doing > the same at the same moment. > > That’s not merely a limitation, that’s a PITA. Is there a way we > could at least get the rebase part done within the pipeline? i.e. > “rebase and launch pipeline and merge when the pipeline is done” or > something like that? No, "rebase" is currently manual (with "merge when pipeline succeeds" being automatic). This has been clearly communicated, sorry if you missed that. Jonas signature.asc Description: This is a digitally signed message part
Re: new procedure with GitLab CI
On 5/27/20, Valentin Villenave wrote: > On 5/27/20, Jonas Hahnfeld wrote: >> We do want to have the pipeline on the commit before it is merged >> because this replaces patchy. > > Well, that’s absolutely crucial at the MR review stage. But after passing [sorry, I forgot to end that sentence] … After passing the review and countdown process, the need for CI testing decreases. So an option to bypass the pipeline when we reach the “rebase & merge” stage wouldn’t necessarily be harmful. V.
Re: new procedure with GitLab CI
On 5/27/20, Jonas Hahnfeld wrote: > We do want to have the pipeline on the commit before it is merged > because this replaces patchy. Well, that’s absolutely crucial at the MR review stage. But after passing > The only limitation is that all MRs are > checked individually. Not only individually, but sequentially. And with no automatic queue for rebasing, everything has to be done manually: checking whether something’s already running somewhere; waiting until that gets merged; then triggering the rebase/CI while hoping nobody else has been doing the same at the same moment. That’s not merely a limitation, that’s a PITA. Is there a way we could at least get the rebase part done within the pipeline? i.e. “rebase and launch pipeline and merge when the pipeline is done” or something like that? Cheers, -- V.
Re: new procedure with GitLab CI
Am Mittwoch, den 27.05.2020, 10:54 +0200 schrieb Valentin Villenave: > On 5/27/20, Jonas Hahnfeld wrote: > > Pinging this to attention... > > Yeah, that’s one of those “I’ve read it without fully understanding > it” situations (and then the discussion devolved into James’s workflow > and I lost track). > > So IIUC there’s no way to skip the rebase-triggered CI pipeline right > now? (I didn’t quite understand if the -skip option worked or not in > that case.) We do want to have the pipeline on the commit before it is merged because this replaces patchy. The only limitation is that all MRs are checked individually. > Or are we willing to accept situations where, in case of a fairly > trivial rebase where side-effects are absolutely unlikely, people > could manually stop the pipeline as soon as it starts, and force the > merge to happen immediately? This shouldn't and fortunately doesn't work, see above. Jonas signature.asc Description: This is a digitally signed message part
Re: new procedure with GitLab CI
On 5/27/20, Jonas Hahnfeld wrote: > Pinging this to attention... Yeah, that’s one of those “I’ve read it without fully understanding it” situations (and then the discussion devolved into James’s workflow and I lost track). So IIUC there’s no way to skip the rebase-triggered CI pipeline right now? (I didn’t quite understand if the -skip option worked or not in that case.) Or are we willing to accept situations where, in case of a fairly trivial rebase where side-effects are absolutely unlikely, people could manually stop the pipeline as soon as it starts, and force the merge to happen immediately? Cheers, -- V.
Re: new procedure with GitLab CI
Am Samstag, den 23.05.2020, 19:59 +0200 schrieb Jonas Hahnfeld: > Hi all, > > I've now made the necessary settings, merged the changes in > https://gitlab.com/lilypond/lilypond/-/merge_requests/57, changed all > existing merge requests to target 'master', and deleted 'staging'. > I've not rebased the existing merge requests and there's no need to do > so if it's already in one of the later stages (you'll be forced on > submission). However remember that James won't get MRs with Patch::new > for manual regression testing unless it has passed automated tests. > > The new procedure to push / merge is as follows: > 0. The patch reaches Patch::push via the known countdown process. > 1. GitLab only allows fast-forward merges, so it forces you to rebase > your changes. Without conflicts, the UI will present a button for this. > Otherwise, or if you prefer doing so, you can always rebase locally and > force-push the branch. > 2. Updating the merge requests triggers the CI jobs to run. The UI will > have a new button "Merge when pipeline succeeds". You can click this at > your convenience and the system will handle the rest. Otherwise you can > wait yourself and click the "normal" button labeled "Merge" as before. > > > If multiple merge requests are rebased simultaneously, GitLab merges > the first one that finishes CI testing. The other merge is aborted, but > the CI pipeline continues to run AFAICT. So for saving resources, > please try to avoid it. We'll see if this "contention" turns out to be > a problem... Pinging this to attention... signature.asc Description: This is a digitally signed message part
Re: remove merged branches & branches with tags
- Original Message - From: "Valentin Villenave" To: "Jonas Hahnfeld" Cc: "lilypond-devel" Sent: Wednesday, May 27, 2020 7:59 AM Subject: Re: remove merged branches & branches with tags On 5/26/20, Jonas Hahnfeld wrote: Is this OK with everyone? Fine by me. -- V. +1 -- Phil Holmes
Re: remove merged branches & branches with tags
On 5/26/20, Jonas Hahnfeld wrote: > Is this OK with everyone? Fine by me. -- V.
PATCHES - Countdown for May 27th
Hello, Here is the current patch countdown list. The next countdown will be on May 29th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !79 Rational: trade set_infinite () for infinity () - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/79 !78 Resolve "With `title = ""` SVG output differs from PDF output" - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/78 !77 Remove old .css link before installing new one - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/77 !75 Clarify Moment math in the C++ code - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/75 !74 Issue 5262: LM: incorrect staff-staff-spacing example (regression) - Kevin Barry https://gitlab.com/lilypond/lilypond/-/merge_requests/74 !73 Handle round-filled-box with infinity in arguments - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/73 !70 random cleanups in the output framework - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/70 !65 musicxml2ly: support multiple elements - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/65 !63 Fix #967: add a --svg command line option. - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/63 !60 Resolve "Use templates for lots of conversions to SCM and back" - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/60 Countdown: !89 Provide and use Diagnostics base class - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/89 !88 A few minor changes for Percent_repeat_iterator::music_tail - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/88 !87 Remove the read of lily_output_dir - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/87 !86 Use exist_ok=True instead of checking os.path.isdir() first - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/86 !85 Clean up warnings in lily/change-iterator.cc - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/85 !83 doc build cleanups - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/83 !82 Enable debug checks in CI - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/82 !81 Add CFF font name cache to get_postscript_name () - Masamichi Hosoda https://gitlab.com/lilypond/lilypond/-/merge_requests/81 !76 cleanups related to break-visibility handling - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/76 !71 Fix input/regression/skyline-grob-rotation.ly - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/71 !69 ps-to-png: use GhostScript's DownScaleFactor for antialiasing - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/69 !53 Allow CSS-style colors anywhere - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/53 Review: !91 Doc: expand NR 1.6.2.3 Hiding staves - Valentin Villenave https://gitlab.com/lilypond/lilypond/-/merge_requests/91 New: !92 Don't quote and evaluate command line variables - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/92 Waiting: !72 Move skylines_from_stencil out of the Stencil class - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/72 *** Regards, James
