Created attachment 125491 [details] Picture of the bug. Reproduction: 1. Install Droid Sans as font (https://www.google.com/fonts/specimen/Droid+Sans) 2. Write at least two words and underline them 3. Put this symbol: ● between them 4. Underline this symbol so everything is underlined You will see that the underline is too long. Why is that and how can we repair this?
Created attachment 125495 [details] sample document showing miscalculated underlines when fallback glyphs are present On Windows 10 Pro 64-bit en-US with Version: 5.1.3.2 (x64) Build ID: 644e4637d1d8544fd9f56425bd6cec110e49301b CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Locale: en-US (en_US) also on Version: 5.3.0.0.alpha0+ (x64) Build ID: b2abb97a6545096d6952430f7ff37cadb1a23707 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-06-04_00:22:16 Locale: en-US (en_US) Confirmed. However it is not confined to Droid Sans. Rather it occurs with any fontface that does not include a glyph for codepoint U+25cf and so fallback font substitution for the glyph occurs. When underlined only fallback glyphs have issues with the length calculated incorrectly. It seems to be linked to the number of characters in the underline that preceed the glyph. Of LO bundled fonts, for simple demonstration Caladea does not cover U+25cf, while Carlito does. Gentium fonts also do not. But occurs when underlining any glyph with or without OpenGL rendering enabled. STR OpenWriter Select Carlito font enter "ab" and select underline position cursor between a & b type "U+25cf" position cursor after the f, and convert to glyph with <alt>+x underline should be correct, ending at Pilcrow if displayed. Repeat Select Caldea font (or any font without coverage of the glyph). enter "ab" and select underline position cursor between a & b type "U+25cf" position cursor after the f, and convert to glyph with <alt>+x underline should be correct? Result: underline extends beyond selected characters. It occurs when the glyph is not covered and must be substituted, and for those glyphs an underline is miscalculated and underlining extends past the selected text. The length as miscalculated is affected by the number of characters underlined that precede the fallback glyph. Test document attached.
Created attachment 125496 [details] sample impress document showing miscalculated underline affect in text boxes Underline miscalculation likely does affect all modules. Here in Impress for example.
Apparently nothing new, priority back to medium normal. Issue inherited from OOo, present in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 If anyone would like to check Linux or OS X please feel free and adjust OS if appropriate.
@Chris, Hey, you still with us? Hadn't seen a lot from you since February. Hope all is well. Anyhow, if you've a moment, from while you were cleaning things up implementing consistent FontLineStyle naming in https://gerrit.libreoffice.org/#/c/21892/ any thoughts on what might be going wrong with applying underlining (or overlining or strikethrough) to a string selection that contains fall back font, as in the examples? Something is handled wrong in calculating length of underling/overlining/strikethrough markings, but nothing new as seems its been like this forever. Stuart
Not sure, but seems that with HarfBuzz we get better layout for the underlining when a fallback font glyph is used. This needs another look.
Version: 5.3.0.2 (x64) Build ID: 5ad7b2889021c491af62f7930a4b1cb631392f16 CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; Layout Engine: new; Locale: en-US (en_US); Calc: group Resolved WFM, the new HarfBuzz based layout seems to have cleared this nicely.