Legal numbering is a way to influence the number format of values inherited in a multi-level
numbering. Say, the outer numbering uses Roman numerals and the inner numbering uses X.Y as the number
format, but the inner level wants to display the outer values as Arabic numerals. If this is wanted
(and guessing from the name, sometimes lawyers do want this), then the inner number portion will
expand to values like "2.01" instead of "II.01", while the outer number portions will remain values
like "II".
Mike did 80% of the work, what you can
see here is just the RTF/DOC filters.
Picking a smaller feature task like this looked like a good idea, since I wanted to spend some of
the time on regression fixing around last year's multi-page floating table project.
It shows how the outer "II" gets turned into "2", while it remained "II" in the past. This works for
both loading and saving.
The same feature is now handled in the RTF filter as well. There the relevant detail is the
\levellegal control word, which has an odd 1 default value (the default is usually 0). Here is the
result:
You can get a snapshot / demo of Collabora Office 24.04 and try it out yourself right now: try the
unstable snapshot. Collabora
intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all
of this work will be available in TDF's next release too (24.8).
This post describes some challenges around having multiple views of one opened document in
LibreOffice core, when those views belong to LOK views, representing different users, with their
own language, locale and other view settings.
This work is primarily for Collabora Online, but is useful for
all clients of the LOK API.
LOK views are meant to represent separate users, so we need to make sure that when a user sets their
preferences and trigger an action, then the response to that action goes to the correct view, with
the correct view settings.
This is different from the desktop LibreOffice use-case, where multiple windows are still meant to
share the same user name, language, undo stack and so on.
In this post, I would like to present 4 small improvements that recently happened to the LOK API to
provide this wanted separation of views.
The first was an issue where two users were
editing the same document, one busily typing and the other clicked on a link in Calc. What could
happen sometimes is the link popup appeared for the user who typed, not for the user who clicked on
the link:
This specific problem can be fixed by making sure that link click callbacks are invoked
synchronously (while the clicking view is still active) and not later, when the current view may or
may not be the correct one.
It turns out the same problem (async command dispatch) affects not only hyperlinks, but many other
cases as well, where we want to stay async, for example, when one dialog would invoke another
dialog, like the Calc conditional format -> add dialog:
There you don't want to change async commands into sync commands, because that may mean spinning the
main loop inside a dialog, resulting in nested main loops. This can be fixed by making sure that
async commands to be dispatched (sfx2 hints in general) are processed in a way that the current view
at dispatch & processing is the same, which is now the case.
The third problem was around wrong language & locale in the status bar:
This is not simply a problem of missing translation, the trouble was that the status bar update is
also async and by the time the update happened, the locale of the view on the left was used, for a
string that appears on the right.
The way to fix this is to perform the update of toolbars/statusbar/etc (in general: SfxBindings) in
a way that the language at job schedule time and at UI string creation time is the same.
The last problem was quite similar, still about bad language on the UI, but this time on the
sidebar:
This is similar to the statusbar case, but the sidebar has its own executor for its async jobs, so
that needed a fix similar to what the statusbar already had, now done.
You can get the latest Collabora Online Development Edition 23.05 and try it out yourself right now:
try the development edition.
Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we
expect all of this work will be available in TDF's next release too (24.8).
Previous posts described the hardest part of multi-page floating tables: making sure that text can
wrap around them and they can split across pages. In this part, we'll look at a case where that
content is not just text, but the wrapping content itself is also a table.
Regarding testing of the floating table feature in general, the core.git repository has 92 files now
which are focusing on correct handling of floating tables (filenames matching
floattable-|floating-table-). This doesn't count cases where the document model is built using C++
code in the memory and then we assert the result of some operation.
Here are some screenshots from the improvements this month:
The first screenshot shows a situation where the mouse cursor is near the right edge of the first
page of a floating table. What used to happen is we found this position close to the invisible
anchor of the floating table on that page, then corrected this position to be at the real anchor on
the last page. In short, the user clicked on one page and we jumped to the last page. This is now
fixed, we notice that part of the floating table is close to the click position and we correct the
cursor to be at the closest position inside the table's content.
The next screenshot shows a floating table where the content wrapping around the table happens to be
an inline table. You can see how such wrapping didn't happen in the past, and the new rendering is
close to the reference now.
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the
unstable snapshot. Collabora
intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all
of this work will be available in TDF's next release too (24.8).
Previous posts described the hardest part of multi-page floating tables: reading them from
documents, so we layout and render them. In this part, you can read about UI improvements when it
comes to creating, updating and deleting them in Writer.
Regarding testing of the floating table feature in general, the core.git repository has 89 files now which are focusing on correct
handling of floating tables (filenames matching floattable-|floating-table-). This doesn't count
cases where the document model is built using C++ code in the memory and then we assert the result
of some operation.
Here are some screenshots from the improvements this month:
The first screenshot shows that the underlying LibreOffice Insert Frame dialog is now async
(compatible with collaborative editing) and is now exposed in the Collabora Online notebookbar.
There were other improvements as well, so in case you select a whole table and insert a new frame,
the result is close to what the DOCX import creates to floating tables. This includes a default
frame width that matches the table width, and also disabling frame borders, since the table can
already have one.
The next screenshot shows an inserted floating table, where the context menu allows updating the
properties of an already inserted floating table, and also allows to delete ("unfloat") it.
Several of these changes are shared improvements between LibreOffice and Collabora Online, so
everyone benefits. For example, inserting a frame when a whole table was selected also cleared the
undo stack, which is now fixed. Or unfloating table was only possible if some part of the table was
clipped, but now this is always possible to do.
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the
unstable snapshot. Collabora
intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all
of this work will be available in TDF's next release too (24.2).
Multi-page floating tables always wrapped their anchor text only on the last page, to be compatible
with Word's default behavior. There is a special flag in DOCX files to wrap on all pages, though. In
this part, you can read about handling of this flag in Writer.
Regarding testing of the floating table feature in general, the core.git repository has 84 files now which are focusing on correct
handling of floating tables (filenames matching floattable-|floating-table-). This doesn't count
cases where the document model is built using C++ code in the memory and then we assert the result
of some operation.
Here are some screenshots from the fixes this month:
The first screenshot shows a case where multi-page floating tables are nested. For this document, we
not only have an inner and an out table, but we also have a middle one, giving us 3 nesting tables.
Some of the inner table frames had a bad position, leading to overlapping text, now fixed.
The next screenshot shows the case where the magic allowTextAfterFloatingTableBreak flag is set.
We used to wrap content of the anchor only on the last page, unconditionally. Now we either wrap on
the last page (default) or on all pages (when this flag is present).
The last screenshot shows a document full of floating tables. These used to be inline ones, and then
they could not overlap by definition, but now extra effort was needed to position them in a way that
no overlap happens between the tables. Now our render result matches Word.
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the
unstable snapshot. Collabora
intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all
of this work will be available in TDF's next release too (24.2).
Multi-page floating tables and nested tables could not be combined so far. Instead we tried to lay
out the outer table on multiple pages and all inner tables were still limited to a single page. In
this part, you can read about removing this limitation.
Regarding testing, the core.git repository has 73 files now which are focusing on correct
handling of floating tables (filenames matching floattable-|floating-table-). This doesn't count
cases where the document model is built using C++ code in the memory and then we assert the result
of some operation.
Here are some screenshots from the fixes this month:
The first screenshot shows a case where not only a single floating table is split across pages, but
also the table's only cell hosts an inner multi-page floating table. This is more complicated at a
layout level, because we can't just move part of the table to a next page, which has no parts of the
outer table yet.
The next screenshot shows a case where the inner floating table starts at the cell start of the
outer table. The DOCX import case needed addition effort to get working, because as soon as the
inner floating table's content is moved to the floating frame from the body text, the reference to
the cell start at the outer table level was invalidated and the whole table conversion failed.
This screenshot shows a bug where multiple inner floating tables started at the cell start of the
outer table. Handling this correctly on our end had to ensure that each (potentially multi-page)
floating table gets its own unique anchor point, and this can be combined with nesting, with the "at
cell start" special case on top of it. Once all three can be combined, a real-world documents
gets its table instead of just having the content the of the table in the body text.
The last screenshot shows an editing session where we keep inserting new paragraphs at the start of
the document, so new items are created at the end of the fly chain as needed, and old items are
deleted at the start of the fly chain as needed. We had a bug here so that the content we wanted to
move forward was inserted at the end of the document, leading to a weird selection that started at the
document end and continued on a previous page. Now this works correctly: once the first page is full
of empty paragraphs, the second page hosts the first row and half of the second row. The third page then
can host the second half of the second row and the third row.
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the
unstable snapshot. Collabora
intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all
of this work will be available in TDF's next release too (24.2).
The current post features sub-tasks for the multi-page floating table work that is around an
explicit table overlap control that Word has (and Writer lacked so far), compatible border rendering
of split tables and having footnotes in floating tables, which was not working previously.
Regarding testing, the core.git repository has 60 files now which are focusing on correct
handling of floating tables (filename matching floattable-|floating-table-). This doesn't count
cases where the document model is built using C++ code in the memory and then we assert the result
of some operation.
Here are some screenshots from the fixes this month:
The first screenshot shows a case where the anchor paragraph of a floating table had some autotext
(e.g. "dt", which stands for dummy text), and pressing the relevant shortcut (F3) expands that
autotext with the actual content. This includes changing the anchor position of the floating table,
which lead to overlapping text. (A multi-page floating table has multiple anchors, we have to make
sure we don't set all of them to the new value as-is.)
The next screenshot shows a case where two tables are positioned in a way that they would overlap.
Word has a flag that asks the layout to still re-position the second table so the overlap doesn't
happen, and now Writer supports this as well.
This screenshot shows a bug where the anchor text on the first page was also duplicated on the
second page. Now we properly start the anchor text on the last page of the floating table, like Word
does.
What you can see is a floating table that has 2 pages, but simply a split of the table would result
in no bottom border on the first page and no top border for the second, like perhaps you would
expect it, matching Word. This is now fixed, the layout infers the border style in those cases
correctly.
The last screenshot shows a mini-feature: it was possible to float tables and to have footnotes in
tables, but not both at the same time. The screenshot shows a case where a floating table is
needed, so a specific paragraph is above the table. But we couldn't float the table, because
it had a footnote and that would be lost as-is. Now you can have a correct position for that
paragraph and the footnote is there as well, at the same time.
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the
unstable snapshot. Collabora
intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all
of this work will be available in TDF's next release too (24.2).
The previous post finished with an "almost done" state for overlapping tables: this is a cluster of
problems where tables are allowed to overlap, but various other formatting make them not overlap in
practice in Word, but they do overlap in Writer. In this post, we'll see what was necessary so an
initial set of old documents now render perfectly, which started to work during the past month.
The feature is enabled by default and the DOCX/DOC/RTF import makes use of it.
On the positive side, core.git repository has has 49 files now which are focusing on correct
handling of floating tables (filename matching floattable-|floating-table-). Also, there are
additional tests that quickly build a specific multi-page floating table in the memory and do some
operation on it, e.g. delete the last row and assert what happens.
Here are some screenshots from the fixes this month (right click, open image in new tab for larger size):
Old, new and reference rendering of a floating table with negative vertical position, relative to an empty anchor.
The first case is about a document where the bottom of the page had a floating table, where the
position (relative to the anchor) was a negative vertical offset. In this case Writer used to move
the floating table to the next page, but now matches Word: the space in the previous page is used
for the floating table. This fixed overlapping text on the next page.
Old, new and reference rendering of a floating table with a large bottom margin in the anchor paragraph. Notice how the old rendering had a larger spacing between footnotes, which resulted in a 2 page document. The new and reference renderings have smaller spacing between footnotes and are of 1 page.
The next case is about floating tables in footnotes, the anchor needs to have no visible margins to
provide the correct layout.
Old, new and reference rendering of a floating table with an overlap due to vertical offsets. The old rendering had a big second table, it completely covered the first table. The new and reference renderings shift the second table to a next page to avoid overlap.
This case was about an unwanted overlap of floating tables. Incorrect handling of the vertical
offsets meant that the second floating table was rendered on top of the first one, making the text
in the first floating table unreadable. Now we shift down the second floating table, so no overlap
happens.
New rendering of a floating table with anchor text that starts with a newline.
This document had a layout loop on load. The problem was specific to the case when the anchor text
of a floating table started with a newline character, which has its own position in the document
model, but doesn't really have a width at a layout level, so needs special handling. This is now
fixed, the document loads and renders fine.
Old, new and reference rendering of a document with lots of floating tables.
This document had only 4 pages, but lots of floating tables, carefully positioned to not overlap in
Word. You can see how the old Writer rendering result was hard to read and it now looks correct.
Old, new and reference rendering of a floating table with a hidden anchor.
Writer used to hide floating tables anchored inside hidden paragraphs, but Word shows them all the
time, now we match this behavior.
Old, new and reference rendering of a floating table with an overlap.
The next document first had all of its tables in the first page, now fixed.
Old, new and reference rendering of a floating table with an overlap between the table and the footer area.
A remaining problem was that the second table and the footer area could still overlap. This is now
fixed: Word sometimes does allow such an overlap, but it depends on the baseline of the anchor
position, so in the current case we can detect that such an overlap is not wanted.
Old, new and reference rendering of a floating table with a half row on the first page.
The last problem with this document was a poor split of the floating table, the first half row of
the second table still went to the first page. Now we correctly detect that such a split is not
wanted and simply start the second floating table on the second page, which results in a pretty good
rendering of this document.
And that's where we stand. Certainly more work is needed to fix rough edges, but we get there step
by step -- the theme is slowly transitioning from overlap problems right after load to unexpected
rendering problems during editing.
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the
unstable snapshot. Collabora
intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all
of this work will be available in TDF's next release too (7.6).
The previous post finished with a first fix for overlapping tables: this is a cluster of problems
where tables are allowed to overlap, but various other formatting make them not overlap in practice
in Word, but they do overlap in Writer. In this post, we'll see what started to work during the past
month.
The feature is enabled by default and the DOCX/DOC/RTF import makes use of it. This allows
stress-testing the layout code with complex user documents. The next target is to actively search
for documents that rendered reasonably in the past but are now unreadable and fix them.
On the positive side, core.git repository has has 40 files now which are focusing on correct
handling of floating tables (filename matching floattable-|floating-table-). Also, there are
additional tests that quickly build a specific multi-page floating table in the memory and do some
operation on it, e.g. delete the last row and assert what happens.
Here are some screenshots from the fixes this month:
Section break directly between floating tables
The first problem was that in case two floating tables were directly after each other, a section
break between them was lost. What you can see above is a successful transfer of the break
properties to the first paragraph on the next page, so the tables don't overlap but are laid out on
separate pages.
Incorrect split of a multi-page floating table
Looking through internal documents, a sample was found where a table with 2 rows was not split, even
if the previous page would have enough space for the first row. This is the old, bad layout.
Correct split of a multi-page floating table
And this is how it looks after the fix.
2 floating tables are lost
The rest of the screenshots are from a complex internal document, which has 4 pages, but in total
contains 11 floating tables. First I focused on getting correct rendering of this in Writer for
DOCX. All the problems were not visible previously, as non-floating tables can't overlap, so bad
formatting problems did not cause problems in practice. The first subset (public reproducer) had 3
tables in it, but Writer only rendered one of them.
Normal table and 2 floating tables are fixed
After fixing the problem, both lost tables are now there.
Unwanted overlap of two floating tables
The next case is about overlapping tables: the table is there, but the anchor positions are so
close that the content overlaps and it's hard or impossible to read the text.
Fixed overlap of two floating tables
And this is how it looks after the fix.
Bad handling of nested floating tables
The next trouble is with nested floating tables: in case all inner tables are inline, then the table
above the images will require more space then requested and that will lead to overlapping text
later.
Better handling of nested floating tables
The first fix is to make these inner tables also float if requested in the file format (but not
split for now, to develop incrementally). This helps, but the position of the inner table's anchor
is still incorrect.
Good handling of nested floating tables
Finally the anchor position of the table is also correct: no intersecting borders, no overlapping
text, no unexpected need for lots of vertical space.
Layout-loop for a floating table
The next problem was a layout loop, which was terminated by the built-in loop control in a way that
rendered text outside the table to show up inside the table.
Fixed layout-loop for a floating table
And here is the correct rendering. Note that in case a floating table's anchor is positioned with a
negative vertical offset, then it can happen that text before the table will be rendered below the
table. But this is intentional and also happens in Word.
Bad handling of negative vertical offsets
The last problem for this blog post is the case when a large floating table is anchored in a
single-line paragraph. Now Writer insists that the anchored object and the anchor text is on the
same page, so even if there is space for the last table on a previous page, it moves the table to
the next page.
Good handling of negative vertical offsets
And here is the correct rendering: all tables fitting the first page. Also note that the last table
is moved up, so while the document model order is "after-table-2-second table-3 after-table-3", the
rendered / layout order will be "table-3 after-table-2-second after-table-3" -- again,
intentionally.
And that's where we stand. Certainly more work is needed to fix some remaining unwanted overlapping
of floating tables, but we get there step by step.
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the
unstable snapshot. Collabora
intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all
of this work will be available in TDF's next release too (7.6).
The previous post finished with crash testing: the interesting subset of that testing tool is to take
hundreds of thousands of documents and in the Writer case import them into a document model and
layout them. If any of this crashes, mark that for future investigation. In this post, we'll see
what else started to work during the past month.
The feature is enabled by default and now the DOCX/DOC/RTF import makes use of it if. This allows
stress-testing the layout code with complex user documents, hopefully with the found breakage fixed
before it would be released in a stable version.
On the positive side, core.git repository has has 37 files now which are focusing on correct
handling of floating tables (abbreviated as "floattables"). Also, there are additional tests that
quickly build a specific multi-page floating table in the memory and do some operation on it, e.g.
delete the last row and assert what happens.
Here are some screenshots from the effort so far:
Floating table inside a multi-column section
The first case is about multi-column sections: in this case Word doesn't try to split them between
pages. What you can see on the screenshot is that Writer lays out content on the previous page so
that remaining space is left, but we don't try to split the table between the first and the second
page, even if there would be space on the first page and even if this means the table overlaps with
the second column, matching what Word does.
UI to disable split of a floating table
UI to enable split of floating tables were added quite early: this is a new checkbox on the frame
properties dialog. However, disabling the split of floating tables was broken, the already
created layout was not updated to properly move back "follow" fly frames from later pages to the
current page, which is now fixed.
Chaining enabled, so no split frames
Writer already had a feature to split content in a frame into multiple frames, but that one required
creating those frames in the model explicitly, such chaining is a feature that is useful in other
use-cases and is parallel to multi-page floating tables. The UI now ensures that the user can split
frames only in case chaining is not used, to avoid confusion.
Split enabled, so no chaining
This is now also true in the other way around: if split of a floating table is allowed, then we
disable the frame chaining UI to avoid trouble later.
The latest crashing document
At this point I went back to crashtesting & crash bugreports, and the latest reported crash was for
a document that is visible on the above screenshot. This was a bit tricky: it required 3 fixes to
make it not crash and also a layout loop fix.
Disabling split of frames at a layout level
Next was a mini-feature: even if floating tables normally split across pages by default, Word has a
document-level compatibility switch to turn this split on or off by default, at a layout level.
Floating tables from RTF are not split by default, DOC and DOCX split them by default.
What you can see on this screenshot is that a DOCX document may have this flag enabled, and then you
allow splitting on the UI / at a document model level, but Writer may still decide to not split
them, to provide the correct layout.
Overlapping floating tables
The previous post already mentioned the problem area of overlapping tables. A first step in this
direction is to fix this bug document with Arabic text and 2 overlapping tables, making them
unreadable.
Fixed overlap of floating tables
And in this case here is the fixed version, where reading the table now depends on your language
skills. :-)
In this case, the problem was a lost section break of type next page, when a section started with a
floating table, which is a corner-case.
And that's where we stand. Certainly more work is needed to fix more unwanted overlapping of
floating tables, but we get there step by step.
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the
unstable snapshot. Collabora
intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all
of this work will be available in TDF's next release too (7.6).
