chiron-fonts/chiron-hei-hk

Building the font

Closed this issue · 3 comments

hfhchan commented

Hi tamcy, sorry to bother you with some questions about the inner working of compiling Chiron Hei HK.

I'm interested in knowing about the build steps used to generate the new Chiron Hei HK fonts. If I remember correctly, there used to be a PHP repo for selecting characters for remap and characters for redrawing (?). I'm mostly interested in which font tools can be used that support and preserve variable glyphs. Also which software can be used to draw new variable glyphs?

I tried using ttx to export the Source Han Sans VF fonts before but it did not yield me easy to parse glyph data. My plan is to make a web based font editor, open to multiple users, which supports remapping and editing the glyphs to make a Kangxi-isque version of Source Han Sans while keeping the VF glyphs. I intend to make it support importing components (strokes) from other characters. Would appreciate if you could give some suggestions!

If other venues are better for discussion, e.g. some details which you may not prefer to reveal online, I am also available on Twitter and Telegram.

tamcy commented

There seems a couple of ways of building a Source Han Sans derivative out there, mine is probably the most uncreative one, as I am just using AFDKO to do it, with FontForge as my glyph editing tool. Here I am writing the building steps in reverse order because I feel that things can be more clearly explained with this approach.

3. Building the final VF OTF

You can check my comment in the Source Han Sans repository for the neccessary steps to build the final VF OTF, and the additional comments by punchcutter for more professional information.

In this step the cff2vf tool in AFDKO will be used, As defined in the .designspace file, the command expects two source .otf files to build the final VF OTF. These two .otf files are the two extremes of the weight axis, i.e. the "ExtraLight" and the "Heavy" masters.

The two master OTFs are very similar to a static font instance. What's different are the font menu names, the CID font info, and the content of the glyphs - unlike a static font instances which overlapping contours are usually removed, the overlapping contours in the VF masters must be kept as-is for correct interpolation.

2. Building the two master OTFs

Since the master OTFs are very similar to the static OTFs, these OTFs can be built from the .ps file using the makeotf command. While the Source Han Sans repository only contains a list of commands to build to the static OTFs, the method is very much the same for VF Master OTFs.

I understand that the above isn't enough for you because you need to build your own Source Han Sans derivative because a certain amount of glyphs have to be changed. But the point here is that each .ps file represents the master of a single dimension (weight), thus it can be easily manipulated using the tx tool in AFDKO and probably other tools. The file is not VF-specific at all; you don't need a tool that specifically support VF format to edit it.

1. Modifying the source files

When working with Source Han Sans, modifying a glyph can either be just remapping the glyph of a codepoint to another region, or editing the contours of a glyph.

Given Source Han Sans is a CID-keyed font, remapping a codepoint to another region actually implies changing the CID of that codepoint to another one. This involves modifications of the cmap file.

Editing a glyph (i.e. changing the contours of a glyph in the .ps file) isn't that simple because it is not supported by AFDKO, as least not directly. But still it can be done with the following workflow:

  1. Export the glyph that needs editing from the source .ps file.
  2. Edit the glyph.
  3. Merge the modified glyph back and export it to a new .ps file.

In fact this is exactly what was illustrated in Dr. Ken Lunde's presentation which can be found here (see page 25), and also in the CJK Type Blog.

Step 1 is done via t1; step 2 is done via any font editing tool (FontLab Studio is mentioned in the website/presentation notes. I use FontForge), and step 3 is done via mergeFonts, another AFDKO tool.

The only difference is that you don't need sfntedit to replace the CFF table of the .otf file as you are going build your own .otf file with different cmap, features and cidfontinfo data.

One thing to keep in mind when modification the same glyph of the two Masters is that "font sources to derive a variable font is that corresponding glyph outlines must be point-compatible: they must have the same number of contours and the same number of points in each contour.". This will probably be taken care of if user is using a font editing application with proper VF support. Otherwise, the user is solely responsible of this.

As you see, this is not as straightforward as simply opening the font in a VF-ready font editor (Glyphs/FontLab maybe?), edit the glyphs, and click save. But this is probably what you are looking for given you are aiming to develop a "web based font editor".

Practically you'd need a couple of scripting to ease your workflow, save you from doing repetitive tasks, performing contour validation, etc. You probably also want to have the glyph data imported into the database for loading and persisting via APIs in a web based solution.

  • 👍1
NightFurySL2001 commented

@tamcy May I ask how do you generate the instance weights from the VF source files? Either UFO or binary generated fonts are OK.

tamcy commented

@NightFurySL2001
tx -t1 -U [weight] [vf_file].otf [instance_file].ps