Backward compatibility or valid input
caolanm at redhat.com
Mon May 15 11:33:03 UTC 2017
On Fri, 2017-05-12 at 18:20 +0100, Tamas Zolnai wrote:
> Caolan, I don't see a bug number in the commit message. So I don't
> know what was the actual test case there. Do you remember something
> about what was the issue? Maybe we can find a better solution for
I've sent Tomas a document which reproduces the original problem.
The document generator is LibreOffice 126.96.36.199, and the document is one
with redlines enabled where there are a massive amount of duplicate
frames anchored to the same paragraph which results in a document which
on load is slow to load and unuseably slow to scroll through or work
I think the source to *that* problem may have been 'Fix single node
CopyRange' 9099e21b89184bd4e39def497e483cac4a77ec5a and that problem
may have been fixed with 'Revert "Fix single node CopyRange"'
If that commit was not the root of the duplicate frames then it was
something of that nature, such that on every save of documents with
frames anchored to certain locations of redlines the frames got
duplicated. So on load the document is impossibly slow to work with.
The catch was what to do about the existing documents containing
duplicate frames generated with versions before the fix went in.
I take your point that "it used to work and now it doesn't" wrt
anonymous/duplicate frame names, but I didn't see any great solutions
to the pressing need to get documents generated by ourselves to load
again and LibreOffice (normally) always writes unique frame and the
spec can be read to indicate that they have to be unique which gave a
way out to repair the existing pool of affected documents by dropping
frames with duplicate names.
More information about the LibreOffice