[luatex] font expansion

Robert w.m.l at gmx.net
Sat Jul 15 02:02:04 CEST 2017

On 08.07.17 17:26, Hans Hagen wrote:
> On 7/8/2017 12:16 AM, Robert wrote:
>> On 07.07.17 18:34, Hans Hagen wrote:
>>> AFAIK one can make an instance of such fonts and use that.
>> But that's what I've been asking about the whole time: whether it is
>> possible to use instances instead of autoexpanding (ie., linear
>> distortion). And my tests led me to believe that this is, in contrast
>> to pdftex, *not* possible with luatex, which was corroborated by what
>> you said in your last post:
> I'm out pf th epdftex dev loop for a while but i wonder if it really
> creates instances from multiple masters.

No, it does not, and that's the whole point. In pdftex it is possible to 
use *existing* instances (created by external tools, in the case of MM 
fonts, mmpfb, for example, which have to be named <font>+5.tfm, 
<font>+10.tfm and so forth), *instead* of automatic expansion. So that, 
if you have created font instances in advance, there is a difference 
between specifying the "autoexpand" key to \pdffontexpand (in which case 
pdftex would disregard the existing instances), and leaving away the 
"autoexpand" key (in which case it would use the existing instances).

In luatex, there is no difference, and it seems to always autoexpand 
instead. I don't care if it does, it's just contrary to what the manual 
seems to suggest:
   (1) there is no mention of a difference between luatex's 
\expandglyphsinfont and its pdftex counterpart \pdffontexpand in terms 
of "autoexpand";
   (2) the boolean key "auto_expand" still exists in the "fonts" array, 
even though its setting doesn't seem to make any difference whatsoever.

> What it did was create copies
> of fonts i.e. the tfm character data with different widths for
> characters so that the par builder can use that info when breaking into
> lines. Then the backend adds that instance (when used) which is nothing
> more that using the same font with a different width array and applying
> a different horizontal scaling. Luatex does not need to create the copies.

I guess here you are talking about pdftex's old (pre-1.20) method of 
autoexpanding by embedding multiple (automatically calculated) instances 
of the same font. Since 1.20, pdftex does not create copies anymore 
either, but that's not what I'm asking about anyway.

> In the early (research) time of pdftex it could embed metafony instances
> and create them runtime and/or use fonts with a scale added to the
> filename given that a map file provides the real thing.

Exactly, only that this is still today possible in pdftex, but not in 

>>> Concerning variable fonts: these are already supported for a while
>> Does this mean that the width axis will be taken into account for
>> expansion?
> No, as currently the hard coded mechanism is using scaling. But its
> trivial to kick in a copy with a scaled axis in an extra (lua driven)
> pass given that there is a variation in the font that is tuned for it
> (which i doubt, because often other properties (region related and so)
> also change). I will probably do that once there are useable public and
> free fonts.

Good to hear that it's trivial, and looking forward to seeing this 


More information about the luatex mailing list