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

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

Offen
#295 3 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Python
Sterne
17.2k
Forks
1.4k
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

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

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.