Description: When I use LODev Writer, open Character dialog, I found sample text always overlap each other. Steps to Reproduce: 1. Open LibreOfficeDev Writer 2. Format > Character Actual Results: See my attchment Expected Results: - Reproducible: Always User Profile Reset: No Additional Info: Version: 5.3.0.0.alpha1+ Build ID: 05d2a66955f8a6552a79696474386ca9f45f9ef2 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-07_23:34:48 Locale: zh-CN (zh_CN); Calc: group User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Created attachment 128645 [details] Screenshot from LODev Writer
Can you test with the old layout engine, and/or 5.2?
Created attachment 128646 [details] sampler - character preview sampler of the Character dialog previews by renderer and layout engine... Version: 5.3.0.0.alpha1+ Build ID: f6391d9696bfa7485bf785ac81edef4d5441e232 CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-10_00:11:47 Locale: en-US (en_US); Calc: CL the sample text, or selection, is generated in the SvxFontPrevWindow http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#621 Confirming things degrade a fair bit with the HarfBuzz layout.
Seems we directly scale the selection or sample text to compose the preview for rendering in the dialog http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#98 http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#706 So is this another DirectWrite scalling issue, or something in the way the dialog is being composed misbehaving with HarfBuzz layout? And then there is bug 57672 for combining forms that has long had an issue with the preview. @Tomaž, Chris?
(In reply to V Stuart Foote from comment #4) > Seems we directly scale the selection or sample text to compose the preview > for rendering in the dialog > > http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#98 > http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#706 Oh, that is just broken! Setting font width means “scale the text horizontally by the font width / font height” not ”set text to fit in this width”. I blame the odd choice for naming, it should have been X scale and Y scale not width and height. > So is this another DirectWrite scalling issue, or something in the way the > dialog is being composed misbehaving with HarfBuzz layout? And then there is > bug 57672 for combining forms that has long had an issue with the preview. so this is another duplicate of bug 103725, though I think the right fix here is to not set font width at all.
(In reply to Khaled Hosny from comment #5) > (In reply to V Stuart Foote from comment #4) > > Seems we directly scale the selection or sample text to compose the preview > > for rendering in the dialog > > > > http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#98 > > http://opengrok.libreoffice.org/xref/core/svx/source/dialog/fntctrl.cxx#706 > > Oh, that is just broken! Setting font width means “scale the text > horizontally by the font width / font height” not ”set text to fit in this > width”. I blame the odd choice for naming, it should have been X scale and Y > scale not width and height. Reading the code above again, I’m not sure it does what I thought it is doing.
Font scaling issue. *** This bug has been marked as a duplicate of bug 103725 ***
@Khaled, reopening this rather than bug 103725 On windows 10 Pro 64-bit en-US with recent master or with Version: 5.3.0.3 (x64) Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; Locale: en-US (en_US); Calc: group With OpenGL rendering enabled, the font name preview or a selection of text for preview in the Character dialog is again being compressed. Preview appears reasonable with default GDI based rendering. STR 1. new Writer document with OpenGL rendering enabled 2. enter sample text "Some sample text for preview" 3. select text 4. context menu -> Character dialog expected -- preview should be formatted as on document canvas actual -- preview is compressed horizontally 5. disable OpenGL (Tools -> Options -> View) and restart 6. repeat 1 - 4 actual -- preview is formatted as on document canvas So this handling for the dialog preview seems correct with HarfBuzz for GDI, but not with DirectWrite--while rendering to document canvas seems unaffected.
*** Bug 104939 has been marked as a duplicate of this bug. ***
Just with OpenGL rendering enabled. Initially during HarfBuzz implementation this affected both default GDI and OpenGL based rendering. Now (at 5.3.0.3) correct with default GDI handling, but OpenGL rendering of the character preview remains compressed.
*** Bug 105741 has been marked as a duplicate of this bug. ***
The incorrect glyph spacing with OpenGL rendering is also affecting preview/sample text on Impress master slides-- bug 105741 and bug 105768
*** Bug 104796 has been marked as a duplicate of this bug. ***
bug 105976 -- Text width scale doesn't work when not 100% and OpenGL is enabled, suggests the issue here is not with the Character style dialog but in mishandling of Direct2Write/DirectWrite font scaling applied to the sample text or selection composed in the dialog when OpenGL is enabled. Default GDI+ based rendering handles font sample/selection correctly.
*** Bug 105976 has been marked as a duplicate of this bug. ***
*** Bug 105768 has been marked as a duplicate of this bug. ***
*** Bug 105709 has been marked as a duplicate of this bug. ***
Additional information: this happens in Impress 5.3.0.3 in any text box, as long as a text box is not completely filled. When the box is full and Impress starts to rescale the text, character spacing is correct.
*** Bug 106279 has been marked as a duplicate of this bug. ***
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a51b7a1c3a7e7cf7b0c733e1dec40288278c1884 tdf#103831, tdf#100986: Force using GDI when needed It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 106319 has been marked as a duplicate of this bug. ***
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4375eefb644d03ab4bafbc091436166a8494dc91&h=libreoffice-5-3 tdf#103831, tdf#100986: Force using GDI when needed It will be available in 5.3.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Version 5.3.2 dev solves the problem for me. version info: 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: fr-FR (fr_FR); Calc: group
*** Bug 106452 has been marked as a duplicate of this bug. ***
*** Bug 106528 has been marked as a duplicate of this bug. ***
*** Bug 106550 has been marked as a duplicate of this bug. ***