Bug 125573 - FILEOPEN PPTX Text in text transform shapes is not scaled to the path
Summary: FILEOPEN PPTX Text in text transform shapes is not scaled to the path
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.1.1.2 release
Hardware: All All
: medium normal
Assignee: Regina Henschel
URL: https://standards.iso.org/ittf/Public...
Whiteboard: target:6.4.0
Keywords: filter:pptx
Depends on:
Blocks: 100348
  Show dependency treegraph
 
Reported: 2019-05-29 11:31 UTC by Regina Henschel
Modified: 2019-06-29 19:38 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
OOXML WordArt shape and screenshot of PowerPoint 365 (33.04 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2019-05-29 11:31 UTC, Regina Henschel
Details
Document for experiments with ScaleX (16.78 KB, application/vnd.oasis.opendocument.presentation)
2019-06-23 17:21 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2019-05-29 11:31:49 UTC
Created attachment 151758 [details]
OOXML WordArt shape and screenshot of PowerPoint 365

Open the attached file. It contains a shape with a "triangle" transform and an image of the shape in PowerPoint. Notice, that the text is not scaled to the path length.

The error does not only occur in this shape, but other shapes with 'warp transform' are effected too.

The OOXML specification contains an algorithm how to transform the text content. It is in section 20.1.9.16 prstTxWarp. That is page 2906/2907 in ISO/IEC 29500-1:2016(E). The idea is, that the tightest rectangle around the text is mapped to the area between the two paths of the shape. If you move the handle a little bit, the paths are drawn as help lines.

This is a follow up report to bug 116350, where the feature was implemented.
Comment 1 Xisco Faulí 2019-05-30 10:36:51 UTC
Reproduced in

Version: 6.3.0.0.alpha1+
Build ID: aa687b22991e6c674b1d8653d52fbe9a50080174
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 2 Regina Henschel 2019-06-23 17:13:52 UTC
I have collected some remarks on the problem in https://wiki.documentfoundation.org/Development/Remarks_on_Fontwork_and_TextWarp, especially in sections Scale and ScaleX.
Comment 3 Regina Henschel 2019-06-23 17:21:23 UTC
Created attachment 152361 [details]
Document for experiments with ScaleX

There exist no UI to change the value of property "ScaleX". The attached document, contains a macro, to toggle this property for a selected shape in Impress. (The macro is only for to examine the property ScaleX and is not designed for general usage.)
Comment 4 Commit Notification 2019-06-26 16:38:02 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/e7c0bc4811029abca878343dcce8057f9d3b7053%5E%21

tdf#125573 Scale text to path for TextWarp, use fromWordArt

It will be available in 6.4.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.
Comment 5 Regina Henschel 2019-06-29 19:38:19 UTC
The fix is integrated in Version: 6.4.0.0.alpha0+ (x64)
Build ID: 9105b85c708f42024ce063b9a944466c0afdfe9a
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-28_22:42:37
Locale: de-DE (en_US); UI-Language: en-US
Calc: threaded

There are still some differences for those shapes, which have more than one pair of paths, and for legacy shapes which multiple lines. That is no problem of import, but the current drawing engine is not able to draw it the same way as MS Office.
The missing properties of the shapes, e.g. fill, are treated in other issues. So I think, the part of getting the correct outline of the shape is fixed now (besides easy hack bug 125560).