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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
