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
