latex3 / fontspec

Font selection in LaTeX for XeTeX and LuaTeX
http://latex3.github.io/fontspec/
LaTeX Project Public License v1.3c
276 stars 33 forks source link

New interface to `mode=x` #342

Closed wspr closed 5 years ago

wspr commented 5 years ago

Newer LuaTeX/luaotfload features use more mode= settings. Need to re-think the interface...

u-fischer commented 5 years ago

Some details about what is needed:

mode=XYZ allows to use a custom font reader/shaper. It works by calling a fonts.readers.XYZ function which then does the hard job. Currently we have as mode basic, node, harf (in luahbtex-harf) and plain (only as small example somewhere in luaotfload github). But it is possible to create more.

So some code is needed to declare a new mode XYZ, and to call it so that it is used instead of mode=node. For the second part I'm currently using

\ExplSyntaxOn
\keys_define:nn {fontspec-renderer}
 {
  Renderer / harf .code:n =
   {
      \tl_set:Nx \l_fontspec_mode_tl {harf}
      \tl_gset:Nx \g__fontspec_single_feat_tl { mode=harf }
   }
 }

\ExplSyntaxOff

Beside this such a font reader perhaps wants to pass more info. In the special case of the harf reader, Khaled would like to pass AAT/Graphite etc to the underlying harfbuzz e.g. as mode=harf;shaper=AAT.

wspr commented 5 years ago

Thanks Ulrike, the extra detail is great. Are there an arbitrary number of options like shaper or is it a well-defined set for the time being? If arbitrary we could fall back on something like

Harfbuzz  % → `mode=harf`
Harfbuzz = {shaper=AAT}  % → mode=harf;shaper=AAT

If there's only one or two I'd be inclined to have

Renderer = Harfbuzz, Shaper = AAT

or if there is only shaper then even more abbreviated like

Renderer = Harfbuzz : AAT
khaledhosny commented 5 years ago

The list of shapers is not fixed. Currently HarfBuzz supports ot, coretext_aat, graphite2 and fallback, and might add default and aat in the near future, and who knows what would happen long term. So I’d rather we have an interface that can be easily extended in the future. Note that the shapers are more or less the same thing as the /OT, /AAT and /GR font modifiers that XeTeX supports, so a unified interface for both might be a good ides.

wspr commented 5 years ago

@khaledhosny — I just realised that we shouldn't need something like

Renderer = Harfbuzz

since can't that be detected by the fact that the engine in use is luahbtex ? So if we assume that mode=harf can be automatically picked up, I would propose

Renderer = OpenType
Renderer = AAT
Renderer = Graphite
Renderer = Fallback
Renderer = Default
Renderer = <foo>  % ← uses `shaper=foo`

Is that right, or do we need to differentiate between luaotfload and Harfbuzz even in your forked engine?

khaledhosny commented 5 years ago

Right now luahbtex is for all practical purposes the same as luatex with an additional luaharfbuzz module, so we can’t assume HarfBuzz is used (furthermore, one can build luaharfbuzz and use it with regular luatex. But I think the following mapping should work and is still backward compatible:

Renderer = Node     % mode=node
Renderer = Base     % mode=base
Renderer = HarfBuzz % mode=harf
Renderer = OpenType % mode=harf,shaper=ot
Renderer = AAT      % mode=harf,shaper=coretext_aat
Renderer = Graphite % mode=harf,shaper=graphite2
Renderer = <foo>    % mode=harf,shaper=foo

If we want to automatically detect if HarfBuzz can be used and enable it, then I probably need to turn luahbtex-harf into a proper LaTeX package and provide, say, an \ifharfbuzz check that can be used to conditionally turn on HarfBuzz support. The package would be responsible for checking the presence of luaharfbuzz module and gracefully handle its absence.

khaledhosny commented 5 years ago

Also, related to this. Even if \defaultfontfeatures{Renderer=harf} is used (with @u-fischer code above), fontspec still seems to make many font definition calls without using mode=harf (see https://github.com/khaledhosny/luahbtex-harf/issues/30) and I think we need to make sure the mode is always passed.

wspr commented 5 years ago

I’ve pushed code for the Renderer but not yet looked into all of the “trial” font loading code. That might take me a little longer to get around to, sorry...

u-fischer commented 5 years ago

since can't that be detected by the fact that the engine in use is luahbtex ? So if we assume that mode=harf can be automatically picked up, ...

even if the engine is luahbtex we can't assume that every font should be loaded in this mode.