Re: OT: FontForge (was: writing system)
From: | Henrik Theiling <theiling@...> |
Date: | Saturday, January 8, 2005, 19:32 |
Hi!
"H. S. Teoh" <hsteoh@...> writes:
>...
> > But before rendering bitmaps, Metafont converts the program to cubic
> > splines, so there is another level of generic representation that
> > could be converted. No idea whether it is used, but theoretically,
> > it's possible to convert before bitmaps are rendered.
>
> But that's still the easiest part of the process. The power of
> Metafont is that font programs are parametrized, and the font programs
> can act on the parameters in arbitrary ways. To truly capture the
> entire quality of a Metafont, one would have to translate the function
> of the program on its parameters into font hinting parameters. This is
> the part that's probably infeasible or impossible to implement.
> (NP-completeness or NP-hardness comes to mind... and likely
> intractability.)
Sure, sure, but even LaTeX normally uses a set of fixed sizes. So you
could run Metafont at, say, 5, 6, 7, 8, 9, 10, 11, 12, 14, 18 and
22pt, and then use the converted font that comes closest for any given
size.
This ignores whether TrueType can handle this -- I don't know. I
think PostScript fonts cannot automatically handle different curves
for different sizes, but simply scale linearly on both axes..
Further, do all of these font types use cubic splines? PostScript
does, but what about TrueType. I vaguely seem to remember that it
uses quadratic splines only. To convert order 2 to order 3 would be
easy, but order 3 to order 2, is, of course, quite hard.
I will not claim font conversion is easy -- I know it is not. There
would probably be good tools if it was easy. I just wanted to say
that Metafont first computes cubic splines and then renders them just
like PostScript does as well. That's all. :-)
> Well, sanokí (Ebisédian's writing system) doesn't really have too
> large a number of glyphs, but it is significant, so I wrote a program
> to typeset it. :-)
Ha, you seem to have very similar needs as I have when conlanging --
the ligature rules of Fukhian were so hard that even LaTex could not
master them. I wrote a preprocessor for LaTeX that composes ligatures
and inserts separators (similar to an Arabic 'tatweel' U+0640).
And for Tyl Sjok, the font renderer also preprocesses LaTeX and
replaces romanised Tyl Sjok by an inclusion of a generated PostScript
file for each glyph. :-)
For both scripts, HTML support is quite bad, however. The missing
link isn't programmed yet -- but Tyl Sjok, using PostScript, will be
easier to use.
> I'm generally willing to learn conlangs, if I get the chance to use it
> reasonably often. :-)
Since not even I am currently willing to learn my own conlangs, you
will probably not have much chances of a nice chat. :-) But *if* you
start learning, say, Qthen|gai, I will try it, too, I think :-))) --
I'm sure it's really hard to master, though. And since the whole
grammar is programmed in Lisp, it takes alsmost no effort to change
the grammar: all the texts will adjust automatically. This means the
language is still heavily in flux. (Relay 10 text at Jan's page must
be considered Old Qthen|gai now (at that time: Q'en|gai)...)
(Which script will be used for Qthen|gai is not yet decided --
currently it uses Fukhian, but I'm not too satisfied with that.)
**Henrik