Bug 84521 - EDITING: Converting text with spaces to polygon/curve/contour results in duplicated characters
Summary: EDITING: Converting text with spaces to polygon/curve/contour results in dupl...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.3.2.2 release
Hardware: Other Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: bibisected, bisected, patch, regression
: 89201 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-30 16:41 UTC by Mikko Ahlroth
Modified: 2017-08-26 22:14 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Two example texts converted to polygon, the lower one having one space added to the end (15.86 KB, image/png)
2014-09-30 16:41 UTC, Mikko Ahlroth
Details
The same problem. But it happens without space at the end. (91.00 KB, image/png)
2015-02-07 13:05 UTC, Sergio
Details
Before commit 162f11cdb94b415ff9d58674e94fb01a745a69eb (19.50 KB, image/png)
2015-04-02 11:06 UTC, Matthew Francis
Details
After commit 162f11cdb94b415ff9d58674e94fb01a745a69eb (10.08 KB, image/png)
2015-04-02 11:06 UTC, Matthew Francis
Details
Ignore CT errors (872 bytes, patch)
2015-04-02 18:36 UTC, Pierre-Eric Pelloux-Prayer
Details
naive patch (566 bytes, patch)
2015-04-02 18:38 UTC, Pierre-Eric Pelloux-Prayer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mikko Ahlroth 2014-09-30 16:41:55 UTC
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
Comment 1 Mikko Ahlroth 2014-09-30 16:43:27 UTC
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.
Comment 2 Alex Thurgood 2014-09-30 17:10:40 UTC
Confirming on LO 432 and OSX 10.9.5
Comment 3 Alex Thurgood 2014-09-30 17:14:37 UTC
Also present in master

Version: 4.4.0.0.alpha0+
Build ID: faf99f6f405e076d5c9ab95c876ae1ffb896f8d1
Comment 4 Alex Thurgood 2014-09-30 17:17:02 UTC
Not present in Version: 4.1.4.2
Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72
regression
Comment 5 Alex Thurgood 2014-09-30 17:22:12 UTC
Not present in Version: 4.2.4.2
Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
Comment 6 vilpan 2014-10-01 11:44:23 UTC
Could not reproduce on Debian "wheezy" 7.6 using LO 4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d.
Comment 7 Björn Michaelsen 2014-11-28 09:42:17 UTC Comment hidden (obsolete)
Comment 8 Joel Madero 2014-12-06 19:18:15 UTC
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.
Comment 9 Sergio 2015-02-07 13:05:23 UTC
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.
Comment 10 Matthew Francis 2015-02-13 15:18:27 UTC
The problem isn't visually identical but I wonder if this is related to bug 81876
Comment 11 Sergio 2015-02-14 06:44:14 UTC
(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.
Comment 12 Matthew Francis 2015-04-02 08:25:26 UTC
Since the fix to bug 81876, the characters no longer appear to me to be duplicated, but they are still "squished"
Comment 13 Matthew Francis 2015-04-02 11:06:12 UTC
Created attachment 114554 [details]
Before commit 162f11cdb94b415ff9d58674e94fb01a745a69eb
Comment 14 Matthew Francis 2015-04-02 11:06:41 UTC
Created attachment 114555 [details]
After commit 162f11cdb94b415ff9d58674e94fb01a745a69eb
Comment 15 Matthew Francis 2015-04-02 11:14:11 UTC
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
Comment 16 Pierre-Eric Pelloux-Prayer 2015-04-02 11:34:20 UTC
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.
Comment 17 Pierre-Eric Pelloux-Prayer 2015-04-02 18:36:38 UTC
Created attachment 114564 [details]
Ignore CT errors
Comment 18 Pierre-Eric Pelloux-Prayer 2015-04-02 18:38:05 UTC
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?
Comment 19 Robinson Tryon (qubit) 2015-12-14 05:33:52 UTC Comment hidden (obsolete)
Comment 20 Joel Madero 2015-12-14 15:31:29 UTC
I can't reproduce this in Linux (Bodhi Moksha) with Version: 5.2.0.0.alpha0+
Build ID: 5df326438fd3a5613a52b4de1935426911ff1301
Comment 21 Alex Thurgood 2015-12-14 17:08:36 UTC
*** Bug 89201 has been marked as a duplicate of this bug. ***
Comment 22 Xisco Faulí 2016-09-13 09:26:00 UTC Comment hidden (obsolete)
Comment 23 Xisco Faulí 2016-09-26 20:58:24 UTC
Adding keywords bibisected, bisected, patch
Comment 24 eisa01 2017-08-26 22:14:31 UTC
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