Re: two pipelines for a single merge
> Le 19 nov. 2022 à 08:42, Werner LEMBERG a écrit : > > > 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). Best, Jean
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? Note that I simply press the 'Rebase' button followed by 'Merge if rebase succeeds'. Werner
Re: strut problem, Re: strut problem, Re: strut problem, Re: strut problem
> Le 19 nov. 2022 à 08:04, Werner LEMBERG a écrit :
>
>> A stencil has an X extent, a Y extent and a stencil expression
>> (Scheme list). That's all.
>> Think of it in another way. If LilyPond gave non-empty skylines to
>> stencils with empty extents, a grob with its stencil set to
>> #empty-stencil would stop taking no space. Instead, it would take
>> the space of a point and start influencing the spacing. I think it
>> should be clear that this is a bad idea.
>
> OK, understood. 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.
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.
>> Can we take a step back? What are the use cases for \strut in the
>> first place? Maybe we can invent something that works more sanely
>> and fits the same purposes.
>
> 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.
>> 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]]
> ```
Note that markup commands don’t support optional arguments.
\with-replaced-skyline sounds a lot like
\with-outline \translate #'(offset . 0) markup2 markup1
(which also changes horizontal skylines).
\with-added-skyline sounds like
\with-outline \overlay { markup1 \translate #'(offset . 0) markup2 } markup1
Supporting the 'extent' parameter would take some modifications to the C++
code. Do you have a specific use case for it?
Jean
Re: strut problem,Re: strut problem,Re: strut problem,Re: strut problem
> A stencil has an X extent, a Y extent and a stencil expression > (Scheme list). That's all. > > Think of it in another way. If LilyPond gave non-empty skylines to > stencils with empty extents, a grob with its stencil set to > #empty-stencil would stop taking no space. Instead, it would take > the space of a point and start influencing the spacing. I think it > should be clear that this is a bad idea. OK, understood. 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. > Can we take a step back? What are the use cases for \strut in the > first place? Maybe we can invent something that works more sanely > and fits the same purposes. 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. > 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]] ``` Print `markup1` but give it a modified vertical skyline. Both functions overlay the skyline of `markup2` on top of `markup1`; `\with-added-skyline` takes the maximum of both, while `\with-replaced-skyline` replaces the skyline of `markup1` with the one from `markup2`. For computing the new skyline, `markup2` is shifted horizontally by `offset` (default is 0), and only `extent` (an interval) is taken from it (default is the extent of the complete `markup2`). Note that `markup2` must have a non-zero extent to take any effect. No idea whether such functions make sense in the long run... Werner
PATCHES - Countdown to November 21
Here is the current countdown report. The next countdown will begin on November 21st. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1732 convert-ly: Print "not smart" message for markup->string - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1732 !1731 *.scm: Add missing backslashes in documentation strings - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1731 !1728 Whole notes (and longer) don't warn about weird stem size - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1728 !1727 Add support for solitary '+' in figured bass - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1727 !1725 Fix text replacements for non-ASCII input on non-Unicode-aware locale - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1725 !1724 Fix direction for whole note tremolos on third line - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1724 !1722 Figured bass inside Staff doesn't collide with scripts - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1722 !1717 build: Fix some documentation build glitches - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1717 !1677 max-slope-factor for tuplet brackets - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1677 Countdown: !1734 Resurrect banana commas - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1734 !1733 GregorianTranscriptionVoice: stop making ligatures transparent - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1733 Review: !1721 Unify and fix grob property type checks - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1721 New: No patches in New at this time. Waiting: !1710 Web: Update Download part for 2.24 - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1710 Cheers, Colin
Re: BDWGC fix in 2.24?
Le 18/11/2022 à 16:17, Kevin Barry a écrit : On Fri, Nov 18, 2022 at 11:06:45AM +0100, Jean Abou Samra wrote: Hi, 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? How sure are we that this patch fixes the issue? That would have to be confirmed through the 2.23.82 release candidate. Assuming that it does fix it, then I think our options are: - release what we have anyway, and follow up with a patch release removing our workaround when it's no longer needed - wait for the patch to be released My personal preference is for the latter option, but I think either option is OK. We have been in a really awkward situation with Guile 1 vs. 2 and macOS in the past years. The 2.24 release will fix that, so delaying it for an amount of time we don't really know is the option I like the least. Ivan Maidanski said "I think it [the release] should happen in Jan 2023". Even if it's early January, we will need a release candidate to test that it works, so the final release goes from mid-December to mid/end-January at best, but we don't know when exactly the BDWGC release will be, and it might depend on the time the maintainer finds he has in the coming months. Jean OpenPGP_signature Description: OpenPGP digital signature
Re: strut problem,Re: strut problem
Le 18/11/2022 à 23:16, Werner LEMBERG a écrit :
Put yourself in the shoes of LilyPond trying to compute the skylines
of this stencil:
(ly:make-stencil "" empty-interval '(-0.3 . 0.7))
According to you, the skyline should be a zero-width spike. At
which horizontal coordinate is this spike? Any value would be
legitimate.
Well, I don't consider this as something stand-alone but as a markup.
A markup has an anchor, i.e., it starts at a point X, doesn't it? The
strut would thus have the same horizontal coordinate as X.
A markup is code for a stencil. A markup command does not provide any
information to the outside other than the stencil it returns.
Skylines are a concept defined on stencils, not on markups.
A stencil has an X extent, a Y extent and a stencil expression
(Scheme list). That's all.
Think of it in another way. If LilyPond gave non-empty skylines
to stencils with empty extents, a grob with its stencil set to
#empty-stencil would stop taking no space. Instead, it would take
the space of a point and start influencing the spacing. I think
it should be clear that this is a bad idea.
If \strut needs to have an empty X extent for horizontal spacing
reasons, you will need to use ly:stencil-outline.
Understood now, thanks. David suggests
```
#(define-markup-command (strut layout props)
()
#:properties ((baseline-skip))
(make-transparent-box-stencil
empty-interval
(cons (* -0.3 baseline-skip)
(* 0.7 baseline-skip
```
and I wonder whether the existing `\strut` command should be changed
to this code.
Well, but this does not make \strut taken into account in
the vertical skylines, does it? If it does, I am not seeing
the effect.
David is right, however, that the make-transparent-box-stencil
helper can be used here. Here is a variation of my second
snippet that uses it:
\version "2.23.81"
#(define-markup-command (strut layout props)
()
#:properties ((baseline-skip))
(let ((yext (cons (* -0.3 baseline-skip)
(* 0.7 baseline-skip
(ly:make-stencil
(ly:stencil-expr (make-transparent-box-stencil '(0 . 0.05) yext))
empty-interval
yext)))
{
\override TextScript.show-vertical-skylines = ##t
e'4^\markup { "a" }
e'4^\markup \concat { \strut "a" }
}
\markup \line { "a" "a" }
\markup \line { "a" \strut "a" }
But this is really walking on thin ice, in my view.
Can we take a step back? What are the use cases for \strut
in the first place? Maybe we can invent something that works
more sanely and fits the same purposes.
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.
Jean
OpenPGP_signature
Description: OpenPGP digital signature
Re: strut problem,Re: strut problem
> Put yourself in the shoes of LilyPond trying to compute the skylines > of this stencil: > > (ly:make-stencil "" empty-interval '(-0.3 . 0.7)) > > According to you, the skyline should be a zero-width spike. At > which horizontal coordinate is this spike? Any value would be > legitimate. Well, I don't consider this as something stand-alone but as a markup. A markup has an anchor, i.e., it starts at a point X, doesn't it? The strut would thus have the same horizontal coordinate as X. >>> If \strut needs to have an empty X extent for horizontal spacing >>> reasons, you will need to use ly:stencil-outline. Understood now, thanks. David suggests ``` #(define-markup-command (strut layout props) () #:properties ((baseline-skip)) (make-transparent-box-stencil empty-interval (cons (* -0.3 baseline-skip) (* 0.7 baseline-skip ``` and I wonder whether the existing `\strut` command should be changed to this code. Werner
Re: strut problem,Re: strut problem,Re: strut problem,Re: strut problem
> You did see the code I posted that would do what you asked for? Sorry, no, I missed it. Thanks! Werner
Re: BDWGC fix in 2.24?
On Fri, Nov 18, 2022 at 11:06:45AM +0100, Jean Abou Samra wrote: > Hi, > > 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? How sure are we that this patch fixes the issue? Assuming that it does fix it, then I think our options are: - release what we have anyway, and follow up with a patch release removing our workaround when it's no longer needed - wait for the patch to be released My personal preference is for the latter option, but I think either option is OK. I don't like the idea of a stable release built from an unreleased version of BDWGC. Kevin
Re: BDWGC fix in 2.24?
On 11/18/2022 4:06 AM, Jean Abou Samra wrote: Do we keep the current workaround, which still gives some crashes? In that case, possibly releasing with a "known issue" note, and explaining how Windows users could use Windows Subsystem for Linux if they have very large scores approaching memory limits? And, then maybe have 2.24.1 release after the BDWGC fix comes down. It looks to me like the different choices will be a matter of figuring out which set of trade-offs will be best for the entire LilyPond community, within acceptable norms for a stable release. -- Karlin High Missouri, USA
Re: strut problem,Re: strut problem,Re: strut problem,Re: strut problem
Werner LEMBERG writes:
> Why is the vertical extent of the strut ignored?
Because side positioning is primarily based on (vertical)
skylines, not extents.
>>>
>>> Thanks. What is the reasoning behind this? For me, this behaviour
>>> is unexpected.
>>
>> By the way, this is one reason why \strut is not such a great thing
>> in my opinion. I suppose that in LaTeX, {\strut abc} and {abc
>> \strut} (or whatever the exact syntax is) are equivalent. In
>> LilyPond, they can't be, since if you want \strut to factor into the
>> skylines, its placement will be visible in the shape of the skylines
>> (and consequently make a difference in the spacing).
>
> You are correct with your LaTeX observation. However, the longer I
> think about struts – even `\vspace` is nothing else than a vertical
> strut! – the more I believe that there is a conceptual problem in
> LilyPond: There is a 'typesetting mode' where vertical struts have an
> effect (like the problem originally reported in 'lilypond-user',
> starting with
> https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00237.html),
> and there are other modes without such an effect.
You did see the code I posted that would do what you asked for?
--
David Kastrup
Re: strut problem
Le 18/11/2022 à 12:34, Werner LEMBERG a écrit :
It is completely unclear to me how you would take non-printing
stencils with empty extents into skylines. How should the resulting
skylines look like? If the X extent is empty-interval, why should
the vertical skyline take this stencil into account on '(0 . 0) and
not on, say, '(2 . 2)?
I don't understand what you mean, please elaborate.
Put yourself in the shoes of LilyPond trying to compute the skylines
of this stencil:
(ly:make-stencil "" empty-interval '(-0.3 . 0.7))
According to you, the skyline should be a zero-width spike.
At which horizontal coordinate is this spike? Any value would
be legitimate.
What I want: Let's assume we have `\markup \concat {"a" \strut "a"}`,
then the vertical skyline would be
```
|
___|___
| a a |
```
i.e., there would be a (zero-width) spike between the two 'a' glyphs.
If \strut needs to have an empty X extent for horizontal spacing
reasons, you will need to use ly:stencil-outline.
Please give an example.
Here is a refinement of my initial reply:
\version "2.23.81"
#(define-markup-command (strut layout props)
()
#:properties ((baseline-skip))
(let ((yext (cons (* -0.3 baseline-skip)
(* 0.7 baseline-skip
(ly:make-stencil
(ly:stencil-expr
(ly:stencil-outline
empty-stencil
(make-filled-box-stencil '(0 . 0.05) yext)))
empty-interval
yext)))
{
\override TextScript.show-vertical-skylines = ##t
e'4^\markup { "a" }
e'4^\markup \concat { \strut "a" }
}
\markup \box "a"
\markup \box \concat { \strut "a" }
Now the output of \strut should have a 'spike' skyline on
'(0 . 0.05) and an empty (not '(0 . 0), but really empty,
i.e. empty-interval = '(+inf.0 . -inf.0)) X extent.
(Which is kind of weird, by the way.)
OpenPGP_signature
Description: OpenPGP digital signature
Re: strut problem,Re: strut problem
>> What I suggest is that zero-width/zero-height objects
>> *are* taken in account for computing the skylines.
>
> What makes your (redefined) \strut not taken into account [...] is
> caused by the "" stencil expression, which LilyPond never gives
> skylines to
Ah, thanks.
> It is completely unclear to me how you would take non-printing
> stencils with empty extents into skylines. How should the resulting
> skylines look like? If the X extent is empty-interval, why should
> the vertical skyline take this stencil into account on '(0 . 0) and
> not on, say, '(2 . 2)?
I don't understand what you mean, please elaborate.
What I want: Let's assume we have `\markup \concat {"a" \strut "a"}`,
then the vertical skyline would be
```
|
___|___
| a a |
```
i.e., there would be a (zero-width) spike between the two 'a' glyphs.
> If \strut needs to have an empty X extent for horizontal spacing
> reasons, you will need to use ly:stencil-outline.
Please give an example.
Werner
Re: strut problem
Le 18/11/2022 à 12:05, Werner LEMBERG a écrit :
The latter. What I suggest is that zero-width/zero-height objects
*are* taken in account for computing the skylines.
What makes your (redefined) \strut not taken into account into
skylines is not just its empty X extent. You can see that it is still
not taken into account if you replace empty-interval with '(0 . 10).
That is caused by the "" stencil expression, which LilyPond never
gives skylines to -- unless it's the whole stencil: you can see
that in this example:
\version "2.23.81"
#(define-markup-command (strut layout props)
()
#:properties ((baseline-skip))
(ly:make-stencil ""
'(0 . 10)
(cons (* -0.3 baseline-skip)
(* 0.7 baseline-skip
{
\override TextScript.show-horizontal-skylines = ##t
\override TextScript.show-vertical-skylines = ##t
e'4^\markup { "a" }
% \strut not taken into account for vertical skylines
e'4^\markup { \strut "a" }
% Here, \strut *is* taken into account.
e'4^\markup \strut
}
It is completely unclear to me how you would take non-printing
stencils with empty extents into skylines. How should the resulting
skylines look like? If the X extent is empty-interval, why should
the vertical skyline take this stencil into account on '(0 . 0)
and not on, say, '(2 . 2)?
If you want something in the skylines, you need to tell
LilyPond how its skylines should look like, with the extents.
If \strut needs to have an empty X extent for horizontal
spacing reasons, you will need to use ly:stencil-outline.
Regarding the latter, the handling looks inconsistent. I've opened
https://gitlab.com/lilypond/lilypond/-/issues/6472 about that.
Thanks. However, I can't immediately that these two problems are
related :-)
The same happens with embedded-ps as with "" above.
Jean
OpenPGP_signature
Description: OpenPGP digital signature
Re: strut problem
>> However, the longer I think about struts – even `\vspace` is
>> nothing else than a vertical strut! – the more I believe that there
>> is a conceptual problem in LilyPond: There is a 'typesetting mode'
>> where vertical struts have an effect (like the problem originally
>> reported in 'lilypond-user', starting with
>> https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00237.html),
>> and there are other modes without such an effect.
>>
>> What about making LilyPond properly integrate (finite) struts into
>> the skyline?
>
> I'm not understanding what you mean by this precisely. Are you talking
> about a change to the definition of \strut or a change to how skylines
> are computed?
The latter. What I suggest is that zero-width/zero-height objects
*are* taken in account for computing the skylines.
> Regarding the latter, the handling looks inconsistent. I've opened
> https://gitlab.com/lilypond/lilypond/-/issues/6472 about that.
Thanks. However, I can't immediately that these two problems are
related :-)
> Note that, say, a vertical strut between "V" and "A" would also
> defeat kerning.
Yes.
> Have you already found yourself needing to fine-tune skylines?
Yes, sometimes.
> I have always gotten along by tweaking padding and padding-like
> properties.
Me too, but I can imagine that inserting a strut might be easier,
especially if skylines have a lot of valleys and mountains.
> By the way, can you check what your mail client is doing with
> email subjects? Your email's is
>
> "strut problem,Re: strut problem,Re: strut problem,Re: strut problem"
Interesting, I have never observed this before. This must be a bug in
my e-mail client ('mew' for Emacs). Thanks for noticing!
Werner
Re: strut problem
Le 18/11/2022 à 05:46, Werner LEMBERG a écrit : You are correct with your LaTeX observation. However, the longer I think about struts – even `\vspace` is nothing else than a vertical strut! – the more I believe that there is a conceptual problem in LilyPond: There is a 'typesetting mode' where vertical struts have an effect (like the problem originally reported in 'lilypond-user', starting with https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00237.html), and there are other modes without such an effect. What about making LilyPond properly integrate (finite) struts into the skyline? I'm not understanding what you mean by this precisely. Are you talking about a change to the definition of \strut or a change to how skylines are computed? Regarding the latter, the handling looks inconsistent. I've opened https://gitlab.com/lilypond/lilypond/-/issues/6472 about that. I see two advantages. * It removes the above-described modality, which seems unnecessary to me. If it is really necessary, it lacks an explanation in the NR. * It would allow fine-tuning of the skyline in a simpler way than what currently is possible. Imagine, for example, that you need some empty space above letter 'V' of the string 'VAVA': ``` | | ++---+ |VAVA| ``` The 'correct' solution would be to put letter 'V' into a `\with-dimension` box or something similar [please correct me if there is something better]. However, doing so might produce a different output if, say, there is kerning: Pango now sees 'V' and 'AVA', and the kerning between the first 'V' and 'A' is lost, AFAIU. The alternative would be to insert a vertical strut right before letter 'V'. Note that, say, a vertical strut between "V" and "A" would also defeat kerning. Have you already found yourself needing to fine-tune skylines? I have always gotten along by tweaking padding and padding-like properties. By the way, can you check what your mail client is doing with email subjects? Your email's is "strut problem,Re: strut problem,Re: strut problem,Re: strut problem" Jean OpenPGP_signature Description: OpenPGP digital signature
BDWGC fix in 2.24?
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. 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? Thanks, Jean OpenPGP_signature Description: OpenPGP digital signature
