Closed wspr closed 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
.
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
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.
@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?
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.
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.
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...
since can't that be detected by the fact that the engine in use is
luahbtex
? So if we assume thatmode=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.
Newer LuaTeX/luaotfload features use more
mode=
settings. Need to re-think the interface...