Bug Hunting Session
Bug 112385 - Right most character in string with Arial font being clipped with OpenGL rendering
Summary: Right most character in string with Arial font being clipped with OpenGL rend...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.4
Keywords:
Depends on:
Blocks: VCL-OpenGL DirectWrite
  Show dependency treegraph
 
Reported: 2017-09-14 10:35 UTC by Willim
Modified: 2018-10-30 18:54 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Samples of issue (313.40 KB, application/x-zip-compressed)
2017-09-14 10:40 UTC, Willim
Details
Calc & Writer test 20170915 (555.96 KB, application/x-zip-compressed)
2017-09-15 02:52 UTC, Willim
Details
Screen Resolution and Requested Info (439.74 KB, application/x-zip-compressed)
2017-09-15 05:36 UTC, Willim
Details
Calc & Writer test 20170915 _03 (251.83 KB, application/x-zip-compressed)
2017-09-15 13:16 UTC, Willim
Details
series of 400% magnified clips of a Writer canvas table (89.07 KB, application/pdf)
2017-09-16 01:26 UTC, V Stuart Foote
Details
Requested Information + Tests with other Fonts (1.16 MB, application/x-zip-compressed)
2017-09-16 02:43 UTC, Willim
Details
debug log with opengl INFO and WARN level events for a TB39 build (744.99 KB, application/x-zip-compressed)
2017-09-16 16:34 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Willim 2017-09-14 10:35:16 UTC
Description:
Libre Office Calc and Writer do NO display characters properly when using athe Arial font.
1's can appear as "ticks" other characters are chopped on their right hand edges.

Windows 10 15063.608 

Steps to Reproduce:
1. Open a Writer Document
2. Set Font to Arial type 1<NL>, 1<NL> repeatedly i.e a single one, 1, each line
3. Zoom to 66%

Similar issue at 172%

Actual Results:  
See above 

Expected Results:
One's do not display properly


Reproducible: Always

User Profile Reset: No

Additional Info:
I had no such problems on AOO using Arial font

Major  ... as if 11 is typed the tens looks normal and the unit is faint

Other numbers appear chopped at right hand edges

I hope to attach screen snips


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Comment 1 Willim 2017-09-14 10:40:02 UTC
Created attachment 136237 [details]
Samples of issue

Attachments show issue
Comment 2 V Stuart Foote 2017-09-14 18:23:05 UTC
Can not reproduce on Windows 10 Ent 64-bit en-US with 
Version: 5.4.1.2 (x64)
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 8; OS: Windows 6.19; UI render: default; 
Locale: en-US (en_US); Calc: group

With default HA or CPU rendering, or with OpenGL rendering, Arial font(s) are all rendered correctly in both Writer and Calc, no clipping as you show.

Have you rebooted since doing the installation?
Comment 3 Willim 2017-09-15 02:49:52 UTC
My Desktop PC is switched off each night and I restart it to "clear the memory" at other times during a day.

ApacheOpenOffice was not good at "releasing" memory after large sorts 370_000 lines. LibreOffice is quite good at sorting and "releasing" the memory according to "Task Manager" > Processes.

I have created two files today, Calc and Writer documents. In the Writer document the date and time stamps are in the header. In the Calc document in the first and last rows.

On my PC it is only at zoom ratio 66% that LibreOffice is particularly bad, to the point of being useless when using the Arial Font. Using Font size 12 LibreOffice does not display "ending "1"'s properly. At other zoom ratios there are issues e.g. the single "6" at 100" zoom ratio.

At Zoom Ratio 66%
Font size 14 "1"'s appear faint compared to other numbers 
Font size 10.5 Right hand side of characters are cut - "0"'s appear as "C"'s

I have re-loaded ApacheOpenOffice. As can be seen do I NOT experience the Arial font issue I have with LibreOffice.

I use a 27" diagonal Acer Monitor

The Arial Font Issue affects all my previously created documents.

000_Files_01.txt lists the .zip file contents
Comment 4 Willim 2017-09-15 02:52:25 UTC
Created attachment 136253 [details]
Calc & Writer test 20170915

Today's tests for Calc & Writer attached.
Comment 5 Willim 2017-09-15 02:54:16 UTC
I reboot at least on daily basis
Comment 6 V Stuart Foote 2017-09-15 04:00:44 UTC
We need to know the GPU and drivers in use and the rendering mode you are running LibreOffice in, i.e. with OpenGL, with default rendering with Hardware Acceleration, or with CPU only rendering (from the Tools -> Options -> View panel).

Also could you please post result of the Help -> About dialog, and also a run of msinfo32.exe, just clip the Summary panel and the Display panel.
Comment 7 Willim 2017-09-15 05:36:22 UTC
Created attachment 136256 [details]
Screen Resolution and Requested Info

Hi Stuart,

Seems to be "a screen resolution" issue

Used same test files as last submission

I checked on HP x360 Notebook screen res 1366*768 and "OK"

Set PC to 1366*768 & "OK"
Set PC to 1680*1050 ... issue
Set PC to 1920*1080 ... issue

As noted Arial, Font size 12, zoom ratio 66%  and above screen resolutions

Good luck :-)
Comment 8 V Stuart Foote 2017-09-15 06:41:06 UTC
(In reply to Willim from comment #7)
> Created attachment 136256 [details]
> Screen Resolution and Requested Info

Thank you. Had a look, but still need details from the Components -> Display panel of a msinfo32 run for the affected system.  That will provide the GPU and driver details.

Also, since this appears to be affecting you with OpenGL rendering, what affect does disabling OpenGL have? Done from Tools -> Options -> View, uncheck the "Use OpenGL for all rendering", OK out and relaunch LibreOffice.
Comment 9 Willim 2017-09-15 13:16:02 UTC
Created attachment 136264 [details]
Calc & Writer test 20170915 _03

Hi Stuart,

Turning off Open-GL "fixes the issue"

AOO don't have Open GL option

From an outsiders point of view (dangerous thinking retired man)

For Open GL to work:-
 character spacing = 100 and
 "change" character width =, say, 90%. (Just an old man's idea :-)

This would "explain" the disappearing "1"'s and vertical edges on "6"'s and "0"'s. The white space around the characters is overwriting adjacent characters. 

Thank you
Comment 10 V Stuart Foote 2017-09-15 15:33:00 UTC
(In reply to Willim from comment #9)
Looking at the msinfo32 Display panel you posted (thank you BTW), with current Intel driver (15.40.34.4624/20.19.15.4624) the Intel HD Graphics 4400 iGPU of your Haswell (2013) i3-4160 CPU should be well supported on Windows 10. You might update to the latest Intel driver (15.40.36.4703)[1], but would not expect that to fix this isolated OpenGL DirctWrite rendering issue. 

> From an outsiders point of view (dangerous thinking retired man)
> 
> For Open GL to work:-
>  character spacing = 100 and
>  "change" character width =, say, 90%. (Just an old man's idea :-)
> 
> This would "explain" the disappearing "1"'s and vertical edges on "6"'s and
> "0"'s. The white space around the characters is overwriting adjacent
> characters. 

No, OpenGL rendering and default HA or CPU rendering all "read" the font metrics for each font, and "stamp" glyphs using those metrics. Believe it is the stamping of the glyphs to canvas that differ between OpenGL and default rendering.

Myself I have not see this "clipping" of a specific font, usually the whole GUI would be affected dependent on OpenGL driver support for particular GPU. I can not reproduce this effect on Arial font with Intel HD Graphics 620 GPU with same Intel OpenGL driver.

You might use an external utility (BablePad, or MainType, etc.) just to verify your version of the Arial font is the Windows 10 correct MonoType v6.90 (Arial regular, 2015, w/3127 characters).

As it does toggle correct when disabling OpenGL setting to new. Though it would be helpful if we had a few others reproducing.

@Tomaž, Khaled, Tor--thoughts on OpenGL mishandling a font metric then clearing up with default rendering? Anything specific the OP could provide that would help diagnose?


=-ref-=
[1] https://downloadcenter.intel.com/download/26984/Graphics-Intel-Graphics-Driver-for-Windows-15-40-
Comment 11 Luis 2017-09-15 22:52:47 UTC
I can reproduce this issue in Windows 8.1
Using zoom level between 66 and 71 or using Arial with font size of 8 and zoom to 100%.
To me seems like bug 111882.

Version: 6.0.0.0.alpha0+
Build ID: fdc85f759c4ef69f4ccdb7f160ad4bce7e61b231
CPU threads: 2; OS: Windows 6.29; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-09-10_01:50:28
Locale: es-ES (es_ES); Calc: CL
Comment 12 V Stuart Foote 2017-09-16 01:26:59 UTC
Created attachment 136276 [details]
series of 400% magnified clips of a Writer canvas table

So, confirming on Windows 10 Ent 64-bit en-US with nVidia GPU and
Version: 5.4.1.2 (x64)
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
Locale: en-US (en_US); Calc: group

Attaching a PDF of a series of Windows screen Magnifier clips of a Writer table with "11" entered in its cells on a 1920x1200 resolution monitor.

Clips start with Writer document canvas zoomed to 200%, and decrease down to a 90% zoom. At each zoom step the rendering of the canvas noticeably changes at the right edge of the entry, but the "one rendered as a tic" issue clearly shows at the 100% zoom. Below 90% the rendering to canvas is too small to have any differences.

Default HA or CPU only rendering does not mangle the right most character and both are shaped the same.

Demonstrates that the OpenGL rendering is not setting the same bounding box as used for default rendering uses.
Comment 13 V Stuart Foote 2017-09-16 01:46:14 UTC
Test document was a simple 3 row 4 column table with "11" entered in each cell with Default paragraph and a font selection of Arial at 8pt.
Comment 14 Willim 2017-09-16 02:43:05 UTC
Created attachment 136278 [details]
Requested Information + Tests with other Fonts

Hi Stuart,

2_LO_* Information requested
3_LO_* Test of "range" "tics" instead of 1's 66-72

4_LO_* Arial "tics"  Arial Black 1's - NO "tics"

This led me to checking my other fonts.

6_LO_* Most Fonts on system "looked" at, these appeared to have "glitches"

Of particular interest perhaps? :-

 Arial       - Arial Black
   x             OK
 Source Code - Source Code B
   OK           "topped"

Perhaps a "Font design" issue i.e. not consistent? 

PC was "reset" 15-Sep-2017 i.e. Windows 10 Pro (15063.608 as of today) & all software re-installed.  

I'll have a look at your tests 136276 however I doubt if I can add much more unless farther information required.
Comment 15 Willim 2017-09-16 04:01:37 UTC
Hi

Comment 11 by Luis same range of zoom ratio 66 - 71


On HP x 360 Win 10 Home (105063.608)
Intel Celeron N2830 2.16GHz

Intel HD Graphics
Driver Version 10.18.10.4358
INF File oem2.inf (iVLV2M_w10 section)

Same Arial Fonts as Desktop

Using Open GL:-

Down to Arial Font Size 6 Zoom Ratio 66 No Issues (need magnifying glass to see) 

Source Code Pro Black Font Size 18 Zoom Ratio 66 OK
Source Code Pro Black Font Size 16 or less Zoom Ratio 66 - "1's topped"

Source Code Pro Black Font Size 12 Zoom Ratio 100 OK
Source Code Pro Black Font Size 11 or less Zoom Ratio 100 - "1's topped"

Source Code Pro Black Font Size 9 Zoom Ratio 133 OK
Source Code Pro Black Font Size 8 or less Zoom Ratio 133 - "1's topped"

Source Code Pro Black Font Size 8 Zoom Ratio 150 OK
Source Code Pro Black Font Size 7 or less Zoom Ratio 150 - "1's topped"

Source Code Pro Black Font Size 7 Zoom Ratio 166 OK
Source Code Pro Black Font Size 6 Zoom Ratio 166 - "1's topped"

See 6_LO_SCPB066_12_52.PNG in attachment of 2017-09-16 02:43 for a example of Source Code Pro Black "topped" - the top of a 1 appears cut from top left to bottom right.
Comment 16 V Stuart Foote 2017-09-16 06:12:48 UTC
Rendering changes as the document canvas is zoomed larger or smaller are expected, everything is resampled to scale the document canvas inside the application frame.
 
Unless there are specific OTF/Graphite font attributes in use, or some pair kerning, characters on the ends should render the same as characters in the middle of a string.

So the OpenGL rendering issues here seem more about the lack of space given to render a glyph at the start or the end of a text object--and clipping occurs. That is an implementation issue in OpenGL text rendering.
Comment 17 Willim 2017-09-16 08:31:25 UTC
Hi Stuart,

I now know to switch off Open-GL within Libre Office when using. I am comfortable  with that.

I'll leave to you Gurus or your colleagues to fix Open-GL font issues as and when you/they can.

Bon chance  - Good Luck.
Comment 18 Michael Meeks 2017-09-16 08:38:15 UTC
Very odd. I wonder if it is another rounding error; would be interesting to have a dbgutil build with a SAL_LOG=+INFO.opengl.vcl+WARN.opengl.vcl for that test.
Comment 19 V Stuart Foote 2017-09-16 16:34:44 UTC
Created attachment 136290 [details]
debug log with opengl INFO and WARN level events for a TB39 build

(In reply to Michael Meeks from comment #18)
> Very odd. I wonder if it is another rounding error; would be interesting to
> have a dbgutil build with a SAL_LOG=+INFO.opengl.vcl+WARN.opengl.vcl for
> that test.

attached...

Windows 10 Home, 64-bit en-US with
Version: 6.0.0.0.alpha0+
Build ID: 403c7729734ed1a545f0436e31c4d14a2724606d
CPU threads: 4; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-09-13_09:13:53
Locale: en-US (en_US); Calc: CL

Simple 3 row 4 col ODT, with "11" and font set to Arial in the table content style.

Opened directly from Cygwin64 terminal command line:

SAL_LOG=1+INFO.opengl.vcl+WARN.opengl.vcl ./soffice.exe tdf112385_vsfTestDoc_8ptArial.odt 2> tdf112385_debug.txt

after opening, highlight last row, copy and paste to table, then save, close and exit LO.
Comment 20 Aron Budea 2017-11-05 23:25:11 UTC
Seems fixed in master, but not in 5.4.3.2.
Comment 21 V Stuart Foote 2017-11-06 01:17:30 UTC
(In reply to Aron Budea from comment #20)
> Seems fixed in master, but not in 5.4.3.2.


Think it was the DirectWrite adjustment for OpenGL rendering for bug 113347 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=de811bb2359757b90a0a9851963bd8702b97dab0&h=libreoffice-5-4

In master already, 5.4.4.1 when rolled.
Comment 22 V Stuart Foote 2018-10-30 18:54:01 UTC
Fixed by Mike K. with the DirectWrite adjustment for OpenGL rendering for bug 113347 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=de811bb2359757b90a0a9851963bd8702b97dab0&h=libreoffice-5-4