[tex-k] dvipsk

[Peter Breitenlohner]

On Wed, 26 Jan 2005, Tomas G. Rokicki wrote:

>> In the Omega mode, tfm can be nonexistent, and search() should
>> return NULL silently in order to search for ofm next,
>> without calling mktextfm which always fails in the case
>> where ofm is used. Thus kpse_find_file should first be called
>> with mustexistflag=false.
>
>> side effect:
>> In the Omega mode (default), mktextfm is never called.
>> If one wants to call mktextfm, one must invoke
>> with -noomega option.
>
> Oops.  I'm sure that's gonna break something.  What do we do?

I'm not quite sure what this discussion is about. Is this a problem raised
by merging dvipsk and odvipsk into one binary, or did it exist before.

Unless we (or rather I) have messed up something in the recent
modifications, the two programs
 	A	old dvipsk
 	B	new dvipsk with "-noomega"
behave identical, and the same should be true for
 	C	old odvipsk
 	D	new dvipsk without "-noomega"

There should be absolutely no difference between A<=>B, and the only
differences between C<=>D I can imagine occurs if texmf.cnf (or the
environment) assigns different values to MKTEXxxx.dvips and MKTEXxxx.odvips.

I see three and only three differences between B and D:

(1) If a tfm file is not found in tfmpath, then D will try for an ofm file
in ofmpath whereas B will not, and finally both will try cmr10.tfm.

In each step the program will or will not try to generate a file according to
MKTEXxxx (and some flags used when calling search()).

My impression was that with the default setup (o)dvipsk at present doesn't
try to generate tfm/ofm files but I might be wrong.

(2) If a vf file is not found in vfpath, then D will try in ovfpath whereas B
will not.

(3) B will reject ofm files found as *.tfm in tfmpath as well as vf files
with charcodes >255 found in vfpath.

NB: I have some doubts about the usfulness to create tfm/ofm files from
within dvips od xdvi.

regards
Peter Breitenlohner <peb at mppmu.mpg.de>