[tex-live] Having a .fmt for different engines
Jonathan Kew
jonathan_kew at sil.org
Sat Jan 6 11:37:29 CET 2007
On 6 Jan 2007, at 9:29 am, Gerben Wierda wrote:
> On Jan 5, 2007, at 19:36, Thomas Esser wrote:
>
>> I see that several people have remembered that I
>> am all against having duplicates in texmf trees. We can't really go
>> without
>> them (e.g. language.dat), but the use of duplicates should only be
>> done
>> for a very good reason.
>>
>> kpathsea has a few tricks that allows us to do this to some extend.
>> But,
>> it all only works if the setup is 100% right and it fails as soon as
>> something is slightly wrong.
>
> In te "me too" category, I want to support Thomas here. I have some
> experience in supporting users and I can tell you that stuff like this
> is a major source of trouble for users. This major source is only made
> even more troublesome because for years there will be outdated and
> wrong instructions flowing around on the web.
>
> My personal preference is a change in ConTeXt.
I'd agree that this is the preferable solution.
While we *could* modify fmtutil, along the lines of the patch I
showed, I absolutely agree that the cost and risk of doing this so
close to TL2006 release is a major concern. And it's difficult to
predict how many complications and support issues may arise "in the
wild".
Given that:
(a) ConTeXt is the only package where this is an issue
(b) it runs tex engines via scripts that have the opportunity to
configure the setup appropriately
(c) users are therefore not directly exposed to the exact name of
the .fmt (or engine) used
I think it would be best for this to be solved by ConTeXt using
engine-specific .fmt names.
JK
PS: About to send, but just seen Taco's message "Don't go blaming
context...". True. It's not a question of figuring out who to blame,
but of looking at the big picture and finding the best way forward
from where we are. I think, on balance, that a change within ConTeXt
would provide the best solution at the least overall cost. Then
fmtutil can maintain the ConTeXt formats alongside others without
other infrastructure changes.
Another option is to do nothing, and let ConTeXt formats be managed
entirely separately from the others. However, I think this will tend
to leave ConTeXt somewhat marginalized in the TeX Live world, which
would be regrettable. I'd like TeX Live to be much more than just
LaTeX Live. :)
More information about the tex-live
mailing list