[Libreoffice-bugs] [Bug 131304] [META] MS Word compatiblityMode = 15
bugzilla-daemon at bugs.documentfoundation.org
bugzilla-daemon at bugs.documentfoundation.org
Fri Mar 13 11:24:45 UTC 2020
https://bugs.documentfoundation.org/show_bug.cgi?id=131304
--- Comment #4 from Justin L <jluth at mail.com> ---
(In reply to Mike Kaganski from comment #3)
Hi Mike. Yes, this is exactly the kind of conversation we want to have here. I
think the key here is understanding comment 1. From my understanding,
ultimately compatibilityMode has ALMOST NOTHING to do with layout, but mostly
with allowing advanced options in the UI.
> Does taking into account the document's original compatibility mode make
> sense?
Absolutely. It basically is required in order to fulfil the intention of being
nice to the "oldest version user". And we have been doing that (round-tripping
the existing compat mode) since 2014-ish.
> Writing it back implies that we also write the data according to that
> mode. Do we implement writing things differently for those levels?
Yes, but the impact is minimal because there are currently only two cases where
export differentiates. When we don't it results in bug reports. However, there
are VERY few current exceptions based on compatibilityMode. The ones I could
find in the code are noted in the "blocked" section of this bug report.
> When someone edits a DOCX in LO, one sees the data as it was imported; and
> expects that it shows in Word identically. There are two possible ways to
> *approach* that:
> 1. We stick to a chosen compatibility mode, and write everything accordingly;
That would break the spirit of compatibility mode - to overwrite with a NEWER
mode. In a shared document context, that puts the user of old Word 2007 at a
disadvantage, because now new MS Word will start to add features that old Word
2007 can't understand. Of course, we could revert and say that we will only
write in the oldest 2007 mode from now on, but I don't think you are suggesting
that...
> In any case, we likely should have flexible *import* code taking the
> original mode into account - to read it as it was in original document.
Nothing new here. We already have to handle importing every possible
compatibilityMode. But there hasn't been much in the past 7 years.
> 2. We implement export methods for each possible compatibility mode,
> but do we want to make the nightmare of supporting export zoo?
We already have to do this too - since we round-trip the mode.
Considering that the mode number (15) hasn't changed since 2013, there is no
nightmare situation here. The nightmare could come at the NEXT revision - and
at that time we could decide to NOT round-trip the next version number, but
replace it with the old 15 that we support - which is exactly the intention of
this flag.
--
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/20200313/39a004e9/attachment-0001.htm>
More information about the Libreoffice-bugs
mailing list