By looking at discussions at "Fundamental Questions
," "Letterlike Symbols
," "U+2018 and U+2019
," and so forth, it looks like all arguments are the same; what to do with ambiguous code points. I think all agrees that if they appear alone within Asian context, they should be upright. If they appear within Latin context, they should be rotated. So adding just one more property should suffice all the requests.
I wished to add more such modes or tailoring in future versions, but I'm now convinced that adding it now works better, rather than having one code point good value for one usage and the other code point for the other usage just because doing so looks like more common as of today. That might be different tomorrow.
We have SVO, where most characters are upright as long as doing so doesn't look break. My proposal is to have its counterpart, where most characters are sideways. This property has following use cases:
- Asian documents where symbols are primarily used in conjunction with letters or numbers.
- Asian documents with a lot of Latin context. This includes math books, technical documents, guidebooks for travelers, etc.
- Non-Asian documents with Asian snippets. Setting Han characters rotated look wrong even when they appear in table cells for instance, so adding this value enforces the goal of UTR#50 to look vertical flow not broken without any markups in more scenarios.
Fortunately, the property should not be that hard to develop, and I hope it's not very controversial. We can start with copying values from SVO or MVO for where EAW=W or F, and set all the rest to R. This method aligns to what three people in this forum want, and works good for future code points additions.
As of draft #5 + recent consolidated feedback, only 5 code points have different values for SVO and MVO after filtered by EAW=W or F:
draft #5 + recent consolidated feedback wrote:
U+3000 IDEOGRAPHIC SPACE -- MVO=U, SVO=R
U+FE49 ﹉ DASHED OVERLINE -- MVO=R, SVO=U
U+FE4A ﹊ CENTRELINE OVERLINE -- MVO=R, SVO=U
U+FE4B ﹋ WAVY OVERLINE -- MVO=R, SVO=U
U+FE4C ﹌ DOUBLE WAVY OVERLINE -- MVO=R, SVO=U
We need to come up with whether they should be R or U for RVO given its goals and use cases, but MVO/SVO for these code points are still under discussions if I understand correctly, so we can keep watching and decide whether to copy from SVO or MVO after the discussion is done.