Bug 103831 - Horizontal text scaling doesn't work correctly when OpenGL is enabled on Windows
Summary: Horizontal text scaling doesn't work correctly when OpenGL is enabled on Windows
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All Windows (All)
: high major
Assignee: Khaled Hosny (inactive)
URL:
Whiteboard: target:5.4.0 target:5.3.2
Keywords: regression
: 104796 104939 105709 105741 105768 105976 106279 106319 106452 106528 106550 (view as bug list)
Depends on:
Blocks: Font-Rendering VCL-OpenGL HarfBuzz-regressions
  Show dependency treegraph
 
Reported: 2016-11-10 14:41 UTC by Volga
Modified: 2017-09-30 00:17 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot from LODev Writer (21.19 KB, image/png)
2016-11-10 14:43 UTC, Volga
Details
sampler - character preview (70.95 KB, application/pdf)
2016-11-10 16:59 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volga 2016-11-10 14:41:18 UTC
Description:
When I use LODev Writer, open Character dialog, I found sample text always overlap each other.

Steps to Reproduce:
1. Open LibreOfficeDev Writer
2. Format > Character 

Actual Results:  
See my attchment

Expected Results:
-


Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 5.3.0.0.alpha1+
Build ID: 05d2a66955f8a6552a79696474386ca9f45f9ef2
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-07_23:34:48
Locale: zh-CN (zh_CN); Calc: group


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Comment 1 Volga 2016-11-10 14:43:46 UTC
Created attachment 128645 [details]
Screenshot from LODev Writer
Comment 2 Khaled Hosny (inactive) 2016-11-10 16:11:26 UTC
Can you test with the old layout engine, and/or 5.2?
Comment 3 V Stuart Foote 2016-11-10 16:59:13 UTC
Created attachment 128646 [details]
sampler - character preview

sampler of the Character dialog previews by renderer and layout engine...

Version: 5.3.0.0.alpha1+
Build ID: f6391d9696bfa7485bf785ac81edef4d5441e232
CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-10_00:11:47
Locale: en-US (en_US); Calc: CL

the sample text, or selection, is generated in the
SvxFontPrevWindow
http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#621

Confirming things degrade a fair bit with the HarfBuzz layout.
Comment 4 V Stuart Foote 2016-11-10 18:56:53 UTC
Seems we directly scale the selection or sample text to compose the preview for rendering in the dialog

http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#98
http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#706

So is this another DirectWrite scalling issue, or something in the way the dialog is being composed misbehaving with HarfBuzz layout? And then there is bug 57672 for combining forms that has long had an issue with the preview.

@Tomaž, Chris?
Comment 5 Khaled Hosny (inactive) 2016-11-10 19:49:37 UTC
(In reply to V Stuart Foote from comment #4)
> Seems we directly scale the selection or sample text to compose the preview
> for rendering in the dialog
> 
> http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#98
> http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#706

Oh, that is just broken! Setting font width means “scale the text horizontally by the font width / font height” not ”set text to fit in this width”. I blame the odd choice for naming, it should have been X scale and Y scale not width and height.

> So is this another DirectWrite scalling issue, or something in the way the
> dialog is being composed misbehaving with HarfBuzz layout? And then there is
> bug 57672 for combining forms that has long had an issue with the preview.

so this is another duplicate of bug 103725, though I think the right fix here is to not set font width at all.
Comment 6 Khaled Hosny (inactive) 2016-11-10 20:20:49 UTC
(In reply to Khaled Hosny from comment #5)
> (In reply to V Stuart Foote from comment #4)
> > Seems we directly scale the selection or sample text to compose the preview
> > for rendering in the dialog
> > 
> > http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#98
> > http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#706
> 
> Oh, that is just broken! Setting font width means “scale the text
> horizontally by the font width / font height” not ”set text to fit in this
> width”. I blame the odd choice for naming, it should have been X scale and Y
> scale not width and height.

Reading the code above again, I’m not sure it does what I thought it is doing.
Comment 7 Khaled Hosny (inactive) 2016-11-10 21:45:35 UTC
Font scaling issue.

*** This bug has been marked as a duplicate of bug 103725 ***
Comment 8 V Stuart Foote 2017-01-28 21:20:21 UTC
@Khaled, reopening this rather than bug 103725

On windows 10 Pro 64-bit en-US with recent master or with
Version: 5.3.0.3 (x64)
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

With OpenGL rendering enabled, the font name preview or a selection of text for preview in the Character dialog is again being compressed.

Preview appears reasonable with default GDI based rendering.

STR

1. new Writer document with OpenGL rendering enabled
2. enter sample text "Some sample text for preview"
3. select text
4. context menu -> Character dialog

expected -- preview should be formatted as on document canvas

actual -- preview is compressed horizontally

5. disable OpenGL (Tools -> Options -> View) and restart
6. repeat 1 - 4

actual -- preview is formatted as on document canvas

So this handling for the dialog preview seems correct with HarfBuzz for GDI, but not with DirectWrite--while rendering to document canvas seems unaffected.
Comment 9 V Stuart Foote 2017-01-29 14:29:43 UTC
*** Bug 104939 has been marked as a duplicate of this bug. ***
Comment 10 V Stuart Foote 2017-01-29 14:35:27 UTC
Just with OpenGL rendering enabled.

Initially during HarfBuzz implementation this affected both default GDI and OpenGL based rendering. Now (at 5.3.0.3) correct with default GDI handling, but OpenGL rendering of the character preview remains compressed.
Comment 11 V Stuart Foote 2017-02-05 18:49:17 UTC
*** Bug 105741 has been marked as a duplicate of this bug. ***
Comment 12 V Stuart Foote 2017-02-05 18:56:13 UTC
The incorrect glyph spacing with OpenGL rendering is also affecting preview/sample text on Impress master slides-- bug 105741 and bug 105768
Comment 13 Telesto 2017-02-05 20:59:38 UTC
*** Bug 104796 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2017-02-14 14:06:49 UTC
bug 105976 -- Text width scale doesn't work when not 100% and OpenGL is enabled, suggests the issue here is not with the Character style dialog but in mishandling of Direct2Write/DirectWrite font scaling applied to the sample text or selection composed in the dialog when OpenGL is enabled.

Default GDI+ based rendering handles font sample/selection correctly.
Comment 15 Khaled Hosny (inactive) 2017-02-22 22:08:14 UTC
*** Bug 105976 has been marked as a duplicate of this bug. ***
Comment 16 V Stuart Foote 2017-02-28 21:32:59 UTC
*** Bug 105768 has been marked as a duplicate of this bug. ***
Comment 17 V Stuart Foote 2017-02-28 21:35:56 UTC
*** Bug 105709 has been marked as a duplicate of this bug. ***
Comment 18 Paulus Kieviet 2017-03-01 05:00:21 UTC
Additional information: this happens in Impress 5.3.0.3 in any text box, as long as a text box is not completely filled. When the box is full and Impress starts to rescale the text, character spacing is correct.
Comment 19 Khaled Hosny (inactive) 2017-03-03 03:12:37 UTC
*** Bug 106279 has been marked as a duplicate of this bug. ***
Comment 20 Commit Notification 2017-03-03 13:24:55 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a51b7a1c3a7e7cf7b0c733e1dec40288278c1884

tdf#103831, tdf#100986: Force using GDI when needed

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 V Stuart Foote 2017-03-04 15:59:35 UTC
*** Bug 106319 has been marked as a duplicate of this bug. ***
Comment 22 Commit Notification 2017-03-07 16:09:25 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4375eefb644d03ab4bafbc091436166a8494dc91&h=libreoffice-5-3

tdf#103831, tdf#100986: Force using GDI when needed

It will be available in 5.3.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 23 mondfabrik 2017-03-08 20:59:38 UTC
Version 5.3.2 dev solves the problem for me.

version info:
Version: 5.3.2.0.0+
Build ID: a990b46ccc788db45ff4d8f0d47b799782ecb2af
CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-3, Time: 2017-03-08_19:18:26
Locale: fr-FR (fr_FR); Calc: group
Comment 24 V Stuart Foote 2017-03-09 13:37:51 UTC
*** Bug 106452 has been marked as a duplicate of this bug. ***
Comment 25 V Stuart Foote 2017-03-14 21:13:08 UTC
*** Bug 106528 has been marked as a duplicate of this bug. ***
Comment 26 Aron Budea 2017-03-17 05:07:15 UTC
*** Bug 106550 has been marked as a duplicate of this bug. ***