Created attachment 187957 [details] Baseline mismatch between lines in different fonts Suppose I use two different fonts in table cells on the same line. For example: My table has one column with a name in a regular serif font and the other has email addresses set in a monospace fonts. It turns out, that in this case, the baselines for the (first line of the) text in the same table row will be different. And this can't be fixed even by playing with the vertical alignment. See attachment for an example. I believe this is a problem, although not necessarily a bug per se.
I don't see an issue. Resize the row so the vertical alignment has some impact and you see vtop, vbottom, vcenter drawing the text at the respective positions.
Created attachment 187979 [details] Screenshot of attachment 187957 [details]
(In reply to Heiko Tietze from comment #1) > I don't see an issue. Resize the row The baselines should be aligned even if I don't resize the row. I'd say with the default vertical alignment, but at the very least there should be some vertical alignment in which the baselines align. It's not as the I've done something special with the table which could legitimately cause misalignment. I should not need to change the size to get alignment.
(In reply to Eyal Rozenberg from comment #3) > The baselines should be aligned even if I don't resize the row. Could you please share a screenshot of your expectation?
Khaled, do you have an opinion on this?
(In reply to Heiko Tietze from comment #4) > Could you please share a screenshot of your expectation? I can't quite do that; let me explain. I expect the baseline of the text in both cells to be the same. In my sample document, I marked the right cell (Liberation Serif)'s baseline; either the left cell should have the right's baseline; or the right get the left's; or they should both have something in the middle. Personally I think the right cell's baseline is more appropriate: The left cell text has a much higher effective bottom margin than effective top margin. But that's just an aesthetic observation, there might be other considerations. So I don't have a specific expectation to put in a screenshot.
(In reply to Stéphane Guillou (stragu) from comment #5) > Khaled, do you have an opinion on this? It depends on what the expectation is. It seems the current behavior aligns the ascenders and descenders not the base lines. It probably makes sense, for top alignment you need to aligns the top of the lines so that is the ascender, for bottom alignment it is descender and for middles align it is line height (ascender + descender). If one sets highlight color, it will be clear that the line boxes are aligned. I don’t see how baseline alignment can fit any of these three modes. Perhaps what is requested here is a baseline alignment mode.
(In reply to خالد حسني from comment #7) > It depends on what the expectation is. It seems the current behavior aligns > the ascenders and descenders not the base lines. I guessing you mean either ascenders or descenders? > It probably makes sense, > for top alignment you need to aligns the top of the lines so that is the > ascender, for bottom alignment it is descender and for middles align it is > line height (ascender + descender). I'm not sure that aligning ascenders or descenders makes sense. Suppose we have two fonts F1 and F2 which are identical, except that F1 has really long ascenders - just extended upwards for l, and b, and d etc. We now write: ------------- | abcd | abcd | ------------- with the left cell being set in F1 and the right in F2; so I'll replace d with an l-over-a-d . Now, let's what would the user expect? ------------- | l | | | abcd | abcd | ------------- ------------- | l | abcd | | abcd | | ------------- I claim that even with _top_ alignment - the user would expect the first option. Why? Because the _mean_lines_ [1] are aligned - the top of the main part of the glyphs. Ascenders are extra; somewhat ornamental. It's the "meat" of the text that needs to be aligned. So, I guess after would expect that: top v-alignment -> alignment of meanlines bottom v-alignment -> alignment of baselines middle v-alignment -> alignment of middle-point between baseline and meanline What is the basis, in principle or historically, to act otherwise? > If one sets highlight color, it will be > clear that the line boxes are aligned. Well, they are, but that's like saying the table cells are aligned. Alignment of cells and boxes doesn't matter much if it does translate into alignment of the text within those boxes. [1] : https://en.wikipedia.org/wiki/Mean_line
(In reply to Eyal Rozenberg from comment #8) > ------------- > | l | | > | abcd | abcd | > ------------- > > ------------- > | l | abcd | > | abcd | | > ------------- > > I claim that even with _top_ alignment - the user would expect the first > option. Why? Because the _mean_lines_ [1] are aligned - the top of the main > part of the glyphs. Ascenders are extra; somewhat ornamental. It's the > "meat" of the text that needs to be aligned. In your first option the text is bottom aligned not top aligned. It is easy to test what users expect by checking multi-line cells, where the expectation is definitely that the top of the lines is aligned with top alignment and the bottoms with bottom alignment.
(In reply to خالد حسني from comment #9) > In your first option the text is bottom aligned not top aligned. Ah, but it is top-aligned! The mean-lines of the text on both cells are aligned, at their highest possible position.
(In reply to Eyal Rozenberg from comment #10) > Ah, but it is top-aligned! The mean-lines of the text on both cells are > aligned, at their highest possible position. I'll illustrate with a slightly v-longer row: ------------- | l | | | abcd | abcd | | | | | | | | | | | | | ------------- ------------- | l | abcd | | abcd | | | | | | | | | | | | | | ------------- both of these are valigned to the top, but the first example has the meanlines aligned, while the second example has the extenders aligned (it also happens to have the baselines aligned but that's because it's hard to draw it differently with ASCII art)
Created attachment 187999 [details] Baseline, meanline and v-alignment - with long and short ascenders Khaled, please have a look at this attachment (or the screenshot to follow soon). I think what's being aligned is not the ascenders; it looks more like the mean line.
Created attachment 188001 [details] Screenshot of attachment 187999 [details]
Created attachment 188002 [details] Screenshot of behavior in MS Word 16 The behavior in MS Word 16 is similar to our current behavior, apparently.
I don’t really have anything more to added. This is a feature request since the current behavior is working as intended.
(In reply to خالد حسني from comment #15) > I don’t really have anything more to added. This is a feature request since > the current behavior is working as intended. But if the intention is wrong, then it's a bug.
(In reply to خالد حسني from comment #15) > I don’t really have anything more to added. This is a feature request since > the current behavior is working as intended. What about the question regarding what's being aligned? Top-of-ascenders or mean line? Or something else? Also, if the original intention was mis-determined, then it's a design bug rather than an implementation bug...
(In reply to Eyal Rozenberg from comment #17) > What about the question regarding what's being aligned? Top-of-ascenders or > mean line? Or something else? > > Also, if the original intention was mis-determined, then it's a design bug > rather than an implementation bug... IIUC we have never made direct use of the 0 base within a font. Rather, we take the font's total height --between ascent top and descent bottom (font designers choice with M hight plus any *internal* leading above or below) and that height is what is alligned TOP, CENTER or BOTTOM. Meaning that any two fonts with different metrics will ALWAYS allign differently--there is no common base line extracted from font(s). Try it with an exaggerated font like Styx Two. Short of a rewrite of VCL font handling, don't see a bug here, it is doing what is expected. While enhancement to actually align on the 0 base would be at odds with what other word processors do, don't see much demand there.
Duplicate in bug 118035 "Text-to-text alignment doesn't work in Textbox" and some confusion in bug 154145 "Vertical or Horizontal Alignment in Calc being set to default, but it's not clear what it does". Resolved is bug 96125 "FORMATTING: Writer paragraph text-to-text alignment doesn't work".
Created attachment 188010 [details] Screenshot: behavior of LO (left) vs. MSO (right) LibreOffice (left) vs. MSO365 (right; document exported as docx) Font size 18, larger O is 28. I assume Eyal asks for something like MSO does (and not to align the bounding box). If we change this it has an impact on legacy documents.
> LibreOffice (left) vs. MSO365 (right; document exported as docx) So the understand the difference correctly, LibreOffice adjusts the baseline for each letter if needed, whereas MSOffice calculates a baseline shared by all letters in a line.
(In reply to V Stuart Foote from comment #18) > IIUC we have never made direct use of the 0 base within a font. Rather, we > take the font's total height --between ascent top and descent bottom (font > designers choice with M height plus any *internal* leading above or below) > and that height is what is aligned TOP, CENTER or BOTTOM. I don't quite understand what this means. Vertical alignment of 2D objects means choosing some horizontal line relative to each of them, and moving the objects so that those lines identify, and some other constraint is satisfied (with different constraints for top, center and bottom). But how can you "align height"? If you mean setting the top of the fonts including ascenders to be the top of the respective table cells - that's not what happens. Also, when text laid out in a paragraph, alignment is on the baseline. > Try it with an exaggerated font like Styx Two. Do you mean Stix Two? https://www.stixfonts.org > Short of a rewrite of VCL font handling, don't see a bug here, it is doing > what is expected. You're conflating the difficulty of addressing the issue with the question of whether there's an issue. It could be, that addressing this would require tremendous efforts, in which case this will have very low priority. But that is irrelevant to the question what the correct behavior _should_ be. > While enhancement to actually align on the 0 base would be at odds with what > other word processors do, don't see much demand there. 1. Consistency between the rendering of text in consecutive table cells vs consecutively on a line. 2. The use of tables as a mechanism of controlling 2D text placement, as opposed to having to manually manipulate multiple boxes/frames. For the table to be usable, we need finer control over alignment within it - and reasonable defaults which don't look garish.
(In reply to Heiko Tietze from comment #20) > Created attachment 188010 [details] > Screenshot: behavior of LO (left) vs. MSO (right) Wow, I didn't even notice our the behavior with different fonts in the same table cell. > > Font size 18, larger O is 28. I assume Eyal asks for something like MSO does > (and not to align the bounding box). Actually, no, that's not what I'm asking for. I mean, I am asking that all of the letters in the same cell be aligned at the baselines, for sure; but I'm also asking that, for each row, the baselines in both cells of the row to be the same; and MSO does not equate them. > If we change this it has an impact on legacy documents. Yes, that's true. But - let's put this consideration aside, i.e. suppose that either we decide our rendering was buggy before, or alternatively, we adopt the new behavior along with some indicator in the ODF which older documents wont have. I would like us to figure out / decide what is the _appropriate_ behavior: What is best for our users to get (and perhaps whether there is more than one valid expectation, in which case perhaps we need some kind of configurable choice). After deciding that in the abstract, let's talk about feasibility, necessary effort, backwards compatibility concerns etc.
(In reply to Heiko Tietze from comment #20) > Created attachment 188010 [details] > Screenshot: behavior of LO (left) vs. MSO (right) > > LibreOffice (left) vs. MSO365 (right; document exported as docx) Mixed font sizes on the same cell not sharing the same baseline looks like a bug to me, and deserves its own issue. Can you share the ODT/DOCX document? I’m trying to replicate the (left) behavior, but I’m getting the (right) one.
Created attachment 188034 [details] Goofy example (In reply to خالد حسني from comment #24) > ...looks like a bug to me, and deserves its own issue. > Can you share the ODT/DOCX document? Table with various vertical alignments. Tried to mark the deviation from the expected result; Eyal had probably the first in mind where Mono is not exactly at the baseline but since all other have more or less serious issues I could imagine it's caused by the same code. Interestingly MSO does not much better and I wonder how the same table looks with Latex or Scribus.
The table is probably not relevant since Serif/Mono are well aligned at the baseline but not for other options, in particular with mixed font sizes.
I think there is some confusing here. Heiko’s file is using paragraph alignment, and it looks odd but understandable. The issue here is about cell alignment.
I don't have a great deal of knowledge in this area, however, wouldn't it make sense to have a common baseline within the cell like in this Wikipedia article: https://en.wikipedia.org/wiki/Ascender_(typography) In my mind, it looks very messy when we have different fonts that are not in alignment. I would tend to agree with Eyal's assessment of the next steps. Cheers everyone
(In reply to خالد حسني from comment #27) > I think there is some confusing here. Heiko’s file is using paragraph > alignment, and it looks odd but understandable. The issue here is about cell > alignment. So, yes, I did open this bug about text that has "Automatic" (which effectively means "Baseline") paragraph valignment. In fact, even the cell valignment was not that much of a focus - my interest was in the simple case of the user not having touched any valignment settings. In that case, valignment is top, and I only mentioned other valignments to emphasize how changes them doesn't help avoiding the problem. That being said, there is room to question the alignment behavior of paragraph valignment. Question is, do we want to make this into the "mother of all valignment bugs" and discuss everything here, or split off multiple more specific bugs. I'm kind of leaning towards staying with a single bug first until some kind of general policy is decided on regarding how valignment should behave, and then possibly splitting of others. And speaking of policy, I think we need to focus more on what we _expect_ to happen in various cases rather than what is actually happening. Perhaps we could use a TDF wiki page with screenshots and attachments? Perhaps we should have a chat session / Design meeting about this? Perhaps both?
Duplicate of bug 68573
(In reply to Heiko Tietze from comment #30) > Duplicate of bug 68573 I don't see how this is even related to 68573.