Fix unknown axis #4
Conversation
justvanrossum
commented
Nov 16, 2023
justvanrossum
commented
- Add MutatorSans.fontra as test font
- Parametrize testing
- Fix bug when a non-existing axis is referenced
| @@ -0,0 +1,54 @@ | |||
| glyph name;code points | |||
| A;0041,0061 | |||
There was a problem hiding this comment.
sorry if I hijiack this, I got curious about the .fontra source file which I see for the first time, and noticed this glyph-info.csv.
Two questions:
- if it's a .csv, should it not only use one separator, either
;or,? Here I see both used. Maybe that's fine but it means one has to parse things twice instead of in one go, or need to use a special parser instead of off-the-shelf csv parser - I was also reminded about [UFO4] Separating unicode from glif unified-font-object/ufo-spec#77, I thought we were leaning towards having {unicode: glyphName} map for codepoints instead of {glyphName: [unicodes]}, to better represent what cmap does and avoid potential double-mappings. I'm curious why you ended up the way you did for fonta source format.
There was a problem hiding this comment.
- The separator is
;, and I used,to separate multiple unicodes in a single cell. (I will probably addU+for each code point, though.) - I'm still a bit torn about that, however, there's also Longer term idea: add a .csv file for glyph info unified-font-object/ufo-spec#163, which this could be a starting point for. I think that's a very valuable idea, and allows us to add arbitrary columns for additional glyph information.
There was a problem hiding this comment.
Btw. here is the implementation for the .fontra format: https://github.com/googlefonts/fontra/blob/main/src/fontra/backends/fontra.py
There was a problem hiding this comment.
I see, thanks. They way I see it, unicode codepoints are not a glyph property at all, it's the other way around, so they are kind of special in this regard and maybe should be stored in their own cmap.txt or cmap.csv as a mapping from unicode to glyph name. Anyway, these are just my 2 cents.
There was a problem hiding this comment.
unicode codepoints are not a glyph property at all
I agree with you in principle, but having both a glyph-keyed table, and a code point-keyed table seems a bit contradictory (or redundant) as well.
I originally wanted to implement the "pure cmap" concept for Fontra. The first thing the client wants to know is "which glyphs exist", and "what is the cmap". For large (CJK) fonts this can be a bottle neck on page-startup, so I decided to combine two into one, which I called the "glyph map", which is essentially what glyph-info.csv is.
(I could still have a pure cmap in the format, and use the reverse for wire communication. But then I remembered the glyph spreadsheet idea, which is something that I have high hopes for.)
There was a problem hiding this comment.
Also btw. Fontra has an entry point called fontra-copy, which can be used to convert any format it can read to any format it can write (the latter only .designspace/.ufo and .fontra). For example:
fontra-copy myfont.designspace myfont.fontra
fontra-copy myfont.glyphs myfont.fontra
fontra-copy myfont.glyphs myfont.designspace
fontra-copy myfont.ttf myfont.fontraVery much limited to the subset of font data that Fontra currently understands, which isn't much besides glyph data.
