[OpenFontLibrary] hinting workflow

[Eric Schrijver]

Op dinsdag 15-06-2010 om 17:00 uur [tijdzone +0200], schreef 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


Hey guys,

Thanks a lot for your feedback!

That does seem like tedious work :(

I do agree with Peter that a standard would be nice. I guess that’s
something for the long term though. Because one would need thorough
knowledge of the different ways it is being implemented now and the time
to develop some implementations.

At least we could read into the different formats Erik mentioned and
document them here, so that we get a better overview on the different
ways hinting is being implemented across the industry.

For now I agree with Dave that XgridFit would be the most logical format
to use, since it is already an XML based format and already in use in
the FOSS toolchain…

A graphical tool would be cool. If I understand correctly one can run
XgridFit from inside Fontforge and do live preview, but you still have
to change the values by typing code—anyone volunteering to close that
gap :-)?


I do think all this shows hinting is still a bit of a black art. Am I
correct in thinking that most projects could at first get by using the
automated hinting of the design programs? Or is that typographic
blasphemy :) 

Having a properly designed typeface which spans a reasonable character
set should be the first goal I guess, many projects don’t even advance
to that stage.

What do you think?
Fontforge could for example do automatic hinting at the same time it
generates the (o/t)tf’s from the ufo.