Bug 116459 - Thickness of characters decrease simultaneously when requesting width decrease of the text.
Summary: Thickness of characters decrease simultaneously when requesting width decreas...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.2.1 release
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2018-03-17 18:36 UTC by brstpierre
Modified: 2018-03-19 16:01 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
PDF example of behaviour using Scribus for comparison (38.34 KB, application/pdf)
2018-03-17 18:36 UTC, brstpierre
Details
Screenshot Linux vs. Windows 10, 80% scaled (71.37 KB, image/png)
2018-03-18 13:53 UTC, Buovjaga
Details
Screenshot Linux vs. Windows 10, 50% scaled (65.70 KB, image/png)
2018-03-18 14:00 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description brstpierre 2018-03-17 18:36:52 UTC
Created attachment 140678 [details]
PDF example of behaviour using Scribus for comparison

In Libre Office 5 or 6, (Windows 10 - 64 bits), when I modify the width of some part of a text, using the command " Format ", " character " (width scale in%), it appears that the thickness of characters decrease simultaneously with the width decrease of the text.

In older versions of LibO it was not the case (as far as I can remember)

If I compare the same process operated with Scribus for example, the thickness of the characters is not affected. Example is attached with a sample text on which I apply a contraction of 5 % in Scribus. I would expect to get the same result in LibO.

If I am right, using the version included in Ubuntu 17-10 (32 bits), the thickness of the charactèrs seems to be not affected.
Comment 1 Buovjaga 2018-03-18 13:34:55 UTC
I confirm it, but the Linux result looks worse than Windows in my eyes. The characters blend into each other in an ugly way.

For testers: Format - Character - Position: Scale width.

Comment from Khaled on IRC:
"the directwrite path does not handle asymmetric character scaling, but we should be forcing GDI in this case."

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 070dbae6b4dc497d6ae898e60203d25b0e608d73
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on March 17th 2018

Version: 6.1.0.0.alpha0+ (x64)
Build ID: 3677ca53c60304830285233474466de3272ec183
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-18_01:31:20
Locale: fi-FI (fi_FI); Calc: group
Comment 2 Buovjaga 2018-03-18 13:40:06 UTC
Code pointer from Khaled, if someone wants to dig into this: https://opengrok.libreoffice.org/xref/core/vcl/win/gdi/winlayout.cxx#417
Comment 3 Buovjaga 2018-03-18 13:53:00 UTC
Created attachment 140682 [details]
Screenshot Linux vs. Windows 10, 80% scaled
Comment 4 Buovjaga 2018-03-18 14:00:21 UTC
Created attachment 140683 [details]
Screenshot Linux vs. Windows 10, 50% scaled
Comment 5 ⁨خالد حسني⁩ 2018-03-18 14:13:46 UTC
This is the expected behavior and has always been like that AFAIK (bugs in some versions not withstanding). If you want to change the spacing only, set a “Pair Kerning” value.
Comment 6 brstpierre 2018-03-19 16:01:36 UTC
Thank you for your comments.
I was guided by a previous use of decreasing width percentage to adjust length of part of my text (LibO 3 as far as I can remember)where the things appeared to work as expected.
I will follow the recommandation of Khaled.