OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  Editing Office Version & XML indent

    Posted 07-03-2020 17:43
    Hello Francis, What office version are you currently using? The meta.xml of your last document was empty, so I could not figure it out. Same LibreOffice version for editing ODF TC deliverables It might be reasonable if we are working all with the same LibreOffice version for editing the ODF specification documents. The idea behind the above is that multiple people can load & save deliverable documents without changing unintentionally something. Therefore, I would suggest settling with the latest stable version 6.4.5.2 : https://www.libreoffice.org/download/download/ Otherwise, state your version and I install your old one. Enabling Pretty Printing As I would like to be able to edit the content.xml easier and get some impression on what changes you made, therefore I would, in addition, suggest enabling XML indent by LibreOffice. Michael was so kind explaining to me how this can be enabled in LibreOffice - usual XML indent does not work as it would add whitespaces inside paragraph elements. Two ways to enable prettyprinting: Tools->Options->Advanced->Expert Configuration Search for "prettyprinting" and enable it. Open the config file registrymodifications.xcu within Windows: <USER SETTINGS> = %APPDATA%libreoffice4user Linux: <USER SETTINGS> = ~/.config/libreoffice/4/user/ and add the following: <item oor:path="/org.openoffice.Office.Common/Save/Document"><prop oor:name="PrettyPrinting" oor:op="fuse"><value>true</value></prop></item> I taste option#1 successfully. Best regards, Svante


  • 2.  RE: Editing Office Version & XML indent

    Posted 07-03-2020 19:24
    Hi Svante   I m using LibreOffice version 6.3.6.2 for Windows 10. I update LibreOffice when prompted. If I check for updates, LibreOffice says my copy is up-to-date. I could update to version 6.4.5, but I have tended not to think if myself as an early adopter .


  • 3.  Suggestion of upcoming handling of ODF TC deliverables - earlier: Re: Editing Office Version & XML indent

    Posted 07-03-2020 22:01
    Hi Francis, I would suggest we are bringing all your working draft files into our GitHub repository. The final ODF 1.2 artefacts are already checked in: odf-tc/src/main/resources/odf1.2 You might want to add your current state-of-work at: odf-tc/src/main/resources/odf1.3 odf-tc/src/main/resources/odf1.4 I would suggest to place the ODTs of all parts with the schemas flat in the directories and unzip the ODT in addition n a directory named identical aside with "_" instead of ".". The reason for the duplication is that the XSLT is not yet able to access the XML within the ODT and Git is just better with pretty printed XML files as with binary blobs. On the other hand, for convenience, I would like to be able to open quickly open the file without zipping it myself. There should be a script to unzip them and a pre-commit hook test that both (ODT & unzipped XML) are identical, but one step after the other. You might as well edit the XML. Although the MIMETYPE should not be compressed, my bet is LibreOffice (LO) will fix it. After you added your documents, we might test if an update of LO will change the existing parts by loading and saving them (aside from the metadata string). Michael got such a regression tests AFAIR. In addition, we might want to commit the results of our transformations as well, e.g. for ODF 1.3: odf-tc/src/test/resources/odf1.3/references It is easier to spot regression if we have the former results of our transformations at hands in history. Of course, the file names will change in the future according to the input, but the work is quite preliminary at this point. As a rule of thumb. All files being delivered are in the directory: odf-tc/src/ main / all other files, being mostly test and test documents will reside beyond: odf-tc/src/ test / I am reusing the Maven build system standard layout . Perhaps later we might switch to Gradle . GitHub Pages is activated, but I want to improve it, the test commits will be cleaned up later in my fork, I have moved tests to: https://github.com/svanteschubert/testing-github-pages/ For the ODF 1.3 CS02, I would suggest you work without change-tracking most of the format changes is too noisy in change-tracking anyway. We should be able to track your changes in the content.xml via GIT. Still, it would be helpful if we use GitHub commit on the deliverable artefacts as semantical steps using a certain commit pattern including the issue ID and title. Although we are using still JIRA we might want to overtake the GitHub keywords , e.g. I suggest we use: "Fixes #242 bug title". In case of the format task, you might add the subtask instead of the bug title. Last but not least, later we might want to fix one task after the other. Starting with no changes in the beginning, we would enable change tracking for this task. Fix the JIRA issue within the specification The editor would do a pull-request, triggering via Travis several tests. Another TC member as a reviewer will check the task against the JIRA issue - we might want to enable (later) branch protection for review The ODT will be committed as reviewed within GitHub still with change-tracking The ODT will be committed again with GitHub with all changes accepted Now this iteration would repeat. The advantage is that we have change-tracking only for this task and might generate DIFF PDF from the change-tracking ODT to show the changes related to one issue. The disadvantage we might end up with more than one DIFF PDF if we have to start such iteration for the same issue again and we won't have one DIFF document. As a developer, I would be happy to have a list of changes related to new features with all changes related in one PDF and/or ODT. In addition, I never liked the all-diff-included with all the format changes, it is far too much noise, as it included all format changes as well. Talking about PDF DIFFs they did not work out very well for ODF 1.3, there is not a single change in the XML part of part 2, which is obviously wrong: http://docs.oasis-open.org/office/OpenDocument/v1.3/cs01/part2-packages/OpenDocument-v1.3-cs01-part2-packages-DIFF.pdf Therefore it's time for changes :-) Have a nice weekend, Svante Am Fr., 3. Juli 2020 um 21:23 Uhr schrieb Francis Cave < francis@franciscave.com >: Hi Svante I m using LibreOffice version 6.3.6.2 for Windows 10. I update LibreOffice when prompted. If I check for updates, LibreOffice says my copy is up-to-date. I could update to version 6.4.5, but I have tended not to think if myself as an early adopter . ð I generally use the Grid view in Oxygen to read content.xml, so I haven t been bothered by the lack of pretty printing, but I have now set prettyprinting to true in my copy of LibreOffice. Kind regards, Francis From: Svante Schubert < svante.schubert@gmail.com > Sent: 03 July 2020 18:43 To: Francis Cave < francis@franciscave.com > Cc: office@lists.oasis-open.org Subject: Editing Office Version & XML indent Hello Francis, What office version are you currently using? The meta.xml of your last document was empty, so I could not figure it out. Same LibreOffice version for editing ODF TC deliverables It might be reasonable if we are working all with the same LibreOffice version for editing the ODF specification documents. The idea behind the above is that multiple people can load & save deliverable documents without changing unintentionally something. Therefore, I would suggest settling with the latest stable version 6.4.5.2 : https://www.libreoffice.org/download/download/ Otherwise, state your version and I install your old one. Enabling Pretty Printing As I would like to be able to edit the content.xml easier and get some impression on what changes you made, therefore I would, in addition, suggest enabling XML indent by LibreOffice. Michael was so kind explaining to me how this can be enabled in LibreOffice - usual XML indent does not work as it would add whitespaces inside paragraph elements. Two ways to enable prettyprinting: Tools->Options->Advanced->Expert Configuration Search for "prettyprinting" and enable it. Open the config file registrymodifications.xcu within Windows: <USER SETTINGS> = %APPDATA%libreoffice4user Linux: <USER SETTINGS> = ~/.config/libreoffice/4/user/ and add the following: <item oor:path="/org.openoffice.Office.Common/Save/Document"><prop oor:name="PrettyPrinting" oor:op="fuse"><value>true</value></prop></item> I taste option#1 successfully. Best regards, Svante