How to mix maths & text in labels ?

Wonderful! this is great news. How have you done it? Have

    > you written a DVI driver? or do you use TeX and associated
    > tools to create a bitmap and put that on the image? Or
    > something else?

For *Agg, we use tex + dvipng and load the output as a transparent,
anti-aliased raster, caching the dvipng output in ~/.tex.cache for
efficiency. For PS, we use tex + dvips + psfrag + latex + a patched
ps2epsi. The latter is cumbersome, but it works. In an ideal world,
we would simply use tex + dvips but embedding the postscript fragments
generated by dvips in arbitrary locations on the figure, but this has
proved challenging.

Having our own dvi parser would be a nice solution. As you noted, the
format isn't too complicated, except for the font handling and the
fact that you need your own bytecode processing engine to extract the
information. We're waiting until Robert Kern has another boring
experiment to site through for this one.

JDH

Hi list

    > Wonderful! this is great news. How have you done it? Have
    > you written a DVI driver? or do you use TeX and associated
    > tools to create a bitmap and put that on the image? Or
    > something else?

For *Agg, we use tex + dvipng and load the output as a transparent,
anti-aliased raster, caching the dvipng output in ~/.tex.cache for
efficiency. For PS, we use tex + dvips + psfrag + latex + a patched
ps2epsi. The latter is cumbersome, but it works. In an ideal world,
we would simply use tex + dvips but embedding the postscript fragments
generated by dvips in arbitrary locations on the figure, but this has
proved challenging.

Have you looked at how PyX (http://pyx.sourceforge.net/) handles things?
They have excellent support for tex/latex labels and it seems to be
implemented in a much "cleaner" way than you describe above. As far as I
can see, they run a single TeX job containing all the strings from the
current plot (see the texrunner class in pyx/text.py) and then parse the
dvi output themselves (see pyx/dvifile.py)

Having our own dvi parser would be a nice solution. As you noted, the
format isn't too complicated, except for the font handling and the
fact that you need your own bytecode processing engine to extract the
information. We're waiting until Robert Kern has another boring
experiment to site through for this one.

Well, PyX is GPLed so I don't see why you couldn't adopt their DVI
parser. One thing you need to bear in mind if you are using TeX to
generate PS output is that the resultant files will probably be
unacceptable to many scientific journals without further processing. The
production staff generally try to open the PS files in Adobe Illustrator
and this causes multiple problems with files generated both by PyX and
by dvips. The solution is to convert all fonts to outlines before
submission (and also make sure all bbox coords are +ve). You can do this
with recent versions of ghostscript:

gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=epswrite -dEPSFitPage \
    -sOutputFile=new.eps old.eps

I suppose I should introduce myself since I haven't posted to this list
before. I've been looking at various python scientific plotting packages
for the last few months. I'm currently using gnuplot (supplemented by
bash or python scripting) for interactive use and quick hacks, together
with PyX for publication-quality output. Matplotlib looks very
interesting since I think it could potentially replace both gnuplot and
PyX. The features it seemed to be lacking the last time I looked in any
detail (v 0.70) were

1. Good, flexible support for reading data from files

2. Publication-quality text handling for math and accented characters
(i.e., full LaTeX support)

It looks like you have now addressed point 2 at least, so I've just
downloaded 0.81alpha from CVS and I'll see how it goes. The big
advantages matplotlib has over PyX in my opinion are a more intuitive
API and a larger/more-active developer pool and user base.
   
Best wishes

Will

···

On Wed, 2005-06-01 at 13:25 -0500, John Hunter wrote:

--
  Dr William Henney, Centro de Radioastronom�a y Astrof�sica,
  Universidad Nacional Aut�noma de M�xico, Campus Morelia

Hi William,

Hi list

>
> > Wonderful! this is great news. How have you done it? Have
> > you written a DVI driver? or do you use TeX and associated
> > tools to create a bitmap and put that on the image? Or
> > something else?
>
> For *Agg, we use tex + dvipng and load the output as a transparent,
> anti-aliased raster, caching the dvipng output in ~/.tex.cache for
> efficiency. For PS, we use tex + dvips + psfrag + latex + a patched
> ps2epsi. The latter is cumbersome, but it works. In an ideal world,
> we would simply use tex + dvips but embedding the postscript fragments
> generated by dvips in arbitrary locations on the figure, but this has
> proved challenging.

Have you looked at how PyX (http://pyx.sourceforge.net/) handles things?
They have excellent support for tex/latex labels and it seems to be
implemented in a much "cleaner" way than you describe above. As far as I
can see, they run a single TeX job containing all the strings from the
current plot (see the texrunner class in pyx/text.py) and then parse the
dvi output themselves (see pyx/dvifile.py)

> Having our own dvi parser would be a nice solution. As you noted, the
> format isn't too complicated, except for the font handling and the
> fact that you need your own bytecode processing engine to extract the
> information. We're waiting until Robert Kern has another boring
> experiment to site through for this one.

Well, PyX is GPLed so I don't see why you couldn't adopt their DVI
parser. One thing you need to bear in mind if you are using TeX to
generate PS output is that the resultant files will probably be
unacceptable to many scientific journals without further processing. The
production staff generally try to open the PS files in Adobe Illustrator
and this causes multiple problems with files generated both by PyX and
by dvips.

Why is this?

The solution is to convert all fonts to outlines before
submission (and also make sure all bbox coords are +ve). You can do this
with recent versions of ghostscript:

gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=epswrite -dEPSFitPage \
    -sOutputFile=new.eps old.eps

Coincidentally, I was just addressing the use of gs's epswrite this morning on
the matplotlib-devel list. Unfortunately, epswrite will yield a file that
does not render well on screen. Given the increasing popularity of online
publication, it seems this approach for generating eps files would not be
acceptable to scientific journals either.

I suppose I should introduce myself since I haven't posted to this list
before. I've been looking at various python scientific plotting packages
for the last few months. I'm currently using gnuplot (supplemented by
bash or python scripting) for interactive use and quick hacks, together
with PyX for publication-quality output. Matplotlib looks very
interesting since I think it could potentially replace both gnuplot and
PyX. The features it seemed to be lacking the last time I looked in any
detail (v 0.70) were

1. Good, flexible support for reading data from files

Could you give an example? In my experience, datafiles tend to get so
complicated that all of Matlabs tools were useless. I end up writing code
specific to every type that isnt as simple as a few comment lines that are
ignored followed by a delimited array of data.

···

On Thursday 02 June 2005 11:49 am, William Henney wrote:

On Wed, 2005-06-01 at 13:25 -0500, John Hunter wrote:

--
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd55@...163...
http://people.ccmr.cornell.edu/~dd55/

William Henney wrote:

Hi list

"Chris" == Chris Barker <Chris.Barker@...259...> writes:

   > Wonderful! this is great news. How have you done it? Have
   > you written a DVI driver? or do you use TeX and associated
   > tools to create a bitmap and put that on the image? Or
   > something else?

For *Agg, we use tex + dvipng and load the output as a transparent,
anti-aliased raster, caching the dvipng output in ~/.tex.cache for
efficiency. For PS, we use tex + dvips + psfrag + latex + a patched
ps2epsi. The latter is cumbersome, but it works. In an ideal world,
we would simply use tex + dvips but embedding the postscript fragments
generated by dvips in arbitrary locations on the figure, but this has
proved challenging.

Have you looked at how PyX (http://pyx.sourceforge.net/) handles things?
They have excellent support for tex/latex labels and it seems to be
implemented in a much "cleaner" way than you describe above. As far as I
can see, they run a single TeX job containing all the strings from the
current plot (see the texrunner class in pyx/text.py) and then parse the
dvi output themselves (see pyx/dvifile.py)

Having our own dvi parser would be a nice solution. As you noted, the
format isn't too complicated, except for the font handling and the
fact that you need your own bytecode processing engine to extract the
information. We're waiting until Robert Kern has another boring
experiment to site through for this one.

Well, PyX is GPLed so I don't see why you couldn't adopt their DVI
parser.

Because matplotlib isn't GPL'd. It would probably be worth asking the PyX developers if they'd be willing to share the code under another license (essentially the python license), however.

The features it seemed to be lacking the last time I looked in any
detail (v 0.70) were

1. Good, flexible support for reading data from files

This really isn't a plotting issue, it's an IO issue. there's some good stuff in SciPy for this. I've also written a fast file scanner, kind of like Matlab's fscanf. Someone asked if they could put it in SciPy, but I'm not sure if it ever made there. Let me know if you want it.

Also, Python itself provides everything you need to read files.

2. Publication-quality text handling for math and accented characters
(i.e., full LaTeX support)

Yeah, this is cool. I only wish that there was a designed-to-be-embedded TeX distribution out there. There are all kinds of applications for it, and requiring a full TeX distro is a pretty big burden for folks that don't use it already. Of course, if they do, then this is an easy way to get great typesetting.

-Chris

···

On Wed, 2005-06-01 at 13:25 -0500, John Hunter wrote:

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

Hi Chris

> One thing you need to bear in mind if you are using TeX to
> generate PS output is that the resultant files will probably be
> unacceptable to many scientific journals without further processing. The
> production staff generally try to open the PS files in Adobe Illustrator
> and this causes multiple problems with files generated both by PyX and
> by dvips.

Why is this?

The main problem was the fonts. The first thing they do as a matter of
policy is to open the file in Adobe Illustrator. This requires that the
full font be present in the file apparently (I only have this second
hand) because Illustrator allows you to edit the text of the labels. A
little bit like running a PS file through pstoedit and then editing it
with xfig I guess - that doesn't work with TeX fonts either.

Here is the thread from when I raised the issue with the helpful folk on
comp.text.tex

http://groups-beta.google.com/group/comp.text.tex/browse_frm/thread/d19575460c561d6b/d447807bb7813dba

There may be a solution that does not involve converting all fonts to
paths but that was the easiest way out since I was under time-pressure
and dealing with production staff who seemed to be working from a very
limited script :slight_smile:

> The solution is to convert all fonts to outlines before
> submission (and also make sure all bbox coords are +ve). You can do this
> with recent versions of ghostscript:
>
> gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=epswrite -dEPSFitPage \
> -sOutputFile=new.eps old.eps

Coincidentally, I was just addressing the use of gs's epswrite this morning on
the matplotlib-devel list. Unfortunately, epswrite will yield a file that
does not render well on screen. Given the increasing popularity of online
publication, it seems this approach for generating eps files would not be
acceptable to scientific journals either.

I think it looks fine so long as you turn on the "Smooth line art"
option in your PDF viewer. Unfortunately, this is not on by default in
acroread, presumably because it increases rendering times.

If someone can come up with a foolproof way to make figures containing
TeX fonts that are acceptable to scientific journals, I, for one, would
be very grateful.

> 1. Good, flexible support for reading data from files

Could you give an example? In my experience, datafiles tend to get so
complicated that all of Matlabs tools were useless. I end up writing code
specific to every type that isnt as simple as a few comment lines that are
ignored followed by a delimited array of data

Yes, I wasn't thinking of specialized data formats. Python already has
fine support for reading, e.g., FITS files. I was thinking more along
the lines of gnuplot's support for simple ascii data tables. E.g., easy
selection of columns to plot, single blank line indicating a gap in the
plot, double blank line indicating a new dataset, etc. This is all
trivial stuff that I can easily write myself but it would be nice if it
were a part of the plotting package (PyX does this well). It's not
really a sticking point though.

Cheers

Will

···

On Thu, 2005-06-02 at 12:28 -0400, Darren Dale wrote:

William Henney wrote:

Yes, I wasn't thinking of specialized data formats. Python already has
fine support for reading, e.g., FITS files. I was thinking more along
the lines of gnuplot's support for simple ascii data tables. E.g., easy
selection of columns to plot, single blank line indicating a gap in the
plot, double blank line indicating a new dataset, etc. This is all
trivial stuff that I can easily write myself but it would be nice if it
were a part of the plotting package (PyX does this well). It's not
really a sticking point though.

scipy's read_array, while not identical to gnuplot's, isn't bad at all:

In [8]: scipy.io.read_array?
Type: function
Base Class: <type 'function'>
String Form: <function read_array at 0x4083c614>
Namespace: Interactive
File: /usr/lib/python2.3/site-packages/scipy/io/array_import.py
Definition: scipy.io.read_array(fileobject, separator=None, columns=None, comment='#', lines=None, atype='d', linesep='\n', rowsize=10000, missing=0)
Docstring:
     Return an array or arrays from ascii_formatted data in |fileobject|.

     Inputs:

       fileobject -- An open file object or a string for a valid filename.
                     The string can be prepended by "~/" or "~<name>/" to
                     read a file from the home directory.
       separator -- a string or a tuple of strings to indicate the column
                    separators. If the length of the string tuple is less
                    than the total number of columns, then the last separator
                    is assumed to be the separator for the rest of the columns.
       columns -- a tuple of integers and range-tuples which describe the
                  columns to read from the file. A negative entry in the
                  last column specifies the negative skip value to the end.
                  Example: columns=(1, 4, (5, 9), (11, 15, 3), 17, -2)
                          will read [1,4,5,6,7,8,11,14,17,19,21,23,...]
                  If multiple arrays are to be returned, then this argument
                  should be an ordered list of such tuples. There should be
                  one entry in the list for each arraytype in the atype list.
       lines -- a tuple with the same structure as columns which indicates
                  the lines to read.
       comment -- the comment character (line will be ignored even if it is
                  specified by the lines tuple)
       linesep -- separator between rows.
       missing -- value to insert in array when conversion to number fails.
       atype -- the typecode of the output array. If multiple outputs are
                desired, then this should be a list of typecodes. The columns
                to fill the array represented by the given typecode is
                determined from the columns argument. If the length of atype
                does not match the length of the columns list, then, the
                smallest one is expanded to match the largest by repeatedly
                copying the last entry.
       rowsize -- the allocation row size (array grows by this amount as
                data is read in).

     Output -- the 1 or 2d array, or a tuple of output arrays of different
               types, sorted in order of the first column to be placed
               in the output array.

cheers,

f

Hi Fernando

···

On 6/2/05, Fernando Perez <Fernando.Perez@...179...> wrote:

scipy's read_array, while not identical to gnuplot's, isn't bad at all:

Yes, that looks like just what I want. Thanks!

Will

--

  Dr William Henney, Centro de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

Hi All,

There may be a solution that does not involve converting all fonts to
paths but that was the easiest way out since I was under time-pressure
and dealing with production staff who seemed to be working from a very
limited script :slight_smile:

> > The solution is to convert all fonts to outlines before
> > submission (and also make sure all bbox coords are +ve). You can do
> > this with recent versions of ghostscript:
> >
> > gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=epswrite -dEPSFitPage \
> > -sOutputFile=new.eps old.eps
>
> Coincidentally, I was just addressing the use of gs's epswrite this
> morning on the matplotlib-devel list. Unfortunately, epswrite will yield
> a file that does not render well on screen. Given the increasing
> popularity of online publication, it seems this approach for generating
> eps files would not be acceptable to scientific journals either.

I think it looks fine so long as you turn on the "Smooth line art"
option in your PDF viewer. Unfortunately, this is not on by default in
acroread, presumably because it increases rendering times.

If someone can come up with a foolproof way to make figures containing
TeX fonts that are acceptable to scientific journals, I, for one, would
be very grateful.

John has gotten us most of the way there. I think the problem I am having
embedding these LaTeX-generated eps files is related to the fact that the
postscript constructs in the image are not isolated from the main document,
dvips is not creative in naming them, and therefore the font properties (or
encoding, or something) are being corrupted.

Since I also have limited time, I could use epswrite for now. The resulting
figures are not fantastic on screen, (I already had smooth line art enabled
in Adobe Reader), but marginal improvements can be had by increasing the
viewer's resolution. The print version is still good. Since epswrite
basically converts the fonts to an image anyway, I would like to propose one
last time that if text.usetex is true, we draw the text as an image in eps,
just until the better solution becomes available. That way the screen version
would still look good, the entire picture would open in Adobe illustrator,
how big would the files be?

I am going to add an option to use LaTeX instead of TeX to render the text.
TeX is about 30% faster than LaTeX, but ever since John pointed out how much
the bitstream fonts suck, I cant help but notice how much the bitstream fonts
suck. Right now I am using the pslatex package, and these fonts are quite an
improvement. The txfonts package is also nice. How do people feel about two
more rc options: one to select tex or latex, and another to choose the font
package?

···

On Thursday 02 June 2005 6:34 pm, William Henney wrote:

[...]

> For *Agg, we use tex + dvipng and load the output as a transparent,
> anti-aliased raster, caching the dvipng output in ~/.tex.cache for
> efficiency. For PS, we use tex + dvips + psfrag + latex + a patched
> ps2epsi. The latter is cumbersome, but it works. In an ideal world,
> we would simply use tex + dvips but embedding the postscript fragments
> generated by dvips in arbitrary locations on the figure, but this has
> proved challenging.

Have you looked at how PyX (http://pyx.sourceforge.net/) handles things?
They have excellent support for tex/latex labels and it seems to be
implemented in a much "cleaner" way than you describe above. As far as I
can see, they run a single TeX job containing all the strings from the
current plot (see the texrunner class in pyx/text.py) and then parse the
dvi output themselves (see pyx/dvifile.py)

just comment/question, which might be irrelevant, but still:
would a PyX backend make sense?

One approach could be to write out a python
script with the PyX commands corresponding
to the present graphics.
(For example, one then could tweak the resulting script
until the result is fine for publication...)

The big advantages matplotlib has over PyX in my opinion are a more
intuitive API and a larger/more-active developer pool and user base.

Creating plots using PyX tends to need more code than with matplotlib.
On the other hand PyX is *very* flexible which is
reflected in its design. OTOH, the quality of PyX generated graphics
exceeds anything else I have looked at in more detail.
Also, it is easily possible to
change the fonts and their size (+ linewidths, colors etc.)
depending on whether one needs a graphics for inclusion
into a publication (e.g. computer modern roman font)
or a presentation (e.g. cmbright family)
so that graphics and the text around it match nicely.

The wish of a "front-end" to PyX did come up on the PyX mailing
list, if I remember correctly.
So maybe using a matplotlib+PyX-backend combination
would be something useful.

Best wishes,

Arnd

···

On Thu, 2 Jun 2005, William Henney wrote:

On Wed, 2005-06-01 at 13:25 -0500, John Hunter wrote:

I have some good news! This morning I discovered the ability to set the
resolution during the creation of an eps file with epswrite:

gs -dBATCH -dNOPAUSE -dSAFER -q -r6000 -sDEVICE=epswrite -dLanguageLevel=3 \
-dEPSFitPage -sOutputFile=foo.eps foo.ps

This file can be embedded in a new latex document and it has no font
information so the text is rendered properly. The final output looks great
when printed or viewed with Adobe Reader. I think this is the way to go. As
for file size, the eps output from examples/tex_demo.py is about 50KB.

Sorry for all the recent noise (this discussion seems to have wandered through
several threads), but I was really starting to get worried about meeting my
deadlines! I'll try to commit the changes today.

Darren

···

On Thursday 02 June 2005 10:46 pm, Darren Dale wrote:

>
> If someone can come up with a foolproof way to make figures containing
> TeX fonts that are acceptable to scientific journals, I, for one, would
> be very grateful.

John has gotten us most of the way there. I think the problem I am having
embedding these LaTeX-generated eps files is related to the fact that the
postscript constructs in the image are not isolated from the main document,
dvips is not creative in naming them, and therefore the font properties (or
encoding, or something) are being corrupted.

Since I also have limited time, I could use epswrite for now. The resulting
figures are not fantastic on screen, (I already had smooth line art enabled
in Adobe Reader), but marginal improvements can be had by increasing the
viewer's resolution.

Hi,

there are sometimes I change a little bit the function load to extend it a little bit and increase the speed, John didn't like it but that can be useful for some other people like you:

http://sourceforge.net/mailarchive/message.php?msg_id=10836085

Regards,

N.

William Henney wrote:

···

Hi Chris

On Thu, 2005-06-02 at 12:28 -0400, Darren Dale wrote:

One thing you need to bear in mind if you are using TeX to
generate PS output is that the resultant files will probably be
unacceptable to many scientific journals without further processing. The
production staff generally try to open the PS files in Adobe Illustrator
and this causes multiple problems with files generated both by PyX and
by dvips.
     

Why is this?

The main problem was the fonts. The first thing they do as a matter of
policy is to open the file in Adobe Illustrator. This requires that the
full font be present in the file apparently (I only have this second
hand) because Illustrator allows you to edit the text of the labels. A
little bit like running a PS file through pstoedit and then editing it
with xfig I guess - that doesn't work with TeX fonts either.

Here is the thread from when I raised the issue with the helpful folk on
comp.text.tex

http://groups-beta.google.com/group/comp.text.tex/browse_frm/thread/d19575460c561d6b/d447807bb7813dba

There may be a solution that does not involve converting all fonts to
paths but that was the easiest way out since I was under time-pressure
and dealing with production staff who seemed to be working from a very
limited script :slight_smile:

The solution is to convert all fonts to outlines before submission (and also make sure all bbox coords are +ve). You can do this
with recent versions of ghostscript:

gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=epswrite -dEPSFitPage \
   -sOutputFile=new.eps old.eps
     

Coincidentally, I was just addressing the use of gs's epswrite this morning on the matplotlib-devel list. Unfortunately, epswrite will yield a file that does not render well on screen. Given the increasing popularity of online publication, it seems this approach for generating eps files would not be acceptable to scientific journals either.

I think it looks fine so long as you turn on the "Smooth line art"
option in your PDF viewer. Unfortunately, this is not on by default in
acroread, presumably because it increases rendering times.

If someone can come up with a foolproof way to make figures containing
TeX fonts that are acceptable to scientific journals, I, for one, would
be very grateful.

1. Good, flexible support for reading data from files
     

Could you give an example? In my experience, datafiles tend to get so complicated that all of Matlabs tools were useless. I end up writing code specific to every type that isnt as simple as a few comment lines that are ignored followed by a delimited array of data

Yes, I wasn't thinking of specialized data formats. Python already has
fine support for reading, e.g., FITS files. I was thinking more along
the lines of gnuplot's support for simple ascii data tables. E.g., easy
selection of columns to plot, single blank line indicating a gap in the
plot, double blank line indicating a new dataset, etc. This is all
trivial stuff that I can easily write myself but it would be nice if it
were a part of the plotting package (PyX does this well). It's not
really a sticking point though.

Cheers

Will

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Since I also have limited time, I could use epswrite for now. The resulting
figures are not fantastic on screen, (I already had smooth line art enabled
in Adobe Reader), but marginal improvements can be had by increasing the
viewer's resolution. The print version is still good. Since epswrite
basically converts the fonts to an image anyway, I would like to propose one
last time that if text.usetex is true, we draw the text as an image in eps,
just until the better solution becomes available. That way the screen version
would still look good, the entire picture would open in Adobe illustrator,
how big would the files be?

I think this is a good idea, at least to have as an available option. If
you convert the text into an anti-aliased grayscale (or color) image,
then you could probably get away with 150 ppi and the images would not
be large at all (I assume you use something like Flate or RLE
compression). After all, the fraction of the page covered by text will
be small in most instances. It may actually reduce the file size since
you wouldn't need all the font headers.

The only problem I see is that I'm not sure how well PS supports
transparent images - so I can envisage situations in which the text box
might occlude other parts of the graph.

I am going to add an option to use LaTeX instead of TeX to render the text.
TeX is about 30% faster than LaTeX, but ever since John pointed out how much
the bitstream fonts suck, I cant help but notice how much the bitstream fonts
suck. Right now I am using the pslatex package, and these fonts are quite an
improvement. The txfonts package is also nice. How do people feel about two
more rc options: one to select tex or latex, and another to choose the font
package?

Yes please! I would strongly prefer LaTeX over TeX. Also, I think you
really want a mechanism for the user to specify preamble commands
(loading optional packages, defining macros, etc). This would obviate
the need for a special command to choose the fonts.

As an aside, I think mathptmx is better than txfonts if you want a Times
Roman math font. The problem with txfonts is that the kernings are
terrible, particularly for superscripts on brackets and the like. On the
other hand, txfonts does have the "varg" option, which replaces the
pointy-bottomed "v", "y" and "g" with round-bottomed versions. The
pointy bottomed "v" is almost indistinguishable from a "nu", which is
rather unfortunate in a formula for the Doppler shift like $\delta v /
c = \delta \nu / \nu$ :slight_smile:

One final point. I don't understand why you are including ps2epsi in
your toolchain. I thought that the "i" in "epsi" fell by the wayside
over a decade ago. Are there really still any applications out there
that use the %%BeginPreview ... %%EndPreview bitmap? It just seems like
useless and unnecessary bloat to me. It makes tex_demo.eps from the
examples/ directory 5 times larger than it need be!

Best Wishes

Will

···

On Thu, 2005-06-02 at 22:46 -0400, Darren Dale wrote:

--
  Dr William Henney, Centro de Radioastronom�a y Astrof�sica,
  Universidad Nacional Aut�noma de M�xico, Campus Morelia

Hi Darren

> Since I also have limited time, I could use epswrite for now. The resulting
> figures are not fantastic on screen, (I already had smooth line art enabled
> in Adobe Reader), but marginal improvements can be had by increasing the
> viewer's resolution.

I have some good news! This morning I discovered the ability to set the
resolution during the creation of an eps file with epswrite:

gs -dBATCH -dNOPAUSE -dSAFER -q -r6000 -sDEVICE=epswrite -dLanguageLevel=3 \
-dEPSFitPage -sOutputFile=foo.eps foo.ps

This file can be embedded in a new latex document and it has no font
information so the text is rendered properly. The final output looks great
when printed or viewed with Adobe Reader. I think this is the way to go. As
for file size, the eps output from examples/tex_demo.py is about 50KB.

Hmm, very strange. I'd been getting all the same results without
bothering with the ghostscript resolution switch. I can't honestly see
why the resolution should have much to do with it since I thought it
only affected any vector->raster conversions, whereas epswrite should be
keeping everything as vector, albeit flattened. I am using GNU
Ghostscript 7.07 (2003-05-17). My files look fine on-screen in ghostview
et al. When converted to PDF they look godawful in xpdf and kpdf but
fine in acroread with "Smooth Line Art" enabled.

Cheers

Will

···

On Fri, 2005-06-03 at 09:48 -0400, Darren Dale wrote:

--
  Dr William Henney, Centro de Radioastronom�a y Astrof�sica,
  Universidad Nacional Aut�noma de M�xico, Campus Morelia