adobe-fonts / adobe-fonts/source-han-sans

U+30FB and U+2027 are not full-width

Open
#295 3 comments 1 reaction 0 assignees View on GitHub
Dominant language
Python
Stars
17.2k
Forks
1.4k
PR merge metrics
No merged PRs in 30d

Description

### Prerequisites

* [x] If you are reporting an issue that affects glyphs for characters for a particular region or regions, did you verify that the characters are within the supported scope of the region or regions? This generally means GB 18030 or Tōngyòng Guīfàn Hànzìbiǎo (通用规范汉字表) for China, Big Five or CNS 11643 Planes 1 & 2 for Taiwan, HKSCS-2016 for Hong Kong, JIS X 0208, JIS X 0212, and JIS X 0213 for Japan, and KS X 1001 and KS X 1002 for Korea.
* [x] Did you thoroughly search the [open](https://github.com/adobe-fonts/source-han-sans/issues) and [closed](https://github.com/adobe-fonts/source-han-sans/issues?q=is%3Aissue+is%3Aclosed) issues to avoid reporting a duplicate issue?
* [x] Did you go through the [official font readme file](https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.pdf) to better understand the scope of the project, to include the *Known Issues* section at the very end?

### Description

*Source Han Serif mirror issue*: https://github.com/adobe-fonts/source-han-serif/issues/93

Using language-specific OTFs (with full 65535 glyphs support, not the subset OTFs), the character `・` (U+30FB, Katakana Middle Dot) is sometimes rendered as proportional-width, but it should always stay full-width. Here are the steps to reproduce this bug:
1. Type `・` into whatever layout program.
2. Use any one of the 3 Chinese-oriented (SC, TC, or HC) OTFs to render this character.
3. Either language-tag with `ZHS`, `ZHT`, or `ZHH` (under any script `latn`, `grek`, `cyrl`, `kana`, `hang`, or `hani`), or just use the font’s default script and language. The character `・` is rendered as full-width.
4. Switch language tag to `JAN` or `KOR`, then the character `・` becomes proportional-width.
5. But using J or K versions of the OTFs, U+30FB will stay full-width.

Similarly, the character `‧` (U+2027, Hyphenation Point) has the exact same problems.

### Bug analysis

By default, to render either U+30FB or U+2027, the 5 OTFs (SC, TC, HC, J, and K) all use `cid1644` (full-width).

To render `·` (U+00B7, Middle Dot), SC, TC, and HC still use `cid1644` (full-width). However, J and K use `cid117` (proportional-width).

To render `•` (U+2022, Bullet), SC, TC, and HC still use `cid1644` (full-width). However, J and K use `cid733` (proportional-width, but a different one).

The lookup tables `cn2jp`, `cn2kr`, `tw2jp`, `tw2kr`, `hk2jp`, and `hk2kr` all contain the following line:
```
substitute \1644 by \733;
```
So this is the source of the problem:
1. This substitution is needed, because when a user types `•` (U+2022), we want it to be full-width in `ZHS`, `ZHT`, and `ZHH`, but we want it to be proportional-width in `JAN` and `KOR`.
2. But this simple substitution carries two problems:
1. When a user types either `・` (U+30FB) or `‧` (U+2027), the substitution to proportional-width still happens in SC, TC, and HC, although either glyph should stay full-width.
2. When a user types `·` (U+00B7) using the SC, TC, or HC font, but language-tagged the character with `JAN` or `KOR`, the result is `cid733`. But using the J or K font, the result is `cid117`. The two should all be `cid117`.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.