Menu
▾
▴
1 Attachments
#3330 bracketify-stencil moves grob's refpoint
Originally created by: *anonymous
Originally created by: janek.li...@gmail.com
Originally owned by: dak@gnu.org
using bracketify-stencil (and probably also parenthesize-stencil) results in a new stencil that has its refpoint moved. This results in wrong placement:
{
\override Staff.TimeSignature #'stencil = #(lambda (grob)
(bracketify-stencil (ly:time-signature::print grob) X 0.3 0.5 2))
\time 2/4 c'2
}
see attached - the refpoint is at the bottom of new stencil, and the extent is something like (0 . 6). Insteaad, the refpoint should stay where it was (in the middle of timesig vertically), and the extent should be sth. like (-3 . 3).
Originally posted by: dak@gnu.org
Issue 3330: bracketify-stencil moves grob's refpoint
Also fixes parenthesize-stencil.
http://codereview.appspot.com/8685044
Labels: Patch-new
Owner: dak@gnu.org
Status: Started
Originally posted by: dak@gnu.org
Patchy is running just now, but frankly I am somewhat sceptic that the horizontally parenthesized versions will work nicely in text markup due to the resulting negative dimension to the left (didn't we just have some effects on staff braces recently).
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests. In markup-scheme.ly, \hbracket and \bracket collide. Accepting patch nevertheless since review is needed: this could be considered expected behavior in connection with the wishes to keep the reference point and/or allow negative escapements.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Cf issue 807 and the patch committed at that time:
commit [r843635e6870c6501ae7ab43022e9e9492033910e]
Author: Thomas Morgan <tlm@ziiuu.com>
Date: Fri Oct 30 21:02:38 2009 +0000
Fix #807: Inconsistent \bracket positioning.
Originally posted by: dak@gnu.org
There is also issue 732 involved. This is a wildly inconsistent mess. Let me state a set of requirements that the bunch of increasingly fragile patches tries to meet at the same time:
\markup \parenthesize x should maintain the reference point of x
\markup { a \parenthesize b c } should allow sufficient space for the the parentheses
\markup { a \hspace #-1 b } should backspace b over a
\markup { a \null b } should have the same spacing as \markup { a b }
The spacing in a line is solely determined by stencil dimensions.
The reference point of a stencil is solely determined by stencil dimensions.
So if we can't use our X stencil dimensions for figuring out our X placement, let's draw the Y stencil dimensions into it:
commit [ra10833e185f24d63ba084634e24933347e347185]
Author: Keith OHara <k-ohara5a5a@oco.net>
Date: Tue Dec 4 21:34:32 2012 -0800
stencil.cc: Backspacing stencils are not empty
diff --git a/lily/stencil.cc b/lily/stencil.cc
index a488c59..eb3420d 100644
--- a/lily/stencil.cc
+++ b/lily/stencil.cc
@@ -66,10 +66,13 @@ Stencil::extent (Axis a) const
bool
Stencil::is_empty () const
+/* If only one of X- or Y-extent is empty; such a stencil can be useful
+ * for backspacing, as with \hspace #-2, so we do not consider it empty.
+ */
So now if only one extent is empty, it can be used for backspacing, but only in one direction. So now our bracket/paren is backspacing into the previous character in a line as its other extent is not empty.
How do we get out of this nuthouse?
Here are a few observations:
a) negative escapements/dimensions are considered valid, so it does not make sense to declare one dimension "empty" unless we are talking about the untouched +inf,-inf dimension pair. left > right is not at all the same as "empty" when we allow for backspacing material
b) if we distinguish backspacing/non-backspacing alone from the stencil dimensions and want \parenthesize x to have the same reference point as x, this stencil must not backspace inside of a line in spite of having a negative x-min.
c) if \hspace #-3 is supposed to backspace, in contrast, the distinguishing difference should be that \hspace #-3 has an _empty_ Y interval (currently it is a _non_-empty one).
And empty does _not_ mean min>max like it does with intervals. People still with me on this?
Originally posted by: pkx1...@gmail.com
Umm... I think this needs to stay on review for now.
Originally posted by: dak@gnu.org
"I think this needs to stay on review for now": unless we enjoy running in circles. The fix is obvious, but then we are back at a state we already had at one point of time and which we did not want to stay with, either.
Huh, actually this is more like "NeedsWork" when I think of it: after all, we would not want it just in this state.
I am not sure I'll make another proposal on this issue anytime soon, but have not decided yet.
Labels: -Patch-review Patch-needs_work
Originally posted by: k-ohara5...@oco.net
Yes, what the patch above does seems obviously correct. A construction like (☺) where ☺ is something that is usually centered, would be expected to have its left extent '[', its reference point '.', and its right extent ']' arranged like this:
[ . ]
That would be fine if LilyPond spaced markup in a line using the extents, placing ']' against the '[' of the next markup.
However, LilyPond spaces markup by placing the the reference point '.' relative to the end ']' of the extent of the markup to the left. That means the left extent of a markup '[ .' backspaces onto whatever is at its left. If we put something like (☺) in a sentence it backspace over the object to its left.
Historically, backspace was encoded as a zero-length markup arranged like this:
][ .
This kind of backspace would not move the cursor if we spaced markups in a line based on extents.
Issue 732 tried to place markups in a line based on extents, breaking backspacing. While fixing the backspace, I made backspace into negative-length :
] .[
Now backspace should work if we place markups in a line based on extents. I did not, however, keep that aspect of the original patch, because that aspect of the patch did not solve any problems identified in the issue.
I think the patch above, together with a change to place markups in a line based on extents, would make everything simpler. The question is whether it works for existing uses.
Originally posted by: janek.li...@gmail.com
You may be interested in looking at issue 1814. There, the problem was exactly that "ears" of the breve notehead backspaced into other objects, and it was fixed by including those ears in the stencil extent (before that they actually sticked out of the bounding box).
I think Keith is right in his comment: LilyPond should place left edge of the next object on the right edge of the previous object, and don't meddle with refpoints.
I think this approach should solve our problems, and i don't see any situations that cannot be managed that way.
Originally posted by: dak@gnu.org
"not meddle with refpoints" sounds better than it is when we don't have refpoints independent from the box dimensions/positioning.
Anyway, on it.
Originally posted by: dak@gnu.org
Issue 3330: redo much of the stencil stacking/spacing/empty-check
This contains a number of commits:
Keep half-empty buildings out of skylines
Let \hspace and \vspace use Y-empty and X-empty spacing, respectively
simplify stack-stencils
Let stack-lines not use padding before X-empty stencils.
Let stack-stencil-line not use spacing around Y-empty stencils
Let Stencil::align_to check axis-specific emptiness before punting
Let Stencil::add_at_edge skip offsets for half-empty stencils
Actually, in-axis direction half-empty stencils are omitted, while
out-of-axis half-empty stencils (usually vspace/hspace) are added
without padding.
Let Box::translate ignore empty axes
Give ly:stencil-empty? an optional axis argument
Create Stencil::is_empty (Axis)
Let Stencil::is_empty use Box::is_empty
This is a change in semantics as an axis interval of '(1 . -1) is considered
empty as an interval, while it is not sufficient for making a box axis
empty.
Make Box::is_empty more selective and create an axis-specific variant
Boxes are not really "empty" just because they show negative
advancement on some axis. A box is empty if its original dimensions
of (+inf . -inf) are still unchanged for both axes. And boxes can
make an impact in one axis but not another, so is_empty can take an
axis as argument now.
Use (+inf . -inf) consistently for empty stencil intervals
http://codereview.appspot.com/8869044
Labels: -Patch-needs_work Patch-new
Originally posted by: dak@gnu.org
Forgot the original fix
http://codereview.appspot.com/8869044
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests. markup-scheme has parenthesized expressions almost running into one another, but that is likely the intended spacing. parenthesize-markup gets correct alignment as opposed to previously. bar-lines.ly is flagged, but its not obvious why. Backspacing over material does not work, though, even though no regtest shows it.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Backspacing did not work
http://codereview.appspot.com/8869044
Labels: -Patch-review Patch-new
Originally posted by: dak@gnu.org
Patchy the autobot says: Well, issue 807 is back. If we want refpoints to stay the same for brackets and 807 not running into another and working backspace, we can't combine lines one by one from their end since then issue 807 has to consider left-hanging brackets and backspacing the same.
Labels: -Patch-new Patch-needs_work
Originally posted by: dak@gnu.org
Ok, I got another change coming up. Keith brought an example in issue 732 that looks like
\markup {"a" \hspace #-4 "b" "ccccc" \translate #'(-2 . 1) "ddd"}
Now, it is obviously impossible to fix both issue 807, this issue, and have the translate above stomp over ccccc unless we change negative translate to cut material off the left edge and that seems even more horrible. So if you want overlap, use negative \hspace. Translate will refuse to roll material into one another. I think that's acceptable.
I have to hone a few more things and then I'll put up a new patch.
Originally posted by: janek.li...@gmail.com
@comment 15:
i'm not sure about what happens when we add brackets around something. Does this result in creating a new stencil that contains both the bracketed object and the brackets, or does it simply insert two additional stencils before and after the object?
Originally posted by: dak@gnu.org
Comment #17: uh, the output of bracketify/parenthesize is a single stencil, so how could anything but the former happen?
Originally posted by: janek.li...@gmail.com
Ok, so it works as i thought.
In this case, i think that what Keith suggested in comment 8 (attach left edge to right edge, not refpoint to right edge) should solve the problem with issue 807. If it doesn't, there must be something i don't understand.
Originally posted by: dak@gnu.org
Complete overhaul again, assembling stencils front to back
http://codereview.appspot.com/8869044
Labels: -Patch-needs_work Patch-new
Originally posted by: dak@gnu.org
Typo
http://codereview.appspot.com/8869044
Originally posted by: dak@gnu.org
And another typo
http://codereview.appspot.com/8869044
Originally posted by: dak@gnu.org
Fix chordname kerning
http://codereview.appspot.com/8869044
Originally posted by: dak@gnu.org
Yet another typo
http://codereview.appspot.com/8869044
Originally posted by: dak@gnu.org
Huh. "Fix chordname kerning" was done on the assumption that I need to cater for some negative kerning not working in that context. The kerning, however, is positive. Seems like that should be allowed to work as intended without meddling with the chordname code.
Labels: -Patch-new Patch-needs_work