plateau: ordered list in PDF being rendered differently in viewer

[ReesePlews]

in Plateau doc02 (sources/002-v5) an ordered list in the PDF is rendering as a) b) c) is being rendered in the viewer as 1) 2) 3)

correctly ordered list from the PDF

the same ordered list in the viewer

[ronaldtse]

Plateau follows JIS list item labeling. The PDF is correct here.

[ReesePlews]

thanks @ronaldtse;

additionally this main issue also occurs in the viewer version of Plateau doc01 (sources/001-v5)

[ronaldtse]

The issue is programmatic so both documents will exhibit the same behavior.

I believe the best way to handle is have the list label progression definition embedded in the XML source as presentational elements. Ping @opoudjis

[ronaldtse]

Ping @opoudjis to ensure that list labels are included inside MN XML.

[opoudjis]

Ping @opoudjis to ensure that list labels are included inside MN XML.

They already are.

== Scope

. A
. B
.. C

generates in Presentation XML:

<ol id="_c13d3d7e-6fc6-5aa6-f368-0d81b8c7d1ee" type="alphabet"><li id="_901e8405-d465-420b-bdfb-8727f0997d12" label="a"><p id="_b09dbe9c-3b42-c169-a87c-f4aec97a79ec">A</p>
</li>
<li id="_64dfe52a-081c-4906-b2d2-a35ed939f36b" label="b"><p id="_3998aee2-a32d-aca5-5fd3-4f39c4eb22ab">B</p>
<ol id="_ca89636b-d2f4-a3de-0021-c32d7dc82844" type="arabic"><li id="_40a2f481-930b-4dc4-85f9-13c2850706fa" label="1"><p id="_16a81ca9-25c3-0794-9c32-c056592d6c63">C</p>
</li>
</ol>
</li>
</ol>

Note the li/@label attribute.

[ronaldtse]

@opoudjis there is type="alphabet" and label="b" but is the result b) or b.? This is unclear.

[opoudjis]

As metanorma/metanorma-iso#319 https://github.com/metanorma/metanorma-iso/blob/main/lib/isodoc/iso/html/style-iso.scss will show, changing the rendering in HTML of a ordered list label is convoluted.

The only way this is going to be realisable at all is by providing a separate value for the rendering template: the label needs to be kept alone as a value, which would be the input into any CSS counter, and then styled by the template:

ol[class="roman"] > li::before {
  counter-increment: roman;
  content: counter(roman, lower-roman)") "
}

The CSS would need to be content: %), with % replaced by the counter value derived from label: b.

I will add a label-template attribute to ol/li, which by default will be "%." and in this instance will be "%)".

[ronaldtse]

Thanks @opoudjis. An additional question: would it be better if we can declare the list styling definitions governing the entire document, and referring to them with names?

[strogonoff]

Numbering should be fixed after next deployment.

However, the spacing may take longer to update, and I am not sure it will be done by Feb 28. I believe that belongs to another issue. There is a range of choices made by Firelight about line height, etc. that are more about typography and not so much about content. Some of those choices may conflict with JIS.

(I accept that list numbering is about content, but note that ideally we could probably use cross-references instead of authors simply typing “a.” and “b.” like in this screenshot — cc @ronaldtse? It would be cumbersome with AsciiDoc, but more easy with a visual editor if it’s implemented.)

Note that MN PDF has spacing issues where characters in a list are not grid-aligned with preceding paragraphs (yellow lines on screenshot below). However, Firelight has another spacing issue where characters become misaligned after using “a.” and “b.” in third list item (green lines on screenshot below), I suspect this could be because Firelight is not using half-width or full-width romaji.

Instead of relying on the lines you can observe character bounding box grid alignment/misalignment by selecting text in PDF and in Firelight.

[strogonoff]

I didn’t read the preceding discussion before implementing this. My simple solution works for this case, but I imagine will be a problem if a list is broken by another block and continued.

[ReesePlews]

thanks for checking and updating this discussion @strogonoff

i can clarify a bit, and after recent discussions with @ronaldtse about how the "dynamic delivery" of the viewer app works.

the issue is not the line or character spacing, the main issue was:

an ordered list in the PDF is a, b, c... but in the viewer the ordered list was 1, 2, 3... this creates a navigation problem.
one user sees a, b, c and the other 1,2,3 they cannot easily communicate. additionally in the image in the first post, you can see in the PDF list item c) refers to earlier list items a) and b) .... if you look at the next image from the viewer, you can see that list item 3) refers to a) and b) a と b which makes no sense.

this is what the issue is about. not line or character spacing. at this time, the main worry is not the spacing issues.

if the viewer is fixed to show a. b. c. that is still close enough as the PDF's a), b), c)

of course one may ask why the viewer cannot show ")" instead of "." but it could be explained a pending issues with list symbology.

hope this clarifies things. let me know if there are any questions. thank you.

[strogonoff]

Sure. I’ll investigate showing ), good point…

[ronaldtse]

FYI @opoudjis is working on providing the definitions of the label formatting in the XML for renderers. Hopefully that will save time here and prevent double efforts.

[ReesePlews]

hello @strogonoff please provide an update on this issue. thank you.

[strogonoff]

No updates. I believe the concern with wrong numbering (1/2/3 instead of a/b/c) was addressed two weeks ago.

[ReesePlews]

thank you @strogonoff i see that now and confirm that the numbered list (from the first example) has been fixed.

is this issue kept open because of another problem?

[strogonoff]

I still want to try a)/b)/c) with parentheses. It may be visible in supported browsers after the next build. But the original issue is probably solved now…