Re: [office] Alternatives for OFFICE-2102

[Michael Stahl <mstahl@redhat.com>]

On 30.03.2017 19:03, Svante Schubert wrote:
> So why are we doing all this?
> The reason for whitespace handling is likely that ODF applications are
> able to identify and delete additional space inserted by pretty printing
> the XML being done by users in any other text/XML editor.

and we have already seen that this doesn't work perfectly in every case,
and won't work perfectly with generic heuristics, without the
pretty-printer applying ODF-specific rules.

> There are many variations to do quick fixes to save some time fixing
> existing ODF applications, but just for the theory what would be the
> fix if whitespace handling should work with ODF 1.3?
> 
> It is relative simple:
> 
>  1. Add whitespace elements (text:tab, text:s, text:line-break) in the
>     RelaxNG schema for every descendant of text:p/h that has already
>     character data (perhaps define character data)

let's take the first element from the list of <text:p> child elements
that don't currently do whitespace processing: <dr3d:scene> 10.5.2

it has a child <svg:title>, which allows <text/> content - so you want
to do whitespace processing there since it's a descendant of <text:p>.

however, <dr3d:scene> does not necessarily occur in a paragraph, it may
also occur in a <style:handout-master> element, which is never a
descendant of <text:p>.

do we now say that <svg:title> must have whitespace processing when it
occurrs as a descendant of <text:p>, but not otherwise?  to me that is
the road to madness.

to me a necessary criterion to apply whitespace processing is that the
text content of the <text:p> descendant is conceptually part of the
paragraph text - so all captions on drawing objects and authors on
annotations and that sort of stuff shouldn't do whitespace processing.

>  2. Fix the wording consistent to "descendants"

"descendants" is better than "children", and furthermore i would perhaps
move all mention of "descendants" into non-normative notes, and leave
the normative text to say "processing shall be done if and only if the
element allows <text:s> etc. as children".

>  3. 6.1.2 "White Space Characters"
>     <http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#White-space_Characters> (and
>     likely other sections) have to be overworked that 
>       * ODF 1.3 producers
>          1. Will exchange multiple space characters always to text:s
>             with count attribute
>          2. Will exchange even every single space before and after any
>             descendant element of text:p/h with text:s (to avoid Jos'
>             problem)
>       * ODF 1.3 consumers
>          1. Will remove any space character before and after any
>             descendant element of text:p/h
>          2. Will remove any linebreak and adjacent whitespace characters

as said above i disagree with "any descendant".

>  4. To make the above work, the version attribute(s) shall become
>     mandatory for ODF 1.3, which should be done anyway to ease a
>     developer's life.
> 
> What do you think?

i think we should restrict ourselves to specify something that has as
much backwards compatibility as possible with existing implementations,
with particular regard to how existing consumers will interpret
whitespace in ODF 1.3 documents.

given the current inconsistencies in implementations it's not possible
to make everybody happy, but we should not introduce additional
compatibility breakage that isn't there currently.