[tex-k] dvipsk

[Peter Breitenlohner]

On Sat, 15 Jan 2005, Karl Berry wrote:

>    1.  Should I make this change, or someone else?
>
> I had the impression that peb was going to send a patch?
>
> As far as the jpatch-related change in download.c goes, I had the
> impression that Akira's suggestion was the way to go.

Hi Karl, Tom,

I am willing to do that, but I'd need several days to do it right. In fact I
have already started, and as a first step I'm using the Omega way of doing
things for !Omega as well, thereby greatly reducing the number of "#if(n)def
Omega"'s, but not yet changing any functionality and still keeping two
separate programs.

In doing so I had to look very closely at the code and found a few glitches:

e.g.
negative DVI fontnumbers are mishandled (possible segfault).
With "-E" DVI fontnumbers>255 are mishandled as well.
Yes I know such fontnumbers shouldn't occur in normal DVI files, but...
(BTW: xdvik does handle negative DVI fontnumbers).

or
in odvipsk there is no protection against accessing characters
beyond the end of the chardesc array

or
the option parsing in dvips.c has one point that might segfault

or
the present tfm/ofm reading code isn't very defensive against broken
files. E.g., a tfm with ec>255 could easily segfault.

==============

What are the current rules re: mymalloc/xmalloc and realloc/xrealloc?

>    3.  Do we want magic executable-name sniffing to set the flag?  (That
>
> I see no harm in it, but I also don't think it's worth more than, say,
> 10 minutes.  In practice, I can't see that there is any harm to the
> omega stuff always being enabled.

I'd proceed as in xdvik: no dependence on the name of the executable,
the processing is normally as in the present odvipsk, but with a 
commandline switch "-noomega" the Omega extensions are disallowed:
- ofm files
- ovf files (i.e. vf files from ovfpath)
- set2/put2 commands in dvi or vf files
(as is said in the xdvi manpage, that's mainly for the case of extremely
tight memory, or for the case of problems).

regards		Peter