In labels in vertical writing mode, replace punctuation with fullwidth equivalents

[1ec5]

Per #3438 (comment), but various Chinese and Japanese dashes and brackets are rotated 90° or 180° when laid out vertically. Apart from dashes and parentheses, punctuation might be uncommon in road names (the most commonly line-placed names). However, if it ever occurs, the result could be confusing. For example, an em dash (—), left unrotated, could be confused with a radical (丨) or numeral (〡).

Below are the affected punctuation marks and their vertical forms. Some of them, like the em dash, are used both in Chinese and in English, so the replacement should only occur adjacent to a vertical (CJK) character lest the English side of a bilingual label get mangled.

Horizontal	Vertical
。	︒
—	︱
–	︲
_	︳
（	︵
）	︶
｛	︷
｝	︸
〔	︹
〕	︺
〘	︹ (?)
〙	︺ (?)
【	︻
】	︼
《	︽
》	︾
〈	︿
〉	﹀
「	﹁
」	﹂
『	﹃
』	﹄
｢	﹁
｣	﹂
［	﹇
］	﹈
“	﹁
”	﹂
‘	﹃
’	﹄
…	⋮
.	・

/cc @lucaswoj @nickidlugash @xrwang @friedbunny

[1ec5]

Per #3438 (comment), this is also necessary because a non-CJK glyph may in many cases extend upwards past the cap height, which would cause it to collide with the previous character in vertical text.

[lucaswoj]

adjacent to a vertical (CJK) character

Which of these should our criteria be?

• (a) use vertical punctuation if either of the surrounding characters "allow vertical writing mode"
• (b) use vertical punctuation if both of the surrounding characters "allow vertical writing mode"

[1ec5]

Most CJK punctuation marks have a built-in space, so they bind to one side or another: for example, （ should turn into ︵ based on the CJK-ness of the following character. —, on the other hand, can become ︱ if either adjacent character is CJK. As for #3438 (comment), / is a non-vertical glyph with no vertical equivalent, so #3506 would rotate the standard glyph regardless of what comes before or after.

We might have to endure some trial and error with {name} in Streets source to figure out the right set of rules.

[nickidlugash]

Per #3438 (comment), this is also necessary because a non-CJK glyph may in many cases extend upwards past the cap height, which would cause it to collide with the previous character in vertical text.

To clarify my comment about the solidus character, this punctuation mark should actually not get rotated – only the characters in the list above should get rotated. So this ticket will not solve the solidus issue (although parenthesis, which are on the list, have the same overshoot issue).

[1ec5]

Wouldn't we want to rotate the solidus once #3506 is implemented?

[1ec5]

Actually, there's a whole complement of fullwidth forms we can use for cases where we want to avoid rotating a Western character. For example, we'd replace any solidus adjacent to CJK with ／.

[nickidlugash]

there's a whole complement of fullwidth forms we can use for cases where we want to avoid rotating a Western character.

see my previous comment regarding this.

[nickidlugash]

And yes, we do not want to rotate the solidus if it is surrounded by CJK.

[lucaswoj]

Rather than mark this a "release blocker", I'm going to roll this into #3438

[1ec5]

I've seen conflicting information as to whether this is the correct character to use for Chinese in general and specifically for vertical orientation – solidus (U+002F), versus fullwidth solidus (U+FF0F).

My understanding is that the ordinary ASCII character is preferred for horizontal text while the fullwidth form is preferred for vertical text. The same is true for the quote marks in Simplified Chinese (e.g., “ versus ﹁) and ideally for the single-letter case (but that’s another story).

[1ec5]

Fullwidth punctuation is surprisingly quite common on linear features in Mapbox Streets data, especially on highway names. In OpenStreetMap, a mere 133 ways use fullwidth punctuation in name:zh in 🇨🇳🇭🇰🇲🇴🇹🇼, compared with 1,636 in name. However, the Mapbox Streets source’s {name_zh} property falls back on name if name:zh is absent. There are 3,950 such ways in the largest 🇯🇵 bbox I can create without timing out.

These queries don’t account for ASCII punctuation that often occurs in conjunction with Chinese text.

[lucaswoj]

Initial work done in mapbox/mapbox-gl-test-suite@b6281b1 and 4d5f5e6

[lucaswoj]

Done in #3438

[1ec5]

Next steps: #3587.