[luatex] font expansion

[Hans Hagen]

On 7/15/2017 2:02 AM, Robert wrote:
> 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 fact it also relates to pdftex being tfm based while luatex has wide 
fonts and uses the same backend logic for both and therefore map files 
and backend-used-fonts are dealt with differently (tfm / pfb still can 
use map entries but for instance expansion in luatex has no concept of 
instances, only of expansion factors of glyphs)

(auto expansion is then simulated by automatically generating glyph 
factors automatically while defining the font in lua)

anyway, there are several places where pdftex and luatex differ and this 
is one of them (i can add a remark in the manual about it) and so if you 
look at the pdf you will see the same font being used but with a 
different transform matrix

it's not our objective to be compatible with e.g. pdftex and omega 
(aleph) in all aspects (esp not when it concerns extensions; we dropped 
quite a lot actually)

> 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.

we kept the key in order not to break macro compatiblity (but i agree 
that it can be removed in the lua part and will do that)

>> 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 
> luatex.

of course one can do that: just apply hz expansion to a font and
run over a typeset paragraph and remap (id,ex) combinations to a new 
font id associated with generate metafonts (or use predefined fonts) .. 
that is the (in fact more flexible) luatex way of doing things

>>>> 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 
> supported.
(only when i see use for it, and of course only when there are free high 
quality fonts available that have good wider / narrower instances that 
fit well with the default instance; in fact, in the true nature of 
expansion - hz - one can use fonts that have alternative shapes as 
gutenberg had, but till now i didn't see such fonts)

(as it was one of things that came to mind when i implemented support 
for variable fonts and was discussed at meetings i might as well cook up 
some proof of concept just for fun)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------