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
Created attachment 136237 [details] Samples of issue Attachments show issue
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?
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 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 :-)
(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 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
(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-
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
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.
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 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.
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.
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.
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.
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. 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.
Seems fixed in master, but not in 5.4.3.2.
(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.
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