https://bugs.documentfoundation.org/show_bug.cgi?id=60064
ajlittoz <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |UNCONFIRMED Ever confirmed|1 |0 --- Comment #9 from ajlittoz <[email protected]> --- There appears to be some magic with the ToC styles. Thanks for the tip, JBF. Is it mentioned somewhere in the manual? The workaround you present with an n-columns table is a solution for very simple cases with the penalty of numerous table management (I feel, without any proven argument, that tables induce complexity and some performance cost in a document. Thus the fewer the better (moreover, I experienced many compatibility problems with M$ Office). A less simplistic use case: --------------------------- When I prepare a specification or contract document, during the elaboration period, I need to comment the clauses and explain the rationale behind some choices. Visually, the document is 2-column, but since comments, new proposals and explanations have to be synchronised with text, tables are mandatory. The left-hand column contains the to-be-definitive text and the right-hand column various data with their own styles so that they are easily identified. This styling precludes the use of built-in "comment" feature and "revision" feature is OK for typos but not very handy when a full paragraph must be reworded. Lay-out or style is important, it is part of communication "art" and you spare time if your revised proposals are already styles as they should in the definitive version. But in this intermediate state, the 2-column format halves the available width and some tab stops may fall outside the table-column margin. This is important for tabular data when you want a tab stop some distance from the right margin (thus my simple example with ToC entry which was the closest approximation to my need). Another use case: ----------------- The same style may be use in different contexts (this may also translate to "lazyness"(1) against the document author). Say style "descriptive" is used in a "standard" section with "standard" margins. At some point, a table is used with an item name or reference in first column and a description in the second column styled as "descriptive". Once again, there is a risk of tab-stopping outside the cell. (1) It is possible to define a hierarchical style "descriptive in a table", with modified tab stops, depending on the original "descriptive", but you must define one for each table shape and width! This situation occurs every time your tab stop semantics is "some distance from the right margin". In the present LO implementation, this is specified as a manual computation "margin_width - desired_dist_from_right" which cannot follow margin changes because there is no way to tell LO this distance depends on some other document characteristics. It seems the magic for ToC styles does not apply to user styles. I tested it for all tab flavors (left-, center-, right-aligned). I admit that my proposal is something akin poor man's tables but tables and tabs are not two facets of the same underlying semantic feature and cannot be exchanged freely. In tables, you are locked in the cell geometry and overflow splits your paragraph or word onto the next line. With tab, the text fragment between tab characters may occupy adjacent space if it is empty; an "unused" tab stop is skipped without adverse effect on lay-out. The aim of this feature request is to decrease the document maintenance cost and try to keep the company standard style dictionary standard, i.e. preventing people from fiddling with it (sure, for good reasons) resulting in deviation from the standard lay-out rules. Are my arguments clear enough? -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
