[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 8r fonts
Piet Tutelaers writes:
> 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.
An .mtx or .etx file contains a lot more information than a .tfm or
.enc file, for example algorithms for faking glyphs or kern pairs.
One of the important points of fontinst is that there's a published
.mtx and .etx format, which (for better or worse) I promised that all
future fontinst releases would be compatible with.
> 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.
I've published the file formats for .etx and .mtx files, and future
versions will be upward compatible... in particular I'm not going to
change from TeX syntax to Perl syntax.
> 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
And add (5) runs in something like real time on a Sparc Ultra. But
(1) There's 12kLOC to port.
(2) There's 12kLOC to port.
(3) There's 12kLOC to port.
(4) There's 12kLOC to port.
(5) The current version isn't broken, and any attempt to fix it will
introduce more bugs than it will cure.
> 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.
If you want to do it, then go ahead, but this porting effort would
take something like 3 months (fontinst is > 4 years old now) and I
really don't see a big gain for the effort.