Created attachment 126280 [details] Sample Document Rotated text shows incorrectly for certain fonts on windows. To recreate: 1. New doc 2. Write sample text. select it 3. Choose Linux Libertine G font. any size 4. Format->Character->Position->Rotation/Scaling 5. set to 90 or 270 The glyphs are not rotated. Advance widths and glyph positions seem to be ok. I have encountered this with 3 fonts so far: 1. Linux Libertine G 2. Linux Biolinum G 3. Linux Libertine Display G
Reproduced in 5.1.2.2, not reproduced in 5.1.0.3, OS: Windows 7. => regression Affected fonts all seem to be Graphite ones.
regression from: commit 620a1351a7627246f139a54a8cc3b35fa7ef8434 Author: Tim Eves <tim_eves@sil.org> AuthorDate: Tue Mar 8 14:46:49 2016 +0700 Commit: Michael Meeks <michael.meeks@collabora.com> CommitDate: Mon Mar 14 17:52:41 2016 +0000 tdf#97171: Use DirectWrite for OpenGL glyph caching A squash of several commits. Most important points mentioned below: [novel elided]
This now affects any rotated text. Its seems the the DirectWrite renderer does not handle text rotation at all.
Ah - right =) of course this is supposed to be a big feature of DirectWrite: http://www.basschouten.com/blog1.php/font-rendering-gdi-versus-directwrite So its certainly possible (I guess). Would love to be rendering the glyphs on the GPU from some SDF representation rather than caching based on some transform ;->
We currently do rotation only for vertical CJK text (mainly due to a misunderstanding of mine), so the code just need to be generalized.
Created attachment 128522 [details] Vertical Text in Tables Also Broken Just wanted to make sure that the generalized solution will also work with text in tables. It's a fairly common practice for people to use vertical text in tables as row labels.
Created attachment 128523 [details] Chart labels are also broken
I noticed that is for 5.1, where my examples only are broken for 5.3 and correctly display with $ SAL_NO_COMMON_LAYOUT=1 soffice.exe. Should I file new bug reports for them or is it all the same bug?
The original bug was Graphite only, which I think it was broken since 5.1, but we are now using the same (broken) code even for non-Graphite fonts. So it is the same bug but it shows up for different fonts at different versions.
Bug 101442
*** Bug 103741 has been marked as a duplicate of this bug. ***
*** Bug 103767 has been marked as a duplicate of this bug. ***
Should be fixed with cgit.freedesktop.org/libreoffice/core/commit/?id=d436065bc1c68fc2d90e73253d8c00503c72dfd0.
On Windows 10 Pro 64-bit (1607) en-US with Version: 5.3.0.0.alpha1+ Build ID: 84f644eee78106f01486098d446d9163b62927eb CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-15_23:52:44 Locale: en-US (en_US); Calc: CL Reversion to using GDI+ rendering rather than DirectWrite has restored rotation of the text but just for default rendering. With DirectWrite and OpenGL rendering the rotation is still broken. =-ref-= https://cgit.freedesktop.org/libreoffice/core/commit/?id=d436065bc1c68fc2d90e73253d8c00503c72dfd0
Does it work with OpenGL but without HarfBuzz?
(In reply to Khaled Hosny from comment #15) > Does it work with OpenGL but without HarfBuzz? Yes it rotates with the old layout engine and OpenGL rendering.
Khaled, Do we really want to tie DirectWrite to "Use OpenGL"? DirectWrite is hardware-accelerated using Direct2D. Does "Use hardware-acceleraton" do anything under Windows? If not, wouldn't it make more sense to tie DirectWrite to that? https://cgit.freedesktop.org/libreoffice/core/commit/?id=d436065bc1c68fc2d90e73253d8c00503c72dfd0
(In reply to Luke from comment #17) > Khaled, > Do we really want to tie DirectWrite to "Use OpenGL"? DirectWrite is > hardware-accelerated using Direct2D. Does "Use hardware-acceleraton" do > anything under Windows? If not, wouldn't it make more sense to tie > DirectWrite to that? > @Luke, Assume you are referring to the GUI layout in Tool -> Options -> View from when we added a control for toggling OpenGL rendering at 4.4 and overriding the black listing of OpenGL for driver/GPU combinations. Prior to that the two checkboxes "Use hardware acceleration" and "Use anti-aliasing" performed simple toggle actions--they both still function and the hardware acceleration can be deselected IIUC to force graphics control to CPU rather than the GPU. In effect rendering can be OpenGL, or default GDI+, or non-accelerated CPU/GPU--the check boxes control that. I don't think we want or need to change that. Issue is with DirectWrite adopted for OpenGL rendering. For the initial OpenGL implementation Tor had tried MS Uniscribe rather than DirectWrite but that had to be backed out as unsupportable and we moved forward with a DirectWrite implementation contributed by Tim E. and Martin H. for Graphite font support. Now Akash and Khaled implemented a "new" HarfBuzz based layout engine to replace the "old" mix of GDI and OpenGL/DirectWrite provided layout with code "common" to all target platforms. In the process they used DirectWrite calls and Direct2D for both GDI default rendering and OpenGL rendering. Issues with correctness of the LibreOffice DirectWrite implementation is affecting scaling, rotation and positioning of glyphs. The implementation has troubles in OpenGL rendering for both the old layout and the new HarfBuzz layout--and it was affecting the GDI+ rendering where used in the new layout. The last commit here only reverts the GDI+ DirectWrite rendering with HarfBuzz to use the old rendering, so glyphs rotate and scale correctly when needed--they will not with OpenGL enabled, keeping status quo with the old layout. We have had to do this to move HarfBuzz layout forward in 5.3.0 while waiting for the DirectWrite implementation to be improved/completed.
(In reply to V Stuart Foote from comment #16) > (In reply to Khaled Hosny from comment #15) > > Does it work with OpenGL but without HarfBuzz? > > Yes it rotates with the old layout engine and OpenGL rendering. OK. Anyway, someone else will have to look into OpenGL issues, as I don’t have a Windows setup capable of using it.
Rotated text now disappears with OpenGL rendering + new layout engine. Tested with 5.3beta1 and 5.4 master build from 2016-12-10. Seems to work in 5.3alpha1. Should this go in a separate bug report?
(In reply to Aron Budea from comment #20) > Rotated text now disappears with OpenGL rendering + new layout engine. > Tested with 5.3beta1 and 5.4 master build from 2016-12-10. Seems to work in > 5.3alpha1. > Should this go in a separate bug report? yes, this is OpenGL problem (c) Khaled
*** Bug 105880 has been marked as a duplicate of this bug. ***
*** Bug 106030 has been marked as a duplicate of this bug. ***
i have a similar problem: calc, version 5.3.0.3 reproduce the problem: 1 fill in text in cell (like "test test test test" 2 right click with mouse and choose format cells 3 fill in degrees field: 270 (problem also shows with other angles except the 0 degrees) result: the letters are supposed to be shown on top of each other. the letters overlap each other though and it becomes unreadable. however the distances between the letters is gone or "negative" distance. problem happened in 5.3.0.3 last working version i know off: 4.2 (i did not upgrade for a long time, so i do not know about versions between 4.2 and 5.3.0.3)
*** Bug 106198 has been marked as a duplicate of this bug. ***
*** Bug 106083 has been marked as a duplicate of this bug. ***
(In reply to Khaled Hosny from comment #19) > OK. Anyway, someone else will have to look into OpenGL issues, as I don’t > have a Windows setup capable of using it. @Khaled, are you set up now for OpenGL development on Windows? Otherwise... @Khaled, Tim, Martin, Tor, * Is there agreement yet on how to correct the DirectWrite/Direct2D implementation for use with OpenGL rendering on the Windows builds? At 5.3 the default GDI+ rendering is working well with HarfBuzz, but HB with OpenGL with our current DirectWrite/D2D implementation--not so much, as here. And IIRC there were remaining issues with some of the Graphite font features needing DirectWrite/Direct2D, e.g. combining forms.
(In reply to V Stuart Foote from comment #27) > (In reply to Khaled Hosny from comment #19) > > OK. Anyway, someone else will have to look into OpenGL issues, as I don’t > > have a Windows setup capable of using it. > > @Khaled, are you set up now for OpenGL development on Windows? > > Otherwise... > > @Khaled, Tim, Martin, Tor, * > > Is there agreement yet on how to correct the DirectWrite/Direct2D > implementation for use with OpenGL rendering on the Windows builds? > > At 5.3 the default GDI+ rendering is working well with HarfBuzz, but HB with > OpenGL with our current DirectWrite/D2D implementation--not so much, as > here. > > And IIRC there were remaining issues with some of the Graphite font features > needing DirectWrite/Direct2D, e.g. combining forms. Unfortunately, every time I try to work on this (including right now) I end up with a miserable failure. I don’t know Windows API that much, and we use an “interesting” mix of GDI+ and DirectWrite APIs which is not helping. Not to mention that hacking on Windows is such a painful experience in general.
This is fixed with the same fix for bug 103831.
(In reply to Khaled Hosny from comment #29) > This is fixed with the same fix for bug 103831. Confirmed. Regina's attachment 128554 [details] example from bug 103767 renders correctly. On Windows 10 Pro 64-bit en-US with 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: en-US (en_US); Calc: CL http://cgit.freedesktop.org/libreoffice/core/commit/?id=4375eefb644d03ab4bafbc091436166a8494dc91&h=libreoffice-5-3 or on master https://cgit.freedesktop.org/libreoffice/core/commit/?id=a51b7a1c3a7e7cf7b0c733e1dec40288278c1884 Where we've dropped DrirectWrite Direc2D for OpenGL rendering to use GDI calls for scaling and "non-horizontal" glyphs.