Created attachment 189642 [details] Presentation with boxes demonstrating the bug (examine at different zoom levels) When we v-align the text of an object (say, a shape) to the center - the distance from the baseline to the edge of the bottom margin should be equal to the distance from the cap line (or if you like, the ascender line) to the edge of the top margin. And if the margins are equal, then we should have: |box bottom to baseline| = |cap line to top| the farther we are from an equality, the more it will seem the text is not centered. Of course, this may be affected by the nature of the font itself, e.g. whether it seems that the caps are somehow "too high"; and there will be some difference between the choice of the ascender or the cap etc. - but that's the general rule. The farther we are from this equality, the more the text appear not to be vertically centered. Now, with some fonts, there is a significant difference between the two distances - especially in lower zoom levels. See the attached document, comparing v-centered text in DejaVu Sans vs Liberation Sans: Font to top to bottom ----------------------------------------------------- DejaVu Sans regular 20pt ~0.25 cm ~0.28 cm Liberation Sans regular 20pt ~0.28 cm ~0.27 cm both v-aligned center of course. Regular spacing, no v-spacing after paragraph, default (and identical) bottom and top margin settings. Seen with: Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US but I've noticed this several times over the years. Also saw this with a font named Stencil, and probably several others.
Looks the same in OOo 3.3. Khaled, what's your take on this?
Most likely it is centering the font height, i.e. ascender + descender, and it does not look at the content at all, probably be design. DejaVu Sans has less space above the capitals than below baseline, while Liberation Sans has more or less the same space. If you middle-align in a web browser, you get the same effect, and some fonts are intentionally designed to look vertically centered in such situations https://twitter.com/romanshamin_en/status/1562801657691672576
(In reply to خالد حسني from comment #2) > Most likely it is centering the font height, i.e. ascender + descender 1. I'm not sure that we should think of the font height (w.r.t vertical positioning) as the difference between the ascender and the descender lines, as opposed to baseline to cap line. Of course line spacing should account for those, but not necessarily centering. 2. Are you sure this is the case for these specific fonts? A cursory inspection doesn't seem to agree with that. > and it does not look at the content at all, probably be design. Yes, that's certain. I'm not arguing against this design choice (although that might be an interesting discussion to have). > DejaVu Sans has > less space above the capitals than below baseline, while Liberation Sans has > more or less the same space. But the ascenders are about as high as Liberation Sans... so, > If you middle-align in a web browser, you get the same effect, and some > fonts are intentionally designed to look vertically centered in such > situations https://twitter.com/romanshamin_en/status/1562801657691672576 is ours a case of the font artificially using a larger above-caps space? Also, suppose a font does this intentionally. Why should we respect its desire for extra space, when the user has indicated something different, and the extra space is known not to be necessary?
The ascenders and descenders I’m talking are font settings (number in OS/2 and/or hhea tables) not the actual glyph ascenders and descenders (glyph ascenders and descenders are rarely if ever taking account of for anything as getting them requires measuring the bounding boxes of the glyphs which is both slow and often undesirable as then the measures are dependent on the text content and leads to inconsistencies).
Dear Eyal Rozenberg, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
No change, I believe, with: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d2def868cb3ac5a7e538a911e83d7d907a2ec794 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US