[XeTeX] XeTeX 0.99 released

[Jonathan Kew]

On 7 Dec 2005, at 1:40 am, Will Robertson wrote:

> On 07/12/2005, at 2:57 , Jonathan Kew wrote:
>
>> It's been a while coming, but XeTeX version 0.99 is now available  
>> from <http://scripts.sil.org/xetex> and through i-Installer.
>
> Wonderful, thanks Jonathan.
> Right when I was going to get some work done :)

Thought this might give you some new stuff to play with!

>> * added Syriac OpenType support for Meltho (and similar) fonts to  
>> the layout engine, activated with "script=syrc"
>
> With the next release of fontspec I'm going to be restricting the  
> script selection to scripts that actually contain shaping code. Is  
> there a list anywhere of the scripts that XeTeX supports?

Yes....... in the source code. :)

OK, to be serious: I'm not sure such a restriction is a good idea, as  
some scripts may be rendered OK by the default shaping engine (the  
one that handles Latin and other "simple" scripts). This supports a  
number of relatively generic OpenType features such as character  
composition, ligatures, mark positioning, etc., and allows the user  
to turn on/off additional features (for the entire text run). I'm not  
confident that we can say which scripts *cannot* be adequately  
supported using only such features.... it depends partly on how the  
font developer chooses to use available features to implement the  
script behavior required.

If a font has OpenType tables for a script that doesn't have specific  
shaping code, but works with the default engine, you do still need to  
specify the script tag in the \font command, in order for the proper  
tables to be loaded. So IMO fontspec needs to be able to pass any  
script tag to the font, whether or not there is specific support for  
that script.

>> * font mappings are now applied to the text before checking for  
>> possible hyphenation points, which can change behavior in certain  
>> cases; in particular, en- and em-dashes typed as "--" and "---"  
>> will no longer be considered possible line-break positions
>
> This is a surprise, but a welcome one! From the previous  
> discussions it sounded like this was a bit of a limitation with the  
> technique in general, and although I'd never run into the problem,  
> I wasn't too keen on the idea of my dashes breaking in half...

Indeed.... that was not an acceptable situation.

> Out of curiosity, does this polish off the features you're  
> expecting to have implemented for v1.0?

It's close, I think, though I am still thinking about a couple of  
items.... First, an extended font-loading command that might be  
something like:

    \XeTeXfont\cs = "font-name" style "B/S=10" using ICU features  
"+smcp,+onum" at 12pt
    \XeTeXfont\cs = "font-name" style "BI" using ATSUI features  
"Ligatures=Rare Ligatures" at 12pt

and second, a mechanism to use fonts that aren't installed/registered  
with the OS. This might be done by using the filename directly in the  
\font (or \XeTeXfont) command; but there are possible ambiguities  
there. In theory, a name might be both a valid filename and an actual  
font name. And what about files that contain multiple fonts--which  
one gets used? Another approach would be a new primitive:

    \XeTeXregisterfontfile "filename"

which would simply make the font(s) in the file available for loading  
via the standard \font (or \XeTeXfont) command. This avoids the  
problem of files that actually contain more than one font (e.g.,  
suitcases on Mac OS X; TrueType Collections on other platforms); it's  
up to the user to select the font appropriately by name (and style,  
optical size, whatever), just as if it were installed in the normal way.

> I'm trying to think why I wanted \ifXeTeXfontexists. And off the  
> top of my head I really have no clue. Do you think it's a good idea?

Your other option is actually doing a \font\x="...." (with the  
interaction set to \batchmode, to avoid error messages) and then  
testing whether the resulting font selector is associated with  
nullfont. But I suppose a built-in \ifXeTeXfontexists test might be  
more efficient. I'll think about it. If you can remember why you  
wanted it, let me know what sort of scenario is involved.

JK