Inquiries

[aaronbell]

Hi there!

I am going to be prepping Chiron Hei HK and Chiron Sung HK for onboarding to GF, and had a few questions I wanted to ask.

1. I note that these repositories have been set up with the intention of being for GF use. Can you explain the differences between the sources here and the ones in the main / official repositories? How do you update the sources here?

2. I wanted to confirm that the .ufo is the primary editing source for this font. GF requires that the "true source" where any font development takes place is uploaded to the repository, so I wanted to double-check if there was a local source in a different format (say, such as .fcp or .vfb) and, if so, request that you upload it to the repro as well. Thus, as support for other formats in fontmake improves, the binaries can be built directly from the source rather than using an interchange format such as .ufo.

3. I note this repository has a build system, but Chiron Sung does not. Do you have any preference for how the build system is set up in these repositories? Or is it OK if I set it up per Google Font's recommendation? I want to make sure it is easy for you to manage.

[tamcy]

Thank you for your question! Before the answers I'd like to elaborate a bit more on the background.

As you may know, Chiron Hei HK is derived from Google’s Noto Sans CJK and Adobe’s Source Han Sans. It is different from the upstream with the following differences:

• It serves glyphs for a single region (the Traditional Chinese community), so it’s not a Pan-CJK font.
• It contains modified and new glyphs to match the font’s vision.
• It integrates the full glyph set of the Source Sans 3 family for LGC.

As for how Chiron Hei HK is developed, it is quite different from just opening the source using a font editor, edit and save. It is a custom workflow developed for this particular font family, and what’s said here also applies to Chiron Sung HK.

During the development phase, the followings are done:

• Initialization: Import the latest glyph set of Source Han Sans and its metadata to a MySQL database. They are first converted from .ps to .glifs using AFDKO. This is done once per upstream version.
• Review: For CJK characters and symbols, Source Han Sans/Noto CJK offers one to five regional variants. Desired glyphs are mapped from these variants. If no variant matches, a new pseudo region is created, glyphs are modified and mapped to the codepoint.

This process is done using scripts and the mapping tool I wrote for this project.

In the above image, the selected glyph of the selected region will be exported when building. The “XC” in the second row is the pseudo region.

There is no direct modification to the Source Han Sans glyph set, even in the database. The database contains glyph data of the pseudo region and instructions on “which region is preferred for a codepoint”. This allows me to “rebase” my work to synchronize with the latest version of upstream.

During the building phase, the build scripts will do the followings:

• Export and merge modified glyphs from the database into the original .ps files using AFDKO tools.
• Generate a new CMap file according to the mapping data in the database. Unneeded glyphs will be removed.
• Integrate Source Sans 3 glyphs and feature files.
• Build the binaries via AFDKO. In reality, different source .ps files are built for variable and static fonts to work around glitches found in some applications.

So the ultimate store of the glyphs is in the MySQL database, but still excluding the Source Sans 3 LGC glyphs. Other files, like cmaps and feature files required to build the final VF OTF, are produced at the building phase.

The development of the workflow can be dated back to 2015. The thoughts were to (a) reuse the building process of the Source Han Sans font as much as possible, (b) keep up to date with the upstream at best effort, (c) simplify the glyph selection process. I understand this may not be the best way nowadays. I had been thinking about reworking it, but unfortunately, things got changed a lot and I am no longer able to be as devoted to this project in recent years, so there hasn't been much progress. I also have to confess that as the font becomes increasingly mature, there’s really no big incentive to rebuild the whole building process from scratch, especially when it still may not comply with the Google Fonts standard if I work on it myself.

That said, I believe the font is a valuable addition to the Google Fonts repository. So I’d appreciate knowing your thoughts on this. I had a thought of giving the GF version another name so that it’s seen as a fork of the Chiron font, and find a maintainer for it. I can continue to offer the GF-compatible source in a branch of the main repo when a new version is released to ease the maintainer’s work in integrating the latest changes. In this case the .ufo can be seen as the ultimate source, and there won’t be any problem if the font needs to be diverged (hopefully) a little bit from the Chiron family. But I’m not sure it is an acceptable move.

Given the above, I think it will bring more clarity to my answer to your questions:

Q1: Can you explain the differences between the sources here and the ones in the main / official repositories? How do you update the sources here?

A1: Currently, only binaries are available in the official repository. As for the font itself, the difference is that the main repo offers an additional “PADG” axis in VF (which corresponds to the “Text” subfamily in the static configurations). This custom axis isn’t registered in Google Font and is thus removed. The source in this repo is also a result of the “build” phase in the custom pipeline.

Q2. I wanted to confirm that the .ufo is the primary editing source for this font. GF requires that the "true source" where any font development takes place is uploaded to the repository, so I wanted to double-check if there was a local source in a different format (say, such as .fcp or .vfb) and, if so, request that you upload it to the repro as well. Thus, as support for other formats in fontmake improves, the binaries can be built directly from the source rather than using an interchange format such as .ufo.

A2. “.ufo is the primary editing source for this font” is currently not the case. I am happy to work on a format GF is happy with, but my concern is that given the current font development process they may still be considered “intermediate source” by GF.

Q3. I note this repository has a build system, but Chiron Sung does not. Do you have any preference for how the build system is set up in these repositories? Or is it OK if I set it up per Google Font's recommendation? I want to make sure it is easy for you to manage.

A3. I don’t have any preference for both repositories. The build system in Chiron Hei should also work for Chiron Sung. I just want the structure of the two repos to be as close as possible.

I hope this clarifies some uncertainties. Thanks again!

[aaronbell]

Wow! That's quite a build system that you've set up. Thank you for the detailed explanation.

Essentially, it sounds like you have an AFDKO-based build system, which is totally fine per the Google requirements and the UFOs may not be required at all.

Would you be open to uploading the entirety (either single files, or packaged) of your build system to the repository? That way should someone in 20 years want / need to update the font, the system that you've used is available to do so?

As for the need for a GF-specific version of the font and repository, I think that we might be able to make it easier for you.

(1) The main blocker for merging the two repositories, as I see it, is the use of the PADG axis. But while PADG may not be an approved axis for Google Fonts, but we do have SPAC which behaves much the same way as you've described. See the axis registry.

SPAC
Spacing
Default: 0 Min: -100 Max: 100 Step: 0.1
Adjusts the overall letter spacing of a font. The range is a relative percentage change from the family’s default spacing, so the default value is 0.

If you'd be willing to change the name of the axis and the positions of Small / Text / Larger to follow the above requirements, then I think it would be much easier to make any further changes necessary.

(2) In running fontbakery, I found several issues that I think may be worth solving in your main repository (not just for GF):

• OS/2.fsSelection is not assigned. It should be set to "Regular" at least.
• The default value for the variable font is set to "250" which, while not actually invalid per the spec, does not follow where "ExtraLight" is located normally at 200 (https://learn.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass). In looking at your documentation, that appears to be the position on the weight axis for that master which is totally fine, but it should be translated to the standard locations (usually via an avar table).
• The hhea values must align with the OS/2 values to ensure consistency across platform. I've also suggested an alternate way of setting the vertical metrics (C/J vertical metrics requirements google/fonts#8911) which I'd be interested to try on your project, if you're willing.
• I note in the name table there's some recommended fields missing—in particular name ID 16 and 25
• There is no GASP table, which helps Windows render the font better.
• Some glyphs appear to have overlapping contours. uni2600 is one such glyph.

(3) Finally, there's a set of changes I'd suggest, but these are things that potentially we can implement as a post-production step after the production of the main binaries:

• GF will expect the file name to be standardized with the axis names in the filename–> "ChironHeiHK[SPAC,wght].ttf"
• GF also requires particular approaches to the Copyright notice, which would need to be updated in the name table.
• FontBakery reports some 1500+ glyphs which are "unreachable". These are glyphs which have a set location in the GID order, but as TTF doesn't care about all that, they cannot be accessed either via unicode slot or OT feature. It might be best to strip them out to reduce file size.

I should also note that it could be that as the above get resolved, other issues also crop up that would need resolution.

So the question for you is, are you open to making the above changes to to the public release of the font per GF's requirements? Or should we implement a separate build system specifically for GF? This isn't to say that it needs to be in a separate repository, though. It could certainly be a small post-production script that runs after everything else is done to take the AFDKO-ship binary and makes the necessary changes for GF. What would you prefer?

[tamcy]

Thanks again for the comment. I'd like to address them in three categories.

A. About the SPAC axis

I am aware of the SPAC axis but I think it doesn’t quite match what the custom PADG axis is doing now.

In a Chinese typeface, unless for calligraphic type, the default spacing between two CJK characters are realized by defining the “字面率” (lit. letter/character face ratio). An example as in https://typeproject.com/blog/23862:

Left: 92% letter face ratio; right: 95%. More spacing can be observed in the sample text “字面国際議事堂前” on the left

In this font, increasing the PADG axis value will shrink the CJK glyphs by a little bit (i.e. it will reduce the character’s letter face ratio) to provide more spacing between characters. The em-box and horizontal advance (represented by the outer border) of the CJK glyphs remain unchanged.

As the CJK characters look smaller, the LGC characters should look smaller (but not necessary). While the horizontal advance will decrease, this doesn’t increase the spacing between LGC characters visually.

To summarize, incrementing the PADG axis will increase the spacing between CJK characters perceptually. While the size of the LGC characters may decreases, its spacing barely changes.

B. On uploading the current build system

The project started as an experimental one and is using a frontend and backend architecture. The backend is primarily written in PHP with a MySQL backend, but it grew more complicated eventually and now depends on code written in other languages (stored in other places), and things unrelated to the font project. The building pipeline is only a part of it. So the current state of the build system is not ready for open sourcing.

I had been thinking of splitting the building pipeline from the application, so that the application will be an authoring tool which exports the sources needed to build the binaries. It would be something similar to the Source Han Sans repo, by which glyphs are in a single .ps file. This has been put on hold because (1) I didn’t have the time to do it, (2) I’m not sure it will be acceptable by Google Fonts, if not it would be a waste of effort.

C. On resolving the fontbakery issues and other suggested changes

I am open to changes, just that I prefer to implement changes that can lead to BC-break together to reduce the need of a major version bump (especially if merging the GF and main repo is the way to go). Non BC breaking changes like updating copyright notices and adding the GASP table are fine to me.

• On changing the ExtraLight weight to 200: I agree with the change; in fact this is what I did in the new font Chiron Go Round TC.
• About the glyph issue in uni2600: this is a known issue. I had identified tens of glyphs having similar issues and reported it to the upstream repo. The plan is to leave non-urgent fixes to the upstream, and incorporate fixes from it when ready.

[aaronbell]

@tamcy Thank you for the additional information!

PADG

Makes sense. It sounds a bit like the intention of it is to act as an optical size axis wherein the character face becomes a bit smaller to enable clearer rendering at smaller sizes. Is that accurate? If so, perhaps the opsz tag could be used instead. Alternatively, we could propose a new axis registry tag (if PADG is a universal naming convention), since it sounds like this is functionality that may be present in other CJK fonts.

Build system

Google fonts only really cares about having a mechanism to take the sources, whatever they may be, and outputting binaries via a singular, automated process. So if you have .ps files, or .ufo that are output by your application, then I think they would be fine to be used as a source for the TTF build system. Ideally, it would be good to also have the application in some sort of zip file in case someone other than you ever needs to update the font—maybe in time?

Updates

Great! That makes sense. Assuming we can get the axis naming sorted, which of the items I reported would you be open to implementing in your primary public release? I think most of the GF-specific items I could implement as a post-production script (which I'd PR to your repro to create them as part of the normal build system).

[aaronbell]

@tamcy Following up and seeing if you had any thoughts :)

[tamcy]

@aaronbell
Isn’t been able to spend much time on this lately, so my reply may be delayed. Sorry for that, and thank you for your patience!

PADG

Yes, the character face ratio shares certain similarities with opsz, but it is more dedicated to CJK (or full-width, non box-drawing) characters with different expected behaviors (e.g. no thicker terminals in serif). Also, I think they should be able adjusted separately. I agree with adding a new axis to the registry.

"PADG" is not a very descriptive name. I chose the name because I preferred a configuration that (1) the axis starts with a value of 0, and (2) the full-width character face shrinks as the axis value increases. A name abbreviated from the term "letter/character face ratio" (such as CCFR or CFRO) would be more preferable. Adopting "PADG" would certainly ease the onboarding of this font (and its serif counterpart), but I believe it is better to aim for a name that is more beneficial to the font community. Therefore, I suggest inviting experts from CJK font foundries to provide more insights on this matter, including the necessity of the axis, its naming, and a more accurate description.

Of course I don’t mind a PADG axis being added ;)

Google fonts only really cares about having a mechanism to take the sources, whatever they may be, and outputting binaries via a singular, automated process. So if you have .ps files, or .ufo that are output by your application, then I think they would be fine to be used as a source for the TTF build system.
Glad to hear that! The source files I use to build the font binaries in the primary repository are available on the source branch. It contains all the necessary files to build the TTFs, OTFs, and WOFFs found in the release branch.
It would be ideal if the Google Fonts version could be built from these sources, and new font binaries in the release branch to also be built from the same sources, albeit locally. Please review the sources and confirm if they are fine to use.
Assuming we can get the axis naming sorted, which of the items I reported would you be open to implementing in your primary public release?

I’ll try to summarize the items here:

1. Set OS/2.fsSelection to "Regular" at least.
2. Missing name ID 16 and 25.

I'd suggest these be done on the post processing script in GF deployment. In particular, the absence of name ID 16 is probably due to the convention that “if the NameID=16 string is identical to the NameID=1 string, it is omitted” (p.4 of the document). I am not sure if I can override this.

3. Missing GASP table

I am not very sure about this one too. The source is in the OpenType CFF/CFF2 font format, so there is no GASP table by default. I believe you will need to add it to your pipeline anyway.

4. Others as in this changeset, which includes fixing some LGC glyphs and adding the BASE table.

I will try integrating these changes.

5. [BC] Set the weight of ExtraLight to 200.
6. [BC] Implements the hhea table and vtmx table.

I am fine with the changes, but I will need your guidance on how to do (6) properly. Is it acceptable to test this on the source branch (which you can use to build the GF version) without releasing it on my end first? Also, is it required to keep my release version in sync with the Google Fonts version?

Thanks again!

[aaronbell]

Hi @tamcy
No worries on the delay! I know how things can be :)

PADG

I've submitted an axis registry request here: googlefonts/axisregistry#191. Please take a look at it and see what you think. Given these things need to be more "structured", I suggested some slight modifications of the values used—basically stated that increasing PADG should reflect a % decrease in the ratio from the standard ratio. If you think it should be different, let me know! Either way, there would be a little bit of work to adjust the master position in Chiron, but shouldn't have an impact on the rendering of the ideographs at the specified instances.

I'll send it over to folks I know to weigh in, and we'll see how it goes. Good to have a stake in the ground at least!

I'd suggest these be done on the post processing script in GF deployment. In particular, the absence of name ID 16 is probably due to the convention that “if the NameID=16 string is identical to the NameID=1 string, it is omitted” (p.4 of the document). I am not sure if I can override this.

Yes, this would be easy enough to do with a post-processing script. Recommendations as whether to include it or not vary, but GF does require it so that's what I'll implement in the script.

I am not very sure about this one too. The source is in the OpenType CFF/CFF2 font format, so there is no GASP table by default. I believe you will need to add it to your pipeline anyway.

Yup, again, easy enough. Interesting that the build system doesn't automatically add even a basic one, but creating one is no problem.

changelist

Oh! Don't look at my fork 🫣. Haha. I ran into issues and decided to abandon that approach, especially given our further discussions regarding the build system.

That said, it would be good to figure out how to get a vmtx table building. I'll see what I can do to figure that out.

Is it acceptable to test this on the source branch (which you can use to build the GF version) without releasing it on my end first?

Yes. Totally! The only issue is that the source branch doesn't have the output fonts themselves. I could probably add my post-processing bits to your build_var_ttf.py file, though, and build locally, if you'd rather, and save to a "TTF_GF" folder, or something like that, so it is notably different than the standard versions.

Also, is it required to keep my release version in sync with the Google Fonts version?

Not at all. You can feel free to update your repository as much as you want, and when you want to push a new version to GF, you can submit an update request here (New Issue > Update Font)