Re: [office] OFFICE-2102 proposal

[Michael Stahl <mstahl@redhat.com>]

hello Aarti,

On 18.04.2017 20:04, Aarti Nankani wrote:
> We looked at this and our feedback is, as app developers, what we'd
really like to see would be something like- here's feature X. Here's
what it would have looked like in the file format the old way. Under our
new proposal, here's what it would look like. It is currently difficult
for us to parse that from all the proposed edits to the standard. Can
you help provide that before the voting?

this is quite hard to answer because of the multitude of "old ways" that
are not always in agreement.

if you compare it to ODF 1.2 then a big difference is that the text
fields don't participate in whitespace collapsing any more.

if you compare it to ODF 1.1 then a big difference is that whitespace
around non-text, non-mark elements is collapsed now.

but since i was unable to find an application that implemented either
the ODF 1.1 or ODF 1.2 rules 100% as written...

well, there aren't many changes in any case.

from my testing with Word 2010 ODF import, it likely differs from my
proposal in the following points:

* check that you handle the ruby special case correctly, both when
  importing and exporting

* Word does collapse spaces in text fields while the proposal does not

* if you want to import OOo/LO/AOO documents (in the LO case, versions
  older than 5.4) better in the corner cases that currently don't work
  then implement the "optional" part (steps 2a and 2b)

* IIRC Word writes the whitespace as-is inside text fields when
  exporting, so that part may already be fine

but as always, additional testing may find more issues.

the main reason why i added the extra "optional" steps for consumers is
so they can read all the existing OOo/LO files better, if they want to
do that.

> Also, our main concern is that if a user types multiple spaces into
some field or dialog that gets preserved into the file, that we can
create that in the file format using <text:s> tags or whatever. What we
want to avoid is users specifying multiple spaces and us either blocking
them or stripping them out.

so generally the goal of the proposal is that that should never be a
problem - if it ends up as character data of an element that allows
<text:s> then you encode some spaces as <text:s>, and if it ends up as
character data of an element that doesn't allow <text:s> you just write
multiple spaces without special encodings.

you can also just always write a <text:s> instead of a U+0020 wherever
that is allowed by the schema, i'm not aware of an implementation that
would do the "wrong thing" then, but i have only superficially poked at
3 or 4 non-LO implementations with simple test documents, so what do i
know anyway...


-- 
Michael Stahl | Software Engineer
Platform Engineering - Desktop Team
Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill,
Eric Shander