ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Taco Hoekwater <taco@elvenkind.com>
Subject: Re: ConTeXt on Debian: The wiki entry
Date: Mon, 23 Oct 2006 20:15:54 +0200	[thread overview]
Message-ID: <453D06DA.6010108@elvenkind.com> (raw)
In-Reply-To: <86ejszntvv.fsf@alhambra.kuesterei.ch>

Frank Küster wrote:
> 
>>>- Is it intended that context formats end up in $TEXMF/web2c/pdfetex/?
>>>  If yes, why is that so?  If not, we should rather find out why it
>>>  happens and fix it.
>>
>>Yes, it is. ConTeXt does not support only pdfetex, but all major
>>engines, like XeTeX and Aleph. I have formats in:
>>	
>>   $TEXMF/web2c/aleph/
>>   $TEXMF/web2c/luatex/
>>   $TEXMF/web2c/pdfetex/
>>   $TEXMF/web2c/xetex/
> 
> Ah, okay, that's clear.  Has this already been this way one year ago
> when texlive2005 was released?  Do you know whether the TeXlive
> developers are aware of that?

Yes, it was, Yes, 'they' were aware, and no, 'they' did not want to
fix fmtutil. 'They' only dropped the separate format extensions and
then decided that implementing a replacement was too much effort.

>>>- Why does it make a difference if the formats are created by fmtutil
>>>  instead of texexec (Except for the output directory)?  Should the
>>>  upstream packaging be changed so that fmtutil is never used, but
>>>  texexec, or should fmtutil be fixed to produce the same as texexec?  
>>
>>It is almost certainly better to ignore/block fmtutil and use texexec
>>instead. Properly setting up a ConTeXt update is not necesarily limited
>>to format generation only.
> 
> Hm.  What are the other things that need to be done?

Nothing at the moment, AFAIK. But potentially lots of things.

For instance: the next version of context will support non-kpathsea
file searching, so it will have to initialize its database somewhere.
It may want to/have to delete obsolete files  and/or merge local
configuration files with new released version. Or precompile patterns
files or lua scripts, strip and optimize source files, and perhaps
generate font metrics in one format or another.

ConTeXt comes with its own font map files, so there is no real
reason to fix updmap but if you want to the main problem is this:
you have to extend it so that it does not treat dvips and pdftex
map files as identical.


> To me, as a TeXlive and teTeX guy, it seems preferrable to choose option
> 1 and fix the existing distribution scripts.  However, I don't know yet
> what else is needed when ConTeXt is updated, therefore I might be wrong,
> and switching to texexec might actually be better.  But then this should
> be done consistently, and fmtutil should drop context handling
> completely (or just call texexec).

I am very much in favor of using texexec for everything related to
ConTeXt.

Greetings, Taco

  reply	other threads:[~2006-10-23 18:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-23  8:35 Frank Küster
2006-10-23 10:25 ` Renaud AUBIN
2006-10-23 10:58 ` Taco Hoekwater
2006-10-23 11:39   ` Frank Küster
2006-10-23 18:15     ` Taco Hoekwater [this message]
2006-10-23 19:01       ` Frank Küster
2006-10-24  7:22         ` Taco Hoekwater
2006-10-24  8:24           ` Frank Küster
2006-10-24  8:57             ` Hans Hagen
2006-10-24  8:57             ` Taco Hoekwater
2006-11-01 21:30           ` ctxtools unix puzzles plink
2006-11-01 22:13             ` Hans Hagen
2006-12-25 23:54             ` mkiv files plink
2006-10-25 13:37     ` ConTeXt on Debian: The wiki entry Hans Hagen
2006-10-23 20:47 ` Sanjoy Mahajan
2006-10-23 21:48   ` Hans Hagen
2006-10-24  5:53     ` Frank Küster
2006-10-24  8:18       ` Hans Hagen
2006-10-24  9:01         ` Frank Küster
2006-10-24 11:33           ` Hans Hagen
2006-10-24 13:34             ` Frank Küster
2006-10-24 14:33               ` Hans Hagen
2006-10-25  6:52 ` Gerhard Kugler
2006-10-25  8:55   ` Frank Küster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=453D06DA.6010108@elvenkind.com \
    --to=taco@elvenkind.com \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).