Bug Hunting Session
Bug 112704 - Add ability to "fix" badly imported floating tables with a single click
Summary: Add ability to "fix" badly imported floating tables with a single click
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: DOCX-Tables DOC-Tables
  Show dependency treegraph
 
Reported: 2017-09-27 21:33 UTC by Aron Budea
Modified: 2019-03-12 13:18 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Badly saved DOC (18.00 KB, application/msword)
2017-09-27 21:33 UTC, Aron Budea
Details
Original file for reference (35.50 KB, application/msword)
2017-09-27 21:38 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2017-09-27 21:33:32 UTC
Created attachment 136570 [details]
Badly saved DOC

LibreOffice has trouble importing floating tables when they span over multiple pages. Usually these aren't floating tables on purpose, just happen to be set that way, possibly automatically by Word upon certain actions.

Fixing badly imported tables is tedious:
They're imported in a frame that can't go over page boundaries, so one has to copy the table, paste it outside the frame and then remove the frame.
However, it's important to fix them, since badly imported tables stay that way once saved in Writer.

Therefore it'd be very helpful if the user could fix such tables with a single click eg. from the table menu or from inside the table properties dialog. It would only be applicable to tables in a frame, and could be named something like "Remove enclosing frame" (then again, people might not even know a frame is involved, so it might be named better).

Attaching a sample DOC as it's badly saved in LO 5.4.1.2 and the original.
The import of the original document is fixed in master, but the roundtripped file will remain incorrect without a manual fix.

UX team, please consider where/if this feature could be added.
Comment 1 Aron Budea 2017-09-27 21:38:17 UTC
Created attachment 136571 [details]
Original file for reference
Comment 2 Heiko Tietze 2017-10-01 08:57:11 UTC
The tip with 'import works in master' was helpful.

What I don't understand is why we should find a mechanism for broken content when the roundtrip could be fixed so that nothing breaks.

Second idea, if there is some good reason for such a feature: In the table properties dialog we have an option "Allow table to split across pages and columns". Users may expect auto-repair by unchecking this option, which is not happening because of the frame I guess. But can't we modify this function and remove the frame? Perhaps after confirmation.
Comment 3 Aron Budea 2017-12-03 05:31:39 UTC
Oops, forgot to reply, my bad.

(In reply to Heiko Tietze from comment #2)
> What I don't understand is why we should find a mechanism for broken content
> when the roundtrip could be fixed so that nothing breaks.
Fixing the roundtrip, eg. adding support to floating tables would be quite some work (I don't have an estimation, though). The tuning of heuristics are for relatively specific cases, and a new one can pop up anyime, eg. bug 114217 surfaced just now.

> Second idea, if there is some good reason for such a feature: In the table
> properties dialog we have an option "Allow table to split across pages and
> columns". Users may expect auto-repair by unchecking this option, which is
> not happening because of the frame I guess. But can't we modify this
> function and remove the frame? Perhaps after confirmation.
I'm a bit afraid that adding extra "hidden" functionality to that checkbox is something that might elude users, I'd prefer it as a separate frame-removing button (or maybe have both). I guess that'd also have more impact on the UI, which might be undesirable...
Comment 4 Heiko Tietze 2017-12-04 09:51:12 UTC
How about using the infobar with label/button "The imported table is likely not well placed in the document. Fix automatically? [Yes] x", assuming you can make a good guess about broken import and the probability for false positives is low.
Comment 5 Aron Budea 2017-12-05 01:34:01 UTC
If that's doable, then it sounds good to me. I don't know anything about implementation details or difficulties, so I can't comment on whether that can be feasibly implemented, or if there are pitfalls to it.

Mike, could you share your thoughts on Heiko's suggestion?
Comment 6 Aron Budea 2017-12-12 07:55:03 UTC
I talked to Miklos about this in the meantime, he said this sounds feasible, at the time when the user clicks into a table it can be determined if the table fits in the frame or not.

The other direction of this functionality is already implemented: a table can be enclosed in a frame by selecting it, and inserting a frame.
Comment 7 Heiko Tietze 2017-12-12 08:46:18 UTC
(In reply to Aron Budea from comment #6)
> I talked to Miklos about this in the meantime, he said this sounds feasible,
> at the time when the user clicks into a table it can be determined if the
> table fits in the frame or not.
> 
> The other direction of this functionality is already implemented: a table
> can be enclosed in a frame by selecting it, and inserting a frame.

Perfect, so let's take this as input from UX. Feel free to check back at any time.
Comment 8 Mike Kaganski 2017-12-18 13:34:59 UTC
I suppose that using an infobar is a bad idea. Table in a frame is not something "wrong", such that most possibly requires fixing. Yes, the cases that need the fixing are numerous enough that we would better have the feature to convert tables-in-frames to ordinary tables (until we have a proper floating tables support, which will take quite some time); but popping up an infobar on entry to such a table will bring content jumping (similar to one that we had when table and lists context-sensitive toolbars were attached to top, which was intrusive enough to reconsider their placement to the bottom of window). So, this would make the life of those who work with such floating objects routinely more difficult.

I suppose that the functionality is close enough to "Convert text to table/table to text" in its spirit; it deserves a place in table menu, and possibly a button on a toolbar, where it might hide, of course, but it's not a big problem.
Comment 9 Heiko Tietze 2017-12-18 14:01:25 UTC
(In reply to Mike Kaganski from comment #8)
> I suppose that using an infobar is a bad idea...
> ...
> I suppose that the functionality is close enough to "Convert text to
> table/table to text" in its spirit; it deserves a place in table menu...

True, if you spread badly formatted table over your documents ;-). On the other hand, who expects a 'Fix me' command in the context menu?
What we can do is to overlay the infobar, i.e. make it semi-transparent and draw it above the normal content (shouldn't be too hard) or to pop-up the infobar at the bottom. And of course we could also introduce a '[ ] Never ask again' checkbox plus your entry at the context menu.
Comment 10 Mike Kaganski 2017-12-18 14:19:49 UTC
(In reply to Heiko Tietze from comment #9)
> (In reply to Mike Kaganski from comment #8)
> > I suppose that using an infobar is a bad idea...
> > ...
> > I suppose that the functionality is close enough to "Convert text to
> > table/table to text" in its spirit; it deserves a place in table menu...
> 
> True, if you spread badly formatted table over your documents ;-).

This is getting a little bit subjective. There are legitimate use cases that require that (or tell me what's wrong with https://tex.stackexchange.com/questions/49300/wrap-text-around-a-tabular, or how can I avoid formatting table using a frame in Writer to get that).

> On the other hand, who expects a 'Fix me' command in the context menu?

Who mentioned *context* menus? I meant the usual Table item in the main menu.

Also: who thinks of this option as a "Fix me" option? Well, the OP does. But it's just a use case for the option. Making a table floating/non-floating is a matter of choice in process of document layouting. We can mention in FAQ that the option can be used for fixing badly imported documents. That's enough. I don't see a reason to make this that prominent. Also, making it prominent will emphasize the deficiency in a wrong way, making an impression that we don't want to do it "the right way", but instead force users to fix it afterwards manually themselves (as if we were saying "there's no bug in your bad import; here's a tool to polish the result; no need to file bugs or complain").

> What we can do is to overlay the infobar, i.e. make it semi-transparent and
> draw it above the normal content (shouldn't be too hard) or to pop-up the
> infobar at the bottom. And of course we could also introduce a '[ ] Never
> ask again' checkbox plus your entry at the context menu.

Well, whatever design team deems appropriate. I'll try to add the function and a menu entry; for details on more visible placement, there could be a follow-up.
Comment 11 Heiko Tietze 2017-12-18 16:06:50 UTC
Thought we talk only about tables that spawn over pages, easy to detect as badly formatted. The infobar would pop-up only when the frame does not fit into the actual page. Thing is that the attached example baffles most users (hypothetically, you are right) and they do not have any clue how to fix it. If you think about a proper implementation of wrapping similar to shapes or images- be my guest.
Comment 12 Aron Budea 2019-02-04 00:34:42 UTC
Most of this feature has recently been implemented by Tamas Zolnai. Currently the way it works is that if the user clicks on the frame of such a table (the criteria currently is that the table would overflow the page), a button appears at the bottom end similar to the insert header/footer ones, and clicking it performs the frame removal.

The feature is completely functional as is, further improvements are up for debate, my personal thoughts would be:
- move the button to the top edge instead of the bottom one,
- find a different name for the button, "Un-float Table" is very technical wording, users won't know what it means,
- add the functionality to a menu somewhere so it can be performed in all framed tables, not just bad ones (I'd opt for a context menu).

Whether it's better to have the function belong to the frame or to the table is not straightforward. The frame seems to be fine to me now, the only drawback is that the user specifically has to click on the frame for the button to appear.

One reason I prefer the frame as the target is that all kinds of texts/objects can be put in frames, so the function wouldn't necessarily only be for tables (though I imagine that affecting very few people).

The central point is, it has to be prominent and easily accessible for the badly imported tables, and currently it is.
Comment 13 Roman Kuznetsov 2019-02-04 13:08:32 UTC
(In reply to Aron Budea from comment #12)
>....
> my personal thoughts would be:
> - move the button to the top edge instead of the bottom one,

of course, I agree

> - find a different name for the button, "Un-float Table" is very technical
> wording, users won't know what it means,

I suggest "Normalize table" or "Fix broken table"

> - add the functionality to a menu somewhere so it can be performed in all
> framed tables, not just bad ones (I'd opt for a context menu).

Add into Table menu item "Normalize all table" or "Fix all broken table" that will be active only for DOC/DOCX files with "float" tables
And add the same item into context menu too

> Whether it's better to have the function belong to the frame or to the table
> is not straightforward. The frame seems to be fine to me now, the only
> drawback is that the user specifically has to click on the frame for the
> button to appear.

May be this button should show when you click into any cell in table.