Plateau 2025: rwp test - encoding of text inside [ ] in mn

[ReesePlews]

some problem with the encoding of text inside [ ] in mn; this

doc01: sources/001-v5

sources/001-v5/sections/section-03/section-01.adoc

[[toc3_01]]
=== データ製品の名称

データ製品の名称は、「``3D都市モデル\_[都市コード]_[提供者区分]\_[整備年度]_[オプション]``」とする。
// データ製品の名称は、「``3D都市モデル_[都市コード]_[提供者区分]_[整備年度]_[オプション]``」とする。

``[都市コード]``、``[提供者区分]``、``[整備年度]``及び``[オプション]``は、成果品のルートフォルダの名称に含まれる``[都市コード]``、``[提供者区分]``、``[整備年度]``及び``[オプション]``と一致する。

i am not sure the problem here if it is the _ or something else. investigating in a new branch

[ronaldtse]

@ReesePlews the double backtick syntax is correctly used to indicate "monospace font" because this is a filename (i.e. "code").

This may be the result in the PDF's usage of monospace font causing it to drop below baseline. @Intelligent2013 could you please help check? Thanks!

[ReesePlews]

hi @ronaldtse thanks for examining this. the client made a modification a few months ago. i am not sure which style they are expecting. here is output of my test.

check1

``3D都市モデル\_[都市コード]\_[提供者区分]\_[整備年度]\_[オプション]``

check2

+3D都市モデル_[都市コード]_[提供者区分]_[整備年度]_[オプション]+

check3

pass:[3D都市モデル_[都市コード]_[提供者区分]_[整備年度]_[オプション]]

are these test encodings valid for mn? check2 seemed to produce the clearest result but i am not sure if that is what the client is expecting.

@AIS-RyoMukai which are you expecting in the document?

[Intelligent2013]

It's known Apache FOP bug (https://issues.apache.org/jira/browse/FOP-3175) due the default font monotype Courier New.

I've excluded the font Courier New (the change not merged yet in metanorma-plateau) from the font list and now the font Noto Sans Mono CJ Khk is using for the monotype text rendering:

As you can see the font's Noto Sans Mono CJ Khk baseline is a bit lower than the main text rendered by the font Yu Gothic. I can fix it via the XSLT on-fly, but there is an another visual difference between main text (Yu Gothic font) and monotype text (Noto Sans Mono CJ Khk) - the text in the font Noto Sans Mono CJ Khk looks more bold than text in the font Yu Gothic. It's ok or not?
If not, then we need to use another monotype font that support Japanese characters. Which font would you like to use for displaying monotype Japanese characters?

[ReesePlews]

hello @Intelligent2013 thank you very much for checking this.

the issue with Noto Sans Mono CJ Khk looking more bold is rather "eye-catching"; we have known this, but i am not sure how the client wants to handle it. i will need to ask. i think the uneven baseline is a more serious problem than the heavy-bold appearance, but that is only my opinion.

presently i do not know an open license monotype Japanese font. perhaps @ronaldtse has a suggestion.

the client has also provided these possibly related examples:

doc2: sources/002-v5 - table 5-17 :gml appearing below the baseline (this is from a modspec table)

it could be a source code issue, i am not sure, i have not checked it yet.

additionally, we do have this open issue from last year,

• plateau: non-kanji characters appear unbolded in clause/subclause headings while appear bolded in table/figure titles or captions #372

i dont know if it is related or not. this year i did not mention this because of the work on fontist and i did not want to introduce another issue.

[ronaldtse]

We need to check if baseline issue is due to a font bug or our PDF renderer's bug or something we can fix at our PDF rendering.

Ping @Intelligent2013 , you're the expert in this 🙏