A possibility to change the configuration value after load

[sigto]

Is it possible to change the configuration default-dvi-driver value from run section after luaotfload is loaded during the run?

[zauguin]

What would be the usecase for this? You can always set the driver while loading the font and if you want ti change thevfmdriver you probably have to reload all fonts anyway.

[sigto]

Maybe I missed something, but what about this sample case. Let say we have a document test.tex:

%%\RequirePackage[otfgid]{luafontmaps}
\documentclass{article}\begin{document}Hello world!\end{document}

Compile it: dvilualatex test.tex
As luaotfload is loading automatically dvisvgm driver will be used by default.
If I want to compile the same file with xdvipsk driver I should load other configuration luaotfload.conf file.
Am I wrong?
The usecase could be to change driver in some package with default configuration file loaded:

\RequirePackage[otfgid]{luafontmaps}
\documentclass{article}\begin{document}Hello world!\end{document}

Compile it: dvilualatex test.tex using xdvipsk driver.
So, some lua command config.lauotfload.reconfigure.run.default_dvi_driver = xdvipsk would be fine.

[zauguin]

As luaotfload is loading automatically dvisvgm driver will be used by default.
If I want to compile the same file with xdvipsk driver I should load other configuration luaotfload.conf file.

That is accurate. Alternatively you could explicitly load new fonts with the changed DVI backend.

The usecase could be to change driver in some package with default configuration file loaded:

But why do you want to use the default configuration file here? My base assumption would be that the compiler backend used is more of a system question than a document question. I would expect different people to compile the same document with different backends, while compiling different documents with different backends on the same system seems much weirder.

Anyway if you want to change the default-dvi-driver after loading you can use

\directlua{ fonts.constructors.features.otf.defaults.dvifont = 'whatever' }

HIC SVNT LEONES: This will probably work at the very start of a document, but if you did anything else before it depends on details of when fonts get initialized which fonts this applies to.

[sigto]

But why do you want to use the default configuration file here? My base assumption would be that the compiler backend used is more of a system question than a document question. I would expect different people to compile the same document with different backends, while compiling different documents with different backends on the same system seems much weirder.

The default configuration file is used for all users in every compilation. To use another driver, you must change the system configuration. A more flexible way would be to control it through a LaTeX/Lua package.

Anyway if you want to change the default-dvi-driver after loading you can use

\directlua{ fonts.constructors.features.otf.defaults.dvifont = 'whatever' }

It doesn't work with xdvipsk driver which uses tex native encoding or OpenType font gid's directly without any modification.

HIC SVNT LEONES: This will probably work at the very start of a document, but if you did anything else before it depends on details of when fonts get initialized which fonts this applies to.

It’s understandable and acceptable if it only works at the beginning of the document.

[zauguin]

The default configuration file is used for all users in every compilation. To use another driver, you must change the system configuration. A more flexible way would be to control it through a LaTeX/Lua package.

Or you can put it into a user specific directory. Or put it next to the TeX file to only affect one folder, ....

Anyway if you want to change the default-dvi-driver after loading you can use

\directlua{ fonts.constructors.features.otf.defaults.dvifont = 'whatever' }

It doesn't work with xdvipsk driver which uses tex native encoding or OpenType font gid's directly without any modification.

That's weird, when trying

\directlua{
  fonts.constructors.features.otf.defaults.dvifont = 'xdvipsk'
}
\documentclass{article}\begin{document}Hello world!\end{document}

it works for me.

[zauguin]

It doesn't work with xdvipsk driver which uses tex native encoding or OpenType font gid's directly without any modification.

Not that it matters for this discussion, but OpenType font gids are used by the dvisvgm driver and are explicitly not used by the xdvipsk driver which uses luaotfload specific internal encodings instead.

[sigto]

That's weird, when trying

\directlua{
  fonts.constructors.features.otf.defaults.dvifont = 'xdvipsk'
}
\documentclass{article}\begin{document}Hello world!\end{document}

it works for me.

This simple case works well, but more complex ones fail. The dvisvgm driver sometimes changes the internal font name, which causes problems.

[sigto]

Not that it matters for this discussion, but OpenType font gids are used by the dvisvgm driver and are explicitly not used by the xdvipsk driver which uses luaotfload specific internal encodings instead.

xdvipsk can operate in two modes: internal TeX encoding and OpenType font gids (written directly to the DVI file by the modified LuaTeX engine). In both cases, no modifications are made to the internal font stuff (except for the gid writes to the DVI file).

[sigto]

Let’s freeze our discussions and wait for xdvipsk to be in TeXLive. Users might find working with different configurations acceptable.
Thanks for your time on this question.

[zauguin]

\directlua{
fonts.constructors.features.otf.defaults.dvifont = 'xdvipsk'
}
\documentclass{article}\begin{document}Hello world!\end{document}

This simple case works well, but more complex ones fail. The dvisvgm driver sometimes changes the internal font name, which causes problems.

Please show an example where this fails. Setting this is exactly the same as changing the driver, so if you run this early enough you get exactly the same as changing the driver.

If we ever would add an interface to change the driver we would not do anything different at the end.

[sigto]

Please show an example where this fails. Setting this is exactly the same as changing the driver, so if you run this early enough you get exactly the same as changing the driver.

Example can be taken from:
https://github.com/vtex-soft/xdvipsk/tree/main/Build/source/texk/xdvipsk/testdata/opentype

If we ever would add an interface to change the driver we would not do anything different at the end.

It seems that construction below is ok.

\directlua{%
    fonts.constructors.features.otf.defaults.dvifont = 'xdvipsk';%
    if luatexbase.in_callback('pre_shipout_filter', 'luaotfload.dvi') then
       luatexbase.remove_from_callback('pre_shipout_filter', 'luaotfload.dvi')
    end
    }
\documentclass{article}\begin{document}Hello world!\end{document}

Thanks for the help. I can use this solution without changing the luaotfload bundle,
if it doesn’t cause any more unexpected behaviours with the documents
and 'luaotfload.dvi' callback won't be registered later.

[zauguin]

Example can be taken from:
https://github.com/vtex-soft/xdvipsk/tree/main/Build/source/texk/xdvipsk/testdata/opentype

That example does not include the fonts.constructors.features.otf.defaults.dvifont setting so I don't see how it can demonstrate it not working.

It seems that construction below is ok.

If you have to remove the callback, then that indicates that the callback is already set. This implies that you are setting this too late and a font has already been loaded. Therefore your construction will lead to a incorrectly changed fontname in the output.

Anyway closing here since I can't help analyze issues without a demonstration of the issue.