Numbering portions are the special creatures that are automatically generated at the start of a
paragraph for Arabic numbering or bullets. They are there before the paragraph even starts, and now
the track changes rendering for them is better.
This post is meant to show how this looked in the past and what we improved recently.
Users expect that if they make a text selection in a Writer document and track changes is on and
they delete the content, then that content will be rendered as crossed out. This wasn't exactly like
this in Writer if you had a multi-paragraph selection and your paragraphs were a bullet list. Given
this selection:
If you would like to know a bit more about how this works, continue reading... :-)
As usual, the high-level problem was addressed by a series of small changes, first the code change
and then adjusting tests to expect the new behavior:
Users expect that whenever they make a selection on the UI, they can cut or copy that. And they can
put the cursor to a position and can paste there. The notes bottom panel in Impress is a special
area, which is backed by a "content editable" element in the browser and by an "editeng" widget on
the server, so it's different from the normal document editing canvas where copy&paste used to work
already in the past.
First I had to fix the Ctrl-X/C/V shortcuts, I could model that after Writer comments, which are
also in JavaScript, outside the normal document editing canvas.
Then paste via the notebookbar button was a next step, which was a bit more tricky, since once you
click on a notebookbar button, the notes panel doesn't have the focus anymore.
Finally cut and copy via the notebookbar is now also working, which had to enable these buttons
even if the document editing canvas had no selection, but it works at the end.
This post is meant to show how this is now available on the end-user UI, while previously this was
mostly available for batch conversion and SDK clients only.
A computer's clipboard can contain data in multiple formats, so it would be logical to read and
write Markdown with the text/markdown MIME type. Unfortunately most applications just read from
the text/plain MIME type when non-formatted text is expected. This means writing the dedicated
markdown slot is not read by anyone and in turn reading from that slot usually returns with no data.
The idea is to make "copy as markdown" an explicit action on the UI: when the user opts in, then we
put markdown to the plain text slot on the clipboard, where other software can read it easily. And
similarly, when you paste special, then you can opt in to interpret the plain text data as markdown.
This means that data like aaa _bbb_ ccc won't be interpreted as markdown by accident, but if you
ask for it, you can get your markdown data into Writer easily.
This post is meant to show how the progress indicator you see while pasting is improved, better
showing and hiding when the paste is actually in progress.
Impress copies slides using 3 steps. Our testcase was a 85 slides long slidedeck, pasting that to an
other presentation took 3 steps: downloading the remote slides data, uploading the slides data to
the current document and finally executing the paste UI action, which interprets the ODP slide data.
With enough slides, each step took a bit of visible time:
This post is about pasting, but we had the opposite problem around Markdown in Writer: you could
paste (using the SDK) into Writer, you could also convert to and from Markdown (again, using the
SDK), but you could not actually open Markdown files. This now also works:
To not break compatibility, a single click in Nextcloud still opens the Markdown file in their JS
editor, but similar to PDF files, you can use the "..." menu to access additional actions and there
you can now open the file for editing in Collabora Online as well.
Impress supports lazy-loading images. This means that once you open a presentation with lots of
slides (our testcase was 85 slides), then only the first few slides are rendered, and the images on
other slides aren't even parsed / decompressed.
This is good, the first slide is rendered faster this way. Also the preview of the first few slides
are shown, but the rest of the slides are not rendered, so you can even edit the first slides
without "swapping in" images on later slides.
But we noticed that copying slides between documents means saving the copied slides to ODP, and we
swap in images during ODP save, which makes this operation slower than it needs to be. In practice
75% of the cost was uncompressing PNG files to calculate a checksum on the raw pixel data:
The the issue shows that our goal is to
not call ImpGraphic::ensureAvailable() while saving to ODP. The first step was to calculate the
checksum on the compressed image data. After that, we get a new flamegraph:
Here we swapped in to always have access to a "graphic link". This gives access to the underlying
compressed image data. But a just created image may not have that compressed form, so if you
unconditionally want a "graphic link", you hit a complex code path, which includes swapping the
image in. The solution is to ask for the "shared graphic link", which may not be available. It is
typically available and is the fast path; and we have fallback code in place if the graphic has no
"graphic link". After fixing that, we get a third bad flamegraph:
This last problem is around producing something called a GraphicID. This is used to identify an
image in a unique way, and ODP save uses it to name the graphic in the ZIP file as something like Pictures/10000201000000130000001391B82C7409B72726.png. After fixing that to only use image metadata we get a much more reasonable performance profile:
Inter-dependent change tracking in Collabora Online was mostly a
topic last year, see the post from
November for more info about the
feature in general: this is the case when you create a change on top of another change.
This post is meant to deal with the situation where you already have a recorded formatting and
somebody else creates a new formatting on top of that.
Writer supports insert-then-delete, insert-then-format and delete-then-format as combinations of
changes with different types. So format-on-format is not supported at a file format level, DOCX
can't represent it, either.
But instead of just losing the old format when we create a new format, we can do better: update the
format redline to now track the formatting of the union of the old and new format change.
This still means that the metadata (e.g. author) will be only stored for the new change, but accept
or reject on the format will result in the expected formatting.
And now once a different editor marks the middle B as italic, additionally, then the formatting on
this middle character is now attributed to the new editor:
Without the fix, rejection only removed the italics. With the fix, now reject correctly removes both
the bold and the italic formatting. Accept is a little bit easier, since we don't need to touch the
formatting in the model, just delete the change from the table of changes.
Writer import filters operate in two modes: normally an empty model gets populated by reading user
input from a file, in a certain format. You can also paste similar data from the clipboard, in which
case the target model is not empty and this introduces some complexity.
The markdown import was missing some tweaks which were there already in the ODT and RTF paste code.
Additionally, given that markdown only allows limited formatting, it makes sense to inherit more
formatting from the paste position, so the pasted content's formatting is consistent with the
formatting of the surrounding content.
The document from the issue had bullets
with text "A" and "B", the first problem was that pasting before "A" resulted in a mix of existing
vs pasted content:
The document compare view in Collabora Online Writer allows
comparing documents side by side, see the first post for more
info about the feature in general.
This second post is meant to give you an update on what happened in this area in the last month.
Collabora Online core supports showing or hiding tracked changes in document content, we have a UI
button for that, see the notebookbar's Review tab, the Tracking section's Show button.
Entering doc compare mode or leaving it works by clicking on the View Changes button, in the same
section.
But this means that you can show/hide changes (modifies the document layout, affects everyone) and
also view them (only affects your view), and they do quite different things. :-)
The new UI has a button with a drop-down: the button is toggle that reflects if you compare change
side-by-side or not. And if you click the drop-down next to the button, it's clear that show/hide
is for inline rendering in the document layout while the other option is to render changes
side-by-side:
There were also a number of other smaller improvements: now side-by-side rendering works nicely if
you use IME to type characters, a missing invalidation is sorted out and side-by-side rendering is
better with comments.
If you have two documents or two versions of a document to compare, then traditional tracked changes
is too late, the untracked changes are already in the document.
This work for Collabora Online adds interactive a
non-interactive document compare to create tracked changes after the fact, finally introduces a
document compare view, to better understand these changes.
Collabora Online's core already contained a document compare feature, but this was never integrated
with the SDK (REST API) or with the browser UI.
Additionally, while some users took a training in understanding track changes (or: redlines), the
usage of underlines for inserts and strike-throughs for deletions may not be obvious. An
alternative of this is a side-by-side view, which is now available in Collabora Online for text
documents.
See the SDK, now
you can convert e.g. an editable (new) docx file to PDF in a way that your request references your
old docx file as a parameter, and the resulting PDF shows the differences:
Technically this is a bit similar to image insertion: once you open your new document, you can
compare its content with an old local or remote document:
We worked with Gokay to build this. The LOK API now provides "tile modes" for text documents,
similar to how presentations already have tile modes for slide content, master pages and notes. The
default tile mode is unchanged for text documents, but the Review tab of the notebookbar has a View
Changes button and then the new left hand side, right hand side tile modes allow you to show the
changes side by side:
Removed content is colored with a red-like color, added content is colored with a green-like color.
The matching content on the other side is gray. This is not only for text, e.g. images have a frame
with a similar color.
Now that the LOK API could provide tiles either left or right hand side mode, Gokay built a whole
new tile layout on the browser side, so these are shown nicely side by side.
To better understand what you see on your screen, now there are also labels at the top of the first
pages:
This describes the purposes of the two sides, and in case you're right after a document compare
action, also shows you the file names, modification dates and author names.
For integrators, it's possible to start in this mode by default, if you append &comparechanges=1
to COOL's iframe URL.
Finally if you hover over a tracked change with your mouse, now you get a highlight for that piece
of text on both sides, to match the same parts of the old and new version better. A deletion looks
like this:
If you have a commented text range, which gets deleted while track changes is on and you later save
and load this with Writer's DOCX filter, that works now correctly.
This work is primarily for Collabora Online, but the feature is
available in desktop Writer as well.
It was already possible to comment on text ranges. Comments were also supported inside deletes when
track changes is enabled. These could be already exported to and imported from DOCX in Writer. But
you could not combine these.
With the increasing popularity of commenting text ranges (rather than just inserting a comment with
an anchor), not being able to combine these was annoying.
This required changes to both DOCX import and export: a comment could be deleted or could have an
anchor which is a text range, but you couldn't have both.
You can get a development edition of Collabora Online 25.04 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 (26.8).