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