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.
Created attachment 136571 [details] Original file for reference
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.
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...
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.
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?
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.
(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.
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.
(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.
(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.
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.
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.
(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.
So the functionality is now implemented. Possibly it might be closed; but IMO usability is suboptimal (one has to know exactly what and where to look, and specifically click to the invisible frame to spawn the button). I suggest again to add (in addition to the already implemented button) a menu item under Edit, which would allow to "un-frame content", i.e. when cursor is inside any frame, it would allow simply move the frame content into the main text body (exactly what the button does for the table, but generalized into any frame content). Making this a general-use function.
FTR, the commits implementing the button: https://git.libreoffice.org/core/+/021c3a0ee1c95a1b0b8e7c72f9d8e81718862a62 https://git.libreoffice.org/core/+/6e5c4001c7b5cab2b2cc6419072acbe5fa7cb04a https://git.libreoffice.org/core/+/9c4a374baa4d18dec4066e547d76a40501b20d45 https://git.libreoffice.org/core/+/dcf70bb4188e019154d6201936bf1ee2e16149a3 https://git.libreoffice.org/core/+/9a115beac9a13ae320a9abf578be25bfbff1e02d https://git.libreoffice.org/core/+/dd0b559d6aac5bf09566af735bd00b28c00fb2e4 https://git.libreoffice.org/core/+/b0c758b407deea0d87b51687601af48126d871c9 https://git.libreoffice.org/core/+/5fce6efe346c38d17b933641422c98c9cfe54069 https://git.libreoffice.org/core/+/70c29e50af8e16b864d1e5e5a74c30a1de8250de https://git.libreoffice.org/core/+/9d319865f8bf78d25ca2e614d148420054a6461a https://git.libreoffice.org/core/+/743b0a92acc3d1850f4890efaa706098ebf9f558
Created attachment 156348 [details] Screenshot with the current implementation (In reply to Mike Kaganski from comment #14) > I suggest again to add (in addition to the already implemented button) a > menu item under Edit, which would allow to "un-frame content", i.e. when > cursor is inside any frame, it would allow simply move the frame content > into the main text body (exactly what the button does for the table, but > generalized into any frame content). Making this a general-use function. As a generic function yes. But I would disagree with is a special menu item for very rare cases. The button itself is not so bad, IMHO, but it shows up only for the frame and not the table, eg. with the context menu. The question is: As an ordinary user do I care about frames? If we have "Un-frame table" in the context menu (hidden when the function not applies in the current context) it might be more clear what happens. We could rename it to "Split table across pages", not sure this is technically correct. Btw, the operation is not undoable and requires by that a confirmation dialog.
The button is new in 6.3, but no mention in 6.3 release notes
@Tamás, Áron, Mike: the new button/function works very well in the master, too. Is it possible to close this issue?
Sounds fair, the functionality is there and working. Let's mark this done, and track further usability improvement ideas in a different enhancement.