[XeTeX] Patch: Add an entry for stemv

Jonathan Kew jfkthame at googlemail.com
Wed Mar 4 16:16:00 CET 2009

On 4 Mar 2009, at 14:48, Yue Wang wrote:

> Hi,
>> Sure, in theory they can do that (provided the font license permits
>> it!). However, many users will not feel competent to undertake
>> something like this, even if they become aware that it would be
>> possible. On the other hand, a driver-level workaround such as I
>> described would allow the XeTeX system as a whole to transparently  
>> and
>> automatically improve the results (for whichever "common" fonts  
>> people
>> provide the settings for). Seems like that would be a worthwhile
>> benefit for the user community as a whole.
> driver configuration files make tex code not portable.

No, the TeX code remains portable, and the typeset result remains  
identical in terms of format and content. The only difference would be  
the quality of font rendering, which is analogous to the difference  
between using, say, Computer Modern in 300dpi bitmap format or in Type  
1 format. It's perfectly reasonable for the quality of the PDF to  
depend on how the user's PDF output driver is configured.

> One should also copy the configure file in order to obtain similar  
> result.

And all the fonts, of course, if you want someone on another computer  
to be able to reproduce the exact same output. Otherwise (even if they  
have fonts with the same names), the versions might be different.

>> So I do think it's worth doing something about this, I just think
>> patching xetex to add another option to the \font primitive is not  
>> the
>> most helpful approach.
> Well. maybe we can do this:
> - patch xetex, allow something like \font\a="simsun:special={stemv=0,
> blablabla...}"
> then we ship the special code into xxx1, xxx2, xxx3 or xxx4 related
> field just as the \special does. (ship them after t[2], before
> post_post, in the <font definitions>)
> this might be useful for further development: if user want to set a
> parameter (like weight), no xetex change is needed.
> on the driver side developers can support whatever extension they  
> want.

There'd be no need for any xetex patch, you could just implement  
support for \special{x:font-hack:simsun:stemv=....} with some  
arbitrary syntax that the driver reads, and applies to the named font.  
But I still think providing this information in a driver configuration  
file, so that it doesn't have to be added to every input document but  
is set "globally", is the better approach.

Such a configuration file should probably be designed with  
extensibility in mind, so that if there's some other font parameter  
that people want to override at PDF generation time, that can be  
added. Perhaps use an .ini-like format....

    StemV = 42

    StemV = 98
    StemH = 76



More information about the XeTeX mailing list