OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  OFFICE-2102 test files

    Posted 03-06-2017 15:30
    some test files i've used for OFFICE-2102 * Book1.ods is a spreadsheet, for Gnumeric and Excel * text-input.odt is ODF 1.2 * text-input11.odt is ODF 1.1 * the last 2 files are one of text-input*.odt round tripped by MS Word (it handled ODF 1.1 and 1.2 in the same way) -- 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 Attachment: Book1.ods Description: application/vnd.oasis.opendocument.spreadsheet Attachment: text-input.odt Description: application/vnd.oasis.opendocument.text Attachment: text-input11.odt Description: application/vnd.oasis.opendocument.text Attachment: text-inputfield_Word2010.odt Description: application/vnd.oasis.opendocument.text Attachment: text-input-word2013.odt Description: application/vnd.oasis.opendocument.text


  • 2.  Re: [office] OFFICE-2102 test files

    Posted 03-06-2017 15:44
    On 06.03.2017 16:29, Michael Stahl wrote: > > * the last 2 files are one of text-input*.odt round tripped by MS Word > (it handled ODF 1.1 and 1.2 in the same way) correction for my bad memory: the Word files were manually edited after loading, to insert 2 additional spaces (there is just 1 space after loading), so it's more a test of Word's export. -- 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


  • 3.  Re: [office] OFFICE-2102 test files

    Posted 04-07-2017 16:24
    dear fans of the white-space soap opera, so i tried to write this proposal for the issue and it sounded so easy, but then i noticed that i can't just replace "descendant elements" with "elements that allow <text:s> etc. children" and be done with it. then i've looked in detail at what our implementation actually does, and was surprised that there were things i hadn't noticed yet... for lack of a better idea, i've added some comments to OFFICE-2102 containing several competing proposals, all of which describe what the LO implementation does :) unfortunately it appears that consumers differ a bit in how they interpret the cases that the algorithm in ODF 1.2 neglects to even mention, as i found with some test documents: - whitespace.odt: produced by LO current master build (5.4), contains examples with whitespace both inside and following all the interesting elements, one paragraph per element (naturally this round-trips to itself with LO) - whitespace-test.odt: the same, manually edited to replace every <text:s/> with a U+0020 SPACE, to see if these are ignored - whitespace-test-rt.odt: whitespace-test.odt roundtripped with LO - whitespace-test-word2010.odt: whitespace-test.odt roundtripped with Word 2010 (only version i have) - whitespace-word2010.odt: whitespace.odt roundtripped with Word 2010 please see comments in OFFICE-2102. i suggest we monitor the situation closely before it escalates further... -- 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 Attachment: whitespace.odt Description: application/vnd.oasis.opendocument.text Attachment: whitespace-test.odt Description: application/vnd.oasis.opendocument.text Attachment: whitespace-test-rt.odt Description: application/vnd.oasis.opendocument.text Attachment: whitespace-test-word2010.odt Description: application/vnd.oasis.opendocument.text Attachment: whitespace-word2010.odt Description: application/vnd.oasis.opendocument.text


  • 4.  OFFICE-2102 proposal (was: Re: [office] OFFICE-2102 test files)

    Posted 04-11-2017 15:36
    hello white space aficionados, as requested i've now added a complete proposal to OFFICE-2012, so you have 12 calendar days until the next meeting to review it :) i've decided to create a mixture of the behaviours observed in LibreOffice, Word and Calligra Words, in a way that places stricter requirements on producers than on consumers, so that hopefully interop will improve in the corner cases that currently cause problems. i've also adapted LO to produce documents in line with the proposal; the next release of LO should produce white space that both existing OOo/LO and Word / Calligra Words can import with the same results more often. the proposal would require changes in Word to no longer collapse inside the text field elements. -- 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


  • 5.  RE: [office] OFFICE-2102 proposal (was: Re: [office] OFFICE-2102 test files)

    Posted 04-18-2017 18:05
    Hello 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? 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. Thanks, Aarti


  • 6.  Re: [office] OFFICE-2102 proposal

    Posted 04-19-2017 22:14
    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


  • 7.  Re: [office] OFFICE-2102 test files

    Posted 03-13-2017 12:20
    Hi all, attached is a file, where I have put <text:s> and <text:tab> and <text:line-break> manually into an input field. If I open it in Word 2010, it shows spaces, tab and line-break correctly. (It "repairs" the document, at least because the document is an ODF1.2 extended.) Could you please test with a newer Word? In LibreOffice <text:s> and <text:tab> and <text:line-break> are ignored, as expected. To me it seems as if Word is prepared to read these elements. Kind regards Regina Attachment: Manually set.odt Description: application/vnd.oasis.opendocument.text


  • 8.  Re: [office] OFFICE-2102 test files

    Posted 03-13-2017 13:29
    I was asking myself why would someone add complex whitespace handling to any file format specification at all? To me and all people I have asked the main and likely only reason for this strange whitespace handling is to cope with the pretty printing function of text editors when developers are editing the XML manually, oppose to use an ODF application. Pretty printing breaks the single line into multiple often after 80 to 100 characters. To state the obvious: There is no formal pretty printing specification ;) Nevertheless most text editors are aware of XML and are not breaking the line in a most harmful way, like within a space of an attribute value. I assume the best way to test whitespacehandling for ODF, is to create a test that was using pretty printing and 'adjust' the XML in a way that there are more whitespace than the original ODF XML has intended.  Perhaps a line break and indent in a date field, which not usually expected.  In the given document "Manually set.odt" there is only whitespace XML, which should be not of any problem, right? All the best, Svante PS: I guess the call now starts in 2 min due to day light saving time change in the US, dialing in.. ? 2017-03-13 13:20 GMT+01:00 Regina Henschel < regina.henschel@libreoffice.org > : Hi all, attached is a file, where I have put <text:s> and <text:tab> and <text:line-break> manually into an input field. If I open it in Word 2010, it shows spaces, tab and line-break correctly. (It "repairs" the document, at least because the document is an ODF1.2 extended.) Could you please test with a newer Word? In LibreOffice <text:s> and <text:tab> and <text:line-break> are ignored, as expected. To me it seems as if Word is prepared to read these elements. Kind regards Regina ------------------------------ ------------------------------ --------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/ apps/org/workgroup/portal/my_ workgroups.php