Virtual fonts

[Valeriy E. Ushakov]

On Tue, Apr 11, 2000 at 09:34:21AM +0100, Jeffrey Howard Kingston wrote:

> First, it is a good general principle to start with some problem to
> be solved, and only when it has been clearly expressed to move on
> to potential solutions.  I guess I came in on this discussion late;
> what problem are we trying to solve?

I would always prefer to find a real font that support necessary
glyphs.  This is probably because for Cyrillic it's not sufficient to
hack together just a couple of glyphs missing from Times, so I have
to use real fonts anyway.

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.


. Linguists invents all kind of diacritical marks.  It's quite
  possible that there's simply no existing font for them to use.  They
  have screen fonts, so they can edit and see those chars with
  diacritic on screen, and they want to be able to typeset this
  without mangling readable text into cryptic typesetting commands.

  Compare (ascii art here, imagine real chars are used):
                   _
    om mani padme hum 
     .   .          .

  and

    address@hidden address@hidden padme address@hidden@mdot}


  And if this mangling makes hyphenation (if applicable) impossible as
  well.


> 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.


> what hyphenation means in words containing this remapped character,

Hyphenation is not affected.  Hyphenation works on character codes and
we are talking about providing missing glyphs for characters.  Of
course Lout is not strict in drawing this character/glyph line, but in
this case it should be possible to keep the distinction clear.

In fact preserving hyphenation is a very desirable feature.  I
wouldn't say it's sine qua non, but dumping hyphenation in this case
would cast serious doubt on the usefullness of the whole idea.

I belive troff can hyphenate quite happily in the presense of such
emulated glyphs (Ted?).


> It is easy to say in advance that these things can be ignored,
> but the results will soon have people coming back to try to fix
> them.

Sure.  I'm equally opposed to quick hacks that solve problems 80%.
I've heard stories how C++ standard was made (from participants).  Oh,
and witness perl...  So I'd like to invite interested parties to
participate in the discussion.


Perhaps we can settle for less radical/generic but consistent and
useful solution.

LCM alredy provide enough information to support simple diacritic
construction.

Consider (from LtLAtin2.LCM).

    204 314 Ecaron  LC ecaron;  UA E;  AC caron;
    236 354 ecaron  UC Ecaron;  UA e;  AC caron;

that already gives case mappings and components for the composite.

When a font is used that doesn't have precomposed ecaron we already
know its parts.  We don't know, however, how these parts are to be
combined.

Now consider AFM's CC keyword.  The following example is from
Times-Roman:

    CC Zcaron 2 ; PCC Z 0 0 ; PCC caron 139 212 ;

That gives positioning of components in the composite glyph.

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 ;

So instead of emiting

    (\354) show

we would emit components of the CC list in reverse order (CC is
effectively 'seac' Type1 instruction and 'seac' usually renders accent
first; rationalle is that the WX of the composite is usually that of
the base glyph (first component) and when you render it last your
current point will be were it should be):

    gsave               % for rendering accents
    56 0 rmoveto        % offset for this component
    (\237) show
    grestore            % point is back to where it was 
    (e) show            % and point is where it would be
                        % if we'd render (\354) show

This is effectively just explicit 'seac' implemented at the code
generation level and not at the font level.

Any further comments from interested parties?

SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen