Apache OpenOffice (AOO) Bugzilla – Issue 22765
Chapter management is non-intuitively solved
Last modified: 2017-05-20 10:11:35 UTC
Managing documents For me, it is of utter importance to have chapters. Not just chapters mentioned somewhere in the documentation or the online help system, but real chapters which I can find in the menus, most prominently located in the "Insert Manual Break.. " menu-item of the Insert Menu, or even in a document structure manager type of thing, and, finally in the OpenOffice Document - Contents document. Well, to cut things short. It is really a pain in the ass to manage chapters in a document, since this is in my opinion in no way intuitively solved. Somehow, chapters seem to be hard-codedly associated with the "Heading 1"-paragraph style. This is quite ingeneous in that you have to find out this very circumstance by playing the old trial-and-error game we are all so very fond of. Well, this makes me think of some other products produced by some big player out there, namely Microsoft and their previous versions of the Microsoft Office Suite. If their not-so-intuitive chapter (or rather section) management has finally been re-worked on stays questionable, but why does OpenOffice do such an awful job at it, when it is, IMHO, so easy to do? Instead of hard-coding the chapter status of a page by associating it with the "Heading 1"-paragraph style, why not simply extend the schema of the XML representation and add a text:chapter element to it? Then we could happily use the Heading 1 wherever we like and finally get rid of this tightly coupled and non-intuitively solved issue? This would even have positive influence on the document management, since then I could restructure the document based on chapters, and, while we're at it, perhaps even sections and subsections. My proposal is as such: Incorporate structural elements into the XML schema, besides the ones which are already there, namely: <text:chapter/>, which is derived from <text:p/>. Make the term Chapter available in the Insert-menu, by either having it in the "Manual Break"-menu item or by having it directly as a menu item of the Insert-menu. Allow editing of chapter properties, like name and so on, or perhaps associate this with the a newly to be created "Chapter Title" - paragraph style. This would correspond directly to the document Title paragraph style. Allow editing of section properties, like name and, you guessed it from the above, by associating this with a "Section Title" - paragraph style. This can be hard-coded at will, since they directly relate to each other. But please, no more ""Heading 1" provides both name and identity to the chapter". I guess that, after changing the internal representation of chapters and adding more information to the document will solve all pending issues regarding chapter naming, numbering, Page Styles forgetting their follow-up pagestyles, Page-Styles resetting to default after changing the first heading in the chapter, guess what, "Heading 1", and so on. Besides it would make your code more maintainable when dealing with either paragraphs, or chapters, and subsequently sections.
reassigned to bh
I heartedly agree that chapter management is unworkable and support needs to be elevated to something greater than obscure and essentially undocumented. [Note: "Chapter Name" and "Chapter Number" are *not* hard coded to Heading 1. The chapter information is set by virtue of Tools->Outline Numbering. Whatever style is in the level 1 "paragraph style" drop-down will be your chapber name. So if you have a marked-up document and you want "heading 2" to be your chapter naming style, do Tools->Outline Numbering, select level 1 and then change the paragraph style. Of course your heading numbers will all get renumbered etc.] In many ways this is worse. "The Single Outline" is thus a document wide structure instead of being a repeatable part of a document. In a larger sense, this "Feature" makes it impossible to "put a little outline in a sidebar" in the midst of your document (or in a particular chapter). "Outlines" should be insertable items, like tables. The presence of "outline numbering" as a document-wide feature is "bad". And no, restarting the numbering isn't a real solution in terms of the structural problems. The existing implementation "insists" that each document can contain only one outline, and that the entire document is part of that one single outline, but it leaves everything "before" the first instance of the first heading "orpahend" so there is leader-text and then "the real document"... or something. The thing that is currently controlled by the Tools->Outline Numbering logic should be renamed or something to make it "Document Structure" or something, and it should be anchored into the navigator. Then the term and feature set "Outline" should be reinstituted as a an insertable object. Or something... 8-) This goes to address some of the "hugely problematic" handling of some of more obvious Style Mark handling. For instance, try the following procedure: File->New->Text Document (Type random text) (select that text) Click "Header 1" in the stylelist Now, go to the beginning of the document and you just _*try*_ to insert something *before* that style block. There isnt a navagator or key sequence or menu item in the entire program that will let you do that. Pressing enter inserts a carrage return into the heart of that "one paragraph". This same behavior relocates manual breaks into the style elements that follow them. Consequently if you "do the natural thing" to put in a chapter break [ctrl-enter, type chapter name, mark chapter name as Heading 1, keep typing] then you go back and decide to replace the page breaks with odd-page/right-page breaks, you *invariably* loose the "Heading-1-ness" when you delete the page break. That is painful and wrong. Document features (Section Marks, Chapter marks [which shoudl exists], Page Breaks, etc) *MUST* exist at a level of abstraction which contains the paragraph styles etc, not some sort of compositing. If I do the show-hidden-things Backwards-Roman-P thing, I should be able to see and navigate amongst and select the breaks and marks and such as if they were object anchors. OpenOffice is great for short static work, but it can be vexing as all get out when working with something large and polymorphic. The number of times I have had to play style-patching-monkey to resturcture the whitespace (etc) in my novel to meet the various submission requirements of readers, editors, and publishers (who can be draconian as all get out) has shown the existing "break" and "chapter" and "section" handling to be quite flawed. And that was with straight prose. I have used OpenOffice for years, but I would never undertake writing a technical manual or text book with this software. [Ok, I would, and have, but I end up closing the navigator, ignoring the outlining features, Adding fantom carrage returns on either side of page breaks, and doing all sorts of "because I know better" procedures to circumvent the badness.] But now I just rant. So: Chapter Break Marks. Section Break Marks. Page Break Marks. All at a "outside" or "above" of "between" the "paragraphs" (or in special magical no-text-allowed paragraphs all their own, what with "the paragraph" being so central to the API, and yes, I've looked at trying to fix this but it is beyond me.) All Editable (and therefore targetable and selectable.) They are all breaks after all, you only need to be able to assign things like "chapter name" to the break itself the way you would assign variable text or other attributes. Whoops, ranting again... 8-)
OpenOffice.org Issue Tracker - Feedback Request. The Issue you raised is currently 'Unconfirmed' pending review, but has not been updated within the last 3 years. Please consider re-testing with one of the latest versions of OOo, as the problem(s) may have already been addressed. Either use the recent stable version: http://download.openoffice.org/index.html or consider trying the new OOo 3 BETA (still in testing): http://download.openoffice.org/3.0beta/ Please report back the outcome so this Issue may be Closed or Progressed as necessary - otherwise it may be Resolved as Invalid in the future. You may also wish to search for (and note) any duplicates of this Issue that may have advanced further by checking the Issue Tracker: http://www.openoffice.org/issues/query.cgi Many thanks, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".
Please attach example.
No info from author.