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