You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is for things I could not straightforwardly render into Asciidoc in the Rice document. As you won't be surprised to hear, I'd rather not—I think a little curtailment of formatting possibilities in Asciidoc is a reasonable price to pay. But running these past you.
Table 1 contains an unordered list in "Extraneous matter: organic" and "Extraneous matter: inorganic", and each list element lines up with a row of numbers. That means that each list item is its own table row. I haven't done that in Asciidoctor: while you can embed lists within cells, getting list items to then be considered table rows breaks the table model, and I don't think it's necessary.
"Normative" and "Informative" follows annex names in brackets; it cannot be part of the numbering, as it is in ISO output (Annex C (informative))
Subsection headers cannot be both numbered as subsection headers, and appear inline with their following text (e.g. B.2.1)
There is no automated numbering of "stem" blocks, which is how I'm currently doing formulas. There is automated numbering of examples; but I want to reserve examples for other kinds of markup; and in any case, examples will be automatically labelled and sequenced the same whether they contain figures or formulas or anything else (including the examples recognised as such within Terms and Definitions). I think this one is too hard to come up with a satisfactory answer to, and numbering will be finalised downstream anyway.
The text was updated successfully, but these errors were encountered:
Table 1 unordered list in "Extraneous matter": isn't this just a normal list inside an AsciiDoc (A type) table cell? I din't see why it is its own table row.
For the Annex "Normative/Informative" issue: is the problem in the Index/TOC where the phrase (Normative) is non-bold amongst the bolded sentence?
B.2.1 style clauses seem quite often used in an ISO document, there are also B.5.1 style clauses that do not have headers. I wonder what we can do here?
Automated number of "stem" blocks. I agree that "stem" is appropriate for formula expressions. Numbering is supposed to be done downstream anyway.
Of these discrepancies, 2 and 4 have been resolved. 3 is pending #24, will need formatting attribute in document model.
1 has been realised as a set of table cells, because each list entry lines up precisely with what follows. In fact, that is why #36 has been deferred: ISO does this routinely with chemical table entries, giving units and stem expressions, which means it contradicts Asciidoc's assumption that there is only one header row.
This issue is for things I could not straightforwardly render into Asciidoc in the Rice document. As you won't be surprised to hear, I'd rather not—I think a little curtailment of formatting possibilities in Asciidoc is a reasonable price to pay. But running these past you.
Table 1 contains an unordered list in "Extraneous matter: organic" and "Extraneous matter: inorganic", and each list element lines up with a row of numbers. That means that each list item is its own table row. I haven't done that in Asciidoctor: while you can embed lists within cells, getting list items to then be considered table rows breaks the table model, and I don't think it's necessary.
"Normative" and "Informative" follows annex names in brackets; it cannot be part of the numbering, as it is in ISO output (Annex C (informative))
Subsection headers cannot be both numbered as subsection headers, and appear inline with their following text (e.g. B.2.1)
There is no automated numbering of "stem" blocks, which is how I'm currently doing formulas. There is automated numbering of examples; but I want to reserve examples for other kinds of markup; and in any case, examples will be automatically labelled and sequenced the same whether they contain figures or formulas or anything else (including the examples recognised as such within Terms and Definitions). I think this one is too hard to come up with a satisfactory answer to, and numbering will be finalised downstream anyway.
The text was updated successfully, but these errors were encountered: