The present semantics for tab stops require extensive manual editing when changing the final document size or orientation to keep the layout in sync with the intended design (e.g. switching from DIN to US format or from portrait to landscape). A simple example in TOC (table of contents) A TOC entry has 3 components: section number, title and page number. To nicely align these components, a style with 2 tab stops is defined: the first one as, say, 2cm, left align; the second as 17cm (DIN A4 - two 2cm page margins), right align. Now, document is switched to landscape. The style must be edited to change the second tab stop to 27.7cm. If the document is transmitted to the US, style must again be updated for US stationery. This trouble could be avoided if tab stops were relative to some user-defined origin position instead of the default left margin (in left-to-right writing systems; transpose for RTL). This origin should be user-positioned anywhere between the margins of the current paragraph as a percentage: 0% means left margin, 50% center, 100% right margin, etc. By default, tab stops are relative to origin 0% (compatible with the present design). TOC example solved as: first tab stop unchanged at 2cm, origin 0%, left second tab stop at 0cm, origin 100%, right I do not think values outside 0-100% should be allowed because you cannot rely on proportions between the current paragraph dimensions and the gutter, page, ... However, this does not preclude tab stops from having negative coordinate or big positive values to set text in the left/right margins or gutter. With such an attribute, whenever an area (page, table, table cell, paragraph, ...) definition change occurs, absolute tab stop coordinate are recomputed and the intended layout is kept without user intervention. This feature could even be refined to be document-designer-friendly: if the origin position is itself named (i.e. styled like bullet or numbering styles), experimenting with layout can be very easy. Again an example: Presenting a list of words in tabular form with a leading term at the left and two associated terms to be set symmetrically from some position. This is solved as: - tab stop at 1cm, 0%, left (or no tab stop) - tab stop at -1cm, 75%, right - tab stop at +1cm, 75%, left If the 75% origin has a name/style, the 75 number can be adjusted in a single place to try for the value giving the best layout instead of adjusting individual tab stops. Thank for comments ajlittoz
Can you please provide a test document so this can be tested against and subsequently be confirmed. Setting to NEEDINFO until more detail is provided. After providing the requested info, please reset this bug to UNCONFIRMED. Thanks :)
Created attachment 89707 [details] Writer sample document with word flushed at right margin when A4 portait
What kind of test document do you need? This is an enhancement request for a feature which is not presently offered by Writer. A sample document could be built like this: - create a new A4 portrait document - insert a line containing A (tab) B - give this line a named style, e.g. "Custom" based on "Default" - modify tabs in "Custom" style: create one right-aligned tab at right margin Result: "A" is flushed at left margin, "B" at right margin. Save document, re-open it. Format->Page, change to A4 landscape. Result: "B" is no longer at right margin and stays 17cm from left margin, as per definition. My intent was to keep "B" flushed at right margin, but this is not possible in the present implementation since ALL tabs are relative to left margin. This requires to attach a new property to a tab definition (its coordinate origin).
It is worth noting that for this request to be possible it would require amending ODF and, if interoperability with OOXML is to be maintained, conversion of these percentages to the calculated twentieths of a point equivalent. In ODF v1.2 the style:position attribute in relation to the style:tab-stop element (19.508.3) uses the XSL specification definition for Units of Measure: http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N8185-Definitions-of-Units-of-Measure i.e., centimetre, millimetre, inch, point, pica, pixel, em I suppose this could always be augmented somehow to allow percentage values, although these may ultimately need to be calculated in the internal measurement of LO (fractions of millimetre?) anyway. An separate percentage value (in additional to the scalar value) may be an option, although this would seem to increase conversion complexity. In the OOXML spec the w:pos attribute in relation to w:tab element (17.3.1.37) uses Signed Measurement in Twentieths of a Point (17.18.81 ST_SignedTwipsMeasure) appears to be used. Any percentage value would need to be translated to this unit for export.
Due to comment 4, I feel we need an OOXML / ODF expert to assist with this one. Whiteboard keywords "odf" and "ooxml" added. Status set to NEEDINFO.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team Message generated on: 2015-02-18
This is not a bug but a feature request. Is there a specific section somewhere in documentation.org where such a request would fit? I already provided in comments #2 & 3 a use case for this feature. I can prepare a more relevant test case if you better describe what you need. IMHO, the very simple example provided is descriptive enough of the intended feature semantics. I am aware that implementation is not that simple as ODF specification seems to be impacted. However, this feature would improve LO usefulness and partly bridge the gap between document processing and desktop publication. Temporarily restore NEEDINFO to avoid erasure while waiting for feedback.
(In reply to ajlittoz from comment #0) > [...] > A simple example in TOC (table of contents) > A TOC entry has 3 components: section number, title and page number. To > nicely align these components, a style with 2 tab stops is defined: the > first one as, say, 2cm, left align; the second as 17cm (DIN A4 - two 2cm > page margins), right align. > Now, document is switched to landscape. The style must be edited to change > the second tab stop to 27.7cm. If the document is transmitted to the US, > style must again be updated for US stationery. I disagree. If you did choose right align for the tab stop in the ToC dialog, it is enough to update the ToC (right click on the ToC area and choose update index). I did the following test with LibreOffice 4.4.2.0.0+: 1/ open a long text document with ToC and using several page styles, all in portrait 2/ edit each page style to switch it to landscape 3/ menu Tools > Update > Update All Current behavior: the ToC is updated as expected, page numbers updated and right aligned on the right margin. Test case in comment #3 is not a real life test case. It can easily solved if you avoid to use tabstops but use, for example a section or a table with 2 columns and a paragraph right aligned. Please, could you describe a test case from the real life for which you think the solution you propose is the best way to manage it? From my side, I can't imagine one, so I propose to close this enhancement as WONTFIX. Set status to NEEDINFO, please set it back to UNCONFIRMED once youo have provided requested information. Best regards. JBF
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?
(In reply to ajlittoz from comment #9) > There appears to be some magic with the ToC styles. Thanks for the tip, JBF. > Is it mentioned somewhere in the manual? You should read the documentation and ask for help on users mailing-list before asking for change in the OpenDocument format. I still disagree with you. Please attach a real document (without confidential data) showing the kind of document you want to produce. Best regards. JBF
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO Message generated on: 2015-09-03