Bug 116583 - When using special condensed spacing, underlined text leads to a gap toward the end of the word
Summary: When using special condensed spacing, underlined text leads to a gap toward t...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.6.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency tree / graph
 
Reported: 2018-03-23 10:05 UTC by worldwideweary
Modified: 2023-09-21 05:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Showing the gap in the underline with spacing = 1.0 (3.71 KB, image/png)
2018-03-23 19:41 UTC, worldwideweary 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description worldwideweary 2018-03-23 10:05:40 UTC 
Description:
Is this a known issue? Underlining is gapped when condensed text is utilized (didn't check variations too much, but especially was checked 0.7 condensed)

For instance, on my system, if a style is created with 0.7 condensed text: Character→Position Tab→Spacing→Condensed: 0.7, 
when using underlining with this setting, the result contains corrupted underlines with a horizontal gap toward the end of the word with most fonts.

This is with LibreOffice Writer 5. Would be nice to know if this was fixed in version 6. Sometimes certain fonts work better with special condensation, and having underlining be broken like this with special condensed text settings is unfortunate.

Steps to Reproduce:
1. Type word + Right-Click→Character (or set up a style doing this)
2. Under Position Tab → Spacing → Set Condensed to: 0.7 for example
3. Underline word. 


Actual Results:  
Notice the small gap toward the end of the word(s)

Expected Results:
Underline should be one continuous line as usual, of course.


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 Dieter 2018-03-23 10:33:35 UTC 
I can't reproduce it in Windows

Version: 6.1.0.0.alpha0+ (x64)
Build ID: 9d75bfcfaef97b247b3b6cd346eb27e02ae7b010
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-19_06:25:17
Locale: de-DE (de_DE); Calc: CL

Do you found it also in a newer version than 5.1?
Comment 2 worldwideweary 2018-03-23 10:45:02 UTC 
(In reply to Dieter Praas from comment #1)
> I can't reproduce it in Windows
> 
> Version: 6.1.0.0.alpha0+ (x64)
> Build ID: 9d75bfcfaef97b247b3b6cd346eb27e02ae7b010
> CPU threads: 4; OS: Windows 10.0; UI render: GL; 
> TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-19_06:25:17
> Locale: de-DE (de_DE); Calc: CL
> 
> Do you found it also in a newer version than 5.1?

Haven't tried. I can attest that, although not the same thing, in OpenOffice 4.1.3 I receive the same results with the Times font when doing a switch to 1.0 condensed. It's small but noticeable when zoomed in. It seems to happen when the word is by itself and not for instance the second word in a sentence only underlined, but as with a title centered as one word or a phrase with no non-underlined words in-between. Hrm.
Comment 3 Dieter 2018-03-23 11:03:38 UTC 
Please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 4 worldwideweary 2018-03-23 19:41:48 UTC 
Created attachment 140833 [details]
Showing the gap in the underline with spacing = 1.0

OK. Confirmed. For Windows Version: 6.0.2.1 (x64) with simple phrase 
and (apparently it's just a simple +/- "spacing" function now without the option of default, expanded, condensed) spacing at -1.0 (not -0.1). The resulting underline is still gapped. Attached is a simple image showing this at higher zoom levels.
Comment 5 V Stuart Foote 2018-03-23 20:46:01 UTC 
Confirming, character font effects with negative spacing are showing the extra lines adjacent to paragraph end. But when in line with following words/spaces prior to paragraph end they do not.

It affects the rendeing to canvas of Overlining, Strikethrough, Underlining font efects when spacing is reduced. The effect remains when exported to PDF 

It does not affect strings assembled with combining characters, e.g. U+0332, U+0333, U+0335, U+0305, U+033f

=-testing-=
Windows 10 Ent 64-bit en-US (1709)
Version: 6.0.2.1 (x64)
Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
Locale: en-US (en_US); Calc: group
Comment 6 QA Administrators 2019-03-24 04:09:26 UTC Comment hidden (obsolete)
Comment 7 worldwideweary 2019-03-24 07:00:59 UTC 
This bug still persists. (C'mon: Go Team)

Version: 6.1.5.2 (x64)
Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU threads: 8; OS: Windows 6.1; UI render: default; 
Locale: en-US (en_US); Calc: CL
Comment 8 BogdanB 2023-08-18 16:50:46 UTC 
Aslo in
Version: 7.5.5.2 (X86_64) / LibreOffice Community
Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e
CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 9 BogdanB 2023-09-21 05:49:20 UTC 
Also in 24.2 with Character spacing -0.7
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a34dcd03254480927c403d904c0e754802d97b90
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded