🚀 go-pugleaf

ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

[about some issues in handling text; topic started from context-dependent
glyph selection]
> So, you need another layer on top of PostScript to implement these functions.
> Performance considerations aside, do you have a standard for this layer?

These decisions can be made in the layer that handles other natural-language
dependencies, such as hyphenation.  I'd call it a "text formatter" for want
of a better word.

> Or does this mean that programs that want to be writing-system-independent
> cannot be operating-system-independent?

Not at all.  The operating system shouldn't have to enter into the issue.
The layer which handles the language issues is a program which takes input
generated by the user and produces PostScript as output.  The generated
output is a program to place glyphs (I'm consciously avoiding the word
"character" because it has too many meanings and it's not right here) on
the page.  PostScript is used to describe the appearance of the page, but
the natural-language considerations have all been taken care of before
then.

> If you have a separate text-rendition layer, you'd then have to maintain
> *two* sets of information about each font: the standard PostScript font
> dictionary, and all this extra information, in order to draw sensible-looking,
> readable text with that font.
...
> I'm not suggesting that you write PostScript programs to do page layout
> (thought I agree it would become possible). But *somewhere* there needs to
> be the information necessary to allow the application to do it--and it
> needs to be available in a standard form, or portability goes out the window.

Yes, you get the information about the fonts in two places--on either side
of the PostScript interface.

The information is available for the application to do it.  It's in the
.afm (Adobe Font Metric) files.  There's one such file for each font.
These files give the necessary layout information--widths and bounding
boxes of characters.  They also contain information describing ligatures,
composite characters (e.g., characters built from a base plus a dia-
critical), kerning pairs, and such--things that the PostScript interpre-
ter doesn't know about in its text-rendition operators.  (For example, the
interpreter can't do ligature substitution; it can't know whether it's
needed/desired.)

Applications which do "serious" text processing and produce PostScript
output either use the .afm files directly or (more commonly) have some
associated utility which predigests the .afm's into an internal format
containing the information needed by the application.  But either way,
you've got a standard form for the information the application needs.
-- 
Dick Dunn     rcd@ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...I'm not cynical - just experienced.