This missing functionality exists in Microsoft WordXP (2002/2003 possibly earlier) and it is for me a bug due to slow down for me, of my editing of large legal documents (I do this as a volunteer).
In particularly this effects legal documents where marginalia paragraphs are used for per paragraph numbering - in this situation, the marginalia in LO must be created with Frame style (that's ok per se), but such paragraphs, unlike as in WordXP, cannot be simply navigated through (and therefore simply edited and simply manipulated inside LO macros) with the cursor, from or to the previous (non marginalia) para, nor to or from the subsequent non-marginalia para.
Refer to the odt and other attachments to the following bug to see a simple and clear example of what I am referring to:
Also, bug #62071, is related and I believe VERY SIMILAR in terms of developer impact/effort (should be relatively low, now that bug #62071 has been solved - cursor movement is almost trivially similar).
LO's solved bug #62071 is an improvement over WordXP, and should be kept (of course), but also the MSWord implementation of cursor movement between sequential paragraphs, both normal as well as "marginalia" paras (in LO, "framed" paragraphs).
Explained in minute detail in case useful:
- 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! This new LO functionality should definitely be kept.
- 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.
This makes editing of large legal documents (think 1000 pages) over many months, bearable!
This also makes creating macros to do certain "marginalia" editing, possible (as at LO4.3 I cannot select next "marginalia" frame, from a macro (at least, I haven't figured out how to do this yet)) - so FOR ME, this is a significant bug and estoppel to using LO for the documents I must work on.
(My experience in WordXP includes the creation, editing, modifying and manipulating via macros, the sum total of over 10,000 of these "marginalia" paragraphs in one particularly large document, and the ability to use cursor movement between them and "normal paras", and having WordXP treat these marginalia paras as "just normal paras" is a huge editing and efficiency win! Oh, and also makes it possible to script certain types of changes in macros - THAT's a deal breaker for me (i.e. bug stopping me from using LO).)
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 if possible, and move all our association's documents to LibreOffice while I'm at it - IF possible.
When I look at the XML of the LO document in bug #101753, 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. This should be easy since DELETE now works to delete objects other than "normal paras" - see bug #62071 .
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 (or similarly, to exist logically, for the purposes of cursor movement, between the previous and subsequent paras).
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 option should be made available in the gui/menus/etc (so that any particular macro (or normal editing) can make use of this "natural sequencing") to choose to:
- or DISclude
various types of framed text or other objects, including anchored-to-para "marginalia", as needed.
We should not limit what the end user can accomplish of course.
Sure there is navigation, just not by cursor movement. You can point to and select the Text Frame object, and once selected can edit the text content of the object.
The Text Frame object holding the "marginalia" has no linkage in the internal LibreOffice writer canvas, nor in an ODF Text document. That facet alone is what is missing in how LibreOffice handles them and seems a reasonable enhancement if it can be captured into the ODF.
Would note that in MS Word the "marginalia" are also anchored frame objects-that can be seen in the attached conversions (Word2007/12 & Word2016/16) I've done of attachment 127046 [details]. They are not "paragraphs" from the Word perspective either--although WordXP and the later releases provide a chained linkage between the text and the frames. Allowing cursor movement between paragraph and frame object.
Also, would note that the LO import parsing of the the MS Word2002/10 binary, or OOXML conversions (12,14,16) simply retains no positioning details for the imported Text Frame objects--the anchor is correct, but the "miror on even pages, outer paragraph border" horizontal positioning you "corrected" it with is not applied. The frame is positioned at the anchor--suspect that facet of the LibreOffice ww8 import filter can be corrected.
WordXP is rather old (2002) and has many MS proprietary behaviors. Subsequent MS Office releases have moved the Microsoft platform to a more standards compliant posture with better support for their own OOXML and importantly for interoperability implement support for ODF standards. Opening the older document in a more recent build of Word and then a save as export to ODF may be your better means of conversion.
OfficeXP/10, Office 2003/11, Office 2007/12, Office 2010/14, Office 2013/15, Office 2016/16 -- the codename or version is reflected in the directory structure and configuration details for the release. A document prepared with one of the releases will reflect the release in its meta data.
Created attachment 127057 [details]
test document converted to OOXML from Word 2007
Created attachment 127058 [details]
test document converted to OOXML from Word 2016
Any comments of feasibility of supporting chained linkages between paragraphs and text frames?