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

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

Đang mở
#295 3 bình luận 1 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
Python
Star
17.2k
Fork
1.4k
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

### 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`.

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.