Open vlasakm opened 3 years ago
Either we provide the ConTeXt code with allocator for attributes (current solution) or reserve the first 256 attributes for it.
I also found the defintion of XeTeX \font
syntax, it turns out I somewhat confused "
with [
:
The ⟨font identifier⟩ is the only mandatory part of the above syntax. If it is given in square brackets, (e.g., \font\1="[lmroman10-regular]"), it is taken as a font file name. Without brackets, the name is looked up as both a file name and a system font name.
I was wrong even in the ConTeXt case, \font=name
does font name with file name fallback. I currently let the font name lookup automatically fail, so that file names are forced.
Hm, maybe we could even \fontfam[lmfonts]
by default?
With hot caches, the following (simulating \fontfam[lmfonts]
in \everyjob
):
\fontfam[lm]
\fontfam[heros]
test
\bye
Is:
Time (mean ± σ): 127.0 ms ± 0.8 ms [User: 108.8 ms, System: 17.9 ms]
Range (min … max): 125.7 ms … 128.9 ms 23 runs
(\fontfam[lm]
itself is about ~0.075
.)
Compared to the situation without any \fontfam[lm]
, but with slow luaotfload loading:
Time (mean ± σ): 217.1 ms ± 0.8 ms [User: 173.9 ms, System: 42.8 ms]
Range (min … max): 216.1 ms … 218.6 ms 13 runs
With some complexity, the opentype fonts could even be preloaded too, but I don't know about that. Now they are just read from cache. Also automatically doing \fontfam[lm]
means that the fonts have to be installed and present during the run, but same situation is with the currently preloaded fonts.
We've talked about it before. It would be fine to leave the dependency on luaotfload, but:
We've talked about it before. It would be fine to leave the dependency on luaotfload, but:
* the luaotfload developers extract fontloader from Context in its actual version and add new features. They do it continuously in time. If we throw away the luaotfload then we must to do this work ourself.
We would need to emulate a few features if we need them. Extracting the font loader code is almost a matter of copying two files. Actually testing that the extracted stuff is working correctly is the hard part. The luaotfload
people do that.
I actually think that for both testing the font loader and other OpTeX macros for regressions and other things, a test suite could be considered and users should be encouraged to contribute. Maybe a topic for "Github Discussions"?
* some features (like finding font by its name, no file name, XeTeX syntax) should be kept. There are many internet texts about "how to load a ned OTF font" and these instructions should work in OpTeX too (after \initunifonts, of course).
XeTeX syntax will work without problems.
* We don't want to put OpTeX dependency to whole Context package.
Agreed, but the files will have to be available somehow. luaotfload
distrubutes them with different names. Either way the files can't be included in OpTeX due to licenses, so they will have to reside in external package.
I actually have a few ideas for the unimplemented areas of https://github.com/olsak/OpTeX/pull/67. Will see how that goes, but IIRC luaotfload
doesn't allow font files with .lua
extension, while the original ConTeX code does, so I thats why I will do the experiments here.
Either way the files can't be included in OpTeX due to licenses, so they will have to reside in external package.
This is most important issue. Suppose that we have such package, say its name is fntloader
. First of all, we need a maintainer of such package. I don't feel like doing it. The maintainer must do:
fntoader
.fntloader
package.This job is done by luaotfload
developers now. So, it seems that such maintainer will do paralell job. The benefit is that we have more simple and straightforward fntloader
package than luaotfload
is.
If the maintainer will stop supporting the fntloader
in future (because he/she will have different interests) then OpTeX will lost the support of main package it depends on it. I see a guarantee that this will never happen with luaotfload
package because there are more developers and LaTeX needs it.
Suppose that we have such package, say its name is
fntloader
. First of all, we need a maintainer of such package. I don't feel like doing it.
I am willing to do it. But as you say there are issues:
- watch all news of ConTeXt's fontloader continuously.
There are two possibilities:
-- Please don't update to this version without proper testing. It might be that this version
-- lags behind stock context and the only formal release takes place around tex live code
-- freeze.
- create a documentation of the
fntloader
package.- upgrade documentation if there is something new.
If the code is taken more or less verbatim, ConTeXt is the documentation for better or for worse.
- add a few features not included in Context's fontloader but used in OpTeX.
Quite a lot is actually already part of ConTeXt. Others should be implemented in OpTeX. The hypothetical external package should not modify / add to the ConTeXt code in any significant way.
This job is done by
luaotfload
developers now. So, it seems that such maintainer will do paralell job. The benefit is that we have more simple and straightforwardfntloader
package thanluaotfload
is.If the maintainer will stop supporting the
fntloader
in future (because he/she will have different interests) then OpTeX will lost the support of main package it depends on it. I see a guarantee that this will never happen withluaotfload
package because there are more developers and LaTeX needs it.
Maybe this can be a joint effort of OpTeX and minim.
Currently OpTeX uses the
luaotfload
package for extending LuaTeX font mechanism through Lua code.luaotfload
is a wrapper that allows use of ConTeXt code in LaTeX and plain, but as ConTeXt'sluatex-plain
format proves, the ConTeXt codes is actually usable directly. In fact, the bulk of the font code is available in just a single file -luatex-fonts-merged.lua
.This PR tries to experiment with using this file (and one or two other) for potential use in OpTeX.
luaotfload
is not just a simple wrapper though. For OpTeX's use case not using it would have the following consequences:harf
mode wouldn't be available (but it was never used anyways, just suggested in documentation)luaotfload
's sophisticated mechanism for maintaining font name database couldn't be used (this includes transparent handling of system fonts)luaotfload
font features wouldn't be available (colored fonts, upper/lower casing, fallback fonts, letterspace, embolden, probably more)But I don't see that as too much problematic:
harf
mode as of now wouldn't really be a lossluaotfload
are duplicates of ConTeXt's, and some are really simple, so this can be fixedAs a benefit we gain:
I am still experimenting with this, but I think it is the right way forward.
There may or may not be speed gain / loss - I think that luaotfload's database can prevent some expensive path searching, but there will be gain upfront in loading the Lua code.
I will have to check the syntax differences between luaotfload and ConTeXt's generic mode in regards to
\font
. But my current understanding is that generally XeTeX way of\font\a=[something]
is first a lookup of font name and not file name. In the generic ConTeXt plain\font\a=something
is a lookup that first tries file name and then font name (which currently doesn't work, because I don't generate any font name database).Anyways, while there may be incompatibilities with the old way that I will have to find out, the ConTeXt way seems very nice, and maybe will allow not differentiating between "tfm" and "unicode" version of some OpTeX macros. Maybe with the code preloaded in the format,
\initunifonts
can even be default. And maybe we will get rid of preloaded fonts :-)There remains the problem of distributing the two or three files.
What do you think of the idea @olsak?