Bug 128568 - FILESAVE: DOCX: Fontwork broken with Word 2007-365 format
Summary: FILESAVE: DOCX: Fontwork broken with Word 2007-365 format
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: FontWork-WordArt
  Show dependency treegraph
 
Reported: 2019-11-03 14:26 UTC by Aritz Erkiaga
Modified: 2021-04-15 19:13 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aritz Erkiaga 2019-11-03 14:26:03 UTC
Description:
Saving a document with Fontwork as Word 2007-365 (.docx) shows garbled text upon opening it.

Steps to Reproduce:
1. On a new document, Insert -> Fontwork... -> choose any
2. Save -> Word 2007-365 (.docx)
3. Open the saved document

Actual Results:
The Fontwork is broken, with unformatted text surrounded by blank shapes and colors, or other undesirable effects that seem to depend on the specific platform.

Expected Results:
After opening the document, the Fontwork should look exactly as it did before saving it. This is the behavior with both ODF text documents and Word 97-2003 documents.


Reproducible: Always


User Profile Reset: No



Additional Info:
Although the test was performed on a Linux (Ubuntu-based) machine, the problem has been spotted on Windows 10 too. The visual distortions observed are very different on Windows.

I have tested Fontworks with different backgrounds on my machine; all of them produce the same undesired result. On the other machine, however, only bitmap backgrounds were tested, and they gave an homogeneous rectangular bitmap with no text whatsoever.

Help - About LibreOffice
Version: 6.3.3.2
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 IM 2019-11-04 00:32:54 UTC
Thank you for reporting the bug. I can confirm that the bug is present in:

Version: 6.3.2.2 (x64)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: pl-PL (pl_PL); UI-Language: en-US
Calc: threaded

Version: 6.4.0.0.alpha1 (x64)
Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
Locale: pl-PL (pl_PL); UI-Language: en-US
Calc: threaded
Comment 2 Xisco Faulí 2019-11-05 10:49:45 UTC
Inherit from OOo issue
Comment 3 Regina Henschel 2019-11-05 13:21:31 UTC
OOo or AOO has no export to docx at all, so cannot be inherit form OOo.

LO 6.4 should produce a Fontwork with working handles, and does it here under Windows 10. Export of filling is not implemented yet. The Fontwork gets as solid color that color, which is set for the characters of the text in the "Font Effect" tab. This color is not visible in Writer.

Import of Fontwork from docx is not implemented at all, because it conflicts with the text box, that is used on import of shapes in Writer. So to see the actual exported shape, you need to open the file in MS Word.
Comment 4 Roman Kuznetsov 2021-04-15 19:13:30 UTC
still repro in

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 77419c6f3aba1fd5b1660795923c22a39bdb1bad
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL