Re: RFC on MR 1368

[Werner LEMBERG]

> 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