Created attachment 197143 [details] vertical alignment illustrations Consider the attached presentation with several textboxes on each slide: The first slide uses our Liberation Serif font. You will note that the vertical alignment logic aligns-bottom so that the descender just touches the rectangle edge; but aligns-top so that there is quite some distance between the ascender height and the top of the rectangle. It seems this distance is about what you would find as the distance to a preceding line of text, whose baseline is the top edge of the rectangle; that is verified when we consider the two lines of ochre text I've overlaid over each of the top-aligned and bottom-aligned text. Moreover, you'll note that the middle-aligned text does not actually have its x character - the fundamental one for font metrics - cross the vertical middle at its center. Even the capital-X doesn't cross the middle at its center. IIANM, it seems that its the middle of the line+space-above vertical segment that intersects the middle of the shape's height. This is already problematic, in two ways: 1. It is not legitimate to assume that a single line of text has, or requires, any inter-line spacing, at all. At least, this is not a legitimate assumption in a textbox. 2. More importantly, even if we do assume line spacing - it cannot be assumed to be located above the single line! If we assume each single line has it, then surely, half of it must be above and half below. Or perhaps - the relative placement should depend on the v-alignment, i.e. if we start from the top, then v-space is below each line; if we start from the bottom - it is above; and if we're valigned to the middle, then again half above and half below. ----- Ok, so far we talked about the first slide. Things seemed to make sense and I have an argument against the logic we're using. Now let's proceed to the next slide, where the font is Carlito, having somewhat different metrics. Here - nothing seems to make sense! The bottom-valigned text doesn't touch the bottom, the top-valigned doesn't agree with the above line starting at the top of the box, and I can't even guess what the middle v-alignment means exactly. The logic seems beyond scrutiny. Could it be that the heights are calculated based on metrics for another font? If not - what is it? ----- No, why is all this an issue? Well, because every *** **** time I try to get text to be on the bottom, or the top, of a textbox - I can't quite get it there, and I need to either enter empty lines above or below, or play with faux-subscripting/super-scripting. And it's even worse for middle v-align, where the fact that the line is _not_ in the middle is even more apparent (the top and bottom enjoy some benefit of the doubt due to margins which are somewhat arbitrary). See also bug 163235 about middle v-alignment specifically.
Isn't the "white space" defined by the font's ascender/decender? And I don't see what is part of the font and what results from margins, whether intentionally or as a consequence of a bug.
(In reply to Heiko Tietze from comment #1) > Isn't the "white space" defined by the font's ascender/decender? No, it isn't - look at the attached document. > And I don't > see what is part of the font and what results from margins, whether > intentionally or as a consequence of a bug. The boxes in the attached file have no margins. (And I've filed bug 163527 about visualizing those margins/inter-box text boundaries.)
If you use a character background, you can see the actual size of the character box. And there you see, that this box aligns correctly. It depends on the font, where on this box the lines of a glyph are drawn. NAB for me.
(In reply to Regina Henschel from comment #3) > If you use a character background, you can see the actual size of the > character box. And there you see, that this box aligns correctly. It depends > on the font, where on this box the lines of a glyph are drawn. I'm not sure I'm buying this argument. If highlighting only covers the character (bounding) box and nothing outside of it, then - between consecutive, regularly-spaced lines, there must be some space between the highlighted regions, as otherwise, the bottom of one line could touch the top of the next one. So, one of two things is happening: 1. Highlighting also covers some spacing above the edge of the character box, or 2. The character box itself incorporates some space above all possible characters. which one do you think is the case? Or am I misunderstanding?
Responding with observations and subjective preferences. I do not know why Impress works the way it currently does, and I do not have an opinion about how the implementation should change, if at all. It's possible this was a design decision made for UX or interoperability reasons about which I'm unaware. (In reply to Eyal Rozenberg from comment #0) > Moreover, you'll note that the middle-aligned text does not actually have > its x character - the fundamental one for font metrics - cross the vertical > middle at its center. Even the capital-X doesn't cross the middle at its > center. IIANM, it seems that its the middle of the line+space-above vertical > segment that intersects the middle of the shape's height. Fonts do not provide such a centerline metric. The closest they provide is a strikeout height, but it is not meant for this purpose and I don't think it's safe to use. Using (ascent - descent) / 2 is the most reasonable available closed-form guess. (This is not what we do: see below.) One thing to keep in mind is, if your goal is to make this "look right", a closed-form solution will never be adequate. What "looks right" is when the optical weight of the text above the centerline is equal to the optical weight of the text below it. Correct-looking vertical placement depends on the content of the text. Even if font authors could provide a tuned metric for vertical centering, it would look just as wrong in many situations as what we currently do. > 1. It is not legitimate to assume that a single line of text has, or > requires, any inter-line spacing, at all. At least, this is not a legitimate > assumption in a textbox. I confirm that the vertical positioning of top- and middle-anchored text is based on line height, rather than just font ascent and descent. This is difficult to see with text metrics alone, but can be easily demonstrated by changing the line spacing in the shape style. When line spacing is single, we are vertically positioning text using (ascent - descent + line gap). These are all font metrics, but arguably we are not using them in an intuitive or visually appealing way. Our current approach results in text that appears to me to be positioned too low in general. Subjectively, I think the current approach looks reasonable for top-aligned multi-line text boxes. In this case, each line in the text box has the same amount of whitespace above it as the each of the following lines, which looks correct to me. However, for single-line, I would intuitively expect the line to be anchored at the ascent, not at the ascent+line gap as is the current behavior. It's possible to manually tweak vertical placement by manually changing the line spacing, but there's no way of doing this that is robust against font changes (or, worse, substitutions). Middle-anchored text also looks wrong to me in all cases. Intuitively, I would expect the white space above the ascent of the first line to equal the white space below the descent of the last line. That means, if there's an odd number of lines, the text should be vertically positioned at (ascent - descent) / 2 relative to the middle line, or at the midpoint of the line gap for an even number of lines. Instead, currently, we center based on the sum of the line heights. A two-line text box will be centered at the descent of the first line. This makes all vertically centered text boxes look lopsided to me. This is all just my subjective opinion about what looks good and what makes sense. Others may disagree. There may also be UX or interoperability concerns about which I'm unaware, so it's best if other developers comment on this too.
Created attachment 197208 [details] Multi-line with 1.5x line spacing Screenshot showing lopsided vertically centered text with 1.5x line spacing.
(In reply to Jonathan Clark from comment #5) I would say that if you're ok with top-aligned multi-line placement, then you should support "mirroring" this behavior for bottom-aligned, i.e. start with the line gap at the bottom, then the bottom line, then a line gap, then the next line etc; and for vertical-middle alignment - do the middle between the two, which means half line-gap above and below, then a sequence of (ascender-descender), full line-gap, (ascender-descender) etc. Also - why would you expect a single line not to have a ling gap above it, but the same line to have the line gap just because there's another line beneath? I mean, I know you said it's subjective, but can you try elaborating on the intuition in favor of that? ------------------- Side-comments: > One thing to keep in mind is, if your goal is to make this "look right", a > closed-form solution will never be adequate. What "looks right" is ... > Even if font authors could provide a tuned metric for vertical centering, > it would look just as wrong in many situations as what we currently do. That's a fair point. But a better formula could get us from appearing "way off" to "decent" in a lot more cases. (Plus, we could eventually go as far as a heuristic based on the actual text content, e.g. do something different for all-lowercase text rather than some-uppercase, or with tanween above but not below and vice-versa.) > I confirm that the vertical positioning of top- and middle-anchored text is > based on line height, rather than just font ascent and descent. So, relating back to Regina's comment - it seems that our highlighting also uses the line height rather than the font metrics. > This is > difficult to see with text metrics alone, but can be easily demonstrated by > changing the line spacing in the shape style. ... well, that breaks the highlighting analogy thoug. Perhaps highlighting height is "line height with single spacing" rather than "line height with the currently-defined line spacing".
(In reply to Eyal Rozenberg from comment #7) > (In reply to Jonathan Clark from comment #5) > > I would say that if you're ok with top-aligned multi-line placement, then > you should support "mirroring" this behavior for bottom-aligned, i.e. start > with the line gap at the bottom This seems reasonable to me, although with the caveat that I don't know what this change would break. > Also - why would you expect a single line not to have a ling gap above it, > but the same line to have the line gap just because there's another line > beneath? I mean, I know you said it's subjective, but can you try > elaborating on the intuition in favor of that? It's just gut feel about what I would want for both use cases. If I'm anchoring a single line to the top of a box, I mean for it to be at the top of the box, not for the descent to be a full line height down from the top of the box. However, if I have multiple lines of text, I want them to look balanced (the whitespace between the top of the box and the first ascent should match the whitespace between lines of text). It would be too jarring if the top line suddenly skipped down while a user is typing though, so I don't think we should implement this. If I had to pick one or the other, I would pick what we're currently doing, even though I think it looks wrong for the one-line case.
Created attachment 197215 [details] Comparison for leading-aware vertical alignment Mock-up showing vertical text alignment with and without correct leading handling. The left is a screenshot of the current editeng behavior. The right is the same screenshot, while using a code hack to account for internal and external leading during vertical positioning.