Re: apsfilter 5.4.2 bugs'n'stuff

["Michael Loin" <losse@xxxxxxxxxxxxxxx>]

Matej Vela wrote:
> On Tue, May 02, 2000 at 12:30:53PM +0200, Michael Lossin wrote:
> > * For a local printer, $PRINT_REDIR is not set, so print_data
> > and print_ascii_recode end in void (which most probably is the
> > wrong destination). It should be:
> > [...]
> > I don't know what should happen in print_data... any hints?
> 
> I'm sorry, I didn't understand this?

What I meant was: should the pipe end in "print_raw" or just
"$PRINT_REDIR"? (print_raw should be alright, I guess...)

> > my uniprint profiles for the Epson Stylus Color 640 (there are six
> > of them, hi/med/lo for color and grayscale). I've uploaded them to
> >
> > http://www.geocities.com/BourbonStreet/6789/download/stc640upp.tgz
> 
> I hope you sent them to the authors of Ghostscript too?  I've included
> the profiles, but they don't really belong in apsfilter.

I'll do that, but hell knows when the next release will be out :-\


Here are some other thoughts I had:

* Why is apsfilter relying on the filters_found file? Wouldn't it be
simpler to check for the programs at run-time?
(change  'if [ -n "$HAVE_xyz" ]' to 'if which >/dev/null xyz')
Of course it would be uglier, but WTF... No need to re-run the filter
setup every time.

* (CVS version only) Using acroread in a pipeline results in a /tmp file
left after the script has ended (the "-pairs" construction with two
temporary files is needed).

* I suggested the use of "convert" for various bitmap (and other)
formats. Has anyone done serious comparison of the output quality to
the one generated by "...topnm | pnmtops"? (IMHO it really depends on
the input file.)

* 'This may uglify the source' (TM), but mpage is a tool similar to a2ps,
wouldn't it be nice... *ouch* Don't hit me! :)


Happy filtering
Michael