[luatex] Why obsolete the fontforge name space?

[Yue Wang]

Hi, Hans:

On Tue, Mar 24, 2009 at 7:48 PM, Hans Hagen <pragma at wxs.nl> wrote:
> Yue Wang wrote:
>
>> If there are sufficient funding, write such binding is beneficial.
>
> depends ... 99% of dev in the tex world is not funded and still beneficial
>

TeX and MetaPost was funded by AMS,
XeTeX is funded by SIL,
NTS, LaTeX , etc. are funded by TUG and local groups.
LM, Gyre are funded by NTG, and other gourps.
LuaTeX is funded by the Oriental TeX project and many others.
pdfTeX is originally  funded by the authors' advisor (it is a phd project).
TeXWorks is funded by TUG.
hyph-utf8 is a SoC project
......

writing such a binding might take one or two weeks' work.
It is fair to get paid.

> anyway, it's not on our agenda so such a lib + binding would end up in the
> add-ons activities later on; also, such a library should just expose  data
> which then could be transformed to something else using lua, i.e. it makes
> no sense to let such a lib construct a fontforge like table
>

Even LuaTeX's API/data structures are a bit different from FontForge's
internal presentation.
And it is possible to construct a fontforge like table using FreeType2.

So I think it is better to document such APIs/data structures into a specimen.
All the lib binding developers are recommended to follow the APIs and
data structures.
(like the NextStep or RenderMan way)

In fact, only a small subset of fontforge's data structure (metrics
table) is needed for typesetting.
Most font libraries include this subset.


> actually, if the advantage is sought in faster loading keep in mind that
> it's the construction of the big tables that take runtime, and that will be
> true for all fontloaders (only faster processors and more mem can solve
> that; it's the price for flexibility and in the luatex project flexibility
> and opening up is more important than runtime; as such luatex will always be
> much slower than the other engines and fonts is just one aspect) (we have a
> few ideas for speedups but these might not show up before version 1.0)
>

On my machine, generating and dumping a table for Adobe Song Std in
MKIV takes 30-40 seconds.
Loading the cache takes 1-2 seconds.

When loading the lua cache, lua interpreter should also allocate the
memory and generate the table in the memory.
So in fact the lua part is computational efficient.
It is the fontforge part that takes a lot of time.
At least 20-25 seconds are used for parsing the font and calculating
the bounding box.

Today morning, I wrote a small C program to load and calculate the
Control Box for each glyph in Adobe Song Std,
and it only takes 2 seconds per run, consuming 2M memory. when lua is
involved, I expect it can dump the font to cache in 5-10 seconds,
consuming ~10M of memory.


But, speed and memory consumption are just one reason.
Stability is another important issue: as I said, libfreetype2 was
tested by thousands and thousands of applications, and it is much more
mature than libfontforge.
I think freetype2 is more reliable than fontforge, and more developers
are familiar with freetype2 API.
(On my FreeBSD machine, there are 1000 or more binaries in
/usr/local/bin/, only fontforge and luatex uses fontforge, but at
least 700 of the binaries are linked to libfreetype2)
In addition, I think FreeType's documentation is more clear and
complete (fontforge's API documentation is a mess).
and FreeType also gives better source code comments.


> the standard built-in fontloader datastructures are quite specific and will
> stay close to what fontforge does if only because it makes developing fonts
> as well as debugging lua code easier (for instance same internal feature
> interfaces) while other fontlibs might have a completely different exposure
> of font characteristics
>


Metrics table are not difficult to get from any font libs.
And as long as we have a freetype-like exposure, it is not difficult
to remap it to fontforge-like one.
(just add some "for k,v in xxxtable do xxx=xxx end" or just write the
binding code follow Taco's luafflib.c)



> Hans
>
>
> -----------------------------------------------------------------
>                                          Hans Hagen | PRAGMA ADE
>              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
>     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
>                                             | www.pragma-pod.nl
> -----------------------------------------------------------------
>

Yue Wang