105976 – Text width scale doesn't work when not 100% and OpenGL is enabled

Bug 105976 - Text width scale doesn't work when not 100% and OpenGL is enabled

Summary: Text width scale doesn't work when not 100% and OpenGL is enabled

Status:	RESOLVED DUPLICATE of bug 103831

Alias:	None

Product:	LibreOffice
Classification:	Unclassified
Component:	LibreOffice (show other bugs)
Version: (earliest affected)	5.3.0.3 release
Hardware:	x86-64 (AMD64) Windows (All)

Importance:	medium normal
Assignee:	Not Assigned

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:	VCL-OpenGL Regressions-HarfBuzz
	Show dependency tree / graph

Reported:	2017-02-13 10:56 UTC by Alexander Polkhovskiy
Modified:	2017-02-22 22:15 UTC (History)
CC List:	7 users (show)

See Also:	106146
Crash report or crash signature:

Attachments
The example showing the problem (8.06 KB, application/vnd.oasis.opendocument.text) 2017-02-13 11:05 UTC, Alexander Polkhovskiy	Details
Screenshot of a problem (6.55 KB, image/png) 2017-02-14 12:34 UTC, Alexander Polkhovskiy	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 Alexander Polkhovskiy 2017-02-13 10:56:03 UTC

Description:
Wrong symbols positioning when changing text width scale. Appears in all programs.

Steps to Reproduce:
1. Write some text.
2. Select it.
3. RMB - Character... - Scale width - set it to somthing not equal to 100%.
You see the result (even in preview).

Actual Results:  
Symbols become too close.

Expected Results:
Width should change accordingly to scale chosen.


Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 5.3.0.3
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; 
Locale: ru-RU (ru_RU); Calc: group

Windows 8.1 Pro x64
In 5.2.x this problem didn't exist.
Sorry, if I have chosen the wrong Component, change if it's wrong.


User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Maxthon/5.0 Chrome/47.0.2526.73 Safari/537.36

Comment 1 Alexander Polkhovskiy 2017-02-13 11:05:39 UTC

Created attachment 131172 [details]
The example showing the problem

Comment 2 Buovjaga 2017-02-14 12:19:47 UTC

And how does it behave for you, if you disable Tools - Options - LibO - View - Use OpenGL for all rendering?

Please also include a screenshot of the bad rendering.

Comment 3 Alexander Polkhovskiy 2017-02-14 12:34:25 UTC

Created attachment 131204 [details]
Screenshot of a problem

Comment 4 Alexander Polkhovskiy 2017-02-14 12:35:24 UTC

Thank you. Disabling OGL solves the problem.

Comment 5 V Stuart Foote 2017-02-14 13:54:35 UTC

Confirmed. And a good test document. Thanks!

Related if not same issue as bug 103831 so seems the Direct2D/DirectWrite font handling with OpenGL has gone wonky.

On Windows 10 Pro 64-bit en-US w/nVidia GPU (driver 21.21.13.7653) 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

Comment 6 Aron Budea 2017-02-22 17:56:14 UTC Comment hidden (obsolete)

This bug originated from before common rendering, and it's already in 5.2.2.2 (while not in 5.2.0.4).

I managed to bibisect it down to the following range of ~350 commits, but Writer+GL combination keeps crashing for me after that:
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=5b168b3fa568e48e795234dc5fa454bf24c9805e..0d1ce0a79e1ab1193d741df52ededf5933d93115
(I used bibisect-win32-5.3)

This range is not useful in itself, so requesting further bibisect (people with non-AMD GPUs might have a better chance).

Comment 7 Aron Budea 2017-02-22 18:48:52 UTC

Disregard my previous comment, it's a different issue.

Comment 8 ⁨خالد حسني⁩ 2017-02-22 22:08:14 UTC


*** This bug has been marked as a duplicate of bug 103831 ***