[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  

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.


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