On Tuesday 02 July 2002 12:18 pm, David Kastrup wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> > On Tuesday 02 July 2002 11:06 am, Andre Poenitz wrote:
> > > > I've tried to define a converter that can be used by both the batch
> > > > processor and by the image loader. Ie, it'll work for both multiple
> > > > and single images.
> > >
> > > Fine.
> >
> > Hmmm. Here "gs" seems very slow now that is has the color info to
> > deal with.
>
> Unlikely. I rather suspect antialiasing. You can reduce the
> -dTextAlphaBits value to 2 for a somewhat better performance at some
> loss of quality. Leaving it off will make the stuff definitely more
> ugly, though, albeit quite faster.
Of course the advantage of moving all this into an external script is that
people can modify it at will.
> > It'd be nice if dvipng could deal with this direct since it's this final
> > ps->bitmap step that is expensive.
>
> dvipng works with colors and antialiasing, and it is very fast as
> compared to GhostScript according to its main author Jan-Åke. I am
> really mad at not yet having the preview-latex infrastructure
> finished for making use of it. Only problem up to now is that it has
> just integral shrink factors, but once I have got it in, I will take
> a stab of changing this, too.
I guess that the "ideal" is to move the color definition stuff into
preview.sty as you suggest, so that thereafter it "just works" with either
dvipng or dvips -> gs -sDEVICE=pnm.
> > Because math-macros are dumped into the LaTeX file after the
> > begin{document}. Why is that?
>
> Uh, good question. Why would that be?
Lord knows! But in practice it's not a problem since we can iterate over the
buffer to extract these insets very easily. See the prototype code I posted
in a separate mail.
Angus
