Re: Backward compatibility or valid input

Hi Caolan,

On Monday, May 15, 2017 12:33 BST, Caolán McNamara <caolanm@redhat.com> wrote:

> 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
> > that.
>
> I've sent Tomas a document which reproduces the original problem.
>
> The document generator is LibreOffice 4.4.5.2, 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
> with.
>
> 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"'
> e84f0a9b3223f49b0829f2f55dacbf11ae201c1e
>
> 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.

Thanks for the test document and the explanation. I think this conflict can be solved by checking 
also the frame's size and positions next to the frame name. With that we can distinguish the real 
duplicates from those which only have the same name. I will change the code accordingly.
I can reproduce the issue with the test document you sent (slow import), so I'll make sure not to 
reintroduce that by by the code change.

Thanks,
Tamás