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