Created attachment 107143 [details] Two example texts converted to polygon, the lower one having one space added to the end Problem description: Steps to reproduce: 1. Open a new drawing 2. Insert a text box with some text but NO spaces (linebreaks are ok it seems) 3. Select text box and choose Convert -> To Polygon, text should be converted to polygon ok 4. Undo and change text content to include spaces (even one will do) 5. Try to convert to polygon again, now duplicated, squished characters are added to the polygon and the result is a mess Current behavior: Converted polygon contains duplicate, squished characters Expected behavior: Text is converted properly Operating System: Mac OS X Version: 4.3.2.2 release
Forgot to add in the description (but remembered in the title!) that this also happens when converting text to Curve, Contour and seemingly also 3D.
Confirming on LO 432 and OSX 10.9.5
Also present in master Version: 4.4.0.0.alpha0+ Build ID: faf99f6f405e076d5c9ab95c876ae1ffb896f8d1
Not present in Version: 4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 regression
Not present in Version: 4.2.4.2 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
Could not reproduce on Debian "wheezy" 7.6 using LO 4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d.
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
This is not a blocker - in 3 years on the project I've seen less than 5 bugs that were legitimate blockers. Reprioriting bug: Normal - can prevent high quality/professional work. Medium - default seems appropriate.
Created attachment 113202 [details] The same problem. But it happens without space at the end. The same problem. But it happens without space at the end.
The problem isn't visually identical but I wonder if this is related to bug 81876
(In reply to Matthew Francis from comment #10) > The problem isn't visually identical but I wonder if this is related to bug > 81876 I suppose it is related to bug 81876 because the problems occure only when there are spaces in a text. In both bugs the text is doubled, but in different ways.
Since the fix to bug 81876, the characters no longer appear to me to be duplicated, but they are still "squished"
Created attachment 114554 [details] Before commit 162f11cdb94b415ff9d58674e94fb01a745a69eb
Created attachment 114555 [details] After commit 162f11cdb94b415ff9d58674e94fb01a745a69eb
Adding Cc: to pelloux@gmail.com Hi - you recently did some work in bug 81876 which affected this bug (commit 162f11cdb94b415ff9d58674e94fb01a745a69eb et al). Is there any chance you could take a look at this one too? Attachment 114554 [details] and attachment 114555 [details] show a before and after comparison of the effects of your commit. Before it looks like a correct rendering and a "narrow" rendering are overlaid on one another, whereas after there is only one rendering left - but unfortunately it's the "narrow" one. Thanks
Before commit https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=2ba05b4800d6cc322276a6911792363f8eb32051, the output of CoreText was always used without checking returns code. This introduced duplicate rendering because the partial result from CoreText was drawn as well as the complete result from the fallback code path. This was fixed with https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=162f11cdb94b415ff9d58674e94fb01a745a69eb For bug 84521 it looks like the fallback code produces an incorrect transformation text -> polygon. I'll try to fix this bug as well - if time permits.
Created attachment 114564 [details] Ignore CT errors
Created attachment 114565 [details] naive patch (sorry about the duplicate previous comment) Had a quick look at this issue. AFAIU the problem is indeed in the fallback code of OutputDevice::GetTextOutlines(). This code seems to be barely used (if ever) on Linux so I'm not sure it gets a lot of attention. The bug cause is an invalid scaling value computed in text.cxx: double fScaleX = static_cast< double >(nOrgWidth) / nWidth; double fScaleY = static_cast< double >(nOrgHeight) / nHeight; If you remove the call to: aFont.SetSize( Size( 0, GLYPH_FONT_HEIGHT ) ); a few lines above this will fix the issue. Another solution would be to drop (all?) this fallback code and make sure that the CoreText backend works properly. The attached patch does this in a naive way (and it fixes the issue). Basically instead of propagating CT errors up, it will catch them and ignore the problematic glyph. Any CT expert to help?
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
I can't reproduce this in Linux (Bodhi Moksha) with Version: 5.2.0.0.alpha0+ Build ID: 5df326438fd3a5613a52b4de1935426911ff1301
*** Bug 89201 has been marked as a duplicate of this bug. ***
For the time being, there isn't any bibisect repository covering the 4.3 branch for MAC, thus removing the keyword 'bibisectRequest' and adding 'notBibisectable'
Adding keywords bibisected, bisected, patch
This works for me Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group