[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Alternatives for OFFICE-2102
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]