[Fontinst] Re: Bug in fontinstversion{1.927}

Lars Hellström Lars.Hellstrom at math.umu.se
Thu Jan 27 14:59:45 CET 2005

At 23.02 +0100 2005-01-26, Lars Hellström wrote:
>At 22.23 +0100 2005-01-26, Peter Dyballa wrote:
>>Am 26.01.2005 um 20:34 schrieb Lars Hellström:
>>> The various ties should be U+0361 (COMBINING DOUBLE INVERTED BREVE).
>>I thought of CHARACTER TIE at U+2040 ...
>Oh! It could be. One has to check the character properties to be sure, and
>I'm too sleepy for that now.

I've checked the properties now: The tie accent (and its variants) is
definitely U+0361 rather than U+2040. The former has character class Mn
(nonspacing mark) like all the other accents, whereas the latter has
character class Pc (connecting punctuation) and is thus most like
underscore (U+005F, LOW LINE). A U+0361 should be placed above a pair of
letters, whereas a U+2040 would rather be placed between them.

More on symbol identification: Hilmar Schlegel (who, it seems, doesn't want
his e-mail addressed publicised on the mailing list archives), sent me the

>Lars Hellström wrote:
>>>8j seems to be no problem since the Adobe Glyph
>>>List provides a mapping of PostScript glyph names to Unicode slots. But
>>>these TeX encodings: is there some easy to understand mapping of
>> I'd label this as a glyphic variation on `acute'.
>Would be good to have upper case accent characters - some TT fonts have
>them as internal components.
>> No, that doesn't seem to be in the Unicode standard, but it could be a mere
>> glyphic variation on `emdash'. Does anyone know where and how it is used?
>- -> hyphen
>-- -> endash (half quad)
>--- -> threequartersemdash (3/4 quad)
>---- -> emdash (1 quad size)

Hmm... Obviously not the standard setup, but quite possible.

>I use this all the time to avoid the ugly tight set emdashes one finds
>in English texts.

Tight setting or not is a matter of typographical tradition. I may be worth
to point out that the TUGboat class (and Plain-TeX macro predecessors)
provide commands for non-tight setting of en- and emdashes, so it certainly
isn't unanimous even in English typography.

But how would a threequartersemdash avoid tight setting? Is the glyph 1em
wide but its bounding box only 0.75em?

>Some publishers even had to resort to avoid the emdash
>  in general because it is too ugly (even when set with separating
>spaces ;-). The result is then that -- will be used for rangedash
>(without spaces) and punctdash (with spaces).

This may well be the *non-anglosaxian* typographic tradition. (Kind of like
the \nonfrenchspacing is an anglosaxian speciality.) Using a half-quad-dash
with spaces around is at least the old Swedish typographical tradition.

>Just found that a figuredash would be nice for numbers with dashes
>within running text

Hmm... I think the main thing that sets figuredash out is its vertical
position; it is aligned for upper case digits (non-hanging) rather than as
endash aligned for lower case letters and digits. But this might vary.

>(like ISBN &c)... The minus is to too long, a hyphen
>too short & fat,

That's bad. But the hyphen still is (possibly with exception for
figuredash) the typographically *correct* sign.

>an endash might be not exactly the width of the numbers.

Not to mention that an endash with numbers strongly signals a *range*

>>>hyphendblchar, hyphendbl,
>> Glyphic variations on `hyphen'. (Also cf. `hyphenchar'.)
>In Fraktur fonts the hyphen is a slightly slanted double line. One would
>typically want to use this instead of the usual hyphen but I think it
>was supplied as an additional character...

This is probably an example of the tc* fonts being designed more as the
"Expert" set for the ec* fonts than as a logically coherent symbol font.

>>>tieaccentlowercase, newtie ... to Unicode?
>> Those two ought to be somewhere (or be glyphic variations on something) in
>> Unicode. As I recall it, the `newtie' is the same as the ordinary `tie',
>> but the command for it is supposed to be used in a different position.
>> Perhaps some German can tell us? I haven't seen any mention of these things
>> being used anywhere else than there.
>That's what I can tell you;-)
>BTW, typical encodings lack the apostrophe character (curved shape, like
>lower part of semicolon) which is in (bonafide) Fraktur fonts different
>>from a right quote (prime shape, shifted comma).

??  I can agree prime is usually straight, but in my experience the comma
is more often curved than straight. However this experience may be based
mostly on antiqua fonts.


Lars Hellström

More information about the fontinst mailing list