> Werner instead wants all outlines in one file, all kerning info in a > separate file, all OT features in their own file and so on.
This is not correct. I would *love* to be able to have everything in `.mf` files if it made sense. However, it doesn't. As mentioned in the very beginning of the discussion in the MR, we have IMHO to demote Metafont's use (or rather, MetaPost) to a mere outline and metrics generator because of technical constraints of this old software. It thus becomes just one component in the stream of tools necessary to build the fonts. ``` mf2pt1 Metafont source files (.mf) ---------> FontForge (via mf2pt1) raw Type 1 fonts -------------------------> (hinted) Type 1 fonts, with outline intersections removed and outlines simplified (.pfb) ``` The next step is font merging to create OpenType fonts. ``` FontForge *.pfb ------------> *.otf ``` After this, the font should be enriched with kerning and OpenType features. ``` FontForge Kerning data (.py) ------------> add 'GPOS' OpenType table to font FontFOrge Feature data (.py) ------------> add 'GSUB' OpenType table to font ``` Note that FontForge could be replaced with other, similar tools like Adobe's Font Toolkit. > I felt bold enough to go ahead and separate it out because I think > that this is the key issue. In different words: I am in the middle > of altering a glyph, and it occurs to me this change also affects > the kerning tables, how distracting/disruptive is it for me to > locate the kerning tables and make the change? In normal font editing with Metafont, the problem doesn't exist at all. The reason is that there is no means to visualize the kerning! Instead, you have to generate the font, then processing, say, a small TeX program that generates visual representations of kerning pairs, look at them, adjust the kern value, recompute the font, recompute the representation, etc., etc. Contrary to TeX, there don't exist comfortable IDEs for editing fonts created with MetaFont. And I'm 100% sure that this won't ever happen. > I want to go back to the scenario I outlined at first as an example. > I said: "I am in the middle of altering a glyph, it occurs to me > this also affects the kerning tables". It rarely does, as far as I can say. > I think the idea that altering glyphs and instantly turning around > and revising kerning tables is just not a workflow that people want > to use. Correct, but your mileage may vary. In FontForge, for example, there is a special window to display kerning pairs and to adjust kerning values. Note that while kerning data is stored in a font, it isn't associated at all with the glyphs. They are separate. Even in the old days of Type1 fonts, kerning was separate (in the `.afm` file). > PS: One thing that I find really distracting is all these python > files everywhere, if it is true these are just tables of > hand-authored data, I would personally find it easier to wrap my > head around to have a data format for them. The native language of almost all professional font manipulation tools is Python; it is thus very natural for most font developers if the corresponding scripts use this programming language. Werner