lout-users
[Top][All Lists]
Advanced

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

Re: Another way of tweaking lout to support alien characters?


From: Valeriy E. Ushakov
Subject: Re: Another way of tweaking lout to support alien characters?
Date: Wed, 2 Dec 1998 22:40:40 +0300

On Wed, Dec 02, 1998 at 12:38:46PM -0000, Ted Harding wrote:

> In gtroff, there is no problem whatever with this sort of thing, since you
> can create a character consisting of any combination of whatever font
> marks your PostScript device has resident (either as built-in or as
> downloaded fonts); gtroff will assign metrics to this character derived
> from the font metric files and the positioning commands in the character
> definition.

It's not a problem in Lout, since that's what definitions are for.
You can combine any objects into a new object.


> For instance, "s-caron" could, as I have defined it, result from:
> 
> .acc*over-def v \(ah
> .char \(sv s\*v
> 
> [ \(ah is the gtroff identifier for the "hacek" accent; the first line
>   defines a string "v" which causes \(ah to be placed as an accent above
>   the preceding character; and the second line defines a new character
>   identifier "\(sv" which gives rise to an "s" with a hacek accent,
>   furnished with character metrics which take account of its components.
>   All this uses only the Standard Roman Character Set].

Well, in groff you refer to this "characters" by special \( names (man
groff_char gives a list of predefined ones).  But I believe, that what
Matthew refers to is different.

Suppose you have a font that have a glyph for zcaron.  Suppose you
have another font that have glyphs for latin small letter z (z) and
spacing caron (caron) [or, may be, non-spacing caron], but not for the
latin small letter z with caron (zcaron).

You have a text in Czech (8859-2) that use latin small letter z with
caron (character coded at 0xBE in 8859-2).

If you use the first font - the zcaron glyph will be used for the
input char 0xBE (latin small letter z with caron).  But if you use the
second font to typeset this same word, there's no zcaron glyph.

What Matthew asks for is for Lout to synthesize the glyph for zcaron
by combining existing glyphs for z and caron.  Thus one don't care if
the font that the word will be set in has a zcaron glyph of if the
glyph is synthesized behind the scenes.  The point is to have the
character z with caron (0xBE )not a special name in the input.

You can typeset greek with groff by using \(* names,but I doubt that
native greek will find it convenient to type \(*L\(*a and so on
instead of typing in 8859-7 directly.

The bad news is that Lout doesn't handle it currently.  The good news
is that most of the infrastructure is already there:

maps/00README reads:

    At present the functions are

  [...]

        UA <charname>;   Corresponding unaccented character (must be the
                         name of a character appearing elsewhere in the
                         same file).  This entry is used by Lout to
                         guess size and kerning information for accented
                         characters (when this information is missing from
                         some font metrics file) by using the size and
                         kerning information of the corresponding unaccented
                         character.

        AC <charname>;   Name of the accent character (acute, ogonek, etc.)
                         that forms the accent of this character (must be the
                         name of a character appearing elsewhere in the
                         same file).  This entry is not currently used.

Since Lout knows from the LCM file the UA (base) and AC (accent
modifier) it can, in principle, synthesize missing glyph on the fly.
Ask Jeff when/if this will be implemented.


> The point of all this is that the result is a true character object,
> on the same footing as the letter "A" say, with various metric attributes
> which the software keeps track of.

In Lout characters (or to be precise, glyphs) are objects, and you can
combine arbitrary objects into new objects.  So the problem is not to
make new objects first class citizens (they already are) - the problem
is that little magic that happens with words behind the scenes when
they are transformed from (syntactic) words into objects.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]