Bug 152913 - FILESAVE DOCX handles of Fontwork shape wrong in VML
Summary: FILESAVE DOCX handles of Fontwork shape wrong in VML
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.6.0.0 alpha0+
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Regina Henschel
URL:
Whiteboard: QA:needsComment
Keywords:
Depends on:
Blocks: FontWork-WordArt 128568 VML-Shapes
  Show dependency treegraph
 
Reported: 2023-01-07 15:41 UTC by Regina Henschel
Modified: 2023-02-02 17:28 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
File with "Slant Up" Fontwork shape. (12.81 KB, application/vnd.oasis.opendocument.text)
2023-01-07 15:41 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2023-01-07 15:41:40 UTC
Created attachment 184516 [details]
File with "Slant Up" Fontwork shape.

Open attached document and save it to docx format. Open the saved file in Word. Notice that the handle is at a wrong position and is not moveable in Word.

To see how it should work, switch to a different shape type in the "WordArt" menu in Word and then back to type "Slant-Up".

Examining the docx file you will see, that the fontwork shape is exported as VML shape.
The produced VML markup has these errors:
(1) The y value in the position attribute of the handle uses a reference to a formula (@) instead of a reference to an adjustment value (#). Referencing a formula is no syntactical error, but it determines that the handle is fix in that direction. Only the reference to an adjust value gives a moveable handle.
https://learn.microsoft.com/en-us/windows/win32/vml/position-attribute--h--vml
(2) The x value in the position attribute of the handle uses the constant 0. That is not evaluated in Word but treated as "center". Instead the key "topLeft" has to be used.
(3) The <v:shape> element misses the adj attribute, which determines via the # reference the position of the handle.

The fact, that this shape is not exported as DrawingML but to VML, is an additional, but different error. In case a Fontwork shape has a bitmap fill, it has to be exported to VML anyway, because in current Word the "abc Transformation" is not able to use bitmap fill. So the problem will be still relevant after this special shape will be correctly exported as DrawingML.

The erroneous export to VML has its root in the HasTextBoxContent method in https://opengrok.libreoffice.org/xref/core/filter/source/msfilter/util.cxx?r=6b252b6a#1220 and its use.

The VML export is mixed with the export to binary format. I have currently no idea where the errors come in. Tips are appreciated.
Comment 1 Regina Henschel 2023-01-27 14:23:27 UTC
I have found two reasons so far:
(A) Currently the generated file 'vml-shape-types' (in the installed LO in folder share/filter) is used. In 48 possible presets of Fontwork, 18 markups are missing. And the others have errors in the handle position as described earlier.

(B) The export in VMLExport::Commit() method in vmlexport.cxx has no case for exporting the actual values of the handles. So even when (A) is fixed, the handles position will be wrong.

I will take this bug report for problem (A) and write a new bug report for problem (B).

In the meantime I have change the export so, that any Fontwork shape, which is filled with a bitmap, will be exported as VML. That is necessary because 'abc transform' of DML is not able to use bitmap fill. So you can see the problem not only with "Slant Up" Fontwork shape but with others too, when you use a bitmap fill.
Comment 2 Regina Henschel 2023-02-02 17:28:26 UTC
Using wrong markup for <v:shapetype> element is know in bug 153296. It is partly solved for Fontwork shapes.
Not writing the actual adjustment values is now in bug 153246.

Because this report covers two problems, I close it as invalid.