luaotfload/graphics/etc. merging upstream

[kberry]

I hope the LaTeX people will accept the necessary changes for luaotfload.sty, graphics.cfg, etc. I couldn't add modified files by the same names as the canonical LaTeX ones into TL...

[kberry]

Will xdvipsk be usable without these changes? I'm guessing not. In which case it would be good to submit the changes to ltx sooner rather than later, since it will surely take some time for them to be integrated.

Realistically, I'm guessing we can't expect xdvipsk to be functional at the initial release of TL26. We can include the binaries, but it seems like it will take longer for all the support files to happen. Do you agree? Just wanting to set user expectations ...

[sigto]

It appears that the xdvipsk functionality with the xdvipsk-support packages will be quite complete at TL26.
In some cases, non-standard font glyph names and encodings could cause Unicode glyph mapping to be missed.
To solve these extra Lua maps, font encodings are required. Some optimisation to the current functionality implementation is needed before distributing it to TL26. .

[sigto]

The latest update (svn#78054) precompiles glyph maps (for non-standard names) fonts in binary, making the xdvipsk distribution complete. So, it contains:

• xdvipsk binary;
• texmf-dist/dvips/xdvipsk/xdvipsk-cid.pro (PostScript header);
• texmf-dist/tex/lualatex/xdvipsk-support/ (xdvipsk support lualatex package);
  • xdvipsk-support.sty
  • xdvipsk.def
  • xdvipskmaps.sty
  • xdvipskmaps.lua
• texmf-dist/doc/man/man1/xdvipsk.1 (man page)
• texmf-dist/doc/lualatex/xdvipsk-support/README.md (docs)

These settings are necessary for proper support of Open Type fonts from the user’s perspective:

• texmf-config/tex/luatex/luaotfload/luaotfload.conf
  [run]
  default-dvi-driver = xdvipsk
• use --shell-escape in compilations (to enable creating a folder in the output directory).

More information, examples, etc. would be available at:
https://github.com/vtex-soft/xdvipsk.git

[kberry]

- use --shell-escape in compilations (to enable creating a folder in the output directory). It all sounds good. The need to use --shell-escape is a big (and dangerous) hammer for a small job, though. If the user creates a directory beforehand, can --shell-escape be avoided? If so, that would be good to document. --thanks, karl.

[sigto]

If the user creates a directory beforehand, can --shell-escape be avoided?

It seems that writing outside the output directory is forbidden, so creating a directory beforehand won’t help.
I should investigate further, but it’s likely that such a state will remain in the upcoming TL2026 distro.

OpenType fonts with gid encoding can be used in dvi files, which already solves the issue from xdvipsk’s side. In that case, the additional .xdvipsk directory isn’t used. In the compilation of the tex file xdvipsk-support package otfgidxoption should be used. Currently, there’s no way to create such a dvi file for the current or upcoming standard TL distro. There are two options:

• modify frozen LuaTeX engine;
• implement new driver functionality in the luaotfload package (less efficient in my mind).

I don’t think it can be solved quickly. In both cases, it’s a lack of time.

If it makes sense, I can provide the necessary patches and precompiled binaries for LuaTeX to review. I completely understand Hans’s decision to keep LuaTeX frozen, so I won’t exert any pressure on him. We’re currently using a modified LuaTeX from TL2024 and I plan to adapt the modifications from TL2026 in a week.
The second option is more theoretical because I don’t have a practical implementation. I think it’s less efficient than modifying LuaTeX but it could still work.

[kberry]

It seems that writing outside the output directory is forbidden, Yes, that's correct. I was imagining a subdir of the document's directory where the files could be written. What kind of files are getting created? If they're supposed to be system-wide, I guess that wouldn't help. I don't think it can be solved quickly. Fully agreed. - modify frozen LuaTeX engine; It's not frozen in the sense of no changes, the way tex.web is frozen. There was a long list of bug fixes and a couple new(ish) features this year, as there is every year. If it makes sense, I can provide the necessary patches and precompiled binaries for LuaTeX to review. I think it does. My suggestion would be to first email luigi.scarso at gmail with the proposed changes. Might as well cc me although I'm unlikely to have anything useful to say. The other thing that could help me, Luigi, and Hans understand is an runnable example document + the commands to process it (that succeed with your changes), so we can see what's actually being enable. Definitely good to let this lie fallow until after TL26 is released. Thanks for all, Karl

[sigto]

Let’s go a bit slower. I will try to make some informative minimal examples,
and I’ll share some suggestions for modifying LuaTeX.
Regards,
Sigitas