Menu
▾
▴
2 Attachments
#3255 \with-dimensions doesn't affect the overall size of a TextScript
Originally created by: *anonymous
Originally created by: lemzw...@googlemail.com
Originally owned by: k-ohara5...@oco.net
\version "2.17.15"
\header { texidoc = "
@code{\\with-dimensions} works with zero extents also.
Here is a counterexample.
" }
{
\override TextScript.outside-staff-priority = ##f
c''1-\markup { \with-dimensions #'(0 . 0) #'(0 . 0) { foo } }
-\f
}
Originally posted by: lemzw...@googlemail.com
IIRC, 2.17.0 worked also correctly, but I no longer have this binary.
Originally posted by: mts...@gmail.com
stencil-based vertical-skylines are now used for outside staff positioning.
In order to get the old behavior back, use:
{
\override TextScript.vertical-skylines =
#(ly:make-unpure-pure-container
ly:grob::simple-vertical-skylines-from-extents
ly:grob::pure-simple-vertical-skylines-from-extents)
\override TextScript.outside-staff-priority = ##f
c''1-\markup { \with-dimensions #'(0 . 0) #'(0 . 0) {
foo } }
}
This is definitely a regression, but I'm not sure the best way to fix it. Perhaps document that with-dimensions only affects the dimensions of the stencil but not the vertical skyline?
Originally posted by: lemzw...@googlemail.com
I don't think that documenting this is the right solution. I intentionally use \with-dimensions to hide the real outline of the object, so I would rather have this feature back: Anything included by \with-dimensions becomes invisible to the skyline algorithm, and the skyline algorithm only sees a rectangular box which gets properly positioned.
Originally posted by: dak@gnu.org
Regarding comment #3: agreed. This is another instance where an existing user interface is broken without a user-accessible way of achieving the previous functionality. \with-dimensions needs to override the skyline with an appropriate building in order to make any sense.
Originally posted by: mts...@gmail.com
In the documentation, \with-dimensions is documented as:
"Set the dimensions of arg to x and y."
It sets the dimensions of the argument, which is a markup, not the entire grob (which is in this case a TextSpanner). For example:
{ c_\markup { foo \with-dimensions #'(0 . 0) #'(0 . 0) bar foo } }
Does not effect the entire grob stencil but just the middle word.
I'm not sure if by "object" you mean grob - to set the dimensions of an grob, X-extent and Y-extent are your best bet.
The way to get this behavior back is to revert the current default for TextScript vertical-skylines. For the time being, there is no way to communicate between markups (which are stencils evaluated at compile time) and vertical skylines to do the kind of skyline overrides David's talking about. I'm OK with this reversion if people think that's the right way to go.
Originally posted by: mts...@gmail.com
This is actually part of a bigger issue...if someone does:
\override Hairpin #'Y-extent = #'(-0.1 . 0.1)
this will have no effect on outside staff or side-position spacing because hairpin's vertical skylines are taken from their stencils. Two possible solutions come to mind:
1) Document that outside-staff spacing and side position spacing, for certain grobs, is not based on extents but rather stencils.
2) Never make stencil-based skyline spacing a default. This would bring back all of the bad spacing problems from 2.16, but would make the good spacing accessible via an override.
I'm OK with either of those options, although I'd prefer the 1st.
Originally posted by: dak@gnu.org
I think it would be more reasonable if Y-extent would override skylines when set. However, this does not help with \with-dimensions as far as I can see. In the case of \with-dimensions, we need to get the overriding information attached to the stencil in a manner that is able to override the stencil's contribution to a skyline. Since we also need extents for alignment purposes, we probably still need to have them stored in a stencil, but we'll likely also need to record whether the extents have been stored explicitly or are just a consequence of the skyline calculation.
At first glance, this would appear to make things like an Y-extent override somewhat easier to implement than \with-dimensions.
Originally posted by: lemzw...@googlemail.com
Yes, I think we need a dual interface, this is, both collecting extents and stencils. If a user explicitly sets Y-extent, use it. If \with-dimensions is used, set the extents for all elements contained in the expression. In case we have an explicit extent, create a box-like skyline for it, otherwise use the skyline as defined by the stencil.
Originally posted by: mts...@gmail.com
One thing that is possible is to use the more sophisticated skyline but treat the extents as a sort of bounding box.
I know right away that this will be problematic for grobs like DynamicText when its forte, as the fatness of the f on either side is ignored in the bounding box but is important in the skyline.
However, it would work in the case of most TextScripts (including the one in this example).
What do people think?
Originally posted by: dak@gnu.org
"Sort of bounding box" is rather vague. The setting of the extents to (0 . 0) only makes sense when the regions indicated by skyline and extents are combined with "and", whereas extents used for trying to make something larger will only work when the combination of the regions is done using "or".
So I doubt we'll manage to find a reasonable "sort of" behavior that will not simply _drop_ the skyline information (rather than try to combine it) where an extent is explicitly specified.
Originally posted by: mts...@gmail.com
True.
I'd go back to my previous point, then, that there is nothing wrong with making my skyline work the not-default. Whoever wants to use it can use it (we can even make a command \sexySkylines to turn it on via a lot of overrides) and otherwise the old behavior will just be the default.
If people think this is the best course of action, I'll propose a patch.
Originally posted by: dak@gnu.org
Seems like I did not get my point across in #10: I think it would be best if skylines were used by default _unless_ there was an override of X-extent/Y-extent (I don't have a clear plan how to deal with only one being overriden: presumably it is applied everywhere where the other axis has a non-empty building). That should be a "natural" strategy for overriding extents. I a, not knowledgeable enough about stencils to figure out whethe a similar strategy can be put to use for \with-dimensions.
Originally posted by: k-ohara5...@oco.net
Workaround: add a line
\override TextScript #'vertical-skylines = #'()
which I will shortly suggest that we make the default, anyway.
The code for \with-dimensions doesn't override the grob-property Y-extent, but the field in the stencil data structure (which is used as the default when Y-extent is requested, but not defined as a property)
In cases with non-text objects (like the Hairpins mentioned above) I used to override 'minimum-Y-extent in order to enforce a minimum size -- reserving space for the union, combination with "or", of the actual extent and my specified minimum. There was no corresponding 'maximum-Y-extent, presumably because users never wanted objects to collide.
The example above asks for things to collide, but it is unrealistic, probably in order to be minimal. (The example asks LilyPond to put the baseline of the text at the minimum of 'padding or 'staff-padding below the lowest staff-line or on-staff object.) If we want test inside the staff, we add
\override TextScript #'staff-padding = ##f
More often we want extra space and increase the extents.
Originally posted by: janek.li...@gmail.com
I partly agree to the previous comments, and partly not.
I think the situation is like follows:
before Mike's skylines, we used extents for all positioning stuff. Back then, XY-extent had at least two meanings:
- it described grob dimensions, which were necessary to calculate offsets needed to align grobs to each other,
- it was the grob's outline, used for checking collisions.
These two tasks are similar but subtly different.
After merging skyline patch, more and more grobs (all of them?) use skylines to check for collisions. This is generally a correct approach, and i think that we want to continue moving in that direction. However, it's not clear what we should use extents for, and that needs consideration; the resulting API will be probably significantly different than the old one.
My first thought was that we should ditch extents, but that doesn't make sense: after all, we need to store grob dimensions somewhere (instead of calculating them from the skylines every time we need them). In other words, first meaning described above remains valid. Now, when we want to use something like \with-dimensions, what we want to change are not extents - we want to change grob outlines, and that will /result/ in different extents. In other words, i think that extents should be derived from outlines, in a way similar to how X-offset is derived from self-alignment-X (if you want to change how a grob is aligned, you usually don't override X-offset - you override alignment, and that results in changed offset).
What i think should be made more prominent (and probably change its meaning a bit) is padding. For example, if we wanted to ensure that there'd be a lot of space around dynamics, before 2.17 we could override extents like this:
{
\override DynamicText #'X-extent = #'(-2 . 3)
\override DynamicText #'Y-extent = #'(-2 . 3)
c'\f d'\p e'\f f'
}
After skyline patch these overrides don't work like that, because collisions no longer are calculated from extents. What about using padding for that purpose? I imagine that it would work very similarly to skyline-horizontal-padding - in fact, the only difference would be that setting padding would have effect regardless of whether the grob used skylines or not.
#(ly:set-option 'debug-skylines #t)
{
e'1 \mp
\override DynamicText #'skyline-horizontal-padding = #0.5
e'1 \mp
}
Of course, negative padding should be allowed and it would mean that a grob can overlap with other grobs. Setting padding to -inf should do the same as \with-dimensions #'(0 . 0) #'(0 . 0) did before skylines.
I think that using this padding-based approach will avoid problems that David outlined in comment #10.
The bottom line: i think that we should move away from using extents for spacing objects, and use them only for aligning and similar "logical", "one-dimensional" tasks (spacing in general is a 2D task, even if we move along one axis). I think we should develop "skylinish" ways of solving our spacing problems instead of going back to extents.
Originally posted by: k-ohara5...@oco.net
Any user writing the \with-dimensions command is rather explicitly requesting that the object be spaced with a simple box outline.
Maybe \pad-around could be generalized as suggested in the comment above.
Neither one works in version 2.17.14 (with positive, zero, or negative values) as seen with the example below (using a short but positive horizontal-extent so that the recent desired changes regarding zero-width objects to not confuse the issue.)
{ g1
% -\tweak #'vertical-skylines
% #(ly:make-unpure-pure-container
% ly:grob::simple-vertical-skylines-from-extents
% ly:grob::pure-simple-vertical-skylines-from-extents)
-\markup { \with-dimensions #'(0 . 1) #'(-3 . 3) "tall" }
-"bar"
g1
% -\tweak #'vertical-skylines
% #(ly:make-unpure-pure-container
% ly:grob::simple-vertical-skylines-from-extents
% ly:grob::pure-simple-vertical-skylines-from-extents)
-\markup { \pad-around #3 "tall" }
-"bar" }
If the commented-out tweaks can be put into the function definitions, we would regain the old behavior.
Summary: \with-dimensions doesn't work
Originally posted by: k-ohara5...@oco.net
(No comment was entered for this change.)
Labels: Regression
Originally posted by: k-ohara5...@oco.net
The only alternatives I can think of are
1) documenting TextScript.vertical-skylines = #'() in order to give these markup functions effect when spacing with music
2) adding a box stencil to make the stencil itself as large as with-dimensions
http://codereview.appspot.com/9295044/
Either option makes \with-dimensions and \pad-around increase the space allowed for markup, and thus generally work. Only the first of these options ignores the stencil in favor of the with-dimensions for spacing purposes, and makes the original example work.
Originally posted by: lemzw...@googlemail.com
Regarding this comment from #15:
If the commented-out tweaks can be put into the function definitions, we would regain the old behavior.
I would like to know whether this is possible...
\with-dimensions is especially useful IMHO for giving an option a zero dimension, so I would rather tend to option 1) in comment #17 in case there isn't a better solution.
Originally posted by: k-ohara5...@oco.net
It is awkward to implement the workaround in comment #15, because as mentioned in comment #5 \with-dimensions works on what could be just one part of a markup that might or might not end up in a TextScript. The resulting behavior of considering the whole TextScript as a box if any part of it used \with-dimensions, would be similarly awkward.
Probably best to tag only the piece of markup with the explicit dimensions, so that when skyline-builder sees that tag it uses the extent box rather than stencil for that piece. Then \with-dimensions would be spaced like a \page-ref after issue 3337.
{ \override TextScript.outside-staff-priority = ##f
c''1-\markup \page-ref #'bogus
\with-dimensions #'(0 . 0) #'(0 . 0) "foo"
\with-dimensions #'(0 . 0) #'(0 . 0) "foo"
-\f }
Summary: \with-dimensions doesn't affect the overall size of a TextScript
Originally posted by: k-ohara5...@oco.net
Tag the results of \pad-around \pad-markup \pad-to-box and \with-dimensions so that stencil-integral.cc knows to use the extents and not the stencil expression.
I am struggling to make a regression test that looks obviously-correct when the test passes.
http://codereview.appspot.com/9295044/
Labels: Patch-new
Status: Started
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes make, make test and a full make doc.
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
Patch on countdown for May 25 - 06:00 GMT
Labels: -Patch-review Patch-countdown
Owner: k-ohara5...@oco.net
Originally posted by: pkx1...@gmail.com
Patch counted down - please push
Labels: -Patch-countdown Patch-push
Originally posted by: k-ohara5...@oco.net
While writing a better regression test, I realized one would reasonably expect the space to affect only part of the markup that has \with-dimensions or similar:
f^\markup {\note-by-number #1 #0 #UP \pad-around #0.5 fa }
One would expect skyline spacing for the tall note, but apparently there is reason for padding around the "fa", and one would expect LilyPond to keep note-stems and such things outside that padding.
The "extent" of the piece of the stencil, the only thing affected by \with-dimensions and similar, is forgotten when the stencil is combined with others. We would need to include the \with-dimensions dimensions into the new tag that says "please treat this portion as a simple box" -- or just have \with-dimensions draw an invisible and transparent box.
Labels: -Patch-push Patch-needs_work
Originally posted by: k-ohara5...@oco.net
Some commands like \pad-around are nearly useless at the moment, so I suggest this is Critical.
The pedestrian solution seems the most clear:
Have \pad-around and similar insert a stencil-expression that Mike's skylining can see.
Have \with-dimensions tag the real stencil so Mike's skylining can ignore it
If this concept meets the need, I should go back and implement a specific stencil-expression that means 'reserve space in skylines' but does not put anything in the PostScript output.
http://codereview.appspot.com/9295044/
Labels: -Type-Defect -Patch-needs_work Type-Critical Patch-new