https://bugs.documentfoundation.org/show_bug.cgi?id=116403
Mike Kaganski <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|[email protected] |[email protected]
|desktop.org |
--- Comment #4 from Mike Kaganski <[email protected]> ---
https://gerrit.libreoffice.org/51388
The problem is not in DOC/DOCX, or in the compatibility mode mentioned in
comment 0.
When an index is (re)generated, every right-aligned tab in its tokens generates
a (manually-applied) tabstop position in relevant paragraph, which position is
calculated at the right text margin based on the layout. Further layout changes
don't update the tabstop, unless user updates the index (right-click->Update
index). The first problem (the real bug) is, that calculation of the position
does not take borders into account, regardless of compatibility mode.
Still, when the text area is/becomes narrower than the tabstop position (like
when right margin increases, or when borders exist), *without* the
compatibility mode, the problem is not apparent, since the out-of-textarea
tabstop is overriden by the textarea margin, so the number position gets to the
expected position dynamically (even no index update necessary). But with the
mode active, this becomes immediately visible.
One can check the problem with a new text document: add a heading and a ToC
with default settings; then decrease right page margin and see that page number
doesn't follow the margin (until index update).
So, to fix this first problem, the patch mentioned above simply considers
margins when calculating tabstop position, thus correctly setting it on index
creation/update.
The other thing is if we should also update the position dynamically after
changing margins/borders (or relayouting that could move the index to another
page with different margins/borders). This would be an enhancement, and should
be tracked separately; also, we should consider that user can manually change
the tabstops (when disabled the index protection; after modifications, the
protection could be restored). So, how would we go when the positions were
manually tweaked? dynamic update would destroy the overriden values.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
