[Libreoffice-bugs] [Bug 57155] FILEOPEN Wrapped objects in linked headers/footers not shown in DOCX

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Tue Jul 21 11:09:54 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=57155

Justin L <jluth at mail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=12
                   |                            |9582
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Justin L <jluth at mail.com> ---
The problem of the header graphic not showing up on page 2 is fixed in 7.0 (and
6.3.6) by commit 81ec0039b2085faab49380c7a56af0c562d4c9e4
Author: Michael Stahl on Mon Jan 20 13:48:27 2020 +0100

    tdf#129582 sw: fix copying of flys in header/footer in DOCX/RTF import

    The problem is that the exception for writerfilter in
    IsDestroyFrameAnchoredAtChar() and IsSelectFrameAnchoredAtPara() is
    wrong in the case when the header/footer content is copied via
    SwXText::copyText(); that is, previously the situation was that
    writerfilter relied on Delete not deleting such flys (for
    RemoveLastParagraph) but Copy copying them.

    (regression from 28b77c89dfcafae82cf2a6d85731b643ff9290e5
     and e75dd1fc992f168f24d66595265a978071cdd277)

    So restrict the writerfilter hack to delete; this causes a problem with
    ooxmlexport9 test testTdf100075: it has 2 flys anchored at the
    same paragraph; writerfilter will insert the content into the body and
    then convert to fly; when the 2nd one is converted it will copy the 1st
    fly and anchor it inside the 2nd fly but then unotext.cxx:1719 will
    reset its anchor to inside the body...

    Prevent this unwanted copy by relying on the new parameter bCopyText
    that was introduced in 04b2310aaa094794ceedaa1bb6ff1823a2d29d3e,
    but change things a bit so that the case that pass in the extra flag
    isn't the copyText() one that wants the *normal* selection semantics in
    writerfilter import, but the 2 known places that want the *exceptional*
    selection semantics in writerfilter import (hopefully there aren't more).

    This is not ideal and the various bool parameters to CopyRange() plus
    mbCopyIsMove plus mbIsRedlineMove should probably be consolidated
    into some flags enum passed to CopyRange().

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200721/2e6d1c38/attachment.htm>


More information about the Libreoffice-bugs mailing list