The halt (Alternate Half Widths) and palt (Proportional Alternate
Widths) features—together with their vertical counterparts vhal and
vpal—were defined as GSUB substitution lookups instead of GPOS metric
adjustments. These lookups contained hundreds of ideograph substitutions
copied from the traditional-forms (trad), JIS78/JIS90 (jp78/jp04)
and vertical (vert/vrt2) features, including many Japanese
shinjitai-to-traditional conversions (e.g. 亜→亞, 医→醫, 円→圓).
As a result, enabling halt/palt for width adjustment in Figma or via
CSS font-feature-settings unexpectedly switched Japanese kanji to
Chinese (traditional) glyph forms.
This defect was present from the initial import of the Glyphs source and
affects all four weights (Thin/Regular/Bold/ExtraBold).
Fix: clear the substitution code from halt/palt/vhal/vpal in all
four fontinfo.plist sources so these features no longer alter glyphs.
Glyph-form switching remains available through the dedicated trad,
jp78 and jp04 features, which are left untouched.
Verification:
- hb-shape:
halt=1/palt=1no longer change kanji glyphs;trad=1
still converts to traditional forms. - GSUB: halt/palt/vhal/vpal substitution counts are 0 in all weights;
trad (309) and jp78 (299) are preserved. - fontspector (googlefonts profile): identical results before and after
(PASS 313 / WARN 98 / FAIL 25 / ERROR 4); no new failures introduced.
Note: this change only stops the incorrect glyph substitution. Proper
half-/proportional-width GPOS metrics for halt/palt are out of scope and
can be added separately.
Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
- ci: Guard GitHub Pages deploy job to main branch only
The build job only uploads the github-pages artifact on the main
branch, but the deploy job ran unconditionally. On PR branches the
deploy job tried to deploy a non-existent artifact and failed. Add
the same main-branch guard to the deploy job so it is skipped on
non-main branches.
Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
- test: add fontspector shaping regression tests for halt/palt/vhal/vpal
The shaping/regression check was SKIPped because no test directory was
declared, so nothing guarded against the class of bug fixed in 34ca0c2:
metric features (halt/palt/vhal/vpal) carrying GSUB substitutions.
Declare the test directory in fontspector.toml and wire --configuration
into make test, so both local runs and CI pick it up.
The tests cover all four features that were cleaned up, plus trad as a
positive control. Every case was chosen so that it actually discriminates:
run against the currently published Google Fonts binaries, 5 of the 6
cases fail; run against this branch, all 6 pass.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
- release: bump LINE Seed JP to version 1.016 across all weights
Google Fonts needs the version to increase before it can ship the
halt/palt fix: the published binaries are byte-for-byte the same
versions as our sources were (Thin 1.008, Regular 1.003, Bold 1.010,
ExtraBold 1.015), and fontspector's googlefonts/version_bump failed
with same-version.
The four weights were also versioned independently, which
opentype/family/equal_font_versions reported as a mismatch. Unify them
on 1.016 instead of bumping each one separately: it is higher than every
published weight, so the update is unambiguous, and the family now
carries a single version going forward.
Both checks now pass on all four weights.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
- refactor: drop the emptied halt/palt/vhal/vpal feature records
Following review feedback on #12: the previous commit cleared the
erroneous GSUB substitutions from halt, palt, vhal and vpal but
kept the feature records in the Glyphs sources with empty code.
Those empty records are a no-op in the build. glyphsLib emits them into
the UFO as empty blocks (feature halt { } halt;), and feaLib discards a
feature block that contains no lookups without a warning, so the tags
never appear in the compiled GSUB or GPOS. Generating the .fea with and
without the records confirms the only difference is the four empty
blocks, leaving the binary identical.
Keeping them was therefore purely a source-maintenance choice, and they
are not placeholders for a future GPOS implementation. An empty record
cannot express "deliberately unimplemented" — it is indistinguishable
from leftovers — while the built fonts already express an unimplemented
feature the usual way, by omitting the record. Removing them also costs
nothing later: implementing real width adjustment means authoring the
pos statements, not recreating the feature slot.
None of the four carry the Glyphs automatic flag (only aalt does in
these sources), so Glyphs.app will not regenerate them on reopen.
No change to the built fonts: halt/palt/vhal/vpal were already
absent from the binaries before this commit.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
- fix: remove erroneous GSUB substitutions from vkrn
vkrn (Vertical Kerning) is a GPOS-only feature, but in all four Glyphs
sources it carried 115 GSUB sub rules — an exact duplicate of the
dlig ligature rules. This is the same defect as the one fixed for
halt/palt/vhal/vpal: substitution code copied into a feature slot
that is supposed to hold metric adjustments.
Unlike halt/palt, vkrn is not applied by default, so the impact was
limited to explicit activation. But requesting vkrn for vertical
kerning — via font-feature-settings or a design tool — silently applied
the squared-form ligatures instead:
hb-shape --features=vkrn "株式会社" -> uni337F (㍿)
hb-shape --features=vkrn "TEL" -> T_E_L (㏻)
The rules already exist under their correct dlig tag, so dropping the
vkrn record loses no functionality: dlig still produces uni337F and
T_E_L. Following the policy established in the previous commit, the
record is removed rather than emptied.
Also adds qa/shaping_tests/vkrn.json, covering both failure modes plus
two dlig positive controls, so that a future change which simply
deletes the ligature data cannot pass the suite.
Verification (googlefonts profile, 678 checks across the family, same
fontspector build and configuration on both sides):
before PASS 319 SKIP 239 INFO 19 WARN 79 FAIL 18 ERROR 4
after PASS 323 SKIP 239 INFO 19 WARN 79 FAIL 14 ERROR 4
Exactly four results change — shaping/regression FAIL -> PASS on each
weight — and nothing else moves in either direction. GSUB goes from 19
features to 18; GPOS still contains kern. trad, vert/vrt2 and
dlig are unaffected. The version stays at 1.016, which has not shipped.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
- docs: correct the glyph annotation in the vkrn shaping test
Following review feedback: the note for the vkrn/TEL case labelled the
substituted glyph as ㏻, which is wrong twice over.
U+33FB ㏻ is IDEOGRAPHIC TELEGRAPH SYMBOL FOR DAY TWENTY-EIGHT, an
unrelated telegraph sign that this font does not even contain — it shapes
to .notdef. And T_E_L has no cmap entry at all, so annotating it with
any character is misleading. It is also a distinct design from ℡
U+2121, which is present as uni2121 and which the font produces from
lowercase "Tel":
hb-shape --features=dlig "TEL" -> T_E_L (unencoded)
hb-shape --features=dlig "Tel" -> uni2121 (℡ U+2121)
The note now refers to "the T_E_L ligature glyph" and records that it is
unencoded. "Latin squared forms" is corrected to "Latin ligature forms"
in both TEL cases as well, since T_E_L is a plain ligature rather than
a CJK compatibility squared form.
The ㍿ (uni337F) annotation on the 株式会社 cases is accurate and is
left as is.
Note that the same ㏻ mistake appears in the body of commit e98286e
and in an earlier PR comment. History is deliberately not rewritten to
correct it; this commit is the correction of record.
Test data only — no expectations, inputs or features change, and
shaping/regression still passes on all four weights.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Co-authored-by: Claude Opus 4.8 noreply@anthropic.com