Open NightFurySL2001 opened 2 years ago
RosaWagner
commented
2 years ago Thanks for your submission. It looks promissing :) Would you consider exporting TTF files? These is a page that can help you further to match GF expectations: https://googlefonts.github.io/gf-docs/Spec/
NightFurySL2001
commented
2 years ago Thank you. I am not considering to export TTF files since AFDKO makeotf directly generates the CFF table for OTFs, but if required I can add a conversion step using AFDKO otf2ttf.
I have read the GF Specs and I believe the font has fit most of the requirements, the few problems so far I see includes:
fontmake (but I believe that should not be a problem)build.sh is not available (but build_mergeFont.bat should do the same)OS/2.sTypoLineGap is not 0hhea.ascender and hhea.descender is not the same as the example value (but I think it is a good value for now) OS/2.fsSelection bit 7 (USE_TYPO_METRICS) is turned onRosaWagner
commented
2 years ago but if required I can add a conversion step using AFDKO otf2ttf.
Yes, TTF files are required :)
OS/2.fsSelection bit 7 (USE_TYPO_METRICS) is turned on
That is the correct way.
OS/2.sTypoLineGap is not 0 hhea.ascender and hhea.descender is not the same as the example value (but I think it is a good value for now)
Did you look into the guideline for CJK font? https://googlefonts.github.io/gf-docs/Spec/#cjk-vertical-metrics. In any case, since it's an expansion of ZCOOL, it should follow the same vertical-metrics. Exception can be made though if necessary.
build.sh is not available (but build_mergeFont.bat should do the same)
The important thing is that the font can be built in one click, and that should be well documented into the README.md.
it is built using AFDKO not fontmake (but I believe that should not be a problem)
Would be quite better to generate the ttf from source, but I know that building CJK fonts is quite a run so… you could eventually use some of the gftools scripts to fix some stuff if necessary to match our spec. Also we publish CJK fonts without hinting otherwise the file size is too big.
For what I see, font name, file name and copyright string don't match yet. It should be structured the same as ZCOOL with some added names, also family name can't be hyphenated. No problem with the localized names, but shouldn't contains special characters. I see other stuff, but not important for now.
In any case, we'll look into it and come back to you.
This is a fontbakery report (ignore the glyph coverage fail, we had an issue in the version of the tool).
Fontbakery version: 0.8.6
--- Rationale --- A font's filename must be composed in the following manner: <familyname>-<stylename>.ttf - Nunito-Regular.ttf, - Oswald-BoldItalic.ttf Variable fonts must list the axis tags in alphabetical order in square brackets and separated by commas: - Roboto[wdth,wght].ttf - Familyname-Italic[wght].ttf* 🔥 **FAIL** Style name used in "WD-XLLubrifontTC-Regular.otf" is not canonical. You should rebuild the font using any of the following style names: "Thin", "ExtraLight", "Light", "Regular", "Medium", "SemiBold", "Bold", "ExtraBold", "Black", "Thin Italic", "ExtraLight Italic", "Light Italic", "Italic", "Medium Italic", "SemiBold Italic", "Bold Italic", "ExtraBold Italic", "Black Italic". [code: bad-static-filename]
--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.* 🔥 **FAIL** Missing required codepoints: - 0x02BB (MODIFIER LETTER TURNED COMMA) - 0x02BC (MODIFIER LETTER APOSTROPHE) - 0x200B (ZERO WIDTH SPACE) - And 0xFEFF (ZERO WIDTH NO-BREAK SPACE) [code: missing-codepoints]
--- Rationale --- The OpenType spec requires ASCII for the POSTSCRIPT_NAME (nameID 6). For COPYRIGHT_NOTICE (nameID 0) ASCII is required because that string should be the same in CFF fonts which also have this requirement in the OpenType spec. Note: A common place where we find non-ASCII strings is on name table entries with NameID > 18, which are expressly for localising the ASCII-only IDs into Hindi / Arabic / etc.* 🔥 **FAIL** Bad string at [nameID 0, 'utf_16_be']: 'b'【WD-XL 滑油字】版權 2020-2022 © 夜煞之樂2001 ——中文（繁／正體）擴展及符號設計，ZERO子 ——日文擴展及符號設計，在 SIL 開源字型授權下修改字型。\n【站酷慶科黃油體】版權 2018-2022 © 站酷慶科黃油體計劃作者 (https://www.github.com/googlefonts/zcool-qingke-huangyou)——原字體來源。\n\nWD-XL 滑油字以 SIL 開源字型授權（SIL OFL）1.1 版授權。該授權全文及常見問題解答（FAQ）可在 http://scripts.sil.org/OFL 查閲。'' [code: bad-string] * 🔥 **FAIL** Bad string at [nameID 0, 'utf_16_be']: 'b'[WD-XL Lubrifont] Copyright 2020-2022 © NightFurySL2001 - Expansion for Chinese (Traditional) and symbols, Skr-ZERO - Expansion for Japanese and symbols, modified under SIL Open Font License.\n[ZCOOL QingKe HuangYou] Copyright 2018-2022 © The ZCOOL QingKe HuangYou Project Authors (https://www.github.com/googlefonts/zcool-qingke-huangyou) - Source of original font.\n\nWD-XL Lubrifont is licensed under the SIL Open Font License, Version 1.1. The license is available with a FAQ at: http://scripts.sil.org/OFL'' [code: bad-string] * 🔥 **FAIL** Bad string at [nameID 0, 'utf_16_be']: 'b'【WD-XL 滑油字（かつゆじ）】版権 2020-2022 © NightFurySL2001——漢字（中国語繁体字）の拡張および記号のデザイン、ZERO子——日本語の拡張および記号のデザイン。SILオープンソースフォントライセンス1.1の下でフォントを変更します。\n【ZCOOL QingKe HuangYou】版権 2018-2022 © フォントプロジェクト「ZCOOL QingKe HuangYou」の作成者 (https://www.github.com/googlefonts/zcool-qingke-huangyou)——元フォントのソース。\n\n「WD-XL 滑油字（かつゆじ）」は、SILオープンフォントライセンス1.1にて公開しています。このライセンス全文およびFAQは、http://scripts.sil.org/OFLでご覧ください。'' [code: bad-string] * 🔥 **FAIL** Bad string at [nameID 0, 'utf_16_be']: 'b'【WD-XL 滑油字】版权 2020-2022 © 夜煞之乐2001 ——中文（繁体）扩展及符号设计，ZERO子 ——日文扩展及符号设计，在 SIL 开源字型授权下修改字体。\n【站酷庆科黄油体】版权 2018-2022 © 站酷庆科黄油体计划作者 (https://www.github.com/googlefonts/zcool-qingke-huangyou)——原字体来源。\n\nWD-XL 滑油字以 SIL 开源字型授权（SIL OFL）1.1 版授权。该授权全文及常见问题解答（FAQ）可在 http://scripts.sil.org/OFL 查阅。'' [code: bad-string] * 🔥 **FAIL** There are 4 strings containing non-ASCII characters in the ASCII-only NAME table entries. [code: non-ascii-strings]
--- Rationale --- This is an arbitrary max length for the copyright notice field of the name table. We simply don't want such notices to be too long. Typically such notices are actually much shorter than this with a length of roughly 70 or 80 characters.* 🔥 **FAIL** The length of the following copyright notice (507) exceeds 500 chars: "[WD-XL Lubrifont] Copyright 2020-2022 © NightFurySL2001 - Expansion for Chinese (Traditional) and symbols, Skr-ZERO - Expansion for Japanese and symbols, modified under SIL Open Font License. [ZCOOL QingKe HuangYou] Copyright 2018-2022 © The ZCOOL QingKe HuangYou Project Authors (https://www.github.com/googlefonts/zcool-qingke-huangyou) - Source of original font. WD-XL Lubrifont is licensed under the SIL Open Font License, Version 1.1. The license is available with a FAQ at: http://scripts.sil.org/OFL" [code: too-long]
--- Rationale --- There are some entries on the name table that may include more than one line of text. The Google Fonts team, though, prefers to keep the name table entries short and simple without line breaks. For instance, some designers like to include the full text of a font license in the "copyright notice" entry, but for the GFonts collection this entry should only mention year, author and other basic info in a manner enforced by com.google.fonts/check/font_copyright* 🔥 **FAIL** Name entry COPYRIGHT_NOTICE on platform WINDOWS contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry COPYRIGHT_NOTICE on platform WINDOWS contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry COPYRIGHT_NOTICE on platform WINDOWS contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry COPYRIGHT_NOTICE on platform WINDOWS contains a line-break. [code: line-break]
--- Rationale --- CJK fonts have different vertical metrics when compared to Latin fonts. We follow the schema developed by dr Ken Lunde for Source Han Sans and the Noto CJK fonts. Our documentation includes further information: https://github.com/googlefonts/gf-docs/tree/main/Spec#cjk-vertical-metrics* 🔥 **FAIL** OS/2.sTypoLineGap is "150" it should be 0 [code: bad-OS/2.sTypoLineGap]
--- Rationale --- A known license URL must be provided in the NameID 14 (LICENSE INFO URL) entry of the name table. The source of truth for this check is the licensing text found on the NameID 13 entry (LICENSE DESCRIPTION). The string snippets used for detecting licensing terms are: - "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL" - "Licensed under the Apache License, Version 2.0" - "Licensed under the Ubuntu Font Licence 1.0." Currently accepted licenses are Apache or Open Font License. For a small set of legacy families the Ubuntu Font License may be acceptable as well. When in doubt, please choose OFL for new font projects.* ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=14] [code: http-in-license-info] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=14] [code: http-in-license-info] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=14] [code: http-in-license-info] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=14] [code: http-in-license-info] * ⚠ **WARN** For now we're still accepting http URLs, but you should consider using https instead. [code: http]
--- Rationale --- Serving extremely large font files on Google Fonts causes usability issues. This check ensures that file sizes are reasonable.* ⚠ **WARN** Font file is 5.2Mb; ideally it should be less than 1.0Mb [code: large-font]
--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering. If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.* ⚠ **WARN** This font lacks caret position values for ligature glyphs on its GDEF table. [code: lacks-caret-pos]
--- Rationale --- The OpenType 'meta' table originated at Apple. Microsoft added it to OT with just two DataMap records: - dlng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font is designed for - slng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font supports The slng structure is intended to describe which languages and scripts the font overall supports. For example, a Traditional Chinese font that also contains Latin characters, can indicate Hant,Latn, showing that it supports Hant, the Traditional Chinese variant of the Hani script, and it also supports the Latn script The dlng structure is far more interesting. A font may contain various glyphs, but only a particular subset of the glyphs may be truly "leading" in the design, while other glyphs may have been included for technical reasons. Such a Traditional Chinese font could only list Hant there, showing that it’s designed for Traditional Chinese, but the font would omit Latn, because the developers don’t think the font is really recommended for purely Latin-script use. The tags used in the structures can comprise just script, or also language and script. For example, if a font has Bulgarian Cyrillic alternates in the locl feature for the cyrl BGR OT languagesystem, it could also indicate in dlng explicitly that it supports bul-Cyrl. (Note that the scripts and languages in meta use the ISO language and script codes, not the OpenType ones). This check ensures that the font has the meta table containing the slng and dlng structures. All families in the Google Fonts collection should contain the 'meta' table. Windows 10 already uses it when deciding on which fonts to fall back to. The Google Fonts API and also other environments could use the data for smarter filtering. Most importantly, those entries should be added to the Noto fonts. In the font making process, some environments store this data in external files already. But the meta table provides a convenient way to store this inside the font file, so some tools may add the data, and unrelated tools may read this data. This makes the solution much more portable and universal.* ⚠ **WARN** This font file does not have a 'meta' table. [code: lacks-meta-table]
--- Rationale --- Glyphs are either accessible directly through Unicode codepoints or through substitution rules. Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.* ⚠ **WARN** The following glyphs could not be reached by codepoint or substitution rules: - cid15883 - cid15984 - And cid00933 [code: unreachable-glyphs]
--- Rationale --- The W3C recommends the addition of chws and vchw features to CJK fonts to enhance the spacing of glyphs in environments which do not fully support JLREQ layout rules. The chws_tool utility (https://github.com/googlefonts/chws_tool) can be used to add these features automatically.* ⚠ **WARN** chws feature not found in font. Use chws_tool (https://github.com/googlefonts/chws_tool) to add it. [code: missing-chws-feature] * ⚠ **WARN** vchw feature not found in font. Use chws_tool (https://github.com/googlefonts/chws_tool) to add it. [code: missing-vchw-feature]
--- Rationale --- Mark characters should be in the GDEF mark glyph class.* ⚠ **WARN** The following mark characters could be in the GDEF mark glyph class: cid00803 (U+3099) and cid00804 (U+309A) [code: mark-chars]
--- Rationale --- This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.* ⚠ **WARN** The following glyphs have jaggy segments: * cid00552 (U+2486): L<<601.0,260.0>--<601.0,118.0>>/L<<601.0,118.0>--<635.0,369.0>> = 7.714227394298848 * cid00552 (U+2486): L<<635.0,369.0>--<601.0,618.0>>/L<<601.0,618.0>--<601.0,421.0>> = 7.775434079160043 * cid00553 (U+2487): L<<134.0,370.0>--<168.0,140.0>>/L<<168.0,140.0>--<168.0,307.0>> = 8.408911732600691 * cid00553 (U+2487): L<<609.0,560.0>--<609.0,177.0>>/L<<609.0,177.0>--<635.0,369.0>> = 7.711892412658888 * cid00553 (U+2487): L<<635.0,369.0>--<609.0,560.0>>/L<<609.0,560.0>--<609.0,177.0>> = 7.751779154296687 * cid00770 (U+3073): B<<451.0,719.0>-<452.0,730.0>-<455.0,739.0>-<462.0,745.0>>/B<<462.0,745.0>-<461.0,744.0>-<463.0,745.0>-<467.0,748.0>> = 4.398705354995508 * cid00828 (U+30B4): B<<476.0,650.0>-<476.0,629.0>-<486.0,616.0>-<505.0,612.0>>/L<<505.0,612.0>--<90.0,612.0>> = 11.888658039627968 * cid00828 (U+30B4): B<<579.0,577.0>-<579.0,597.0>-<565.0,608.0>-<553.0,611.0>>/L<<553.0,611.0>--<656.0,611.0>> = 14.036243467926484 * cid00842 (U+30C2): B<<476.0,650.0>-<476.0,629.0>-<486.0,616.0>-<505.0,612.0>>/L<<505.0,612.0>--<490.0,612.0>> = 11.888658039627968 * cid01929 (U+5282): L<<406.0,-59.0>--<406.0,-58.0>>/B<<406.0,-58.0>-<401.0,-83.0>-<380.0,-104.0>-<361.0,-104.0>> = 11.309932474020195 and 28 more. Use -F or --full-lists to disable shortening of long lists. [code: found-jaggy-segments]
--- Rationale --- This check detects line segments which are nearly, but not quite, exactly horizontal or vertical. Sometimes such lines are created by design, but often they are indicative of a design error. This check is disabled for italic styles, which often contain nearly-upright lines.* ⚠ **WARN** The following glyphs have semi-vertical/semi-horizontal lines: * cid09828 (U+8026): L<<716.0,219.0>--<715.0,-69.0>> * cid12947 (U+919C): L<<529.0,5.0>--<528.0,178.0>> and cid14691 (U+9B42): L<<203.0,23.0>--<204.0,237.0>> [code: found-semi-vertical]
| 💔 ERROR | 🔥 FAIL | ⚠ WARN | 💤 SKIP | ℹ INFO | 🍞 PASS | 🔎 DEBUG |
|---|---|---|---|---|---|---|
| 0 | 8 | 11 | 137 | 6 | 60 | 0 |
| 0% | 4% | 5% | 62% | 3% | 27% | 0% |
Note: The following loglevels were omitted in this report:
NightFurySL2001
commented
2 years ago Yes, TTF files are required :)
I will try to generate it with otf2ttf since the font files generated by AFDKO in CFF format is way smaller in comparison. (Raw generated font is 8MB per region, merging all 4 regions into a font with mergeFonts only produce a 6MB TTC final font).
That is the correct way.
Did you look into the guideline for CJK font? https://googlefonts.github.io/gf-docs/Spec/#cjk-vertical-metrics. In any case, since it's an expansion of ZCOOL, it should follow the same vertical-metrics. Exception can be made though if necessary.
The specs sheet said to not set OS/2.fsSelection bit 7 (USE_TYPO_METRICS), and 0 line gap. Also, the font check failed for this too.
🔥 FAIL: Check font follows the Google Fonts CJK vertical metric schema
🔥 FAIL OS/2.sTypoLineGap is "150" it should be 0 [code: bad-OS/2.sTypoLineGap]
(P/S: Dr. should be capitalized)
The important thing is that the font can be built in one click, and that should be well documented into the README.md.
That is written so I believe it is not a problem.
For family name, the name "WD-XL" was a RFN but removed in v2.001, but I would be glad if it is possible to still keep the hyphen it (at least in name ID 1) since the name was used from the first release of the font.
Substitute copyright, registered and trademark symbols in name table entries.
This is actually against the suggestion by Dr. Ken Lunde, who made the Source Han/Noto CJK series, mentioning that (c) does not have any legal status and the copyright symbol should be used in place.
For name ID = 0 (Copyright) I will try my best to modify to the required format, but the OFL license will remain as-is.
name ID = 0 update:
Copyright 2020-2022 \00A9 The WD-XL Lubrifont Project Authors (https://github.com/NightFurySL2001/WD-XL-font); Copyright 2018-2022 \00A9 The ZCOOL QingKe HuangYou Project Authors (https://www.github.com/googlefonts/zcool-qingke-huangyou).\000A\000AWD-XL Lubrifont is licensed under the SIL Open Font License, Version 1.1. The license is available with a FAQ at: http://scripts.sil.org/OFLYes, sorry I got confused with v-metric spec for non-CJK fonts :) you are right for the use_typo_metric flag. We usually prefer typoLineGap = 0 to ensure same line spacing between web and desktop environment. Exceptions can be made for vertical metrics, that will have to be discussed with the person who grants exceptions (@davelab6).
For family name, the name "WD-XL" was a RFN but removed in v2.001, but I would be glad if it is possible to still keep the hyphen it (at least in name ID 1) since the name was used from the first release of the font.
The problem is linked to our toolchain, I don't know if we can make an exception, but I'll ask.
This is actually against the suggestion by Dr. Ken Lunde, who made the Source Han/Noto CJK series, mentioning that (c) does not have any legal status and the copyright symbol should be used in place.
We usually don't use (c) or © at all, I am definitely not the right person to answer that, but I would bet the "Copyright" as a full word is enough (that's how it is done for all the other GF fonts).
(P/S: Dr. should be capitalized)
Thanks, I'll take this into consideration for the next update :)
About how the license should look like, honestly I don't feel I can give any advises. Dave will look into it when he returns to work, and will come back to you.
NightFurySL2001
commented
2 years ago No problem, I will wait for Dave for further suggestion and modification. use_typo_metric and typoLineGap = 0 have been changed in my build tools, and I will wait for further suggestion for the name table.
Out of 8 fails, 6 have been related to name entries:
🔥 FAIL: Checking file is named canonically.
🔥 FAIL: Substitute copyright, registered and trademark symbols in name table entries.
🔥 FAIL: Are there non-ASCII characters in ASCII-only NAME table entries?
🔥 FAIL: Copyright notices match canonical pattern in fonts
🔥 FAIL: Length of copyright notice must not exceed 500 characters.
🔥 FAIL: Name table entries should not contain line-breaks.One remaining fail have been fixed, the GF Core is ignored.
davelab6
commented
2 years ago @NightFurySL2001 thanks for submitting this :) It will take us some time to work through this, but I am keen to add this to the GF library - as you surely know, we need to add many TC fonts :)
NightFurySL2001
commented
2 years ago No problem, thank you for accepting the submission too. I would like to ask for some suggestions to the name table for my font as most issues from FontBakery is related to the copyright string format and font name (ref above discussion, the metrics issue is fixed on my local dev branch)
Also, can you add the CJK tag the same as the Nanum font issue?
From: Dave Crossland @.> Sent: Friday, February 18, 2022 1:14:07 AM To: google/fonts @.> Cc: NFSL2001 @.>; Mention @.> Subject: Re: [google/fonts] Add WD-XL Lubrifont SC/TC (Issue #4264)
@NightFurySL2001https://github.com/NightFurySL2001 thanks for submitting this :) It will take us some time to work through this, but I am keen to add this to the GF library - as you surely know, we need to add many TC fonts :)
— Reply to this email directly, view it on GitHubhttps://github.com/google/fonts/issues/4264#issuecomment-1043203450, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AH7LUSL6UCKE66Q7HS2ZQZDU3UUF7ANCNFSM5NJPCFYA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>
NightFurySL2001
commented
2 years ago Any ETA for review soon?
davelab6
commented
2 years ago It currently is expected to be in July/August/September.
We also have to consider the name, something that's not related to a brand that isn't associated with the project would be better.
davelab6
commented
2 years ago @NightFurySL2001 please could you provide some candidate alternate names? I am concerned this name is too close to the oil can company trademarks :)
NightFurySL2001
commented
2 years ago @davelab6 Will ZH-XL Lubrifont, WID Lubrifont or XLubrifont works? Although I would argue the name is quite far away that it is not noticeable if I did not mentioned how the name comes up.
NightFurySL2001
commented
1 year ago Is there any suggestion to change or modify the font names as yet? I would hope for a smooth upload in Q2 hopefully without major changes to the font when the time comes.
RosaWagner
commented
1 year ago Hi @NightFurySL2001, we didn't have the time to take a look at the name, but we assigned someone that has expertise in Google Fonts requirements and CJK to be able to give you feedback on the onboarding process. We'll look at the name at that moment I think.
NightFurySL2001
commented
6 months ago 👀 be wondering did the font went into the freezer and back 🥶 any updates on the onboarding? We do are severely lacking TC (Traditional Chinese) fonts.
aaronbell
commented
5 months ago @davelab6 Did you have a chance to consider alternate names for this project? (see https://github.com/google/fonts/issues/4264#issuecomment-1157777156)
NightFurySL2001
commented
2 months ago I think the font name is fine as-is without modification.
Font Project Git Repo URL:
https://github.com/NightFurySL2001/WD-XL-font
Note: Please only add Simplified Chinese (SC) and Traditional Chinese (TC) version only; Japanese (JPS/JPN) version is a recent contribution and requires further testing.
Super short description of the Font Family:
WD-XL Lubrifont is a Chinese display font that emphasize on a compat yet welcoming experience, expanded for daily Chinese typography with professional typesetting in mind. Transcription system support includes Hanyu Pinyin, Taiwan Minnanyu Luomazi Pinyin Fang'an (or Tâi-lô), Pe̍h-ōe-jī and bopomofo (or zhuyin). This font is an update and expansion to ZCOOL Qingke Huangyou.
Requirements:
I understand that Google Fonts will publish only fonts that matches its requirements, and I can confirm the project meets them (by ticking the cases, or putting x between the square brackets in text mode):