[OpenFontLibrary] hinting workflow

[Denis Jacquerye]

On Tue, Jun 15, 2010 at 3:15 PM, Ben Laenen <benlaenen at gmail.com> wrote:
> Schrijver wrote:
>> I remember a conversation at lgm with Jan, Ben and Denis about how tricky
>> it is to deal with hinting in a collaborative workflow (and when deploying
>> to multiple platforms).
>>
>> I’m interested in hearing the experiences of the Déjà-Vu team in more
>> detail. What issues did you run into? How did you solve them? Is the way
>> Fontforge stores this hinting data satisfactory? (In that case it could be
>> implemented in UFO in the way Erik describes).
>
>
> Current FontForge format in the sfd files is just the plaintext format you see
> when you open the edit hinting dialog inside FontForge. It used to be some
> binary format (basically each instruction translated to it's number in the
> specs), but I asked to change that since these unreadable binary blobs should
> be avoided, as it's not really patch friendly.
>
> Now, hinting of one glyph isn't really collaborative work: it's not enough
> work that you need more people to work on the same glyph. So the workflow for
> hinting is just that when someone wants to hint a glyph, he just writes the
> instructions in FF and tests it himself (usually someone else will test the
> hints as well).
>
> I've also been looking forward to see a graphical hinter being written,
> something which is available in windows (forgot the name of the program). In
> such a program you'd basically click points to add hinting, instead of writing
> them down, which can be cumbersome and error-prone. So if you'd have such a
> program you could make a different syntax for hinting, which would be more
> high-level compared to the raw instructions. But would such a high-level
> language be a good idea for the main UFO format? I don't think so. Because
> this high-level language would be too limited for "prep" or "func" tables
> (hinting instructions which don't belong to a glyph, but to the font as a
> whole), or if you want to do funky things like the U+F000 glyph in DejaVu Sans
> which shows the current pixel size. Anyway, I can't really tell, I've never
> really thought about the graphical hinter thoroughly. Might be a good
> opportunity now to do that once...
>
> Greetings
> Ben
>

Besides hinting just being low level programming, we had to do a bit
of reverse engineering for DejaVu.
When we started working on hinting, the fonts already had quite a lot
done, but it was all just code and table with no labels nor comments.
So to hint a new character, we'd just look at how a previously hinted
one was done. Trying to understand every step, figure out which values
are called and when relevant add them to the wiki
(http://dejavu-fonts.org/wiki/CVT) so that value can be reused without
going through the whole process.

Luckily most new glyph we had aren't that different from previously
hinted ones. So it's possible to just copy and paste the code, and
edit the values or add/remove parts to match the new glyph.
In cases where that's not possible, it's OK to write all the hinting
instructions from scratch.
Most calls in the instructions use glyph point numbers, CVT index
numbers or function numbers.
On major problem with raw hinting instruction is when the glyph point
numbers change, you have to manually change all the values in the
code.

The workflow with xgridfit is quite similar.
It's just much nicer to be able to name values and therefore just
adjust those when the point numbers change, instead of changing all
the value in the code.
However XML is just not great to hack with.

It would make sense to have some kind of graphical tool to edit those directly.

Cheers,
Denis Moyogo Jacquerye