Created attachment 76233 [details] example of two frame bugs (1) take the attachment, put the cursor in front of "here" and hold Delete. Desired behavior: everything after it gets deleted incl. the frame 2 on p. 2, but instead frame 2 gets put onto p. 1. Thus, if one ahs a document with many frames and wants to delete many pages with many frames, one has to all delete them one by one, which is counterintuitive (2) Put the cursor in front of XXX1 in the table and insert a frame. Even if you set the background of the frame to No Fill, the resulting frame has the same background shading as the cell to which it is attached (see frame 3). This is annoying because it means I can't attrach frames where they belong - i have to cheat and anchor them to the page so they have no background.
PLEASE keep bugs separate, these are two different bug reports. I am investigating item #1, item #2 should be reported as a separate bug.
hm...I don't see "here" anywhere on the document. Can you clarify where to put the cursor?
Oops, sorry, here it is.
Created attachment 76731 [details] Attachment now with "here"
This is a tough one, I believe that the current behavior is intended but indeed could use some work to make it better so, here it goes for triaging. I can confirm that this is a valid enhancement request on: Version 4.1.0.0.alpha0+ (Build ID: b514f0ce86e85d9be269ddf2e797befbbf3423f) Date: Thu Mar 7 21:46:30 2013 +0200 Platform: Bodhi Linux 2.2 x64 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As I've been able to confirm the enhancement request I am marking as: New (confirmed) Enhancement High - would make dealing with documents with multiple frames much much easier. I think frames are used often enough to set this to high, also current behavior is very counter intuitive + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
more of an update, it seems like this is not just for text frames, OLE objects in general, images, etc... all have this behavior. Makes me more sure that this is intended (not sure why, developer may have better insight) Updating title
This bug (now solved it seems, but sort of - see below) particularly effects legal documents where marginalia are used for per paragraph numbering. Refer to the odt and other attachments to the following bug to see what I mean: https://bugs.documentfoundation.org/show_bug.cgi?id=101753 This bug #62071, in its technically specific description, appears to have been solved - for example try opening the .odt attachment to the bug listed just above and go the end of one of the paragraphs, and press delete - the subsequent frame is deleted, AND the following paragraph is joined onto the current paragraph. However, the way this works I think ought to change, to keep the improvement of the LO implementation, but to also include the improvement from the MSWord implementation: In WordXP, when at the end of a para and where the "next" para is actually the marginalia ("legal para numbering") for the subsequent para, pressing <DELETE> does nothing! That's bad. The current (at least LO5.2) LO implementation is definitely more functional, and thus better - delete does something quite useful! HOWEVER, in WordXP, when I am at the end of a para and where the "next" para is actually the marginalia ("legal para numbering") for the subsequent para, pressing <RIGHT> moves the cursor to the beginning of the marginalia para (the para in the "marginalia frame") - again, see the attachments to #101753! - then going to the end of the marginalia (framed) para, then press <RIGHT> again, and the cursor ends up at the beginning of the subsequent paragraph. My experience in WordXP includes the creation, editing, modifying and manipulating via macros, the sum total of over 10,000 of these "marginalia" paragraphs, and the ability to use cursor movement, and having WordXP treat these marginalia paras as "just normal paras" is a huge editing and efficiency win! WordXP allows me to do a lot of things in macros, from fine tuning the refernces in the marginalia, both content and style, whilst jumping back and forth between the marginalia para and the subsequent or any other related para (with the marginalia para being a "ref" or "numbered reference" to its associated subsequent para). This is very common in legal documents. My (volunteer) job at the moment is to convert 10,000 of these marginalia paras into LibreOffice, and learn LibreOffice while I'm at it. When I look at the XML of the LO document, the marginalia paras (at least, so far as they are imported from a .doc 2003 document) are sequenced in between the other paras - so the logical text flow exists, what is needed is really only the final UI tweak of allowing RIGHT and LEFT arrow to --include-- the marginalia (framed) paras. Basically, when a framed (marginalia) para is anchored to another para, it should be considered to be in sequence logically immediately prior to the para to which it is anchored. The question becomes what to do in cursor movement and text logical sequencing, when framed text paras are anchored to char, page or some other object: From a macro developer perspective (aka end user solving various difficult problems perspective), the options should be made available in the gui/menus/etc, so that any particular macro (or normal editing) can choose to include and disclude various types of framed text, including anchored-to-para "marginalia", as needed. We should not limit what the end user can accomplish.
My bug/ feature enhancement, which goes over and above this bug as it stands, now has its own bug report - bug #101765 . So the present bug #62071 can be marked "solved".
Changing priority back to 'medium' since the number of duplicates is lower than 5