On 6 Aug, Hans Hagen wrote:
> At 11:22 AM 8/6/2001 +0200, [EMAIL PROTECTED] wrote:
>
>>For me, it is a frequent source of confusion when Context does things
>>its own way. Filesearching deviating from kpsewhich filesearch was one
>>example; mapfile loading different from what dvips and pdftex do on
>>their own would be another.
>
> actually, file searching is not that different, since the only filetype
> supported by kpsewhich in tex itself are "tex" and "tfm"; i only block
> system wide searches for certain cases by forcing local searches, an dmost
> can be configured; global searches screw up any project with similar file
> names; context is meant for usage is highly structered projects' if you
> refer to figure inclusion, well this is messy anyway between tex's and apps -)
>
> concerning map files: dvips and pdftex already live in a world on their
> own, also, mapfiles can be highly conflicting [try to include a pdf graphic
> while using the default pdfonts.map and there is a reasonable change that
> you run into troubles due to naming conflicts]; also, many fonts in the map
> files are either not on any system, or in different names, etc etc.
> Actually, pdftex should be capable of using a format specific cfg file.
>
> I try to adapt as much as possible to anything standard, but esp with
> regards to fonts, less is standardized that one wishes, and i want once and
> for all to get rid of missing glyphs depending on what cd i mounted.
>
> Actually, it would already help a lot if mapfiles would be structured,
> properly named, etc
>
> Hans
I am certainly not claiming that things are perfect the way they are,
but I have my own workarounds, and I get along ok with kpsewhich and
mapfiles as they are.
What about letting out-of-the-box pdftex and dvips read the same
mapfiles that they would read outside Context, and letting Context use
kpsewhich for all its file searching, and that any non-standard
behaviour would have to be explicitly turned on in a configuration file?
Siep
