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%
One's do not display properly
User Profile Reset: No
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
Created attachment 136237 [details]
Samples of issue
Attachments show issue
Can not reproduce on Windows 10 Ent 64-bit en-US with
Version: 188.8.131.52 (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?
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
Created attachment 136253 [details]
Calc & Writer test 20170915
Today's tests for Calc & Writer attached.
I reboot at least on daily basis
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.
Created attachment 136256 [details]
Screen Resolution and Requested Info
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 :-)
(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.
Created attachment 136264 [details]
Calc & Writer test 20170915 _03
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.
(In reply to Willim from comment #9)
Looking at the msinfo32 Display panel you posted (thank you BTW), with current Intel driver (184.108.40.20624/220.127.116.1124) 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 (18.104.22.16803), 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
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?
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.
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
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: 22.214.171.124 (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.
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.
Created attachment 136278 [details]
Requested Information + Tests with other Fonts
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
Source Code - Source Code B
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 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.
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.
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.
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.
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.
Windows 10 Home, 64-bit en-US with
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.
Seems fixed in master, but not in 126.96.36.199.
(In reply to Aron Budea from comment #20)
> Seems fixed in master, but not in 188.8.131.52.
Think it was the DirectWrite adjustment for OpenGL rendering for bug 113347
In master already, 184.108.40.206 when rolled.
Fixed by Mike K. with the DirectWrite adjustment for OpenGL rendering for bug 113347