Am 2012-09-04 13:23, schrieb Zdenek Wagner:
2012/9/4 Philip TAYLOR <p.tay...@rhul.ac.uk>:
Zdenek Wagner wrote:
Language feature of a font.
OK, now understood, but this does not address my concern
regarding the countless extant fonts that do not have
such a feature. Would it not be better to postulate
a solution that can be used with any extant font ?
My point is that if it were done in the font, it would be done once
and could be used not only in TeX but also in other programs as
Scribus, InDesign etc. If the font designer were a good typographer,
the spaces could be tuned to match the font. I think that Computer
Modern needs larger spaces than Times Roman and there are even more
condensed fonts. Thus the font designer could do it better. For me TeX
solution is for the case that the feature is not implemented in the
font. And it is good that it can be done in TeX. The ideal system
should allow users to switch between using font features and macros.
If the system offered inserting features dynamically without requiring
users to understand font internals, it would be even better.
As somebody who’s a little bit involved in fontdesign, I don’t think
this should be put in the font. The smartness of smartfonts shouldn’t
try to replace the typesetters’ or their engines’ intelligence—because
it simply cannot. Keeping a font universally usable forbids many things
that could be easily done with smartfont techniques. For the very case
of french punctuation imagine a french person who wants to print one of
them without spacing or with a normal space. This might be a rare case,
but it does happen. Should they switch to another locale for that case
although the loacale didn’t change at all?
Two possible smartfont techniques for such locale feature are:
- alternate french punctuation marks with larger sidebearings: this is
very unflexible for users (punctuation characters without additional
space or with different space width are troublesome) but of course
simplifies the typesetting engines’ troubles the most.
- contextual variant of the <non breaking space> character: the
typesetter or their engine has to enter a space at the correct place
that then gets replaced by a (narrower) variant; here I think the
engine’s troubles aren’t really diminuished a lot, but the users’ might
rise. What’s more, contextual lookups that involve <space> don’t work
with XeTeX, so this is not very lucky here too.
Unicode already provides for a bunch of different space characters. IMO,
type designers should provide their fonts with appropriate space
characters (eg. 6-per-em space or thin space) and the typesetter or
their engine should check for the presence of that character and use it.
Best regards,
Georg
--
EB Garamond: http://www.georgduffner.at/ebgaramond
--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
