<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 25, 2021 at 4:03 PM Sergio Callegari <<a href="mailto:sergio.callegari@gmail.com">sergio.callegari@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 23 Apr 2021 09:57:13 +0200 luigi.scarso at <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a> (luigi <br>
scarso) wrote:<br>
<br>
> On Fri, Apr 23, 2021 at 9:48 AM Sergio Callegari <sergio.callegari at <br>
> <a href="http://unibo.it" rel="noreferrer" target="_blank">unibo.it</a>><br>
> wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > I have noticed that luatex now supports variable fonts and I've started<br>
> > experimenting. I am asking a question here but I am unsure if it is<br>
> > actually tied to luatex or luaotfload or maybe fontspec. In case, please<br>
> > be so kind to address me to the correct forum.<br>
> ><br>
> ><br>
> hm, luatex and luahbtex don't support variable fonts directly,<br>
> it's a matter of the format (latex,  context, optex... ) .<br>
Thanks for providing this info. Can you be so kind to expand a little, <br>
as there are still a couple of things that are not 100% clear to me?<br>
<br>
- Common widom found on the net is that variable fonts work only with <br>
the LuaTeX engine, no others and that this become possible only with <br>
LuaTex 1.13. As a matter of fact, xeTeX works without an hiccup on the <br>
file, but after it it is impossible to make a PDF because dvipdfmx <br>
reports "invalid font" . This suggests that the engine and specific the <br>
part of it responsible for the PDF generation plays a role. The only <br>
item that comes to my mind given the situation is lua. If so, would it <br>
be luaotfload the upstream to ask the question to?<br>
<br></blockquote><div><br></div><div>yes</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- The errors reported when attempting to use variable fonts appear to <br>
happen /after/ the format and the tex machinery has completed its work, <br>
that is after the:<br>
<br>
  406 words of node memory still in use:<br>
    3 hlist, 1 vlist, 1 rule, 2 glue, 3 kern, 1 glyph, 4 attribute, 48 <br>
glue_spec<br>
, 4 attribute_list, 1 write nodes<br>
    avail lists: 2:17,3:4,4:1,5:28,6:2,7:116,9:14<br>
<br>
What appears to fail is the step following this one, that is the PDF <br>
generation. This looks consistent with what happens in xetex. But if I <br>
am correct, in both pdftex and luatex the pdf generation is unseparable <br>
from the engine, apart from the role of luaotfload...<br>
<br>
Any suggestion?<br>
<br></blockquote><div><br></div><div></div><div>LuaTeX has  a pdf and dvi backend (as pdfTeX) and a native management of "traditional"</div><div>postscript / truetype /opentype fonts -- but not the font variations.</div><div>"Variable fonts" are managed by the format which, basically create an instance of a "traditional"  font</div><div>from the values of the axes --- this is possible because LuaTeX has the concept of "virtual" font, see</div><div><a href="https://www.tug.org/svn/texlive/trunk/Master/texmf-dist/doc/luatex/base/luatex.pdf?view=log">https://www.tug.org/svn/texlive/trunk/Master/texmf-dist/doc/luatex/base/luatex.pdf?view=log</a><br></div><div><br></div><div>The first implementation (in ConTeXt) was in 2017:</div></div><div><a href="http://www.gust.org.pl/bachotex/2017-pl/presentations/hhagen-2-2017.pdf">http://www.gust.org.pl/bachotex/2017-pl/presentations/hhagen-2-2017.pdf</a><br></div><div><a href="https://www.tug.org/TUGboat/tb38-2/tb119hagen-variable.pdf">https://www.tug.org/TUGboat/tb38-2/tb119hagen-variable.pdf</a><br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">luigi<br></div></div>