Hi Svante I have been working on the styling of Parts 2 Packaging and 3 Schema, with a view to creating fairly soon a âcleanâ styling of an initial working draft of ODF 1.4. However, I do not expect that the documents Iâm working on will definitely be used for the first working draft of ODF 1.4. They are, in a sense, experimental, helping me to understand how and why these documents are styled the way that they are. In the preparation of ODF 1.3 Patrick and I were mainly concerned with text content, not with styling, although obviously we tried to be consistent. Iâm not sure that reverting to the styling of ODF 1.2 will be much help. My impression (which will have to be confirmed by more detailed analysis) is that the styling of ODF 1.2 is at least as inconsistent as the styling of ODF 1.3, because I believe that most of the inconsistencies that I have discovered are in text that did not change between ODF 1.2 and ODF 1.3. ODF 1.2 is full of editorial mistakes, which is why Patrick and I took so much time last year going through the text and finding and proposing fixes for hundreds of textual errors, so there are certainly lots of styling errors too. Iâm also not certain what is the best way to maintain the documentation in future. Programmers love the idea that documentation can be generated from data â or in our case from schemas â but that is because they donât care too much about the readability of the documentation, especially if they are already very familiar with the schemas and their implementation. But standards have to reach a high level of quality as human-readable text, especially for non-native-English readers, so the text has to be presented clearly and as simply as possible. The use of typographic features such as lists, tables, math formulae and other stylistic distinctions is an important part of ensuring maximum readability by new implementers who are unfamiliar with ODF and for whom English is not their native language. So, while it would be possible to embed ODF or HTML in the schema, making it possible to generate good-quality documentation, simpler methods such as using Markdown would not work, because they lack sufficient typographic features to ensure maximum readability of the results. But if weâre going to be embedding ODF in the schema, we might as well draft that ODF in an ODF editor, since doing so as raw XML in an XML schema editor makes no sense at all. So, I think this has to be a two-way process: text embedded in data has to be generated first from documents, so that documentation can later be generated from text embedded in data. With any type of automation at some point there is likely be a law of diminishing returns that comes into play. Iâm not saying we shoudnât automate, but we should bear in mind that total automation of everything may not be worth the effort. For some tasks editors are cheaper to employ than programmers! 😊 Kind regards, Francis From: office@lists.oasis-open.org <office@lists.oasis-open.org> On Behalf Of Svante Schubert
Sent: 16 July 2020 19:10
To: Francis Cave <francis@franciscave.com>
Cc: office@lists.oasis-open.org
Subject: Re: [office] Review of style use in ODF 1.3 specifications Hello Francis, when I was searching for further information on Daniel Carreras ODF 1.2 Formulas Test Suite Generator, I was stumbling over the ODF TC Wiki: Most interesting is the page explaining the styling of the specification: Perhaps this might help you in your styles task! I have gathered all XSLT files mentioned in the ODF Toolkit: If you would not have started your work, yet, I would even consider going back to ODF 1.2 styling, create a mapping between ODF 1.3 and ODF 1.2 styles and replace the ODF 1.3 styles with ODF 1.2 via ODFDOM (Java). Doing some tests that no automatic styles are being used, concatenation consecutive spans with the same style, etc. I wonder how in the future OASIS will come up with new styling wishes in the future, perhaps we will discuss this together. We should keep in the back of our mind that we should strive for a generation of the specification from data - as we are already partly doing it. And should avoid manual tweakings at all costs and should gather scripts of cleaning-up, transforming our existing specification. Hi Svante Regarding your suggestions: - I have commented on OFFICE-4079, indicating how most of this issue can be resolved. I can raise a new JIRA issue, if that is appropriate, for the editorial tasks I think need to be carried out for ODF 1.4, but Iâve not raised a JIRA issue before and maybe someone with more experience could guide me through this the first time. 😊
- My review is preliminary because a detailed reading of the specification may reveal additional styling and formatting issues that I havenât spotted so far, e.g. where direct formatting is overriding named styles (I havenât checked direct formatting overrides). I attach a spreadsheet that contains a list of the named styles that are used in the drafts of Parts 2, 3 and 4 that I have reviewed (in case there are any oddities in this spreadsheet, I created it in Google Drive to share with Patrick, and have downloaded a copy just now).
- Well, Iâm not sure about this. My hope is that this task only has to be done once and never again! 😊 In that case the effort in fully automating the task may not be worthwhile. Global search-and-replace in LibreOffice may be quicker for changing paragraph styles, and global search-and-replace in Oxygen may be quicker for changing character and list styles.
Kind regards, Francis Hi Francis, Thanks for the update! Allow me three follow-up questions & suggestions: - How about adding those editing subtasks to JIRA, perhaps those to be fixed for ODF 1.3 CS02 becoming part of OFFICE-4079 and those for later as a new ODF 1.4 editorial issue.
- What makes your review preliminary? What is missing? Could you point the documents you base your experiences from JIRA (and/or put your latest working draft to GitHub)?
- How about adding the automated tooling for changing the styles as part of the ODF-TC repo - these search & replace tasks should be done by automation.
My action under item 5 of the TC meeting on June 29 was to report in my review of use of styles in the ODF 1.3 specifications. I have performed a preliminary review of the use of paragraph, character and list styles in Parts 2, 3 and 4 of the specifications, considering all drafts issued between July 2018 and January 2020 (CSD02). All three Parts exhibit similar problems, of which the main cases are: - Two or more styles being used for the same purpose within a draft, e.g. the paragraph styles âText Bodyâ and âDefault Styleâ both being used for body text.
- New styles being introduced in later drafts, e.g. the conditional paragraph style âAppendix Headingâ being replaced by the non-conditional paragraph style âAppendixHeading1â in CSD02 only.
- Styles being dropped in later drafts, e.g. the paragraph style âDefault Valueâ, applied to paragraphs that contain default attribute values, was somehow removed from Part 3 in WD13-03 onwards.
- Many styles whose purpose is unclear and which appear to overlap other styles, e.g. in Part 3 there are four character styles âAttribute Valueâ, âAttribute Value Fragmentâ, âAttribute Value Instanceâ and âAttribute Value Paramâ. Another example: Part 4 contains list styles âExample Numberingâ, âNumbering 1â and âNumbering 5â (what happened to âNumbering 2â, ââ 3â and ââ 4â?).
- Poor naming of styles, e.g. the character style âFurmula Subâ [sic] in Part 3, and inconsistent use of title case in style names.
- Lack of stability in style definitions, which seem to change, especially in CSD01 and CSD02, e.g. changes to space above and below paragraphs, font sizes, background colors, etc.
My proposal is that the first Working Draft of ODF 1.4 should be based upon a template in which the named styles are well-defined in terms of their naming conventions, their definitions and their planned usage. For this to be achieved, the editors should ensure that: - A well-defined style schema is prepared, detailing the names, properties and intended usage of all paragraph, character and list styles.
- There is a single text template to be used as a basis for drafting all Parts of ODF 1.4 and future editions, in which all styles conform to the style schema.
- When ODF 1.3 is issued as a Candidate OASIS Standard, a version of the text of all four Parts is created in which all styles follow the style schema.
- The text so created is imported into the new template to generate a clean working draft of ODF 1.4.
In order to create a well-defined style schema, the editors will need to complete the current review of styles in ODF 1.3, deciding which styles are needed, what properties they should have and how they should be used. I anticipate that this process, ending with the issue of style schema, template and first working draft of ODF 1.4, will take a further two or three weeks. In order to support work on extracting default attribute values from the Part 3 specification, and to improve the HTML generated from the ODT file, I have already prepared an informal draft of Part 3, based upon CSD02, in which the style definitions are reset to what they were in early working drafts (which corresponded better to the styles used in ODF 1.2) and the paragraph style âDefault Valueâ is re-applied to paragraphs in which default attribute values are specified. Francis
|