🚀 go-pugleaf

In article <1992Aug19.120450.1@lucy.claremont.edu> dhosek@lucy.claremont.edu writes:
>And what is this magic method? If it involves, say, some system
>call, then you have two problems: First, the system has to be
>Unicode-knowledgable (in short, the majority of in situ operating
>environments can't use it) and the line breaking software has to
>be willing to interface with this system call. In the case of a
>system like TeX (or any of the systems which use TeX's line
>breaking mechanism), this is likely not a viable choice. TeX
>needs to be able to work (internally) with ligatures as physical
>glyphs. Unicode in this case could be workable as an input
>scheme, but not as a useful coding scheme for fonts.
> 
The only knowledge of Unicode the system has to have is how to map Unicodes
to (initial cuts at) glyphs *for that font*. Once that is done, any
further processing occurs independent of character encoding. Concrete
example: QuickDraw GX on the Mac (which I'm working on). Here, a single font
can have many different 'cmap' tables, which map from various character
encodings to glyph indices in that font. All subsequent processing (such as
formation of ligatures, swashes, kerning, decomposition of ligatures, etc.)
happens in this glyph index space, and is therefore independent of *any*
character encoding.

I'm not sure I understand your point about TeX working with ligatures as
physical glyphs. If I pass GX a string "office" I'll get back widths that
are appropriate to the font being rendered with. One font may have "ffi"
ligatures, another only the "fi" ligature, and still a third no ligatures
at all. The measurements returned will be appropriate to the context. Further,
if these ligatures need to be re-broken for linebreaking purposes, data in
the font again can identify what the whitespace threshholds are before
that breakage happens, and can return appropriate widths.

Your point about Unicode being useful as an input scheme is precisely
correct. In the examples I've cited above, the set of Unicodes mapped
by the 'cmap' table may only number a couple of hundred, but the glyph
repertoire in the font may number in the thousands. There doesn't need
to be a one-to-one mapping, since the Unicodes aren't intended to
convey appearance, but just meaning. As I mentioned in my previous link,
appearance is the responsibility of something other than the character
encoding.

Your analogy of Unicode to ASCII is right on the money. I agree that Unicode
is not the answer to questions of appearance (although, as described above,
it can certainly be used as the input to the process of generating an
appearance for a string of text).

Dave Opstad
Line Layout Weenie