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

[Ted Harding]

On 02-Dec-98 Valeriy E. Ushakov wrote:
> 
> It's not a problem in Lout, since that's what definitions are for.
> You can combine any objects into a new object.

That was my interpretation of the documentation.

>> For instance, "s-caron" could, as I have defined it, result from:
>> 
>> .acc*over-def v \(ah
>> .char \(sv s\*v
> 
> 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.

My impression was that Matej wanted to escape from dependence on
special printer fonts, and since PostScript can do it with standard
fonts by making a composite glyph he would like know how to do it
within Lout.

I've looked at what you wrote about UA and AC functions without being
clear whether it corresponds to what I'm talking about. To refer again
to gtroff (sorry about that, but it is what I know, very well, how to use)
you can define character translation. For instance:

.tr WXYZ...\(cv\(rv\(sv\(zv...

translates the characters "W", "X", ... into the characters \(cv, \(rv ...
(where "W", "X", "Y", "Z" stand for the 8859-2 characters <c-caron>,
<r-caron>, <s-caron>, <z-caron>, and are typed in with corresponding 8-bit
byte-codes: e.g. <z-caron> == 0xBE and appears as <z-caron> on the screen
when typed), where \(zv has been defined as z\*v so as to be printed as
the composite glyph, then typing "Z" would give rise to printing <z-caron>
using standard PostScript characters and no special fonts required; the
font metrics used would be those for the translated form "\(zv" and not
for the "Z" (though in this case the horizontal metrics, at least, would
be the same).

So in gtroff you can type single characters and have them translated to
compound definitions (whose primary names are "\(??" forms).

So I guess the question for Lout is: is there a corresponding
straightforward translation mechanism? I think it should be so, since from
my understanding of the "expert" document you could define anything
(including a single input character) to stand for any defined object.
So <z-caron>[8859-2] = 0xBE = 190 = <three/four>[8859-1] which is
@Char threequarters in Lout. So you can define "@Char threequarters"
to give rise to the composite glyph for <z-caron>. The main question
which is not clear to me is whether Lout, on seeing the byte 0xBE
in the input, will recognise this byte as corresponding to the Lout
evocation "@Char threequarters" for this purpose. If this approach would
work, then I don't think the "UA"/"AC" mechanism would be needed for this.
Am I correct here, or not understanding something?

Or can you simply define "Z" to mean the Lout definition of the composite
object (with compounded metrics, of course), where "Z" is the single
character with code 0xBE?

> 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 same point about character translation would hold for Greek, of
course.

> The bad news is that Lout doesn't handle it currently.  The good news
> is that most of the infrastructure is already there:
> 
> [snipped]
> 
> 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.

As I say, I'm not sure whether it can be done as it should be, neither
from the documentation (what it says about definitions suggests that
it can be done) nor from your statements about the UA/AC functions
(which suggest that at present it cannot be).

With many thanks for your reply,
Best wishes,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Date: 02-Dec-98                                       Time: 22:34:02
--------------------------------------------------------------------