<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="sans-serif"><br>
Hello everyone, <br>
<br>
and a word of appreciation to </font><font face="sans-serif">Will
Robertson for his wonderful fontspec package.<br>
</font><font face="sans-serif"><br>
</font><font face="sans-serif">In a LaTeX document I defined a
\newfontinstance with the "</font><font face="sans-serif">WordSpace" </font><font
face="sans-serif">feature: <br>
<br>
\newfontinstance\arabicfont[Script=Arabic,WordSpace=1.7]{Lotus
Linotype}<br>
</font><font face="sans-serif"><br>
(Yes, the interword space in this font is really too small).<br>
<br>
Now since the command \arabicfont is called many times during
processing (esp. because of a macro that uses it for typing line
numbers in Arabic in the margin), it happens that the rescaling of
fontdimen2 is done again and again, growing exponentially until xetex
complains that the dimension is too large (probably larger that the
page!)
and stops.<br>
<br>
Looking "under the hood" I realized that an additional "WordSpace=1.7"
is
appended to the string of features of the font everytime the internal
fontspec macro is called, and the fondimen rescaling is done for every
one of them, again and again! <br>
<br>
Needless to say, this is probably not the intended behaviour. I guess
saving the original fontdimen{2,3,4} of each loaded font and rescaling
against those original dimensions
instead of the currently active values would be the appropriate thing
to do. What do you think?<br>
</font><font face="sans-serif"><br>
NB: The problem can be circumvented by setting
\addfontfeature{WordSpace=1.7} immediately after the first occurence of
\arabicfont in the document, but I guess this is not a really clean
solution... <br>
<br>
</font><font face="sans-serif">Thanks,<br>
François<br>
<br>
</font>
</body>
</html>