Re: strut problem
>> It would be necessary to add another property to stencils, say, an
>> 'active' flag, so that they can be intentionally taken out of a
>> skyline.
>
> YAGNI. Just use ly:stencil-outline.
OK.
> Are you mindful that ly:make-stencil is a low-level function? If you
> use it, you need to have an understanding of how stencils work at
> the low level.
>
> I don’t see what we would gain by changing those internals.
No problem. I'm only thinking aloud :-)
>> What I want is to have the `\strut` command work in general. If
>> this is not possible – for the reason you've outlined – it should
>> be deprecated, together with some documentation that explains why
>> struts don't work (or are the wrong concept) in LilyPond.
>
> As said above, LilyPond considers the outline of stencils in
> addition to their extents (unlike LaTeX, AFAIK), and the skylines of
> text with \strut will depend on where \strut is put.
>
> So I lean towards the second option.
Me, too.
https://gitlab.com/lilypond/lilypond/-/issues/6473
>>> For example, you could have a markup command that takes a string
>>> and typesets it while giving it the extents + outline of a box
>>> around it encompassing the height of potential ascenders and
>>> descenders.
>>
>> Maybe a more generic solution?
>>
>> ```
>> \with-added-skyline markup1 markup2 [offset [extent]]
>> \with-replaced-skyline markup1 markup2 [offset [extent]]
>> ```
>
> \with-replaced-skyline sounds a lot like
>
> \with-outline
> \translate #'(offset . 0) markup2 markup1
>
> \with-added-skyline sounds like
>
> \with-outline
> \overlay { markup1 \translate #'(offset . 0) markup2 } markup1
Excellent, thanks.
> Supporting the 'extent' parameter would take some modifications to
> the C++ code. Do you have a specific use case for it?
No. I was just envisioning the most general case.
Werner
Re: two pipelines for a single merge
>> Looking into >> >> https://gitlab.com/lilypond/lilypond/-/pipelines >> >> I see that for every merge I do, two pipelines are executed. >> Apparently, this doesn't happen for Jean. What am I doing wrong? > > Nothing. There is one pipeline on the merge request to test it, > then one pipeline on master to create the test baseline for future > MRs (and optionally rebuild the website, if manually triggered). OK, thanks. Werner
Prefer luatex for documentation
In https://gitlab.com/lilypond/lilypond/-/merge_requests/1714 I suggest that we prefer luatex for building the documentation. What do people think? The main advantage of using luatex is complete microtype support; this was activated recently in `texinfo.tex`, and XeTeX doesn't support it in its entirety, lacking font expansion. The microtype feature yields (a) less underfull lines (i.e., less lines with overly large inter-word spaces), (b) less hyphenation, and (c) a better 'grayness' of the pages, thus increasing legibility. While (c) is not a big issue with technical documentation, (a) has quite an impact IMHO, and (b) is valuable since it is always a good thing to avoid hyphenation with keywords and the like because there might be misunderstandings whether the hyphen is part of the keyword or due to the line break. Note also that documentation formatted with luatex has slightly less pages, but this is rather insignificant. Attached you can find an example that demonstrates (a), taken from the MR. You can read more about microtype principles in the documentation of the LaTeX 'microtype' package, of which `texinfo.tex` supports a small subset of the most important features. https://ctan.math.illinois.edu/macros/latex/contrib/microtype/microtype.pdf Werner
Re: Prefer luatex for documentation
On Nov 19, 2022, at 05:19, Werner LEMBERG wrote: > > Attached you can find an example that demonstrates (a), taken from the > MR. The sample LGTM. Beyond that, I prefer not to involve myself in the discussion. — Dan
Making test-baseline fails
Hello,
I'm trying to make a new test-baseline for the automated regression tests.
This time I'm not able to do it. I made first make clean and then make
test-baseline checking out the current git master all while being inside of
the build directory. After a while I get:
testing /home/martin-ribot/dev/lilypond/scripts/build/output-distance.py
...
ERROR: In procedure apply-smob/1:
In procedure primitive-load-path: Unable to find file "lily/lily" in load
path
test results in ./out/test-output-distance
/usr/lib/python3/dist-packages/apport/report.py:13: DeprecationWarning: the
imp module is deprecated in favour of importlib and slated for removal in
Python 3.12; see the module's documentation for alternative uses
import fnmatch, glob, traceback, errno, sys, atexit, locale, imp, stat
Traceback (most recent call last):
File "/home/martin-ribot/dev/lilypond/scripts/build/output-distance.py",
line 1366, in
main()
File "/home/martin-ribot/dev/lilypond/scripts/build/output-distance.py",
line 1354, in main
run_tests()
File "/home/martin-ribot/dev/lilypond/scripts/build/output-distance.py",
line 1300, in run_tests
test_basic_compare()
File "/home/martin-ribot/dev/lilypond/scripts/build/output-distance.py",
line 1287, in test_basic_compare
system(' '.join(args))
File "/home/martin-ribot/dev/lilypond/scripts/build/output-distance.py",
line 67, in system
subprocess.run(["/bin/bash", "-c", c.encode('utf-8')], check=True,
cwd=cwd)
File "/usr/lib/python3.10/subprocess.py", line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/bin/bash', '-c',
b'/home/martin-ribot/dev/lilypond/build/out/bin/lilypond
-dseparate-page-formats=ps -daux-files -dtall-page-formats=ps --formats=ps
-dseparate-log-files -dinclude-eps-fonts -dgs-load-fonts --header=texidoc
-dcheck-internal-types -danti-alias-factor=1 20 19 20grob 20multipage
19multipage added removed added-multipage.ly']' returned non-zero exit
status 1.
make[2]: ***
[/home/martin-ribot/dev/lilypond/build/.././scripts/build/GNUmakefile:10:
local-test] Error 1
make[1]: *** [/home/martin-ribot/dev/lilypond/build/../GNUmakefile.in:281:
test] Error 2
make: *** [/home/martin-ribot/dev/lilypond/build/../GNUmakefile.in:306:
test-baseline-pre] Error 2
--
www.martinrinconbotero.com
Re: Making test-baseline fails
Le 19/11/2022 à 18:31, Martín Rincón Botero a écrit : Hello, I'm trying to make a new test-baseline for the automated regression tests. This time I'm not able to do it. I made first make clean and then make test-baseline checking out the current git master all while being inside of the build directory. After a while I get: Maybe you forgot to run basic "make" before this? Otherwise, did you try deleting the build directory and starting with a pristine one? OpenPGP_signature Description: OpenPGP digital signature
Re: Making test-baseline fails
Thank you for your quick answer. Running make again was indeed all it took for it to start working again. Am Sa., 19. Nov. 2022 um 18:37 Uhr schrieb Jean Abou Samra < j...@abou-samra.fr>: > Le 19/11/2022 à 18:31, Martín Rincón Botero a écrit : > > Hello, > > > > I'm trying to make a new test-baseline for the automated regression > tests. > > This time I'm not able to do it. I made first make clean and then make > > test-baseline checking out the current git master all while being inside > of > > the build directory. After a while I get: > > > > > Maybe you forgot to run basic "make" before this? > > Otherwise, did you try deleting the build directory and starting > with a pristine one? > > > > -- www.martinrinconbotero.com
Re: Prefer luatex for documentation
On Sat, 2022-11-19 at 10:19 +, Werner LEMBERG wrote: > In https://gitlab.com/lilypond/lilypond/-/merge_requests/1714 I > suggest that we prefer luatex for building the documentation. What > do people think? What I'm missing here is the bigger picture: Are we going to continue adding support and switching between TeX engines one after the other? If we prefer LuaTeX, should we stop looking for XeTeX? (As mentioned in the merge request, we want pdfTeX because it's fast and included by default in Ubuntu's texlive-bin / the Docker images). > The main advantage of using luatex is complete microtype support; > this was activated recently in `texinfo.tex`, and XeTeX doesn't > support it in its entirety, lacking font expansion. But pdfTeX does support font expansion, right? Reading through the 'microtype' package documentation, it reads as if all of this comes from pdfTeX... > The microtype feature yields (a) less underfull lines (i.e., less > lines with overly large inter-word spaces), (b) less hyphenation, and > (c) a better 'grayness' of the pages, thus increasing legibility. > While (c) is not a big issue with technical documentation, (a) has > quite an impact IMHO, and (b) is valuable since it is always a good > thing to avoid hyphenation with keywords and the like because there > might be misunderstandings whether the hyphen is part of the keyword > or due to the line break. Do you have an example for this? As I wrote on the merge request, I've been looking through the PDFs you provided, and it's really hard to find places where this actually makes a difference... So in general I have the feeling that this doesn't bring us much, but just keeps adding more checks to our configure and more choices / configurations to test on a somewhat regular basis. I'm not really in favor. Jonas signature.asc Description: This is a digitally signed message part
Re: BDWGC fix in 2.24?
On Fri, 2022-11-18 at 11:06 +0100, Jean Abou Samra wrote: > Hi, > > As illustrated by a recent message on lilypond-user, the > GC issue on Windows is still there for very large scores > in 2.23.81. I suppose this is referring to https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00272.html ? It's always helpful to link to explicit messages, lilypond-user sees far too much traffic for me to keep fully up with it and topics are sometimes discussed in (somewhat) unrelated threads due to when they come up... > In https://github.com/ivmai/bdwgc/issues/454#issuecomment-1313127991 > the BDWGC maintainer said the release of his fix would > probably happen in January, which is later than what we > hope for our 2.24 release. > > What should we do? Do we accept releasing 2.24 from > the release-8_2 branch in BDWGC even though it is not > released? Do we keep the current workaround, which still > gives some crashes? Do we replace our workaround > with Ivan Maidanski's patch, which seems to apply cleanly > on the v.8.2.2 tag? I personally think this should not block the release, simply because big scores have been a pain point on Windows before due to 32-bit limitations [1]. It would of course be nice to fix it (and _maybe_ we can patch in only the minimal parts of the patch), but otherwise I think it is fine to release with a "known issue" as suggested by Karlin (though that issue and the accompanying note in the release announcement need to be very user-friendly). Jonas 1: I'm actually surprised that 2.22.1 can go to 625 scores in the message I linked above, for 2.23.14 already 400-ish scores use more memory than a 32-bit process could have used. I'll need to check that... signature.asc Description: This is a digitally signed message part
Re: BDWGC fix in 2.24?
Le 19/11/2022 à 22:29, Jonas Hahnfeld a écrit : I suppose this is referring to https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00272.html ? It's always helpful to link to explicit messages, lilypond-user sees far too much traffic for me to keep fully up with it and topics are sometimes discussed in (somewhat) unrelated threads due to when they come up... Yes, sorry, it's this one. I personally think this should not block the release, simply because big scores have been a pain point on Windows before due to 32-bit limitations [1]. It would of course be nice to fix it (and _maybe_ we can patch in only the minimal parts of the patch), but otherwise I think it is fine to release with a "known issue" as suggested by Karlin (though that issue and the accompanying note in the release announcement need to be very user-friendly). Both options are fine with me. Thanks, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Prefer luatex for documentation
Luatex is always available with modern tex distros (say at least 5 yrs probably more). In fact pdftex _is_ luatex... I feel texlive is a stable enough bet for people... L On Sat, 19 Nov 2022, 22:15 Jonas Hahnfeld via Discussions on LilyPond development, wrote: > On Sat, 2022-11-19 at 10:19 +, Werner LEMBERG wrote: > > In https://gitlab.com/lilypond/lilypond/-/merge_requests/1714 I > > suggest that we prefer luatex for building the documentation. What > > do people think? > > What I'm missing here is the bigger picture: Are we going to continue > adding support and switching between TeX engines one after the other? > If we prefer LuaTeX, should we stop looking for XeTeX? (As mentioned in > the merge request, we want pdfTeX because it's fast and included by > default in Ubuntu's texlive-bin / the Docker images). > > > The main advantage of using luatex is complete microtype support; > > this was activated recently in `texinfo.tex`, and XeTeX doesn't > > support it in its entirety, lacking font expansion. > > But pdfTeX does support font expansion, right? Reading through the > 'microtype' package documentation, it reads as if all of this comes > from pdfTeX... > > > The microtype feature yields (a) less underfull lines (i.e., less > > lines with overly large inter-word spaces), (b) less hyphenation, and > > (c) a better 'grayness' of the pages, thus increasing legibility. > > While (c) is not a big issue with technical documentation, (a) has > > quite an impact IMHO, and (b) is valuable since it is always a good > > thing to avoid hyphenation with keywords and the like because there > > might be misunderstandings whether the hyphen is part of the keyword > > or due to the line break. > > Do you have an example for this? As I wrote on the merge request, I've > been looking through the PDFs you provided, and it's really hard to > find places where this actually makes a difference... > > So in general I have the feeling that this doesn't bring us much, but > just keeps adding more checks to our configure and more choices / > configurations to test on a somewhat regular basis. I'm not really in > favor. > > Jonas > >
Re: Prefer luatex for documentation
>> In https://gitlab.com/lilypond/lilypond/-/merge_requests/1714 I >> suggest that we prefer luatex for building the documentation. What >> do people think? > > What I'm missing here is the bigger picture: Are we going to > continue adding support and switching between TeX engines one after > the other? Luatex would be the final engine to support. It's the most sophisticated one and under active development, contrary to both pdftex and xetex, which are both in maintenance mode. > If we prefer LuaTeX, should we stop looking for XeTeX? (As mentioned > in the merge request, we want pdfTeX because it's fast and included > by default in Ubuntu's texlive-bin / the Docker images). I replied that from a philosophical point of view I would like to continue with support for all three engines. However, on a practical level, the PDF outlines are bad with pdftex if there are non-ASCII characters. This is not a limitation of pdftex but a limitation of `texinfo.tex`, which doesn't provide support for that, unfortunately (someone™ could contribute this, since the maintainer don't want to add it by himself). For me it's fully ok if pdftex gets used for testing. However, for the generation of the PDF documentation that gets provided to the user, luatex (or xetex) is preferable. >> The main advantage of using luatex is complete microtype support; >> this was activated recently in `texinfo.tex`, and XeTeX doesn't >> support it in its entirety, lacking font expansion. > > But pdfTeX does support font expansion, right? Yes. > Reading through the 'microtype' package documentation, it reads as > if all of this comes from pdfTeX... Yes, font expansion (the so-called 'hz algorithm' originally suggested by the famous typographer Hermann Zapf) started with pdftex. It was actually the PhD thesis subject of the original pdftex author, Han The Tanh. Luatex supports that, too. >> [...] it is always a good thing to avoid hyphenation with keywords >> and the like because there might be misunderstandings whether the >> hyphen is part of the keyword or due to the line break. > > Do you have an example for this? As I wrote on the merge request, > I've been looking through the PDFs you provided, and it's really > hard to find places where this actually makes a difference... Well, everything typeset with `@code` is only hyphenated after a real hyphen; right now, keywords not written with typewriter can only be found in links, most likely in links to the IR. Attached is an example of a 'See also' section from NR section 1.4.2 – as can be seen, the number of hyphens with luatex gets reduced from 5 to 3, which I consider an improvement. Note that I have already tried in a bunch of previous commits to make the PDF output look better with pdftex, too (for example, using ragged-right 'See also' sections and an automatically generated list of hyphenation exceptions for camel-case keywords). > So in general I have the feeling that this doesn't bring us much, > but just keeps adding more checks to our configure and more choices > / configurations to test on a somewhat regular basis. I'm not > really in favor. I disagree with that conclusion, but if you feel that we really, really must disable xetex support in favor of luatex, let's do it. Werner
Re: Prefer luatex for documentation
> Luatex is always available with modern tex distros (say at least 5 > yrs probably more). In fact pdftex _is_ luatex... ??? Definitely not. ``` > pdftex --version pdfTeX 3.141592653-2.6-1.40.24 (TeX Live 2022) kpathsea version 6.3.4 Copyright 2022 Han The Thanh (pdfTeX) et al. There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Han The Thanh (pdfTeX) et al. Compiled with libpng 1.6.37; using libpng 1.6.37 Compiled with zlib 1.2.11; using zlib 1.2.11 Compiled with xpdf version 4.03 > luatex --version This is LuaTeX, Version 1.15.0 (TeX Live 2022) Development id: 7509 Execute 'luatex --credits' for credits and version details. There is NO warranty. Redistribution of this software is covered by the terms of the GNU General Public License, version 2 or (at your option) any later version. For more information about these matters, see the file named COPYING and the LuaTeX source. LuaTeX is Copyright 2022 Taco Hoekwater and the LuaTeX Team. ``` Werner
