[ a very long time ago, in the context of supporting complicated international scripts ] Gilbert Baumann unk6@rz.uni-karlsruhe.de writes:

Brian Spilsbury writes:

...

I have implement (somewhat primitive) international text-style support. [...]

This sounds like a somewhat reasonable design to me, although I would very much prefer if we could move the fontset logic into the frontend by coming up with a sort of font protocol.

So, now, we (at Goldsmiths) have a need for a specific font. At the moment, we have hacked in support to our application using MAKE-DEVICE-FONT-TEXT-STYLE and some extreme hackiness in CLIM-CLX::TEXT-STYLE-TO-X-FONT; the device-font-text-style support in current CVS is ... not extensive, which is not really surprising given that the spec is approximately equally non-extensive.

It tickled my memory, though, and I dug up this proposal:

Something like this:

A font is a mapping from glyph names (indicies) to glyphs. Fonts have additional attributes like name, weight, an encoding, a language and so on. Glyphs have metrics and are drawable to individual media.

FONT protocol class

FONT-NAME font method FONT-WEIGHT font method FONT-SLANT font method FONT-... font method

The individual typographical properties of the font.

SCALE-FONT font size -> font method

Scales the font to a new size.
[Q1: Unit for size?]
[Q2: Should this affect metrics?]

FONT-SIZE font method

Returns the size of the font.

TRANSFORM-FONT font transformation -> font method

Applies a affine transformation to the font. Each glyph drawn with
the returned font are then drawn under the transformation. This
does not affect the individual glyph metrics.

FONT-TRANSFORMATION font -> transformation method

Returns the transformation of the font font.

FONT-GLYPH-METRICS font glyph method -> width ascent descent left-bearing right-bearing

Returns the fonts glyph metrics. To calculate the metrics of
glyphs as drawn my draw-glyph the transformation of the font has
to be applied to the returned values.

[This is to keep the glyph-metrics as scalars instead of making
each metric into a vector].

width should not be negative in case of RTL script, since
typesetting from right to left is consided to be a property of a
text-style; likewise left-bearing bearing on the left hand side
as right bearing is bearing on the right hand size.

Q4: Is there something like top-bearing, bottom-bearing for fonts
designed towards top-to-bottom scripts?

FONT-KERNING font glyph-1 glyph-2 method

Returns the kerning to be applied when typesetting glyph-1 left of
glyph-2.

DRAW-GLYPH medium font glyph x y method

[Q3: Interaction with general designs? Ideally we would make glyphs
into designs itself].

A text-style is a mapping of chracter sequences to font, glyph, position triples for drawing. A text-style then might refer to multiple fonts thus forming a fontset.

Each medium then knows its available fonts. These can be queried by the frontend and combined into a text style.

As you can see there are some questions and I am not entirely sure how things should really look like.

Nor am I. I don't suppose anyone else has had thoughts in the last three years?

We need: a way of specifying that we want to draw text using a specific font (in our case, a FreeType font for tablature) at a specific size. If that's not a DEVICE-FONT-TEXT-STYLE, I don't know where else it should go, but it does imply that a DEVICE-FONT has size.

I'm away from my workstation, but tomorrow I'll send patches showing what we're currently doing.

Cheers,

Christophe