[XeTeX] babel

[Georg Duffner]

Am 2012-09-04 13:23, schrieb Zdenek Wagner:
> 2012/9/4 Philip TAYLOR <P.Taylor at 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