Re: Virtual fonts

[Tamas Papp]

On Tue, Apr 11, 2000 at 06:38:33PM +0400, Valeriy E. Ushakov wrote:

> My understanding is that people request this feature for the following
> reasons (not limited to these particular ones, though):
> 
> . Adobe standard encoding and their "standard" fonts have some of
>   Latin2 precomposed already and have necessary accents to compose
>   missing ones.
> 
>   So full support of their alphabets in standard fonts is just few
>   missing precomposed glyphs away and using custom Latin2 fonts seems
>   unoptimal.

This is the main reason for me. Actually, it's two characters: o and u
with double acute, and the respective capital letters. There are very
few _FREE_ latin-2 fonts around, and they are quite easy to hack
together. I guess that many languages have similar problems.

> > Second, a good font specifies not only the shape of each glyph but
> > also kerning between glyphs.
> 
> If the glyph is something really weird, then kerning probably doesn't
> make much sense.  Otherwise user can specify that this character
> should be considered equivalent to some other character for the
> purpose of kerning - and Lout already does similar thing in its
> kerning code, BTW.

I agree. The user could simply say that the kerning information is
inherited from another character, eg. @dotm would just inherit the
kerning of `m'. Anything more complicated than that needs a special
font anyway, and that, IMO, should not be handled by lout. Users
should use a special font for really extravagant needs.

> Of course, since ecaron is missing, AFM for the font won't have a CC
> line for the ecaron glyph.  But let's suppose we have a syntax to
> augment the information in the AFM with additional user defined
> composites.
> 
>     fontdef TimesCE Plain { Times-Roman
>                           Ti-Rm               # AFM, as shipped by vendor
>                           Ti-Rm+              # more metrics by user
>                           LtLatin2.LCM
>                           Recode }
> 
> Where Ti-Rm+ contains addtional information about the font supplied by
> user.  This file would use the same syntax the AFM file uses and will
> be allowed to contain only CC (composites) and, perhaps KPX (kerning)
> but only for the composites defined in the same file.
> 
> Lout then should notice that Times-Roman has no ecaron and that user
> supplied metrics defines ecaron as 
> 
>     CC ecaron 2 ; PCC e 0 0 ; PCC caron 56 0 ;

This seems to be a good solution that addresses all the problems I've
encountered. BTW, I've noticed that the AC entry in the LCM files is
not currently used (at least that's what 00README says) so it must
have been included for some yet unimplemented feature, I'd like to
know what Jeff had in mind.

> Any further comments from interested parties?

A virtual fontserver would be a cleaner and nicer solution. While the
one you propose does solve all of our problems, and is easier to
implement in the short run, it will be just another hack in the lout
source code without significant changes in the overall structure and
design. Such hacks do make the task of maintaining lout more and more
difficult. 

Lout (the compiler) must have been easier to maintain when it was
relatively small and clean, but now it is big and complex. If I wanted
to contribute to the source code, I'd have to devote a month or more
to understanding the source. The WHOLE source --- that is the curse of
structured programming. What I see as a solution is a virtual font
server written in an OO language, as an interface with different
implementations for different font standards, which could be linked to
lout (eg. Eiffel code via CECIL.) Even if it seems a daunting task,
keep in mind that it could be done incrementally, by writing the
interface and an implementation for Type 1, being the most common
font.

I could see the one below as a viable structure:

[text] ---toglyph--> [glyph] ---virtual font server--> [output]

Lout would read the text and decode it to glyphs. Then it would
request kerning information from the virtual font server, and typeset
the text. After, the virtual font server could be used for dumping the
generated output to a PS file.

Just some random thoughts.

Regards,

Tamas