[tex-live] [luatex] lltxplatform integration

[Élie Roux]

Le 05/06/2015 02:57, Hans Hagen a écrit :
> Speaking for context, I am not that interested in fonts that are 
> installed in fuzzy locations. When I use font from the system (which 
> is rare) I copy it to the tex/texmf-fonts tree of context so that I 
> can be sure that it only changes when I want that. When I need fonts 
> for a project I tend to buy the official versions (often one can
> then use some 5 copies on different machines i.e. other operating 
> systems). I make sure that my stuff works on windows (that I use on 
> workstations) as well as linux (on the servers that we use for 
> running services).

I understand your workflow, but I also understand why users would want
installed fonts to work as the fonts in C:\\Windows\Fonts (the confusing
part is that these fonts actually appear in C:\\Winows\Fonts in the
Windows explorer, even though they're not actually here).

>> The second is already forbidden by shell_escape_commands (which is
>>  good), and if you forbid the first one, this means that users
>> will never be able to have all their fonts found by TeX.
> 
> Afaik users can configure what programs can run.

For shell_escape_commands yes, I think this could be extended to dso,
instead of just a on/off switch.

> In fact, we might make some of the current modules dynamic loaded.

Ok, so having a big switch off by default for dso is thus excluded, as
this means LuaTeX would be unusable in the future...

> (2) Context will never rely on extra modules. There might be support 
> for some (e.g. there is some support for mysql and so) but those are 
> not needed for regular typesetting.

Ok good

> (3) What works for context also can work or other macro packages, but
> the way things get integrated can differ. So, what works in context
> might not work in latex or plain and vice versa. The choice for
> swiglib means that we stick to the original apis but can write macro
> package specific wrappers around it.

The main point here I think is distribution: in the future, how will
ConTeXt ship dso? When will they be released, etc. will
they be included in snapshots, or will there be some kind of package
manager?

> we already have an infrastructure for compiling for years and 
> swiglibs will be part of it (given demand) .. this is also handy for 
> testing luatex betas (and i'm no too interested in spending time on 
> making sure all we do also works in whatever macro package)

This is precisely the point: what about things you're not interested in?
(harfbuzz, lualatex-platform, etc.) Does it mean only you will choose
the dso present in ConTeXt and thus in TeXLive, or is there a
possibility to add a dso in TeXLive that is not in ConTeXt?

> but the reference is always the yearly tl distribution (and it is 
> unlikely that context expects tex live to ship extra libraries fo 
> rits usage)

So I think the main questions are:

- can dso run in TeXLive's "luatex" command?
- if so, what restrictions? how to compile the libraries so that they
respect openout_any, etc.?
- how are the dso compiled and distributed? Provided as binaries by
ConTeXt (preventing inclusions of dso that ConTeXt is not interested in)
or compiled by TeXLive?

Thank you,
-- 
Elie