Re: Upgrading to current makeinfo

>> [*] Currently, HTML output is handled by an ancient version of >> `texi2html' that doesn't understand `@sortas' at all; I'm going >> to add a dummy macro replacement to fix that. As a >> consequence, the index of the HTML output will stay inferior to >> both the info and PDF v

Re: two LSR questions

my perl script to extract all LSR (approved) doc snippets (which get normalized to proper texinfo code using the `pandoc` program). It also creates a dump file of all snippets in the database (omitting the binary fields). We

Re: Patchy email

> makeinfo.notation.log states: > > out/notation/rhythms.texi:1961: misplaced { > out/notation/rhythms.texi:1961: misplaced } > > The respective line appears to be: > > the note name uppercase @example{R}. Their duration is entered > > @example is not an in-text command but rather an env

Re: AU-1.2 Relocation

> I wonder if "bindir/.." shouldn't be "../bindir" (my parents being up > in the genealogy). Nope, as others have already confirmed :-) Werner

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

> What I am worried about is a partitura that puts common dynamics on > every staff, including staves without notes. Never seen that, AFAIK. Can you provide a link to such a score? Werner

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

>> Never seen that, AFAIK. Can you provide a link to such a score? > > I can certainly imagine that sort of things, in an orchestral score > simple enough that all instruments share the same dynamics (as was > common until the late 18th century), and where the LilyPonder may > want to store all

Re: 2.21.0 and announcements

>> We can release 2.21.0 prior to that, of course, since the web page >> updates are (I think) independent from releases. > > Would you mind letting me run translation-status and merge updated > docs from Franscisco and myself into staging? And doing an LSR import would be nice, too – some updat

Re: Anything missing for 2.21.0?

> Anybody can think of a holdup? No holdup, but I would like to see an LSR import to synchronize documentation with snippets. Werner

Re: Anything missing for 2.21.0?

>> No holdup, but I would like to see an LSR import to synchronize >> documentation with snippets. > > I think that's standard as part of the release procedure? Ah, ok, excellent. Werner

Re: Problem with LSR import

> (btw, the html->texinfo conversion doesn’t appear to turn into > @itemize bullet as it ideally ought to.) If time permits I'll continue work on my LSR import script that I've already posted to the list. It uses `pandoc` for the HTML to texinfo conversion, which seems to work quite well.

Re: 2.21.0 released

> Thank you so much for your dedication! Hear, hear! Congrats to everyone involved with the new release! Werner

Re: Copy alist instead of deep copy on Grob clone (issue 561640045 by hanw...@gmail.com)

> I did some better structured measurements, with interleaved runs on > MSDM: [...] Have you ever tried valgrind's `callgrind` tool for profiling (and using `kcachegrind` for displaying the results)? While very slow it would avoid temperature issues and the like – no need to call it multiple tim

Re: poll: switching our development platform

> To conclude, I believe we should choose one of Gerrit and GitLab and > have a trial to see if the processes can be carried over. I'm fine with both. If in doubt please select the one that is easier to manage, and which provides good support for CI and things like this. Werner

Annoying 'langdefs.py' warning

Building lilypond you get a bunch of harmless but annoying langdefs.py: warning: lilypond-doc gettext domain not found. and .../podir-targets.make:14: warning: ignoring old recipe for target 'po-update' messages. Is there a way to suppress them? Werner

Re: Copy alist instead of deep copy on Grob clone (issue 561640045 by hanw...@gmail.com)

>> Have you ever tried valgrind's `callgrind` tool for profiling (and >> using `kcachegrind` for displaying the results)? While very slow >> it would avoid temperature issues and the like – no need to call it >> multiple times to get reliable values. > > What magic does callgrind do to prevent in

Re: poll: switching our development platform

> What would fit our use case in GitLab + CI pretty nicely are Merge > Trains [1]. Interesting, and very nice! This looks like a very useful feature indeed. > Basically this has the potential to replace our current setup of > patchy-staging: Once a patch counted down, we press "Start merge >

Re: Extracting approximate outlines from FT ?

Hello Han-Wen, > I've been looking into performance, and one big source of slowness > is calculating skylines. I found that we calculate exact skylines > based on glyph shapes for some symbols. > > For example, for the F clef, we compute an outline of 23 and 20 > segments, based on sampling the

Re: Annoying 'langdefs.py' warning

>> [...] Is there a way to suppress them? > > I’ve been annoyed by these for quite some time as well. Is it worth > opening a tracker page? For me, it's not *that* annoying :-) Werner

Re: Annoying 'langdefs.py' warning

>> Is there a way to suppress them? > > Well, submitting fixes? I looked into both issues some time ago, but couldn't find out a good solution. Thanks to your clean-ups I can imagine that it's now easier to handle both problems. > IIRC langdefs.py complains that we set LANG=C in the build > p

Re: GS version conflict in packaged 2.20 and 2.21

> [...] As Jonas Hahnfeld pointed out, the problem was calling (within > the installation directory) the unwrapped binary > ./lilypond/usr/bin/lilypond (which then relied on the system default > GS) instead of the wrapper script ./bin/lilypond (which sets > environment variables such as to use t

Re: Patchy email

>>> Does anybody have an idea _what_ and _why_ would leave a .uuid >>> file lying around in the temporary file with, well, an uuid kind >>> of number in it? Is that an artifact of my freetype library or >>> something? Definitely not FreeType, but... >> Seems to be something that fontconfig doe

Re: Annoying 'langdefs.py' warning

> It loads its languages from langdefs.py, and therefore outputs the > following unhelpful warning: > > langdefs.py: warning: lilypond-doc gettext domain not found. > > I understand 'therefore' as 'expectedly' here. Well, yes, but it's still annoying. Since I don't see any reason to have thi

Re: [trial] getting started

> here we go: https://gitlab.com/lilypond-issues/lilypond-trial Very nice, thanks! Werner

Re: Extracting approximate outlines from FT ?

> is there a standard wrt to outline direction? There are two: TrueType and PostScript, which are exactly the opposite. However, all glyphs in a font have the same orientation, so this should be easy to handle. > If I can assume that external outlines go in clockwise order, I > could skip left

Re: Extracting approximate outlines from FT ?

> In https://docs.microsoft.com/en-us/typography/opentype/spec/ttch01 > it is explained that outside curves go clockwise. Does that hold for > other font types too? (PFA, OTF?) PostScript flavoured glyphs like PFA or OTF[*] have the opposite orientation. You can easily check whether the used Fr

Re: Extracting approximate outlines from FT ?

>> PostScript flavoured glyphs like PFA or OTF[*] have the opposite >> orientation. You can easily check whether the used FreeType driver >> for a font is 'truetype': >> >> FT_Face face = Get_FT_Face_For_Current_Font(...); >> FT_Module module; >> >> module = &face->driver->root; >> if (!st

Re: Extracting approximate outlines from FT ?

>> The 'inner' outline of an 'O' glyph has exactly the opposite >> direction of the outer outline. In other words, for getting the >> outermost outline(s) of a glyph you can always skip such 'inner' >> ones. > > I'm confused. Our code currently does > > FT_Load_Glyph (face, idx, FT_LOAD_NO_SC

Re: Extracting approximate outlines from FT ?

>> Unfortunately, the OpenType standard doesn't store the orientation >> of outlines in the `glyf` or `CFF` (or `CFF2`) table. In other >> words, this has to be computed, which further means that you have >> to use `FT_Outline_Get_Orientation` so that you can differentiate >> between inner and o

Re: [trial] current status

> for those not following very closely, a few updates for GitLab: > [...] Thanks again for your continuous work on this! Werner

GSoC for LilyPond

Hello Owen, welcome to LilyPond :-) We are glad that you are with us the next few months (and maybe even longer), and thank you in advance for the work on your project. Our main communication is e-mail, which has served us well since the very beginning. Except for really private messages I as

Re: Extracting approximate outlines from FT ?

>> Mhmm, you could copy the data stored `face->glyph->outline' into a >> new `FT_Outline` structure and iterate over the outlines, [...] > > I wrote something that seems to be working, but I would like to > cache the contours. For Open_type_font, this is easy, but for > Pango_font, each string ca

Re: output-distance snafu

> I sped up output-distance, but broke quality of the graphics > rendering. This is fixed in > https://codereview.appspot.com/560020043/diff/561820043/scripts/build/output-distance.py. > > This problem makes the regtests hard to use, so I want to skip > countdown for this change. +1 Wern

Re: migrating to GitLab

> In any case it's not clear to me whether I should prepare for the > migration today or not. This would be less frustrating if other > high- volume developers (including but not limited to David, > Han-Wen, Werner) commented on the plan... I like it, so please proceed! And thanks for working a

Re: repository at GitLab

> Everything went pretty much as expected, so here's the repo: > https://gitlab.com/lilypond/lilypond Congrats, and thank you very much for your hard work! > I granted everybody access to the group https://gitlab.com/lilypond who > sent requests so far. Please give me access too; my

Re: repository at GitLab

>> Please give me access too; my username on GitLab is 'lemzwerg'. > > Done. Thanks! Werner

Re: Another round of questions

> So, I'm wondering: would it be worth the effort if I did a cleanup > in musicxml2ly's code or is it intended to replace it with Grame's > converter anyway? IMHO only bugfixes should be applied to `musicxml2ly` since `xml2ly` covers much more of MusixXML (and will, AFAIK, also eventually suppor

Re: PATCHES - Countdown for May 17th

>> I think for now it's pushing to staging. Either from the command >> line, or because you have set staging as your destination branch in >> the GUI, in which case you can use a button (usually starting by >> rebase). > > If using the command line, just make sure to push the rebased commit > to

Re: LilyPond GSoC logistics

Hello Owen, > First, would it be possible to shift the schedule a week earlier? > ASU classes start on August 20th, and it would not be ideal for me > to still be working then. I can take the rest of this week to > familiarize myself with the codebase (I've already started doing > that), and th

Re: LilyPond GSoC logistics

> I'll be making a new branch titled "dev/lamb/GSoC-2020" in the > GitLab repository, based off the current master. It will be > "private" in the sense that it's my personal workspace (hence the > "lamb" namespace), but it will be "public" in the sense that it will > be visible to the public. It

Re: Access to push new branch to origin

> I can grant you access to the repository later today if needed. > However I'd first like to understand (probably from Werner) what > makes a branch in the upstream repository more "preserving" than a > public clone. Being distributed it really doesn't make much > difference from the git perspe

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

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 whe

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 whet

Re: GSoC 2020: SMuFL glyph name to index lookup

>> 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. > > it's not just a historical decision

Re: GSoC 2020 update, May 30

> I started work on Han-Wen's suggested order of operations. In order > to make the .mf files output a SMuFL code to their log, I needed to > learn Metafont, which proved to be a language as little documented > as it is ingenious. [...] In case you have TeXLive installed, simply type texdoc

Re: Metafont optional parameters

> I'd like to add an optional parameter for smuflcode to > fet_beginchar, so that I don't have to take two lines redeclaring > the variable in every glyph. Ideally, it won't have to be optional > once every character has it, but in the meantime, it would help with > testing individual characters

Re: GSoC 2020 update, May 30

>> In case you have TeXLive installed, simply type >> >>texdoc metapost > > :D > > I get the doc ... but its all in Cyrillic. Pfft. Towarischtsch, you probably have to adjust your locale settings :-) Try texdoc mpman instead. Werner

Re: Metafont optional parameters

> Han-Wen, I decided to go for your first solution, which is now > committed. ... but not pushed yet, it seems. > Werner, in case you were wondering what I had previously: [...] I saw that, thanks. Werner

Re: GSoC 2020 update, May 30

> [...] I wonder whether using a number type to store the codes is > worth the hassle of conditionally changing the number system. No, it's not. I just wanted to point out that big numbers *are* supported if it is really necessary to do so. > Would it be all right if I continued using strings

Re: Remove lily-git?

> I think it can go. Git is now a standard tool. We don't need to > provide custom UIs for it. +1 Werner

Re: GSoC 2020 update, June 5

Hello Owen, > This week, I was able to encode the whole note (semibreve) glyph in > its proper SMuFL-encoded spot in the PUA based on .mf log output. > > I also got LilyPond to use a generated Scheme hash table to try to > look up a glyph's SMuFL character code before falling back to the > old

Re: Texinfo - manual line breaks in URLs?

>> Is there a reason for this inconsistency? How is it supposed to be? > From what I gather, that’s merely because Werner’s been looking > elsewhere for the past 16 years :-) > https://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=cae1b39741a43547e3f4add29416f24d681e1156 :-) > Now, I’m not c

Re: Texinfo - manual line breaks in URLs?

> I can prepare a version of the docs with all occurences of '@/' > removed and '@urefbreakstyle before' set, so that everyone can > compare and build an opinion on this. Great, thanks in advance. I suggest that you use the `texinfo.tex` file directly from the 'texinfo' git repository so that w

Re: GSoC 2020: OpenType support in FreeType

Hello Owen, > I've given Emmentaler an OpenType lookup subtable for stylistic > alternates, as the SMuFL specification suggests, and, as an > experiment, I have successfully encoded the two types of double > whole note (breve), one as a stylistic alternate of the other. > However, LilyPond's cur

Re: GSoC 2020: OpenType support in FreeType

>> It should be straightforward to set up a fully functional OpenType >> table for stylistic alternatives, as you've started already – the >> 'salt' feature in a 'GSUB' table, I guess. LilyPond then extracts >> and parses this table directly (similar to 'LILY'). This should be >> rather easy to

Re: GSoC 2020: OpenType support in FreeType

>> Unfortunately, the documentation of HarfBuzz is very terse. I've >> just checked >> >>https://harfbuzz.github.io >> >> and couldn't find out how to easily get a list of glyphs with its >> stylistic alternates. Fortunately, the people on the HarfBuzz >> mailing list are willing to he

Re: GSoC 2020 update, June 15

>> Rather late in the week, I also came to the realization that, in >> order to support *any* SMuFL font's optional features, I'll also >> have to read its metadata JSON file if it has one, before >> defaulting to its OpenType features if it doesn't. (Thanks, >> Werner, for guiding me through that

Re: xdvipdfmx fails with some regtests (“Invalid object”)

> xdvipdfmx:fatal: typecheck: Invalid object type: -1 7 (line 2161) > > This is on a Fedora system with xdvipdfmx 20190225 and gs 9.52. It seems that you probably have to update your TeX system... https://tex.stackexchange.com/questions/490616/xdvipdfmx-typecheck-problem If this is not a fe

Re: xdvipdfmx fails with some regtests (“Invalid object”)

>> It seems that you probably have to update your TeX system... > > Update or downgrade? I suggest upgrading. The current maintainer of xdvipdfmx fixes bugs in TeXLive directly – however, this doesn't automatically update the binaries that are in TeXLive's SVN repository. It's not that complic

Re: xdvipdfmx fails with some regtests (“Invalid object”)

> Git bisect actually tells me that xdvipdfmx started misbehaving from > the same commit that caused gs issues: > > 017927b4d63c317e1fc450be2537ccc058072538 (HEAD) > Author: Han-Wen Nienhuys > Date: Fri Jun 5 20:36:42 2020 +0200 > Unify calling convention for command-line and API G

Re: xdvipdfmx fails with some regtests (“Invalid object”)

> Where can I find the source code for xdvipdfmx? Here: https://www.tug.org/svn/texlive/trunk/Build/source/texk/dvipdfm-x/ This is the code for a binary that gets stored under five different names (either as links or as exact copies): xdvipdfmx dvipdfm dvipdfmx ebb extractbb The bi

Re: Texinfo - manual line breaks in URLs?

>> Bisecting yielded that the first texinfo commit that introduced the >> error is >> http://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=aa18f519e091b6ada0fb2b0a65a51880031d5014 > > Uh oh. This looks like it introduces (modifies?) a command named > @seealso but it would appear that we defi

Re: Texinfo - manual line breaks in URLs?

>> David, would you do that and fast-track this mechanical change? > > We don't use camelcase elsewhere in Texinfo. Sounds good, thanks. Werner

Re: Texinfo - manual line breaks in URLs?

>> David, would you do that and fast-track this mechanical change? > > No idea what makes me the go-to here, but anyway. You replied :-) > Thanks! Werner

Re: Texinfo - manual line breaks in URLs?

> What seems most likely to me is that the indices are generated > correctly, but texi2pdf refuses to generate the sorted versions. > > If I call texi2pdf --debug I do not see any invocations of > 'texindex'. May it be that texi2pdf does not call texindex but use > an inlined sorting mechanism th

Re: Texinfo - manual line breaks in URLs?

> The patch did not solve the problem. OK. It was a shot into the dark. > A glance into the texi2dvi code showed that rather this tool causes > the problem. See > http://git.savannah.gnu.org/cgit/texinfo.git/diff/util/texi2dvi?id=2405caa6c7ab01d99af56aa056b1e77485ba Thanks for investigat

Re: GSoC 2020 update, June 19

Hello Owen, thanks a lot for your detailed summary. > This week, I corresponded with Daniel Spreadbury on the W3C Music > Notation Community Group public email list and Behdad Esfahbod on > the HarfBuzz mailing list, and received some clarifications on how > to continue. It looks like we won'

Re: Texinfo - manual line breaks in URLs?

> I do not fully understand what you mean by "this is the right way > for the next development version", The one that has ben just released – 2.21.2. > however - if you think it is feasible to upgrade to the most recent > texinfo.tex version, with the seealso->moreref changes and possibly > furt

Huge PDF doc files

Folks, compiling the documentation of current git I get huge PDFs. For example, the NR is now 44.7MByte – previously (in my case two months ago), it was 7MByte. Then I used gs 9.21, now I use version 9.52; I guess this is the culprit since I don't think that any other program in my environment

Re: Huge PDF doc files

>> compiling the documentation of current git I get huge PDFs. For >> example, the NR is now 44.7MByte – previously (in my case two months >> ago), it was 7MByte. > > I can see the 44M number here, but I have extractpdfmark > disabled. Can you confiirm it is being run? It is, definitely. The ve

Re: Texinfo - manual line breaks in URLs?

>> The index changes look fishy, too: Everything typeset in typewriter is >> indented incorrectly by a space. > Regarding this one: My new best friend git-bisect says that > http://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=0539d4e685a2185dd46d676d0b3f8862493bf8bd > introduced the misaligne

Re: GSoC 2020: Character lookup functions

> The options, as far as I can tell, are these: > >1. We could stick with the old-style glyphnames > (e.g. "noteheads.s0"). This would require minimal change to > most of the code, since smufl_map.json already takes care of > everything by mapping old-style names to charcode

Re: failing CI builds

>> When comparing the build artifacts, I noticed that the output files >> in mf/ are not reproducible. I'm not sure if that is related, > > Unlikely. For unknown reasons metapost is dumping the current time > in its log output [...] AFAIK, Metafont and Metapost (among many other TeXLive binaries

Re: failing CI builds

>> AFAIK, Metafont and Metapost (among many other TeXLive binaries) >> support the `SOURCE_DATE_EPOCH` environment variable to allow >> reproducible builds. I suggest that we set this variable. > > I tried setting it in mf/GNUmakefile, but it didn't work. OK, will ask on the TeXLive mailing li

Re: failing CI builds

>> I tried setting it in mf/GNUmakefile, but it didn't work. > > OK, will ask on the TeXLive mailing list. I got the following answer: METAFONT supports SOURCE_DATE_EPOCH variable. Try export SOURCE_DATE_EPOCH=1 export FORCE_SOURCE_DATE=1 I think MetaPost does not support th

Re: failing CI builds

>> I got the following answer: >> >> METAFONT supports SOURCE_DATE_EPOCH variable. Try >> >> export SOURCE_DATE_EPOCH=1 >> export FORCE_SOURCE_DATE=1 >> >> I think MetaPost does not support the variables. > > I already tried this yesterday and it worked well for getting the >

Re: failing CI builds

>> Well, while Metafont has SOURCE_DATE_EPOCH support, Metapost hasn't >> (yet – this will change in a few days so that the next TeXLive >> version will contain it). >> >> Recent versions of FontForge should have support too, BTW. > > This still doesn't answer why I'm seeing differences in the >

Re: Texinfo - manual line breaks in URLs?

> with the last fixes in texinfo.tex, the output looks much better > now, the @verbatim indentation is fixed, Yes. > the URL spacing is sometimes better, sometimes worse than with the > old texinfo.tex version, IMHO. This I still have to investigate. Will do that in the next few days. > The

Re: [lilypond-book] @format environments

> @format > @exampleindent 0 > @verbatim > \relative { > a4 b c d > } > @end verbatim > @end format > > [...] > > What I do not understand here: The @verbatim environment is not > indented by default, as far as I can see. What is the reason to set > '@exampleindent 0', here? > > (And the enclo

Re: GSoC 2020 update, July 2

> First, I updated the .mf files' fet_beginchar functions to take a > SMuFL name (or a SMuFL name and a SMuFL-style alternate name) > instead of a codepoint, and made sure the python scripts knew how to > deal with it. > > I then split smufl-map.scm into two files: name-conversion.scm, > which m

Re: Accidentals' font

Paolo, I feel obliged to write this e-mail so that we have a healthy and friendly environment to discuss everything related to LilyPond, free of friction as much as possible. I remember previous e-mail exchanges with you and the list where similar issues surfaced. > I don't understand why this

Re: [lilypond-book] @format environments

> please see the attached files for a test case, [...] Thanks, looks good. > What I did not test, however, was texi2html-1.82. Well, it will take some time until we can move on to a newer version, so this has to be tested, too. > So I would vote to make > > @noindent > [Version string if nee

NR pdf is larger with current git by 15%

Masamichi-san, your fix for gs works fine; the resulting PDFs are small again. Thanks a lot! BUT: They are not as small as previously. For example, with commit 21a20de3, the NR has 10 pages more and is now 8.3MByte (I've tested compilation with both gs 9.21 and 9.52) instead of 7.1MByte (with

Re: NR pdf is larger with current git by 15%

>> Is this expected, probably a side effect of your latest changes? I >> uncompressed the PDFs using `pdftk` and did a comparison; >> unfortunately I couldn't see big differences in the diff file, >> which probably hints at small but many changes that accumulate to >> the 15% difference. > > If

Re: NR pdf is larger with current git by 15%

>> > Ghostscript seems to need `-sDEVICE=pdfwrite` to produce the PDF >> > we expect. OK. >> > Is the device specifying way on the new method (without >> > `-sDEVICE=pdfwrite`) documented by Ghostscript documents? If >> > not, it is not a bug in my humble opinion. >> >> I've found the documente

Re: GSoC 2020 update, July 11

Hello Owen, nice to read about your progress! > Around the middle of the week, I tried to figure out how to get the > Emmentaler fonts into an OpenType collection, but FontForge only has > docs for "TrueType Collections". Apparently, FontForge can make > OpenType Collections by setting a "cff

Re: [lilypond-book] @format environments

> So we could either > > 1. Drop the support for 'addversion' in lilypond-book completely I favor that. Werner

Re: Texinfo - manual line breaks in URLs?

>> the URL spacing is sometimes better, sometimes worse than with the >> old texinfo.tex version, IMHO. > > This I still have to investigate. Will do that in the next few days. > >> The issue with the additional space in front of manually sorted >> index entries is fixed for most entries, > > In

Re: 2.21.3 build problem on Mac OS X Mojave

> I’m trying to build LilyPond 2.21.3 locally, both on Debian 9 and > Mac OS X 10.14.6 (Mojave). On the latter, I installed Apple’s > XCode, the needed tools in /opt with MacPorts, and the needed fonts > in /opt/local/share/fonts/urw-core35-fonts. You might apply https://github.com/macports/m

Re: 2.21.3 build problem on Mac OS X Mojave

> In fact I did the ‘git clone’ afresh, moving aside previous > attempts. Thus the contents of ‘build’ on both OSes is the result of > the commands I showed, up to '../configure'. > > That’s why I don’t get what happens… For me, using an up-to-date MacPorts system, compilation of LilyPond from

Re: GSoC 2020 update, July 18

Owen, you progress looks really good. Congrats! Some general comments to the code style: Please avoid overlong lines (i.e., lines longer than 80 characters if possible). Especially if working with git repository viewers like `gitk` or inspecting merge requests on the gitlab web page this is

Re: GSoC 2020: Shape-note notehead encoding

> LilyPond's catalog of shape-note noteheads is unique because it > contains three full sets of noteheads--Aikin (default), Funk, and > Walker. [...] > > My current plan is to define the Aikin noteheads as described in the > SMuFL specs, while the other two sets will be stylistic alternates > wi

Re: GSoC 2020 update, July 18

> in ancient (ars subtilior) notation there actually are noteheads > with two stems (which may also be flagged differently), called > "dragma". a picture search for "dragma ars subtilior" returned poor > images; one not entirely useless is > https://www.last.fm/music/Philippus+de+Caserta/+images/f

Re: GSoC 2020: Shape-note notehead encoding

> Heartland Hymns, 2005 (PDF attached. Yes, Fraktur in 2005. The > German-speaking Mennonite communities were in the USA since 1710 or > so and didn't get the memo that Antiqua has won. The remaining > German speakers are stuck HARD on Fraktur.) > And they d

Re: GSoC-2020 update: Jul 31

> In the meantime, I've gotten Bravura glyphs to appear on the page! Congrats! A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do you change from the (IMHO preferable) `-` to `_` in the file name? I consider `_` an abomination that is only necessary because `-` is not a vali

Re: GSoC-2020 update: Jul 31

>> Another issue: Maybe it makes sense if you try to rebase your >> branch from time to time. > > Really rebase? Yes, I favour rebasing over merging since the former causes a `prettier' git commit tree. > This would be a case where "general wisdom" argues against modifying > pushed commits. Typ

Re: GSoC-2020 update: Jul 31

Well, there's a good reason that gitlab has a big, fat 'rebase' button... >> >> Not sure about the meaning of your message: this button shows up >> because we enabled it as a project-wide setting. To my knowledge, >> the default and most common strategy is merging. Exactly! It's our po

info files no longer built with `make all`

After the big #84 change (i.e., commit 82d72b747) I now see that `.info` files are no longer built if I say `make all` – note I'm talking about `.info` files without images. Is this intentional? If yes, please revert this decision. Otherwise, please fix it! Werner

`make all` too verbose after merge #84

If I now execute `make doc -j4`, I get zillions lines Page 53 Page 1 Page 2 Page 235 ... emitted by gs, and which are completely useless and clutter the terminal output. I let the above command run overnight so that I can check it in the morning; however, inspite of having a really l

Re: `make all` too verbose after merge #84

> On 05/08/2020 04:37, Werner LEMBERG wrote: >> If I now execute `make doc -j4`, I get zillions lines >> >>Page 53 >>Page 1 >>Page 2 >>Page 235 >>... >> >> emitted by gs, and which are completely useless and clu

<    1   2   3   4   5   6   7   8   9   10   >