Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

IBM Plex Sans JP 3.0.0: U+2212 MINUS SIGN has a glyph (`minus`) but no cmap entry, plus 172 other unencoded glyphs

Abierto
  • ¿Algo no está bien?
#728 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
40/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Área
documentation

Línea de trabajo

The issue is about font encoding tables (cmap). The reporter used fontTools to analyze the TTF/OTF files. Start by examining the attached TSV file and image to understand the missing mappings. Check the font source files (likely in the repository's source directory) to see how the cmap is generated. The goal is to update the font build process to include the missing Unicode mappings, particularly for U+2212 and the 172 other glyphs, while preserving existing proportional-width overrides. Verify changes by rebuilding the font and testing with a script similar to the provided Python snippet.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

In @ibm/[email protected] (font version 1.004), the font contains a proper minus sign glyph, but U+2212 MINUS SIGN is not mapped in the cmap table. As a result, U+2212 falls back to another font in browsers and applications, even though the glyph exists.

While investigating this, I also found 172 other glyphs whose names indicate a Unicode code point but which are not mapped in cmap. I'd like to ask whether these are intentionally unencoded.

Environment
  • Release: @ibm/[email protected]
  • Font version: 1.004 (IBM PLEX SANS JP V1.4)
  • Files checked: all 8 weights (Thin, ExtraLight, Light, Text, Regular, Medium, SemiBold, Bold), both OTF and TTF (16 files)
  • Tool: fontTools 4.62.1
1. U+2212 MINUS SIGN is not mapped
  • The glyph exists as minus in the TTF files and as CID 23064 in the OTF files. It has a 600-unit advance width and is correctly designed in every weight.
  • U+2212 is absent from every cmap subtable (formats 4 and 12, all platforms) in all 16 files.
  • The glyph is currently reachable only via GSUB: salt / nalt substitute hyphen → minus, and ital substitutes minus → CID 9594.

For comparison:

  • IBM Plex Sans (V3.005, all 16 OTF and 16 TTF files, roman and italic) maps U+2212 to its minus glyph. The JP glyph has the same advance width and a very similar outline.
  • The official Adobe CMap UniJIS2004-UTF32-H (v1.022) maps U+2212 to CID 693, the full-width minus that Plex Sans JP already maps to U+FF0D.

Plex Sans JP seems to intentionally map several ambiguous-width symbols to proportional glyphs rather than the full-width glyphs specified by the official CMap. Examples include § ° ± × ÷ ′ ″ and many math operators such as ∞ ≠ ∈ ⊂ ∫ (60 code points in total). The 3.0.0 fix for CID 106, 118, 186 and 215 (§ ¶ × ÷) also maps them to proportional glyphs. Following that policy, I would expect U+2212 to map to the proportional minus glyph.

Of the IBM-added glyphs beyond Adobe-Japan1-7 (CID 23059–23080), minus is the only one that corresponds to a single code point but is not encoded. The others are either variants (.alt01, .vert) or are mapped (the arrows at CID 23066–23080). So this looks like an oversight.

Reproduction:

from fontTools.ttLib import TTFont
f = TTFont("IBMPlexSansJP-Regular.ttf")
print(f.getBestCmap().get(0x2212))   # None
print("minus" in f.getGlyphOrder())   # True

Expected: U+2212 is mapped to minus (or at least to some glyph) in all weights and formats.

2. Other unencoded glyphs: are these intentional?

Besides minus, there are 172 glyphs (identical across all weights) whose names (uniXXXX / uXXXXX) indicate a single code point that is not mapped in cmap. The main groups are:

  • Parenthesized, circled, and squared Latin capital letters: U+1F110–1F129, U+1F130–1F149, U+1F150–1F169, U+1F170–1F189 (104 glyphs)
  • CJK ideographs: e.g. U+9FBC–9FCC, U+FA6B–FA6D, U+2A9E6, U+2B746…U+2B81A (41 glyphs)
  • Symbols: U+0FD6, U+26AA, U+26AB, U+26BD, U+26BE, U+26CB, U+25FB, U+25FC, U+2B1A, U+2B60–2B65, U+2B82, U+2B83, U+1F79C, U+1F202, U+3244, U+301E, U+FE17, U+FE18
  • Latin/Greek: U+207F, U+A7B5, U+AB53
  • Private Use Area: U+F0C8–F0CA

I compared these against UniJIS2004-UTF32-H v1.022:

  • 169 of them are mapped in the official CMap, and the CID it specifies is exactly the glyph's position in Plex Sans JP. Some are relatively recent additions to the CMap, e.g. U+1F79C → CID 12244 (added in the July 2019 CMap release). U+9FCC → CID 20156 is an older addition, made when Unicode 6.1 was released.
  • 3 (U+F0C8–F0CA, Private Use Area) are not in the official CMap, so leaving them unencoded seems reasonable.

In addition, 19 more code points in the official CMap are unmapped in Plex Sans JP even though the glyphs exist, but their glyph names don't contain a code point. Examples: U+1B132 / U+1B155 (small ko, CID 12269 / 12271, added in the January 2023 CMap release), U+2B97, U+29C8, U+27BF, U+1F237, U+31350.

In total, 189 mappings from UniJIS2004-UTF32-H are missing from Plex Sans JP. Since the 3.0.0 release notes treat missing mappings (CID 106, 118, 186, 215) as bugs, I suspect these may be oversights too, perhaps because the cmap was built from an older mapping table. However, I'm not sure whether some of them were left unencoded on purpose.

Questions:

  1. Is leaving these glyphs unencoded intentional? If so, what is the policy?
  2. If not, could the cmap be regenerated from the current UniJIS2004-UTF32-H, while keeping the intentional proportional-width overrides?

I've attached a TSV listing every difference between Plex Sans JP and UniJIS2004-UTF32-H (missing mappings, CID differences, and JP-only mappings), along with an image of the 173 unencoded glyphs.

Thank you for your work on Plex Sans JP!

plex-sans-jp-vs-UniJIS2004-UTF32-H.tsv

Image
Lenguaje dominante
CSS
Estrellas
11.7k
Forks
625
Merge medio
20 h 31 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de IBM/plex

Todos los issues de IBM/plex

Issues similares

Más issues de Documentation

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.