matplotlib-devel Mailing List for matplotlib

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> How does matplotlib render glyphs, does it use freetype?
 Darren> Would matplotlib be able to render tex's fonts with the
 Darren> existing codebase, or would I have to delve into metafont?
Yep, it uses freetype and no, we don't have any facility to render tex
fonts. I think the dvi parsing project would be a very nice addition,
but not a trivial task. The tex file formats are pretty arcane: Knuth
is fond of using bytecode in his data files, so you would have to
write a bytecode engine. Robert Kern did this on a rainy afternoon
for the tfm files, so you could use that as an example
 http://sourceforge.net/mailarchive/message.php?msg_id=9894596
JDH

On Monday 23 January 2006 18:27, Robert Kern wrote:
> Darren Dale wrote:
> > I would like to ask for some advice from those out there who have
> > experience dealing with fonts and text layout.
> >
> > At the end of this message is the output of dvitype, which translates a
> > dvi file (in this case a file typesetting "0.8" in ptmr7t fonts) into
> > human readable output. I have considered writing a dvi parser for mpl,
> > intending to extract the information necessary to render text with mpl's
> > existing font and text support. There is some more information at
> > http://en.wikipedia.org/wiki/DVI_(TeX) and
> > http://www.math.umd.edu/~asnowden/comp-cont/dvi.html#setchar.
> >
> > Is this worth pursuing? If I could make it work, mpl's only external
> > dependency would be TeX/LaTeX, even dvipng would not be required.
>
> Quite probably. dvitype is new to me. Doing a DVI interpreter for mpl and
> Chaco has been on my list of things to look at for some time. The things
> stopping me (besides the density of the DVI standard) was that all of the
> readable code I found for interpreting DVI files has been GPLed.
>
> You will need to access the parameters defined in the TeX Font Metric
> files, I think. I recommend using tftopl(1) to convert them to a parseable
> form.
How does matplotlib render glyphs, does it use freetype? Would matplotlib be 
able to render tex's fonts with the existing codebase, or would I have to 
delve into metafont?

Hello,
My problem is the following : I would like to create an image using the 
matplolib facilities and then insert this image
in a <IMG SRC="*data*:*image*/???;base64 *.../> *element.
Then using Gecko (mozilla) and python + xpcom, I would try to interact 
with this image (zoom ...).
In order to succeed I feel I have to understand how a back-end is written.
It seems I have to start with the Figure class.
But then I can't find the image format, the way to return binary data or 
perhaps base64 data.
I don't want to save the figure in a file et then read it with <IMG 
SRC="theFile.png"/>.
The speed would be very low.
What is the process to add a new back-end ?
I wish the encode/decode base64 wil not take too much time for keeping 
the dynamism of gtk back-end (for instance).
What do you think about that ?
Thanks a lot,
Cyril.

I have a suggestion for a feature in the 'resize window' discussion.
We really need some kind of callback when a window is resized manually in
interactive mode. That is, when somebody points his mouse to the corner of =
a
window and drags it to a bigger size. When this happens, and the plot in th=
e
window is supposed to be drawn to scale (so that circles look like circles)=
,
the size of the plot needs to be managed. That is not difficult to do, as
long as their is a signal given that the window was resized.
Thanks,
Mark

Hi Darren,
It's reasonable to be concerned about having two files necessary to
make one plot. The gnuplot pslatex output doesn't do this: it writes
one output file that is essentially a latex "picture" environment
which includes an encapsulated postscript program for the "graphics
part" with a \special command, and uses \put(x,y){\makebox(0,0){TEXT}
for all the text. Since latex has a preferred orientation for text
flow, each piece of rotated text is handled with another \special
command. BTW, I was mistaken earlier when I said that axes were
drawn in latex with gnuplot's pslatex terminal -- they are included in
the postscript, and only text for axis labels and other text is added
in with latex. So I think that emulating this solution would not be
too hard.
The output latex files do not render a figure by themselves, as they
are intended to be used in-place in documents and latex insists on
exactly one \begin{document} / \end{document} pair. But it's trivial
to have a boilerplate outer latex file:
 \documentclass[11pt]{article}
 \usepackage{color,....}
 \pagestyle{empty}
 \begin{document}\begin{figure}{\input{fig.pstex}}\end{figure}\end{documen=
t}
for generating individual graphs, and then doing standard latex / dvips.
I am not necessarily advocating this as "the right way", but offer it
as a suggestion. I've made figures like this for many years. OK, I
admit that I still make many figures for papers and talks this way, as
I know gnuplot, have scripts I've used for years, and there are some
things I can do more easily in gnuplot/latex than mpl.
Advantages of this approach are that a) the latex is not interpreted
by gnuplot, but handed off to latex (any valid latex can be used),=20
and b) the output latex/postscript is easily hackable. The latex
parts (say, the labels) can be easily changed. Colors and linestyles
of the traces can also be changed simply by editng the postscript. Of
course, "Oh, just hack the postscript" is not what mpl should aspire
too, but it's nice to know it's there when you need it.
A sample gnuplot script and output pslatex are at
 http://cars9.uchicago.edu/~newville/Python/MPlot/gnuplot-pslatex/
I also put a python script gp2ps (which requires Gnuplot.py) I use to
turn gnuplot command files with latex labels into eps (using dvips)
and png (using ImageMagick's convert) outputs. Feel free to use this
any way you want, or ignore it. Again, I'm not saying that this is
"doing tex support the right way", but it might beat the headache of
relying on version-specific features of gs.
Cheers,
--Matt

On Monday 23 January 2006 19:06, Ryan Krauss wrote:
> While the gnuplot approach of outputing an eps file plus a tex file
> that does all the axis labeling is probably lots easier to implement,
> I am nervous that if the tex file ever gets seperated from the eps
> file, I am left with a plot with no axis or tick mark labels - or
> labels that were accidentally editted. That may not be a big enough
> concern to justify the extra work to parse the dvi, but it is a
> concern of mine.
>
> It may be irrational on my part, but something about a single eps file
> feels cleaner to me than the seperate eps and tex file approach.
Actually, this was what the first incarnation of usetex looked like: a ps file 
and a separate latex file. In fact, it still does that, but I put a lot of 
work into hiding that from the user and making mpl do the extra work behind 
the scenes to deliver a single eps file. I didnt like the idea of having to 
insert an eps file and some latex code on top of it. What if the file is not 
destined for a latex document? I might want to use the image with all the 
fancy markup in a poster created with inkscape or adobe illustrator.
> On 1/23/06, Matt Newville <new...@ca...> wrote:
> > Hi Darren,
> >
> > It may be very different than what you're doing, but the hybrid
> > approach of gnuplot's 'pslatex' terminal device might be worth
> > considering and looking into. This writes postscript for the graphics
> > part and leaves simple lines (for the axes) and the text as plain
> > latex that overlays the postscript. I think for mpl, you might want
> > to have all the non-text go into the postscript and all the text go
> > into an accompanying latex file, but the idea is the same.
> >
> > One advantage there is portability, as the output is latex+embedded
> > postscript (using \special). It also allows pretty fine-grained
> > control on the output, including changing fonts or doing latex things
> > that mpl can't do (and this can all be done after the fact, so that
> > you can create the figure, and then change the fonts). It does
> > require latex to create the figure, but this step could be automated,
> > at least to stage of the dvi-with-eps-figure stage. Getting to ps,
> > pdf, or png would be less easy to automate but may be doable in a
> > portable way.
> >
> > That sounds easier than parsing a dvi file to me. And postscript
> > backend already exists.
> >
> >
> > --Matt
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files for problems? Stop! Download the new AJAX search engine that
> > makes searching your log files as easy as surfing the web. DOWNLOAD
> > SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

While the gnuplot approach of outputing an eps file plus a tex file
that does all the axis labeling is probably lots easier to implement,
I am nervous that if the tex file ever gets seperated from the eps
file, I am left with a plot with no axis or tick mark labels - or
labels that were accidentally editted. That may not be a big enough
concern to justify the extra work to parse the dvi, but it is a
concern of mine.
It may be irrational on my part, but something about a single eps file
feels cleaner to me than the seperate eps and tex file approach.
Ryan
On 1/23/06, Matt Newville <new...@ca...> wrote:
> Hi Darren,
>
> It may be very different than what you're doing, but the hybrid
> approach of gnuplot's 'pslatex' terminal device might be worth
> considering and looking into. This writes postscript for the graphics
> part and leaves simple lines (for the axes) and the text as plain
> latex that overlays the postscript. I think for mpl, you might want
> to have all the non-text go into the postscript and all the text go
> into an accompanying latex file, but the idea is the same.
>
> One advantage there is portability, as the output is latex+embedded
> postscript (using \special). It also allows pretty fine-grained
> control on the output, including changing fonts or doing latex things
> that mpl can't do (and this can all be done after the fact, so that
> you can create the figure, and then change the fonts). It does
> require latex to create the figure, but this step could be automated,
> at least to stage of the dvi-with-eps-figure stage. Getting to ps,
> pdf, or png would be less easy to automate but may be doable in a
> portable way.
>
> That sounds easier than parsing a dvi file to me. And postscript
> backend already exists.
>
>
> --Matt
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>