Download it now!
Bug 126001 - FILEOPEN DOCX Text box with rotated text jumps from middle of page to top
Summary: FILEOPEN DOCX Text box with rotated text jumps from middle of page to top
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: OOXML-Shapes DOCX-Textbox
  Show dependency treegraph
 
Reported: 2019-06-19 08:02 UTC by NISZ LibreOffice Team
Modified: 2019-10-17 14:46 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file from Word with long text (286.42 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-06-19 08:03 UTC, NISZ LibreOffice Team
Details
Example file from Writer with shorter text (286.12 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-06-19 08:04 UTC, NISZ LibreOffice Team
Details
Screenshot of the original document with long text side by side in Word and Writer (123.78 KB, image/png)
2019-06-19 08:05 UTC, NISZ LibreOffice Team
Details
Screenshot of the original document with short text side by side in Word and Writer (124.51 KB, image/png)
2019-06-19 08:05 UTC, NISZ LibreOffice Team
Details
Example with absolute height of the shape and shape background filled (22.92 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-06-21 15:16 UTC, Regina Henschel
Details
Screenshot of the document in current Writer master (87.35 KB, image/png)
2019-10-17 14:26 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2019-06-19 08:02:06 UTC
Description:
Attached document has a text box at the middle of the page with rotated text direction. Formerly the position of the box was correct compared to Word. Now that the writing direction is imported correctly the box jumps to the very top or the very bottom of the page depending on the contained text length.


Steps to Reproduce:
1.	Open attached files in Word and Writer
2.	Compare the text box position. 
3.	With long single word text the box jumps from the middle of the page to the top; with short text it jumps to the bottom.



Actual Results:
The text box is positioned incorrectly at the top or bottom of the page.

Expected Results:
The text box should be positioned at the middle of the page.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 NISZ LibreOffice Team 2019-06-19 08:03:52 UTC
Created attachment 152285 [details]
Example file from Word with long text
Comment 2 NISZ LibreOffice Team 2019-06-19 08:04:17 UTC
Created attachment 152286 [details]
Example file from Writer with shorter text
Comment 3 NISZ LibreOffice Team 2019-06-19 08:05:12 UTC
Created attachment 152287 [details]
Screenshot of the original document with long text side by side in Word and Writer
Comment 4 NISZ LibreOffice Team 2019-06-19 08:05:40 UTC
Created attachment 152288 [details]
Screenshot of the original document with short text side by side in Word and Writer
Comment 5 NISZ LibreOffice Team 2019-06-19 08:20:25 UTC
URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=ff17478e069cc82681df62514876c06365dd5cd6 

author	Miklos Vajna <vmiklos@collabora.com>	2019-04-25 21:05:43 +0200
committer	Miklos Vajna <vmiklos@collabora.com>	2019-04-26 09:05:04 +0200

Summary: sw btlr writing mode: implement DOCX shape import for tbrl
Comment 6 Gabor Kelemen 2019-06-19 08:29:43 UTC
Bibisected using bibisect-win32-6.3

Adding CC: to: Miklos Vajna
Comment 7 Dieter Praas 2019-06-19 11:42:45 UTC
I confirm it with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

in comparison with MS Word 2016

Additional observation: If I save document with MS Word 2016 and reopen it in LO I recieve a different result, because document was created in MS Word 2010 or 2013.
Comment 8 Regina Henschel 2019-06-21 15:14:33 UTC
Why is this marked as regression? In which version had it worked?

If Word exports a rect with vert="vert" to odt, it doesn't use a custom shape and its rotation of the text-area, but uses a draw:frame and sets style:writing-mode="tb-rl" in the paragraph-properties of the assigned graphic style. I think, that is a good idea in principle. But it would not solve the import immediately, because writing-mode on draw:frame is faulty too. Setting writing-mode to "tb-rl" can be used on custom-shape text-area too. There is no need for rotating the area. "bt-lr" would currently need loext-namespace.

One problem of the given examples is the combination of "Wrap text in shape" with "Resize shape to fit text". Because of "Wrap text", only resize in direction from first text line to last text line makes sense. So the resize direction depends on the writing mode.

A layout, which looks similar to Word would be: Start with the size of the text-area as in original horizontal text direction. Write the text in "tb-rl" writing mode into this area. Adapt the _width_ of the shape, if this is needed.

Currently the text-area goes out of the frame rectangle of the shape. This problem becomes visible, if you set a background color to the shape. In case import should be really done rotating the text-area, then width and height of the area needs to be switched. In case the writing direction tb-rl is used, no rotation would be necessary.

Currently the horizontal and vertical padding of the border is exchanged. I consider this an error, because padding belongs to the border, not to the test area. The text-area has its own size setting via draw:text-areas attribute.

The current solution is not stable. Moving the shape a little bit up/down, creates two totally different layouts; both are wrong. It switches between text-area in rotated size and shape frame rectangle normal size, and second, text-area size not rotated and frame rectangle much too high.

An additional problem in the given documents is, that the shape height is given as "20% to Margin". "Margin" in MS Office means "page text area" in our terms. In horizontal text direction, the hight is reduced to the height of the current text content. In vertical text direction, the hight has to be fixed 20% of the page text area, because in vertical text direction the adaption to the current text content happens in horizontal direction.
Comment 9 Regina Henschel 2019-06-21 15:16:01 UTC
Created attachment 152347 [details]
Example with absolute height of the shape and shape background filled
Comment 10 Gabor Kelemen 2019-06-24 10:03:18 UTC
(In reply to Regina Henschel from comment #8)
> Why is this marked as regression? In which version had it worked?
> 

In 6.2.x the position of the box was about the same as in Word. The rotation did not happen, but at least the box was placed approximately correctly. This was our reasoning to set this as regression.

We know this is still a work in progress from Miklos, that's why we post broken files (we have a lot from our users to check for regressions), to point out what is still missing.

At the same time: many thanks for your detailed analysis!
Comment 11 NISZ LibreOffice Team 2019-10-17 14:26:09 UTC
Created attachment 155090 [details]
Screenshot of the document in current Writer master

Looks pretty good in:

Version: 6.4.0.0.alpha1+ (x86)
Build ID: f0340d58cc0f2808ce8003099ff2a0495360f267
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: hu-HU (hu_HU); UI-Language: en-US
Calc: CL

Text box is still a bit too large, but position and rotation are now fixed.
Comment 12 Xisco Faulí 2019-10-17 14:40:37 UTC
Verified in

Versión: 6.3.3.1 (x86)
Id. de compilación: f41f4c7f9507aeca13cb9df51f34d80e8ba30a99
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded

Closing as RESOLVED WORKSFORME
Comment 13 Xisco Faulí 2019-10-17 14:46:53 UTC
Just for the record, this issue might has been fixed by the combination of https://git.libreoffice.org/core/commit/9c81d0a268cca4ff36eff94c0842361b9c0287ef and https://git.libreoffice.org/core/commit/ff17478e069cc82681df62514876c06365dd5cd6