metanorma / mn-native-pdf

Development repository for mn2pdf with Metanorma document samples
4 stars 2 forks source link

XSLT: check all xslts for list item labels (default also) for ordered lists #296

Closed Intelligent2013 closed 2 years ago

Intelligent2013 commented 3 years ago

As titled.

Intelligent2013 commented 3 years ago

Current labels for ordered lists:

Intelligent2013 commented 3 years ago

@opoudjis In some flavors there is discrepancy between type of ordered lists and list item labels. For example, OGC 00-027: in the source xml type="arabic":

<ol id="_431190c2-840e-4285-a473-92f6a505f7e2" type="arabic">
<li>
<p id="_cd0d2534-0567-4773-8a0b-36b81b9a42eb">It tries to read the default IOR (Interoperable Object Reference) file, which contains the address of the catalog server;</p>
</li>
<li>
<p id="_afd03ba5-715c-4178-956d-befb34ac2fc9">It initializes the ORB (Object Request Broker);</p>
</li>
...
</ol>

in the resulted DOC it shows with 'a', 'b', ... labels: изображение

In xslt for PDF I've made as in doc, i.e. 'arabic' lists shows as 'alphabet', and also another relations established experimentally.

I would like to check all xslt for these rules and set them as in doc/html and my questions is - where is in the ruby code can I find the rules about which labels need to show for list items?

opoudjis commented 3 years ago

Hm.

So,

the base behaviour is in isodoc/lib/isodoc/function/lists.rb:

  OL_STYLE = {
      arabic: "1",
      roman: "i",
      alphabet: "a",
      roman_upper: "I",
      alphabet_upper: "A",
    }.freeze

    def ol_style(type)
      type = :alphabet unless type
      OL_STYLE[type.to_sym]
    end

    # We don't really want users to specify type of ordered list;
    # we will use a fixed hierarchy as practiced by ISO (though not
    # fully spelled out): a) 1) i) A) I)

    def ol_depth(node)
      depth = node.ancestors("ul, ol").size + 1
      type = :alphabet
      type = :arabic if [2, 7].include? depth
      type = :roman if [3, 8].include? depth
      type = :alphabet_upper if [4, 9].include? depth
      type = :roman_upper if [5, 10].include? depth
      ol_style(type)
    end

 def ol_attrs(node)
      { type: node["type"] ? ol_style(node["type"].to_sym) : ol_depth(node),
        id: node["id"], style: keep_style(node) }
    end

That means that, if we allow ol/@type in Metanorma XML, we use that type in HTML generation. If we do not allow ol/@type in Metanorma XML, we instead use the ISO pattern of alternating types depending on list depth. Which hopefully you have already implemented.

Now, if any of those methods are overridden in a flavour, that behaviour takes over. I see the following overrides:

BIPM:

def ol_attrs(node)
        klass, style = if node["type"] == "roman" &&
            !node.at("./ancestor::xmlns:ol[@type = 'roman']") ||
            node["type"] == "alphabet" &&
            !node.at("./ancestor::xmlns:ol[@type = 'alphabet']")
          [node["type"], counter_reset(node)]
                       end
        super.merge(attr_code(type: ol_style((node["type"] || "arabic").to_sym),
                              start: node["start"]), style: style, class: klass)
      end

In other words, allow start on list (which we normally don't), and use only ol/@type as the list type. (The class is about realising start in HTML CSS.)

IETF: has no PDF rendering.

ITU:

 def ol_depth(node)
        return super unless node["class"] == "steps" or
          node.at(".//ancestor::xmlns:ol[@class = 'steps']")
        depth = node.ancestors("ul, ol").size + 1
        type = :arabic
        type = :alphabet if [2, 7].include? depth
        type = :roman if [3, 8].include? depth
        type = :alphabet_upper if [4, 9].include? depth
        type = :roman_upper if [5, 10].include? depth
        ol_style(type)
      end

So whereas ISO uses a) 1) i) A) I), ITU uses 1) a) i) A) I) if this is a steps list

MPFA:

      def ol_depth(node)
        ol_style(node["type"])
      end

So use ol/@type

NIST:

      def ol_depth(node)
        return super unless node["class"] == "steps" or
          node.at(".//ancestor::xmlns:ol[@class = 'steps']")
        depth = node.ancestors("ul, ol").size + 1
        type = :arabic
        type = :alphabet if [2, 7].include? depth
        type = :roman if [3, 8].include? depth
        type = :alphabet_upper if [4, 9].include? depth
        type = :roman_upper if [5, 10].include? depth
        ol_style(type)
      end

So whereas ISO uses a) 1) i) A) I), NIST uses 1) a) i) A) I) for steps, like ITU.

Now. You could repeat this formatting, but it does seem more sensible for me to move this functionality to Presentation XML. Eventually.

The discrepancy in OGC is somewhat surprising, but there is an added complication: I silently allowed the isodoc default to use ol/@type if supplied only very recently, a couple of months ago. If the document was compiled before then, it would use the old behaviour, in which ol/@type was always ignored, in both Asciidoc > Metanorma XML and Metanorma XML > HTML, and only the ol_depth method was used. (You can see that that was the default behaviour from the fact that the flavours use ol_depth to access ol/@type.)

Currently only metanorma-iso and its children (i.e. metanorma-iec, metanorma-gb, but the latter is no longer maintained) ignore any ol/@type supplied in markup: the a) 1) i) A) I) series is mandatory for all ISO ordered lists.

So, to keep things sane:

Intelligent2013 commented 3 years ago

@opoudjis thank you for detailed clarification. I'll fix xslt for these rules, it won't take long, so at this time this task is not urgent.

Regarding OGC document, I download it from here https://github.com/metanorma/mn-samples-ogc/tree/gh-pages, they were created 21 day ago.

opoudjis commented 2 years ago

We add to these exceptions the exceptions of BSI, that list item numbering alternates between alphabet arabic roman. However, that has already been set in the Semantic XML, so nothing further needs to be done for it.

ronaldtse commented 2 years ago

@opoudjis can we document these comparisons of list numberings in some place that we can compare across flavors?

opoudjis commented 2 years ago

We haven't done that anywhere, but ok...

opoudjis commented 2 years ago

Documentation associated with https://github.com/metanorma/metanorma-ogc/issues/359

Intelligent2013 commented 2 years ago

Xslt updated:

Some flavors uses different styles: