Description: At different zoom levels the amount of space between characters don't appear consistent Steps to Reproduce: 1. Load simple attachment 2. Zoom to different zoom levels Actual Results: spacing between characters isn't appealing Expected Results: at 100% for me the "r" appears too far to the left Reproducible: Always User Profile Reset: No Additional Info: See comments in https://bugs.documentfoundation.org/show_bug.cgi?id=144862#c51 downwards
I think the main problem iswith VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D and the text positioning scaling done there before it even gets to the usual text rendering stuff so things are probably already gone wrong before it even gets as far as the underlying text rendering. My thinking is that we should pass the dx positions to vcl untouched and instead set up vcl to scale them rather than scale them in advance in drawinglayer, which would at least give vcl a chance to do something nice.
Created attachment 181833 [details] screencast, watch the letter r
Created attachment 181834 [details] simple example
Created attachment 181835 [details] what it looks like with my local changes
FWIW: repro at different zoom-level in my case Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: c1c8ce3b0f1037bca4d500af2f39363cd9d38db6 CPU threads: 8; OS: Mac OS X 12.3.1; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
FWIW: Slide Show mode (F5) has similar spacing issue, not the r in my case.
I would like to add that in my opinion the bug is also present at Draw and Calc, maybe also Base. Still, I don't know whether these share the same code here. Additionally, it is worth emphasizing that according to the findings discussed related to bug 144862 this issue is most likely *not* to be caused by the missing floating point glyph positioning and thus *not* a duplicate of bug 103322.
Caolán has some things going down in the guts of VCL(vclprocessor2d.cxx) which IIUC should apply to Draw and Calc in addtion to Impress. =-ref-= https://gerrit.libreoffice.org/c/core/+/138448 https://gerrit.libreoffice.org/c/core/+/138450
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1fa731d03ba0f22cb9392a578124ea977eaab2e9 tdf#150462 don't prescale dxarray before using DrawTextArray It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f85cd07295321cf875addeb52aa9e982808b74ae tdf#150462 set mode to keep scaled glyph positions as floating point It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
this appears decent to me, lets see what sort of side effects lurk
Amazing, this is one of the best updates to LO during the last years. Even though it "only" improves the visual appearance, this is often so much underestimated in open source software. Can't wait for it to be included in the stable releases. I think that even the whole floating point glyph positioning stuff is not necessary any more... I also tested Draw and Calc and to me, the rendering here seems to improved as well. Can you confirm this or is the rendering only improved in Writer and Impress now? By the way: There is a bounty on bug 103322, I think you have good arguments for claiming it... even though it was assigned to the floating point glyph positioning.
These particular changes are not limited to impress, so there is probable effects on various things using the "drawinglayer" which is a few bits and pieces around LibreOffice, especially shapes. There is floating point glyph positioning involved in this, just a conservative approach where typically the code already render to our "OutputDevice" set to a high resolution with large integer glyph position values, and can opt in to indicate that the final platform-specific text rendering to the real lower resolution device take them as scaled down doubles instead of the traditional rounded integers and set whatever platform-specific device/rendering settings are available to allegedly make that look good. Basically bug 103322 comment 14 I guess.
Tested with this mornings daily master against 7.5.0 Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 5ac75131556b687a01517ce4520a05bb49c1d840 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL A three line block of "California" each line in Libertinus Serif, Liberation Serif, and Arial at 12pt Clean rendering to screen (1920x1200px) in draw, calc, writer and impress at various canvas scaling 50% - 400%, looks very presentable. Thanks Caolán!
(In reply to V Stuart Foote from comment #14) > > Clean rendering to screen (1920x1200px) in draw, calc, writer and impress at > various canvas scaling 50% - 400%, looks very presentable. Likewise for the "loremp ipsum" string, and calc with & without 'Use printer metrics for text formatting'
(In reply to Caolán McNamara from comment #13) > These particular changes are not limited to impress, so there is probable > effects on various things using the "drawinglayer" which is a few bits and > pieces around LibreOffice, especially shapes. > > There is floating point glyph positioning involved in this, just a > conservative approach where typically the code already render to our > "OutputDevice" set to a high resolution with large integer glyph position > values, and can opt in to indicate that the final platform-specific text > rendering to the real lower resolution device take them as scaled down > doubles instead of the traditional rounded integers and set whatever > platform-specific device/rendering settings are available to allegedly make > that look good. > > Basically bug 103322 comment 14 I guess. Alright, than thanks again for your great work!
Created attachment 181912 [details] string in three serif fonts at different point sizes Simple ODP with Liberation Serif, Libertinus Serif, and Linux Biolinum G at point sizes from 6pt to 14pt Open in Impress and zoom the slide size. With recent work the glyphs remain positioned during scaling. Stroke weights differ between the font/point size as the display is zoomed, but kind of expect that--especially at lower pt sizes. Difference between recent master and 7.3.5.2 is a very noticible improvement in precision of glyph placement.
Created attachment 181998 [details] Font rendering comparison Quickly coming back to this issue. I did some test with dummy text in Impress and comparing the rendering between versions 7.4 and the 7.5 Dev (including the fix) directly shows the improvement. Still, I also exported the test document to PowerPoint and compared the rendering. I attached screenshots from all three samples, captured from the respective presentation mode (LO Impress 7.4, LO Impress 7.5 Dev, PowerPoint). Somehow PP even slightly improves the rendering of LO 7.5 Dev, compare for example the spacing inside the first 'ipsum' and 'diam'. Do you have any idea how LO can achieve the same rendering here?
(In reply to Gibtnix from comment #18) > Created attachment 181998 [details] > Font rendering comparison > > Quickly coming back to this issue. I did some test with dummy text in > Impress and comparing the rendering between versions 7.4 and the 7.5 Dev > (including the fix) directly shows the improvement. Still, I also exported > the test document to PowerPoint and compared the rendering. I attached > screenshots from all three samples, captured from the respective > presentation mode (LO Impress 7.4, LO Impress 7.5 Dev, PowerPoint). Somehow > PP even slightly improves the rendering of LO 7.5 Dev, compare for example > the spacing inside the first 'ipsum' and 'diam'. Do you have any idea how LO > can achieve the same rendering here? * Could you please add file (PPT/PPTX) with the dummy text used in the screenshot. Comparing the same thing makes it easier. * Looking at the screenshots: The glyph spacing with PowerPoint is indeed nicer. * A question: is the issue limited to presentation mode? Or is the rendering of glyphs in PowerPoint also better in non-presentation mode, in your opinion?
Created attachment 182015 [details] Example files (.odt and .pptx) As requested, I added the two example files: the original .odt as well as the .pptx created by exporting the .odt. I think the issue is actually not limited to presentation mode. Still I think the issue is less noticeable in editing mode, however this depends on the zoom level.
(In reply to Gibtnix from comment #20) > Created attachment 182015 [details] > Example files (.odt and .pptx) > > As requested, I added the two example files: the original .odt as well as > the .pptx created by exporting the .odt. > > I think the issue is actually not limited to presentation mode. Still I > think the issue is less noticeable in editing mode, however this depends on > the zoom level. A) I do repro, but not in the same extend. My core problem is with font rendering itself in presentation mode: bug 150609. However this doesn't show up with attachment 181998 [details]. B) The glyph spacing is still broken Presentation Mode with GDI rendering; seems OK in non-presentation mode. No clue if this being on purpose or not
(In reply to Telesto from comment #21) > A) I do repro, but not in the same extend. My core problem is with font > rendering itself in presentation mode: bug 150609. However this doesn't show > up with attachment 181998 [details]. The attachment 181998 [details] does not show the font rendering issues because the screenshots form the attachment all were created with hardware acceleration enabled, but Skia rendering was disabled. Enabling any form of Skia-based rendering reproduces the font rendering but 150609, at least according to my tests. > B) The glyph spacing is still broken Presentation Mode with GDI rendering; > seems OK in non-presentation mode. No clue if this being on purpose or not I also did some tests here, thanks for pointing out. I agree that the rendering improvement currently seems to mostly improve the editing mode while the presentation mode still seems to have glyph position issues. Therefore, should this bug be reopened? Or maybe Caolán can add something here, he probably knows best after fixing the issue in editing mode...
well, I think we should leave this closed as it was addressing a specific finding with RenderTextSimpleOrDecoratedPortionPrimitive2D which seems to have improved matters. The issue with is more obvious in presentation mode could justify another bug, I presume your screenshots were from windows. Is it the same on all platforms I wonder?
(In reply to Caolán McNamara from comment #23) > The issue with is more obvious in presentation mode could justify another > bug, I presume your screenshots were from windows. Is it the same on all > platforms I wonder? Done, bug 150609 -- "Font to thick Presentation Mode with Skia (Raster) enabled" establishes that the presentation mode follows a different font rendering.
(In reply to Caolán McNamara from comment #23) > well, I think we should leave this closed as it was addressing a specific > finding with RenderTextSimpleOrDecoratedPortionPrimitive2D which seems to > have improved matters. > > The issue with is more obvious in presentation mode could justify another > bug, I presume your screenshots were from windows. Is it the same on all > platforms I wonder? Yes, it's from Windows. Still, I will try dev build on Linux whether this issue exists here, too. Hopefully, resolving bug 150609 also fixes this issue in presentation mode.
I did some tests using Linux and I think that bug 150609 seems to be Windows-exclusive. Therefore, hopefully the improved font rendering will also improve the presentation mode on Linux and as soon as 150609 is fixed on Windows, the font rendering hopefully will be fine in presentation mode, too.