PATCHES - Countdown for July 29th
Hello, Here is the current patch countdown list. The next countdown will be on July 31st. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !852 Beaming pattern: use Rational rather than Moment - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/852 !851 Rational: improve handling of infinities and NaN - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/851 !850 Add more music start & length tests - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/850 !849 Clean up completion engravers - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/849 Countdown: !856 Don't duplicate class-specific interfaces in copy constructors - Jean Abou-Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/856 !848 Fix missing space in musicxml.py warning - Jean Abou-Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/848 !845 Quote_iterator simplification - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/845 Review: !857 Support compressing \autoChange and \partCombine - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/857 !855 midi: check close() error status - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/855 !853 The CAIRO backend by knupero, remixed by hanwen - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/853 !839 Allow parenthesizing spanners - Jean Abou-Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/839 New: No patches in New at this time. Waiting: !858 add PNG output to cairo - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/858 *** Regards, James -- Regards James
Re: Cairo: Please test mingw installer
On Thu, Jul 29, 2021 at 11:32 AM Michael Käppler wrote: > Hi Knut, > thank you very much for your work! > > Am 29.07.2021 um 01:13 schrieb Knut Petersen: > > Here are installers for lilypond with the cairo backend after a > > significant remix by Han-Wen. GUB has been changed to use a cairo > > version that fixes three bugs relevant for lilypond, a test would be > > nice. > > > Here the test results that I could acquire so far. > At first I tested the mingw installer under Windows 10. > > The first problem I noticed with a bigger score was that Lilypond failed > with > "schwerer Fehler: Cairo context status 'invalid tag name, attributes, or > nesting'" > > This happens only if point-and-click is enabled. Otherwise it compiles > fine. > Under linux-64, with the same input file, this error does not occur. > Other files also work fine under both architectures. > Unfortunately I do not have time to cook a minimal failing example. > > The following observations are tied to the mingw installer. > > A small nit: SVG files are the only ones having no additional 'cairo' > file extension. Is this intended? > "-dbackend=cairo" has to be last. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Cairo: Please test mingw installer
Hi Knut, thank you very much for your work! Am 29.07.2021 um 01:13 schrieb Knut Petersen: Here are installers for lilypond with the cairo backend after a significant remix by Han-Wen. GUB has been changed to use a cairo version that fixes three bugs relevant for lilypond, a test would be nice. Here the test results that I could acquire so far. At first I tested the mingw installer under Windows 10. The first problem I noticed with a bigger score was that Lilypond failed with "schwerer Fehler: Cairo context status 'invalid tag name, attributes, or nesting'" This happens only if point-and-click is enabled. Otherwise it compiles fine. Under linux-64, with the same input file, this error does not occur. Other files also work fine under both architectures. Unfortunately I do not have time to cook a minimal failing example. The following observations are tied to the mingw installer. A small nit: SVG files are the only ones having no additional 'cairo' file extension. Is this intended? All output formats compiled fine otherwise and look ok at a first glance. The cairo pdf file is twice as large as the 'normal' one: $ ls -l partitur*.pdf -rw-r--r-- 1 Michael 197121 1586286 Jul 29 10:16 partitur.cairo.pdf -rw-r--r-- 1 Michael 197121 721407 Jul 29 10:17 partitur.pdf I made a visual diff of both PDFs. You can download it here: https://drive.google.com/file/d/1NiPODfHVWjawKXjF2t-wveWE-BjMj0Yc/view?usp=sharing The 'classic' PDF is green, the cairo PDF is red. If they match exactly it merges to black. I could not spot big differences, there is a bunch of very small, subtle differences, however. Some timings: $ time /d/Lilypond-generic/2.23.4/usr/bin/lilypond -dpoint-and-click=#f partitur.ly real 0m35.632s user 0m0.000s sys 0m0.078s $ time /d/Lilypond-generic/2.23.4/usr/bin/lilypond -dpoint-and-click=#f -dbackend=cairo partitur.ly real 0m33.175s user 0m0.015s sys 0m0.046s $ time /d/Lilypond-generic/2.23.4/usr/bin/lilypond --ps partitur.ly real 0m33.462s user 0m0.031s sys 0m0.062s $ time /d/Lilypond-generic/2.23.4/usr/bin/lilypond --ps -dbackend=cairo partitur.ly real 0m39.974s user 0m0.015s sys 0m0.062s $ time /d/Lilypond-generic/2.23.4/usr/bin/lilypond --png partitur.ly real 0m51.850s user 0m0.000s sys 0m0.062s $ time /d/Lilypond-generic/2.23.4/usr/bin/lilypond --png -dbackend=cairo partitur.ly real 0m47.377s user 0m0.015s sys 0m0.062s $ time /d/Lilypond-generic/2.23.4/usr/bin/lilypond --svg partitur.ly real 1m53.029s user 0m0.015s sys 0m0.093s $ time /d/Lilypond-generic/2.23.4/usr/bin/lilypond -dbackend=cairo --svg partitur.ly real 1m39.438s user 0m0.015s sys 0m0.046s Michael
Re: accessibility features
Le 28/07/2021 à 16:09, ar...@itu.edu.tr a écrit :
To whom it may concern,
I am contacting you to request information about the accessibility
features of your notation software for the visually impaired users.
The information you may provide in regards to my research, will be
used to provide academical information in my PHD dissertation on blind
musicians’ access to music notation, both to compose and review scores
which are especially in the modern style that have been composed from
1945 to the present.
It is initially important for me to receive reasons from you if any,
some or all of the features of your product are unavailable for the
visually impaired users and the details for that.
Thank you very much for your prospective contribution and
collaboration in advance.
Çağlar Arsu
Istanbul Technical University
Hello,
LilyPond is a text-based music notation software. This
means that the user interface is completely accessible
to visually impaired persons. You can use any text editor
you like (with decent accessibility features of course).
So LilyPond's accessibility is simply a principle of its
core design.
For someone seeking to compose music with peculiar
notation (as you mention modern music), LilyPond is
an ideal tool since you can program every element of
the score. The following examples come to mind.
If this is an important aspect for you, there are
several people on this list who use LilyPond for this
kind of tasks.
https://clairnote.org/
https://lists.gnu.org/archive/html/lilypond-user/2021-04/msg00047.html
https://lists.gnu.org/archive/html/lilypond-user/2013-04/msg00563.html
http://www.mikesolomon.org/scores/passeggiata.pdf
However, LilyPond does not (yet) export Braille music,
nor MusicXML. I've CCed someone who has been working on
conversion from MusicXML to Braille and might have insights.
A number of blind people have been supported by the
user list ("community forum"). You can find raw
feedback in the questions by searching the list
archives at
https://lists.gnu.org/archive/html/lilypond-user/
There is also a blind composer called Hu Haipeng who
was quite active at a time (although I have not seen
him recently). I don't have his email address, but
you could probably get in touch with him using this
contact form:
http://www.brailleorch.org/en/contact/
It's for the website of a Braille music project he
appears to have launched.
Best regards,
Jean
