[luatex] font expansion

[Hans Hagen]

On 7/6/2017 5:46 PM, Robert wrote:
> On 06.07.17 14:02, Hans Hagen wrote:
>> On 7/6/2017 1:37 AM, Robert wrote:
>>>
>>> Firstly, the manual says:
>>>
>>> | When \adjustspacing has value 2, hz optimization will be applied to
>>> | glyphs and kerns. When the value is 3, only glyphs will be treated.
>>> | A value smaller than 2 disables this feature.
>>>
>>> However, what I see is:
>>>   * a difference between \adjustspacing=0 and \adjustspacing=1,
>>>   * a difference between \adjustspacing=1 and \adjustspacing=2,
>>>   * no difference between \adjustspacing=2 and \adjustspacing=3
>>> (regardless of whether the font is expanded with \expandglyphsinfont
>>> or via the luaotfload interface).
>>
>> kerns are normally quite small so you will not really notice it and it
>> being a backend related property the log will not report expansion 
>> factors
> 
> I'm aware that all things microtype are "quite small", so I don't trust 
> my eyes but look into the log file. And there I find for example a kern 
> of -0.56 between "v" and "a" regardless of whether \adjustspacing is set 
> to 2 or 3.
> Or are you suggesting that the reported kern of -0.56 isn't actually a 
> kern of -0.56? Still, even with ridiculously large expansion limits (500 
> 500), I don't see any difference whatsoever. And the uncompressed pdf is 
> also 100% the same (which would reveal a difference of 0.01bp).

Indeed the expansion is not reported. The kern value is unchanged but 
there is an additional kern (factor) traveling with the kern node which 
will be dealt with in the backend.

If you see no difference in the pdf file, then there is an issue inm the 
macros or font related code.

Anyway, I can only speak for context, so what I observe is not what you 
observe (others have to check that).

>> in your font definition below you don't enable kerns anyway (unless
>> luaotfload does that automatically for you)
> 
> Yes, luaotfload enables kerns by default.
> 
>>> So it seems that the former "compatibility" level 1 (same line breaks
>>> as without expansion), which according to the manual should no longer
>>> exist, still does; while the new level 3 does not (all the kerns are
>>> the same as for level 2). Could somebody explain this?
> 
>> 0: nothing
>> 1: glyphs and kerns  (only stretch/shrink)
>> 2: glyphs and kerns  (also in par builder)
>> 3: glyphs            (also in par builder)
> 
> So the compatibility level 1 still exists. This is not mentioned in the 
> manual. Level 3 continues to escape me.

Level 1 is rather useless .. (it was part of experiments when pdftex 
evolved) and by not mentioning it we hope that it will not be used (we 
might remove all traces some day). Level 3 makes sense in some cases 
(and is also handy for testing).

So, in your case: just stick to level 2.

>>> Secondly, I wonder about the status of the "autoexpand" qualifier to
>>> \expandglyphsinfont. AFAICT it is silently ignored, and fonts are
>>> always autoexpanded. Is this correct? Or would it still be possible to
>>> use pre-expanded font instances (say, from a MM font)?
>>
>> it all depends on what magic you rmacro package does ... the \expand..
>> command works when no expansion has been set yet, otherwise you need to
>> pass values (and it depends in your case what 'default' does)
>>  When I test the adjustments here it looks ok (it works).
> 
> Sorry, I don't understand what you're saying. It's not about my macro 
> package or any magic. What I meant is that in pdftex, there is a 
> difference between
> 
> | \pdffontexpand\font 20 20 5 autoexpand
> 
> and
> 
> | \pdffontexpand\font 20 20 5
> 
> The latter requires pre-generated expanded font instances, which are 
> then used and embedded in the pdf.
> With luatex, however, there is no difference between
> 
> | \expandglyphsinfont 20 20 5 autoexpand
> 
> and
> 
> | \expandglyphsinfont 20 20 5

Because we don't have pre-generated (copies of) fonts at all, the 
implementation in luatex is using factors stored with the glyphs (so 
there is no need for copies of fonts cq. faked copies) and in the 
backend a different model of scaling fonts is used, so it's unlikely 
that expansion in pdftex generates the same streams as in luatex.

(In pdftex a complication is that fonts are shared by the engine which 
makes expansion also shared which in turn can have surprising effects 
and that's why some copying mechanism was needed. In luatex each font is 
unique.)

> Existing expanded font instances are ignored, and only the base font is 
> embedded in the pdf. Expansion seems to be calculated mechanically and 
> linearly instead of taking into account the width axis of a Multiple 
> Master font.
There is no support for multiple masters which is obsolete technology 
and (recently) has been cq. is being replaced by variable fonts.

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