Re: font problems
>> * Reduce the number of extra fonts as much as possible to not >> increase the size of the documentation additionally. [Not much a >> problem I think since most fonts will be subsetted by >> ghostscript.] > > I'd prefer to focus on fonts that are widely available. DejaVu and > Libertine are, I'm not sure about Iosevka and Libertinus (but maybe > the packages just have different names?). Iosevka seems to be an excellent font, but there are good alternatives. Libertinus is the (maintained) successor of Libertine, fixing buglets here and there. > Source Sans and Source Serif are by Adobe, are there equivalent > replacements? What's the problem with those Adobe fonts? They are completely free even in the GNU sense... Werner
Re: font problems
>> [for Japanese] → Source Han Serif > > For Japanese fonts, I suggest HaranoAji. > It is the default Japanese font from TeX Live 2020. > > https://www.ctan.org/pkg/haranoaji OK, thanks for the suggestion. Werner
Re: lilypond.pot broken (SCM missing)
On 08/10/2020 16:33, Jonas Hahnfeld wrote: Am Donnerstag, den 08.10.2020, 13:58 +0200 schrieb Michael Käppler: Am 08.10.2020 um 13:35 schrieb Jonas Hahnfeld: Am Mittwoch, den 07.10.2020, 22:49 +0200 schrieb Michael Käppler: Hi all, while adding gettext calls to all warning and error messages I noticed that the strings from all SCM files are missing in lilypond.pot. Bisecting yielded that commit 5e092ee0d9b84d1948dc90e95488e8c9b58576d1 Author: Han-Wen Nienhuys Date: Sat Mar 21 23:46:14 2020 +0100 Inline scm stepmake templates caused the regression. It seems that the definition of $(SCM_FILES) in scm/GNUmakefile does not reach stepmake/stepmake/po-targets.make, where it would be needed to run xgettext on it. I do not know how to fix this correctly, any advice or MR appreciated. https://gitlab.com/lilypond/lilypond/-/merge_requests/446 should fix this and has some explanations what's going on. On the bad side, this means we've lost the translations for French, Italian, and Japanese in commit ea3ead41. The ones in Catalan, Dutch, Esperanto, Spanish, and Swedish are still there, prefixed by #~. I'm not very familiar how the translation of the po files happens, adding Jean-Charles who "fetches" and commits the files. What do we need to resurrect them? If that requires another release, I'm all for doing 2.21.7 from master before creating a stable branch. Jonas Hi Jonas, thank you very much! I will upload a MR today that fixes all warnings and errors that were not i18ned yet. I think it would be reasonable to merge that one, too, before sending the POT file to the Translation project. Posted here: https://gitlab.com/lilypond/lilypond/-/merge_requests/448 So as discussed on GitLab, we should indeed do a new unstable release to add back the erroneously removed messages and give the translators a chance to localize the other warnings and errors. Shall we short-track the fix and the above MR? Phil, would you be available to release 2.21.7 once merged? Regards Jonas No problem. Let me know when to go. -- Phil Holmes
Re: font problems
Am Samstag, den 17.10.2020, 11:58 +0200 schrieb Werner LEMBERG: > Folks, > > some time ago I reported font problems in the documentation (this is, > using fonts that are either not optimal, or not freely available). > > The basic question is which route we should go. > > * Reduce the number of extra fonts as much as possible to not increase > the size of the documentation additionally. [Not much a problem I > think since most fonts will be subsetted by ghostscript.] I'd prefer to focus on fonts that are widely available. DejaVu and Libertine are, I'm not sure about Iosevka and Libertinus (but maybe the packages just have different names?). Source Sans and Source Serif are by Adobe, are there equivalent replacements? > * Be as diverse as possible. Jonas signature.asc Description: This is a digitally signed message part
Re: font problems
> * Documentation/snippets/utf-8.ly: > > [for Japanese] → Source Han Serif For Japanese fonts, I suggest HaranoAji. It is the default Japanese font from TeX Live 2020. https://www.ctan.org/pkg/haranoaji
New French PO file for 'lilypond' (version 2.21.7)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/lilypond/fr.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: font problems
Folks, some time ago I reported font problems in the documentation (this is, using fonts that are either not optimal, or not freely available). The basic question is which route we should go. * Reduce the number of extra fonts as much as possible to not increase the size of the documentation additionally. [Not much a problem I think since most fonts will be subsetted by ghostscript.] * Be as diverse as possible. Here are my suggestions. Please comment. Some of the fonts used originally *are* free; however, they are either no longer maintained today, or better replacements are available, thus my changes. After we have settled on the necessary fonts they should be properly documented as requirements to build the documentation. * Documentation/snippets/changing-the-default-text-font-family.ly: Times New Roman → Source Serif Pro? Luxi Mono → DejaVu Sans Mono? Iosevka? Source Code Pro? * Documentation/snippets/changing-stanza-fonts: DejaVu Sans → ok * Documentation/snippets/utf-8.ly: [for Japanese] → Source Han Serif Linux Libertine O → Libertinus Serif? Source Serif Pro? Linux Libertine Mono O → Libertinus Mono? (very ugly IMHO) → DejaVu Sans Mono? → Iosevka? → Source Code Pro? * input/regression/font-name.ly: Times New Roman → Source Serif Pro? Luxi Mono→ Source Code Pro? Bitstream Vera Sans → Source Sans Pro? Dejau Sans? * input/regression/metronome-mark-formatter.ly: Times New Roman → Source Serif Pro? * input/regression/markup-compound-meter.ly: The character 'e' in one of the `\compound-meter` functions doesn't exist in 'Emmentaler', thus a platform-dependent fallback gets used (on my box, for example, it is 'Roboto-Regular'). → not sure what to do * input/regression/musicxml/31a-Directions.xml: The characters 'abc' are used in the argument of `make-dynamic-script`; they don't exist in Emmentaler, thus a platform-dependent fallback gets used. → not sure what to do * Documentation/en/notation/text.itely Times New Roman (3×) → Source Serif Pro? Luxi Mono → Source Code Pro? Bitstream Charter → ok Bitstream Vera Sans → DejaVu Sans Werner
PATCHES - Countdown for October 17th
Hello, Here is the current patch countdown list. The next countdown will be on October 19th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !458 Sequential_iterator garbage collection - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/458 !456 Let \shape work on scaled values - Thomas Morley https://gitlab.com/lilypond/lilypond/-/merge_requests/456 !455 Emit logging messages during installation - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/455 Countdown: No patches in Countdown at this time. Review: !460 Remove unused debugging switches - Michael Käppler https://gitlab.com/lilypond/lilypond/-/merge_requests/460 !457 Text replacements are not recursive - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/457 New: !465 Avoid construction of std::string - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/465 !461 Fix typo in filename - Michael Käppler https://gitlab.com/lilypond/lilypond/-/merge_requests/461 Waiting: !451 Define notehead attachment points separately - Owen Lamb https://gitlab.com/lilypond/lilypond/-/merge_requests/451 !449 Stepmake / po-targets: Various cleanups - Michael Käppler https://gitlab.com/lilypond/lilypond/-/merge_requests/449 !447 RFC: Rethink horizontal alignment of mid-staff bar numbers - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/447 !435 Text replacements are not recursive (fixes #6050) - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/435 !344 doc: fully qualify doc includes. - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/344 !204 Move parallel processing to lilypond-book - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/204 *** Regards, James
Re: stable/2.22 has branched; master is 2.23.0
Hi Carl, Am Freitag, den 16.10.2020, 12:46 -0600 schrieb Carl Sorensen: > On Fri, Oct 16, 2020 at 11:41 AM Jonas Hahnfeld > wrote: > > > > So master is 2.23.0 and usual development can resume, with the > > pleading to avoid disruptive changes that make picking harder than > > necessary. Fixes should also go to master and I'll pick them to the > > branch. If you really need to do that, please use 'git cherry-pick > > -x' to record the original hash. > > When do we stop worrying about cherry-picking and feel free to make > disruptive changes again? I'm not asking because I have something in > the queue; I'm just trying to understand the policy. I don't think there's a really good answer to that question right now: As long as stable/2.22 is active and point versions might be released, any change in master will cause some amount of work. What I'm asking for is to reduce the number of (large) changes that complicate picking more than necessary. For example, automated formatting touches lines in a number of files with a somewhat spread diff. In contrast, significant work on a particular part of the code (Dan's changes to volta, Owen's work for SMuFL) is very focused and should happen IMHO. Sure, it won't be easy / possible to pick fixes across these changes, but I don't think it makes sense to block any feature development while stable/2.22 is active. After all, the point of branching was to unblock development. So the short answer is: it depends. And I expect this to become less of a concern over time as the fixes picked to the branch decreases. Jonas signature.asc Description: This is a digitally signed message part
Re: stable/2.22 has branched; master is 2.23.0
Le 16/10/2020 à 20:21, Jonas Hahnfeld a écrit : Am Freitag, den 16.10.2020, 20:01 +0200 schrieb Jean-Charles Malahieude: I should have finished and sent fr.po to the FTP over the week-end. I'll group the fetching once a week in a MR to master. I wonder if the translated po files should go via master or directly to stable/2.22: lilypond.pot will be updated with the next unstable releases (should that be necessary). But I don't mind either way, shouldn't pose big problems... I think po files tagged 2.21.7 should go in both 2.22 and master at the same time and, if later amended because of changes in lilypond.pot, cherry-picked into master. I've tried to keep this grouping for the French version, hoping to have correctly qualified the entries… Your chance to group the English version the same and make it "correct" by definition :-D I'll appreciate anybody first checking I've not not affected a wrong category. Cheers, -- Jean-Charles
Re: Old build environments
Am Freitag, den 16.10.2020, 14:30 -0600 schrieb Carl Sorensen: > On Fri, Oct 16, 2020 at 1:02 PM Michael Käppler wrote: > > Hi all, > > a few days ago I wanted to try how some functionality in LilyPond > > worked, when it was added long > > time ago. (about 15 years ago, around 2.7.x or 2.8.x) > > Not very surprisingly I could not even get the code to compile with my > > current build setup. > > > > That made we wonder if it would be a good idea to store a build > > environment that is proven to work > > with the code base every, say, minor version bump. > > > > I actually think that is the motivation for GUB. You could checkout the > GUB repository for the appropriate date, and the LilyPond code should build > under GUB. It might help, but keep in mind that all "packages" in tools:: must be built by the system compiler. Running Arch Linux, I've had problems with that far too often so you might hit similar issues with versions of GUB from that time. And the version range sounds like the very beginning of GUB... Instead, how about using the oldest available binary release (2.8.8)? Jonas signature.asc Description: This is a digitally signed message part
