Christoph Wedler writes:
>>>>>"KJ" == Kyle Jones
<kyle_jones(a)wonderworks.com> writes:
KJ> Please explain how this baseline-shift property would be used.
KJ> I'm assuming it wold do what glyph-baselines do now, except apply
KJ> to the glyphs of a face's font.
>>
>> To display super- and subscripts in HTML and LaTeX buffers (via
>> font-lock).
>>
http://www.fmi.uni-passau.de/~wedler/x-symbol/subscripts.png
KJ> Hmmm, OK. I think this would fit better as a font property
KJ> specifier, like font-ascent.
I don't know. Yes, currently I use different fonts for super- and
subscripts. But that's the point: I want to use the same font for
super- and subscripts (and any smaller font, not shifted), they just
should be displayed differently, i.e., shifted up/down.
Yes. You would use the same font, just not the same font-instance.
Strings like "fixed" and
"-adobe-courier-bold-r-*-*-*-180-*-*-*-*-*-*"
are valid instantiators under X11. What I'm proposing is to allow
instantiators like ["fixed" :baseline-shift 2], to create a shifted
instance of the font. You could then use this kind of instantiator in
any place where a string instantiator is accepted now.
And having the same font with different font properties sounds
strange
to me... Also, the font properties seem to correspond to the properties
--well-- of the font, i.e., the properties mentioned in the bdf files --
baseline-shift wouldn't.
It makes good sense to me, given the overall system structure. I
think it fits in well with the idea that Bill Perry keeps raising
about chopping up the font specifications into individual properties.
It's all just another keyword/value part in the instantiator vector.
If we use a face property, we have a semantic collision between the
glyph baseline property and the baseline-shift property.