[tex-live] [luatex] lltxplatform integration

Élie Roux elie.roux at telecom-bretagne.eu
Fri Jun 5 08:56:07 CEST 2015

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

> 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,

More information about the tex-live mailing list