I have been trying to deal with some font problems related to the new tex
capabilities in MPL. Let me summarize what MPL is doing, when text.usetex is
true in rc:
texmanager runs TeX (or LaTeX) on a string, and John has somehow extracted an
image of that string and its bbox information to intelligently layout and
render the text.
the ps backend will produce a transitional eps file with a bunch of psfrag
markers, along with an associated tex file. backend_ps runs latex on the tex
file, which embeds the eps, and replaces the markers with the actual text.
Now we have a ps file, which can be converted into an eps if desired with
ps2epsi, or maybe this could be changed to a call to ghostscript: gs
-dNOPAUSE -sDEVICE=epswrite -sOutputFile=tex_demo.eps tex_demo.ps. As far as
the user is concerned, you type savefig('foo.eps') and get foo.eps,
blissfully unaware of all the intermediate steps.
Here is my current problem. I embed an eps file generated with ps2epsi in a
new tex document. The dvi looks ok, but after dvips, the text in my figure
gets inverted and shifted. This seems to be a bigger problem when using latex
classes that do some font handling behind the scenes, for example, article
seems ok, but revtex4 and ha-prosper yield unacceptable results.
On the other hand, if I use ghostscript to generate the eps, I can embed the
files and the printed page looks fine, but the fonts look terrible on screen.
Here is a comment from the afpl website
pswrite device generates low level PostScript.
pswrite and epswrite devices reduce everything to path, fill, stroke, clip
image, and imagemask operations. Although the resulting file prints OK it
produces unsatisfactory results when scaled, distilled or imported into
graphic editors. The file can easily exceed 4GB and hit file size limits in
some applications or operation systems. Handling of big files is slow.
The associated bug report (filed over 2 years ago) says this is a low priority
How can MPL deal with these non-MPL issues? I know John doesn't like the idea
of handling text in eps as images, but if we did, could that be a suitable
workaround? Does anyone have another suggestion?