[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 8r fonts

> Piet Tutelaers writes:
>  > In order to get a feeling for the effort needed to rewrite fontinst into
>  > PERL:
>  >  (1) What exact role plays the .etx and .mtx files in the fontinst process?
> The .etx files describe the font encoding, and the .mtx files describe
> the metrics, in a TeX-friendly format.  Both of them make heavy use of
> TeX's macro language to provide control structures such as
> if-statements and commands.  For example the command which defines an
> `unfakable' glyph (a black box with a `missing glyph' special) is:
> \setcommand\unfakable#1{
>    \setglyph{#1}
>       \ifisglyph{#1-not}\then
>          \moveup{\neg{\depth{#1-not}}}
>          \glyphrule{
>             \width{#1-not}
>          }{
>             \add{\depth{#1-not}}{\height{#1-not}}
>          }
>          \resetitalic{\italic{#1-not}}
>          \moveup{\depth{#1-not}}
>       \else
>          \glyphrule{500}{500}
>       \fi
>       \glyphwarning{missing glyph `#1'}
>    \endsetglyph
> }

PERL provides nice features for reading binary files (VF and TFM
files) through pipes, for example:
  open(VF, "vftovp $vffontname $tfmfontname |");
  while (<VF> {
     "process next line of VPL file derived from VF";

So reading the metrics for all characters in a TFM file (your .mtx) and
the information in an encoding file (like 8r.enc) is not difficult.
And with that information above function (it looks like it writes
something to a PL and/or VPL file) seems no real problem.  Macros do
form real pitfalls for programmers. That is the reason C++ has
abondoned them in favour of inline functions (whose use can be checked
at compile time). In PERL you can write powerfull functions.

But perhaps you can think of more difficult issues?

> Fontinst does have a published API for the syntax of commands like
> \setcommand, \ifisglyph etc. etc. but writing a parser and interpreter
> for it would effectively mean reinventing TeX's mouth.  One of the
> reasons why it's implemented in TeX in the first place is to make use
> of the macro language.
> Fontinst itself is only ~2.5kLOC, but once you include all the .mtx
> and .etx files which come with it it's ~12kLOC.  Porting it would be a
> major enterprise for not terribly much gain compared to using perl
> scripts to postprocess fontinst output.
> Alan.

In my opinion the benefits are:
 (1) better understandability
 (2) as a consequence a better maintainability
 (3) no postprocessing needed to generate checksums
 (4) PERL can use all memory your computer has onboard (no fixed arrays like

For most people TeX programming is like assembler programming. The
abstraction level is very low. TeX was never ment to be a general
purpose programming language.

After all this propaganda for PERL I realise that writing PERL needs to
be learned. That takes time (not that much as in TeX). If you decide to
rewrite fontinst in PERL I am willing to help you with the design.