Re: ODF Proposal: OFFICE-4047: Allow overlap graphic property

[Regina Henschel <rb.henschel@t-online.de>]

Hi Miklos,

thank you for taking the time to answer the questions. Point B is still 
a problem, see below.

Miklos Vajna schrieb am 11-Nov-20 um 08:59:
> Hi Regina,
>
> On Tue, Nov 10, 2020 at 10:12:24AM +0100, Regina Henschel <rb.henschel@t-online.de> wrote:
> > the ODF TC has discussed your proposal OFFICE-4047:
> > office@lists.oasis-open.org
> > https://issues.oasis-open.org/browse/OFFICE-4047. There are some aspects in
> > the proposal, which are not clear.
> >
> > (A) What happens if only one of the overlapping objects has set
> > draw:allow-overlap="false"?
>
> Thanks for these questions. As in many other cases, this attribute is
> modeled after an existing OOXML feature, so the intention is to document
> what's already the case there. This usually looks simple at first, but
> then it's easy to forget about corner-cases.
>
> In case there are 2 overlapping shapes and only one of them sets
> draw:allow-overlap="false", then shapes should be positioned in a way to
> avoid the overlap.
>
> > (B) In which way should the application solve the conflict? Please consider
> > LibreOffice bug https://bugs.documentfoundation.org/show_bug.cgi?id=134115
> > in this regard.
>
> The OOXML spec is not crystal clear on this:
>
> "If a DrawingML object cannot overlap other DrawingML object, it shall
> be repositioned when displayed to prevent this overlap as needed."
>
> Experimenting with Word, I found what is mentioned at
> <https://gerrit.libreoffice.org/79141>:
>
> "If there is an overlap, then a shift towards the bottom or towards the
> right would resolve that. Word seems to always push down, do the same
> for compatibility. >
> I imagine never shifting towards the top or left is helpful to avoid
> layout loops, because this means we always progress towards to bottom
> right corner of a page.


I do not see this behavior in Word. Take for example the attachment from 
tdf#134115 
[https://bugs.documentfoundation.org/attachment.cgi?id=162173]. There 
the object is shifted to the left.



I have ask in the forum now. Perhaps that helps.

https://social.msdn.microsoft.com/Forums/en-US/774ee5a5-5f31-4b7f-98d0-65785675c376/docx-looking-for-rules-how-to-reposition-in-case-of-allowoverlapquotfalsequot?forum=os_binaryfile


> > (C) Which object is changed? Depending on mark-up position, on z-order,
> > or...?
>
> I experimented with overlapping shapes where allow-overlap was true for
> both shapes. Let's say there was a red shape and there was a green shape
> on top of it. Then it did not matter which shape was changed to
> allow-overlap=false, the red shape was re-positioned. So I guess the
> intention is that the one which is behind other shapes is re-positioned.

I cannot confirm. In the above mentioned test document, the "red 
frame"-object is moved to the left,

> > (D) How does this new attribute interact with the attribute
> > draw:wrap-influence-on-position?
>
> My understanding is that wrap-influence-on-position has 3 possible
> choices: once-successive, once-concurrent and iterative. Writer defaults
> to once-concurrent and this is never set to an other value for
> imported-from-Word documents. So I believe that iterative or
> once-successive is only for compatibility for older documents; there was
> even some specification on the OOo site regarding this, though now I
> can't find it.
>
> So my expectation is that at least the LibreOffice allow-overlap
> implementation is only tested with the
> draw:wrap-influence-on-position=once-concurrent case. Just to simplify
> life for everyone, perhaps it would make sense to explicitly say that
> allow-overlap should be ignored if draw:wrap-influence-on-position is
> not once-concurrent?
>
> > Would you please be so kind and answer the questions or extend your
> > proposal? You can answer to the mailing list or in OFFICE-4047.
>
> I hope the above helps: as you see the intention is to extend ODF in a
> way that documents imported from OOXML don't loose their allow-overlap
> property. Of course you're right, just because OOXML did a poor job at
> documenting their behavior, it's not an excuse for ODF to do the same.
>
> Thanks,
>
> Miklos

Giving no rules for reposition makes interoperability harder. Let see, 
whether there are some useful answers in the forum.

Kind regards
Regina