[XeTeX] t caron problem (gentium font?)

[Ross Moore]

Hi Peter,

On 20/04/2009, at 7:04 AM, Peter Dyballa wrote:

>
> Am 19.04.2009 um 02:40 schrieb Ross Moore:
>
>> If you also include the line
>>
>>   \UndeclareUTFcomposite[\UTFencname]{x0165}{\v}{t}
>>
>> then  \v{t}  will give you  t\char"030C  using the
>> "Combining caron" at U+030C .
>
>
> Shouldn't \v{t} combine t with COMBINING COMMA ABOVE at U+0313 (̓) or
> COMBINING COMMA ABOVE RIGHT at U+0315 (̕) or MODIFIER LETTER
> APOSTROPHE at U+02BC (ʼ) or a raised comma (or raised COMBINING COMMA
> BELOW at U+0326)?

Yes, you are probably correct, however ...

The reason for associating  \v{t}  with U+0165  is because
this is what happens in  tipa.sty  --- if I recall correctly.
Thus there are existing documents out there that use this
user-level markup to get that character.

xunicode  copes with this using character-level accent variant
automatically, via:

  \DeclareUTFcomposite[\UTFencname]{x0165}{\v}{t}

If you  \UndeclareUTFcomposite  then you'll get the meaning
of  \v  with a 't' argument, bypassing the character-level bit.

Normally \v is used for a proper caron accent, so this is what
you'll get.

There would need to be an extra level of fall-back to have
  \v  using one accent character for some letters, and another
for others.
This requires developing more programming code, for a situation
that could be extremely rarely (if ever) used.

Alternatively, we could define a different control sequence
for the other accent letters, thus using up more of the
namespace without any existing precedent.


Yes, this all could be done, but is the benefit worthwhile?
And, as you say below, just adds to the slowness.

>
>> My question is whether or not it is worthwhile building
>> in checks of the font for the existence of the glyph?
>
> This would slow down the slow XeTeX process even more. Maybe it's
> worth to implement in xunicode a switch or option, maybe "further" or
> "harder," which when given as package option, allows this deeper
> poking. If nothing suitable is found a better font is proposed ...

Yes, I was also thinking along such lines.

Another possibility is to check the value of  \UTFencname
against the standard values of 'EU' and 'U'.

If different, then this indicates that a user, or package-writer,
has specifically set the encoding, presumably to accommodate
a particular font. So assume that the user (package-writer)
knows exactly what he/she wants, hence do no extra checking.

Extra checking could be done with the default encodings,
perhaps also tempered by package-loading options,
as this indicates lack of attempt to fine-tune the fonts.


A further aspect of this would be to allow substantial parts
of the  xunicode  package to be re-read for different fonts,
so that each font can get an encoding that corresponds
to exactly what it supports.

Thus using  \Undeclare...  with a particular encoding removes
character-level support only for that encoding
and not for others.


>
> Would it make sense to create a data base of fonts for certain
> scripts which lists their version number related "features?" One
> useful element would be a list of languages that this version of the
> font actually supports fully, approximated, by construction.

Nice idea, but it'd be tedious work creating it and keeping it updated.
Good project for Google's Summer of Coding, maybe.

>
> --
> Greetings
>
>    Pete


Cheers,

	Ross

------------------------------------------------------------------------
Ross Moore                                       ross at maths.mq.edu.au
Mathematics Department                           office: E7A-419
Macquarie University                             tel: +61 (0)2 9850 8955
Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
------------------------------------------------------------------------