Looking into the "moving anchors" problems in Calc and Writer

Hi everybody,

this is mostly a brain dump for myself, but probably I can get some input.

Now that MM seems to be fixed (in the spirit of correctness before
speed; PDF is correct, ODT seems correct - but still slow), I've started
to investigate the bug of the moving paragraph-bound anchor on ODT file
load (fdo#80926). The bug is actually unrelated to MM and I found a lot
of bugs, which might be related.

See https://bugs.freedesktop.org/show_bug.cgi?id=80926#c5 for the latest
details.

Summary: I'm trying to understand, why SwFmtHoriOrient is already wrong
in SwToCntntAnchoredObjectPosition::CalcPosition for the 2nd page.

Anybody an idea?


IMHO there are two problems:

1. Broken implementation of "First page different style / footer / header"

The original feature seems to have been introduced between OOo 3.3 and
LO 3.5; at least that's where the bug started. There have been many
fixes, but my guess is the implementation is still broken. My main
indicator is the fact, that the "moving paragraph anchor" just happens
on the 2nd page. No other pages seem to be affected. And - to make
things even stranger - just paragraph-anchored draw object with a
negative Y-offset are affected.

And if you MM the document, the 2nd page is still the only affected one.
And it even looses some page-anchored frames, but these are saved
correctly, in contrast to the paragraph-anchored draw objects.

2. Recalculation of anchor positions (for copies?!)

At least I found a calc commit, which was introduced during the 4.1
development cycle and looks suspicious. OTOH I have bisects for Writer
(fdo#80926) and Calc (fdo#67712), which both point to the same commit in
the bibisect repo. Here is one of my main problems:

git log
ba446dd58a4ad324d242afcd5b28d3b4dff5a881..5da10275a7475efdbfd9de14ea58cf8f4c6c1582
--pretty=oneline | wc -l
2240

From my POV it's just a coincidence, that anchored objects broke for
Writer and Calc in this commit range, but I don't know.

My current guess: the recalculations somehow revealed the first problem,
but I don't know how this can affect Calc. Currently that's just a wild
guess.


= Bug list (probably related) =

I've put most of my debugging information into fdo#80926!


== Open bugs ==

fdo#47153 - Form Letter PRINTING: Picture or Draw shape in Page Header
suppresses some contents on most pages of particular document (3.5)
fdo#59428 - mirrored page layout is not actually mirrored (4.1.2)
fdo#63833 - MAILMERGE: Loosing page formatting (3.6.0.1 rc)
fdo#66145 - Turning off Same content on first page' does not reflect in
UI (4.2.0.0alpha0+)

This bug is actually closed but is included as a reference from the fix
of fdo#69282.

BSA target:4.2.0 target:4.0.6 target:4.1.1

fdo#67712 - form controls and draw objects anchored to cell but changes
position after reopening (4.1.0 b1)
=> commit 5da10275a7475efdbfd9de14ea58cf8f4c6c1582
   Related rhbz#915743: Abort UCB call from SvtMatchContext_Impl::Stop

commit 545737df40880875304bffc3f49800d1d2e99723
    fdo#59056: Re-calculate cell anchor position of a pasted drawing object.

fdo#69282 - MAILMERGE: Format (page style) of the first page changed
from other pages in mail merge (4.1.2.3)

Reverting

commit 75084f6c42c27dc95418df9cefed2fddfb26000e
    fdo#66145: do not check IsFirstShared() in SwPageDesc::GetLeftFmt()

fixes the problem for MM.

fdo#70232 - footer affected by header left/right sharing in UI and
ODF/DOCX formats (4.0.6.2)
fdo#80395 - MAILMERGE: Lines move when using mail merge (4.1.4.2)

fdo#80926 - Moving paragraph-bound anchor on ODT file load (3.6.7.2)
=> commit 5da10275a7475efdbfd9de14ea58cf8f4c6c1582
   Related rhbz#915743: Abort UCB call from SvtMatchContext_Impl::Stop


== Already fixed in private/jmux/mailmerge-fixes ==

fdo#34502 - MAILMERGE PRINTING: Field "Page Number" shows constant
number instead of page count (OOo)
fdo#62364 - Mailmerge problem if list or numbering at the end of
document (3.6.6.2)


== MM Speed (still broken, but unrelated) ==

I've put quite some information into fdo#80823 to prevent optimizations
in the wrong area.

fdo#56355 - MAILMERGE: Creating mailing with more than 1000 records is
incredible slow (3.5.6.2)
fdo#79067 - MAILMERGE: mailmerge takes ages to create documents (3.6.7.2)
fdo#80823 - MAILMERGE: Use IDocumentMarkAccess::UNO_BOOKMARK to mark end
of one mail merge part (OOo)


Thanks for any input

Jan-Marek