Bug 154585 - FILEOPEN DOCX table in vertical page layout has zero height because frame has zero height
Summary: FILEOPEN DOCX table in vertical page layout has zero height because frame has...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx, implementationError
Depends on:
Blocks: DOCX-Tables Vertical-Text China-Minority-Scripts
  Show dependency treegraph
 
Reported: 2023-04-03 14:02 UTC by Regina Henschel
Modified: 2024-10-03 16:59 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Table on east asian vertical page (17.61 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2023-04-03 14:02 UTC, Regina Henschel
Details
table on mongolian vertical page (17.59 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2023-04-03 14:04 UTC, Regina Henschel
Details
DOC equivalent (27.50 KB, application/msword)
2024-09-27 14:55 UTC, Miklos Vajna
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2023-04-03 14:02:15 UTC
Created attachment 186441 [details]
Table on east asian vertical page

Open attached documents in Word to see how the layout is there.
Open attached documents in Writer. The table has zero height because the frame, which contains the table, has zero height. When drag the frame to a meaningful height you see, that the table itself exists.
Comment 1 Regina Henschel 2023-04-03 14:04:11 UTC
Created attachment 186442 [details]
table on mongolian vertical page

Remark: To generate vertical page layout in Word you need to install corresponding language packs in Windows.
Comment 2 Buovjaga 2023-04-06 12:04:21 UTC
Confirmed

Arch Linux 64-bit, X11
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 79e60bb93f69370f23010adb078b5a5de5a1e7b2
CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 6 April 2023
Comment 3 Buovjaga 2024-09-27 14:36:17 UTC
Testing with attachment 186441 [details], the table was fully visible before the range of commits (between last40onmaster and last36onmaster in Linux 43all repo): https://git.libreoffice.org/core/+log/c3aa1cefdc6521d34a2a32c20bae1593e1edb5ba..c29af1572ad15ac5199a09e5812fb8354c165329

After the range, it became clipped, but it's edge could be seen and it had normal height. The commits starting with n#775899 seem relevant as they are about tables in frames.

The state continued as showing the edge of the table, changing a couple of pixels along the way. Then in 5.2 commit fd61dee6457a44687f1142dd55bfee6b64fda2ef (tdf#99140 DOCX import: fix table horizontal aligment to be 'from left') made much more of the table visible.

In 6.1, commit e87cc12eaf53efa9b221eae7167ea15bc7896752 (tdf#106390 Intersect the table borders with upper frames) changed the state to the edge only being visible again.

In 7.6, commit ce3308a926f036b87515b8cd97d2b197063dc77a (tdf#61594 sw floattable: import floating tables as split flys by default) made even the edge invisible.

If we use the Navigator, Jim's highlighting code will show us the edge of the table in the canvas, if we hover over the entry.

Miklós, any thoughts on this saga?
Comment 4 Miklos Vajna 2024-09-27 14:55:44 UTC
Created attachment 196748 [details]
DOC equivalent

The current failure seems to be a DOCX import issue, at least the DOC import with this sample seems to import fine. Seeing the quite impressive investigation above, I assume we broke this with Mark.

Tag as implementation error from the "sw floattable" work? I don't mind looking at this, but there is e.g. bug 161001 or bug 162730 that I need to fix first.