From: Arnd B. <arn...@we...> - 2006-03-09 08:16:05
|
Hi, I have a funny problem when embedding a PyX graphics into latex and converting the resulting dvi to pdf via dvipdfm: python gen_fig.py latex embed.tex dvipdfm embed acroread embed.pdf then the plot has no axes labels. Here ### gen_fig.py from pyx import * g = graph.graphxy(width=10) g.plot(graph.data.function("y(x)=sin(x)", min=-1, max=1, points=1000)) g.writeEPSfile("fig") ### and %%%% embed.tex \documentclass{article} \usepackage[dvips]{graphicx} \begin{document} \includegraphics[width=10cm]{fig.eps} \end{document} %%%% I am using: - pyx.__version__: '0.8+' - dvipdfm -v dvipdfm, version 0.13.2c, Copyright (C) 1998, 1999 by Mark A. Wicks I have no idea if this is in any way related to the recent thread on "Palatino font not embedded in PDF" or if this is just a bug in dvipdfm? If you change gen_fig.py to %%%%%%%%%%%%%%%%%%% from pyx import * c = canvas.canvas() g1 = graph.graphxy(width=10) g1.plot(graph.data.function("y(x)=sin(x)", min=-1, max=1, points=1000)) c. insert(g1) g2 = graph.graphxy(width=10, ypos=g1.ypos-1.2*g1.height) g2.plot(graph.data.function("y(x)=cos(x)", min=-1, max=1, points=1000)) c. insert(g2) c.writeEPSfile("fig") %%%%%%%%%%%%%%%%%%%%%% the second graph is not shown at all (in the .pdf). The `dvips embed ; ps2pdf embed.ps ; acroread embed.pdf ` chain works without problems... Best, Arnd |
From: Thomas P. <Tho...@rr...> - 2006-03-09 08:25:21
|
Hi Arnd, maybe this problem is related to the negative bounding boxes of EPS files generated by PyX which has been discussed here: http://sourceforge.net/mailarchive/forum.php?thread_id=7303626&forum_id=23700 Best, Tom Arnd Baecker wrote: > Hi, > > I have a funny problem when embedding a PyX graphics into > latex and converting the resulting dvi to pdf via dvipdfm: > > python gen_fig.py > latex embed.tex > dvipdfm embed > acroread embed.pdf > > then the plot has no axes labels. > Here > ### gen_fig.py > from pyx import * > g = graph.graphxy(width=10) > g.plot(graph.data.function("y(x)=sin(x)", min=-1, max=1, points=1000)) > g.writeEPSfile("fig") > ### > > and > %%%% embed.tex > \documentclass{article} > \usepackage[dvips]{graphicx} > \begin{document} > \includegraphics[width=10cm]{fig.eps} > \end{document} > %%%% > > I am using: > - pyx.__version__: '0.8+' > - dvipdfm -v > dvipdfm, version 0.13.2c, Copyright (C) 1998, 1999 by Mark A. Wicks > > I have no idea if this is in any way related to the recent > thread on "Palatino font not embedded in PDF" > or if this is just a bug in dvipdfm? > > If you change gen_fig.py to > %%%%%%%%%%%%%%%%%%% > from pyx import * > c = canvas.canvas() > g1 = graph.graphxy(width=10) > g1.plot(graph.data.function("y(x)=sin(x)", min=-1, max=1, points=1000)) > c. insert(g1) > g2 = graph.graphxy(width=10, ypos=g1.ypos-1.2*g1.height) > g2.plot(graph.data.function("y(x)=cos(x)", min=-1, max=1, points=1000)) > c. insert(g2) > c.writeEPSfile("fig") > %%%%%%%%%%%%%%%%%%%%%% > the second graph is not shown at all (in the .pdf). > > The `dvips embed ; ps2pdf embed.ps ; acroread embed.pdf ` > chain works without problems... > > Best, Arnd > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > PyX-user mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-user > -- Thomas Pohl, High Performance Computing Regionales RechenZentrum Erlangen Martensstr. 1, 91054 Erlangen, Germany Phone: +49 9131 8528973 Fax: +49 9131 302941 |
From: Arnd B. <arn...@we...> - 2006-03-09 08:47:22
|
Hi Tom, On Thu, 9 Mar 2006, Thomas Pohl wrote: > Hi Arnd, > maybe this problem is related to the negative > bounding boxes of EPS files generated by PyX which > has been discussed here: > http://sourceforge.net/mailarchive/forum.php?thread_id=7303626&forum_id=23700 > > Best, > Tom Oh - yes that seems not unlikely: Looking at fig.eps with gv shows that labels are at negative values (and for the second example, the second plot is all at negative y values). (hmm - this is not the first time that these negative values cause problems http://www.codecomments.com/archive276-2004-11-321834.html) I could not find a bug report for dvipdfm on this (dvipdfmx-20040411 does the same). Would it be possible that PyX generates postscript files with positive bounding box values only? (Somehow that would mean to shift everything by the right(^tm) amount before writing the file...). Best, Arnd |
From: Thomas P. <Tho...@rr...> - 2006-03-09 08:57:14
|
Hello Arnd, Andre sent me this solution: You can provide a paper format in writeEPSfile. PyX will then center the output on that page while the file remains useable EPS. When the page size is large enough, the whole bounding box will be positive. I hope this still works with the current PyX version. Best, Tom Arnd Baecker wrote: > Hi Tom, > > On Thu, 9 Mar 2006, Thomas Pohl wrote: > > >>Hi Arnd, >>maybe this problem is related to the negative >>bounding boxes of EPS files generated by PyX which >>has been discussed here: >>http://sourceforge.net/mailarchive/forum.php?thread_id=7303626&forum_id=23700 >> >>Best, >>Tom > > > Oh - yes that seems not unlikely: > Looking at fig.eps with gv shows that labels are at negative values > (and for the second example, the second plot is all at negative > y values). > > (hmm - this is not the first time that these negative values cause > problems http://www.codecomments.com/archive276-2004-11-321834.html) > > I could not find a bug report for dvipdfm on this > (dvipdfmx-20040411 does the same). > > Would it be possible that PyX generates postscript files > with positive bounding box values only? > (Somehow that would mean to shift everything by > the right(^tm) amount before writing the file...). > > Best, Arnd > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > PyX-user mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-user > -- Thomas Pohl, High Performance Computing Regionales RechenZentrum Erlangen Martensstr. 1, 91054 Erlangen, Germany Phone: +49 9131 8528973 Fax: +49 9131 302941 |
From: Arnd B. <arn...@we...> - 2006-03-09 09:06:51
|
Hi Tom, On Thu, 9 Mar 2006, Thomas Pohl wrote: > Hello Arnd, > > Andre sent me this solution: > You can provide a paper format in writeEPSfile. PyX will then center > the output on that page while the file remains useable EPS. When the > page size is large enough, the whole bounding box will be positive. > > I hope this still works with the current PyX version. yes - this is the solution: c.writeEPSfile("fig", paperformat=document.paperformat.A4) Many thanks!!! If the centering works, I am wondering whether the default (i.e. without any paperformat) should be to avoid negative bounding boxes? Best, Arnd |
From: Thomas P. <Tho...@rr...> - 2006-03-09 09:15:18
|
I would support this feature request: Why not have an option in writeEPSfile which prevents negative bounding box values? It would help to circumvent the problems with eps->pdf conversion. Cheers, Tom Arnd Baecker wrote: > If the centering works, I am wondering whether the default > (i.e. without any paperformat) > should be to avoid negative bounding boxes? -- Thomas Pohl, High Performance Computing Regionales RechenZentrum Erlangen Martensstr. 1, 91054 Erlangen, Germany Phone: +49 9131 8528973 Fax: +49 9131 302941 |
From: Andre W. <wo...@us...> - 2006-03-09 09:33:23
|
Hi, On 09.03.06, Thomas Pohl wrote: > I would support this feature request: Why not have > an option in writeEPSfile which prevents negative > bounding box values? It would help to circumvent > the problems with eps->pdf conversion. I'm -0 on that. While it's better than using a paperformat by default (that we would have the problem which to choose -- while A4 would be natural in Europe, it would be a quite strange choice in the US). Still, I think it's not necessary. First of all it shouldn't be the default. Suppose you're creating a document with crop marks and makeing the whole think a little bigger than your final papersize. That's perfect and you can just use the real and final coordinates in your scripts. As it should be. And why should you need to disable some strange kind of shifting to just get out what you just painted. No, I don't think it's any good ... Lesson to be learned: Use a paperformat. It's a nice, *additional* feature. Just my two cents ... André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Arnd B. <arn...@we...> - 2006-03-09 09:49:45
|
On Thu, 9 Mar 2006, Andre Wobst wrote: > Hi, > > On 09.03.06, Thomas Pohl wrote: > > I would support this feature request: Why not have > > an option in writeEPSfile which prevents negative > > bounding box values? It would help to circumvent > > the problems with eps->pdf conversion. > > I'm -0 on that. > > While it's better than using a paperformat by default (that we would > have the problem which to choose -- while A4 would be natural in > Europe, it would be a quite strange choice in the US). I think neither of us meant that A4 should be choosen. Only that by default the coordinates get shifted so that no negative values arise. Of course, negative values are perfectly valid, as you convincingly argued. However, if there is buggy software, it will be used. This is actually how the whole issue came up: a colleague uses the dvipdfm tool-chain and all my nice PyX graphics came out corrupted (of course he was blaming PyX and me ... ;-). So if it is easy to just shift (no paperformat), I am +1 on this. > Still, I think it's not necessary. First of all it shouldn't be the > default. Suppose you're creating a document with crop marks and > makeing the whole think a little bigger than your final papersize. > That's perfect and you can just use the real and final coordinates in > your scripts. As it should be. > And why should you need to disable some > strange kind of shifting to just get out what you just painted. No, I > don't think it's any good ... Maybe it then depends on the more common use case, which default would be preferrable ;-)... > Lesson to be learned: Use a paperformat. It's a nice, *additional* > feature. > > Just my two cents ... Well, yours weigh more than ours ;-). When using a paperformat and the graph is too large to be centered on that, would it be possible to put out a warning? (I just checked that it is not presently). Or is there some way to check this afterwards? Best, Arnd |
From: Andre W. <wo...@us...> - 2006-03-09 16:15:38
|
Hi Arnd, On 09.03.06, Arnd Baecker wrote: > Maybe it then depends on the more common use case, which > default would be preferrable ;-)... Right. Thats why it didn't got a -1 from the very beginning. If many users really need to get around this problem, I might be outvoted. > When using a paperformat and the graph is too large to be centered > on that, would it be possible to put out a warning? Absolutely. Good idea. It makes perfect sense. > (I just checked that it is not presently). Just check again. After a cvs update ... :-) So use a paperformat and don't get a warning. That's a first improvement. André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Andre W. <wo...@us...> - 2006-03-09 16:42:46
|
Hi, (This not really belongs to the users list anymore. Upcoming notes will be posted to the devel list only.) On 09.03.06, Andre Wobst wrote: > Just check again. After a cvs update ... :-) I've just started a migration of our repository to subversion. André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Thomas P. <Tho...@rr...> - 2006-03-09 10:10:06
|
Andre Wobst wrote: > Lesson to be learned: Use a paperformat. It's a nice, *additional* > feature. Would it be possible to find out the current bounding box of the canvas (with canvas.bbox() maybe) prior to storing? If one could set an individual paper format fitting to this bounding box, this would also be a good solution IMHO. Best, Tom -- Thomas Pohl, High Performance Computing Regionales RechenZentrum Erlangen Martensstr. 1, 91054 Erlangen, Germany Phone: +49 9131 8528973 Fax: +49 9131 302941 |
From: Andre W. <wo...@us...> - 2006-03-09 10:16:45
|
Hi, On 09.03.06, Thomas Pohl wrote: > Would it be possible to find out the current bounding box > of the canvas (with canvas.bbox() maybe) prior to storing? > If one could set an individual paper format fitting to > this bounding box, this would also be a good solution IMHO. Yes, of course we can properly calculate the bbox and do the correct shift. I'm still -0. Maybe adding an option to writeEPSfile could get a +0 from me, but making it the default is a clear -0. Maybe Jörg wants to add some weight here ... André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Thomas P. <Tho...@rr...> - 2006-03-09 10:30:38
|
Hi, Andre Wobst wrote: > Yes, of course we can properly calculate the bbox and do the correct > shift. I'm still -0. Maybe adding an option to writeEPSfile could get > a +0 from me, but making it the default is a clear -0. Maybe J=F6rg > wants to add some weight here ... I totally agree: the default behavior should stay as it is now. Having an option in writeEPSfile to prevent negative boundary values would be handy, nevertheless. Question to the developers: The same functionalty could be achieved by specifying an individual paper format which fits the values from canvas.bbox(), right? Best, Tom --=20 Thomas Pohl, High Performance Computing Regionales RechenZentrum Erlangen Martensstr. 1, 91054 Erlangen, Germany Phone: +49 9131 8528973 Fax: +49 9131 302941 |
From: Andre W. <wo...@us...> - 2006-03-09 15:41:43
|
Hi, On 09.03.06, Thomas Pohl wrote: > Andre Wobst wrote: > > Yes, of course we can properly calculate the bbox and do the correct > > shift. I'm still -0. Maybe adding an option to writeEPSfile could get > > a +0 from me, but making it the default is a clear -0. Maybe Jörg > > wants to add some weight here ... > > I totally agree: the default behavior should stay as it is now. > Having an option in writeEPSfile to prevent negative boundary > values would be handy, nevertheless. > > Question to the developers: > The same functionalty could be achieved by specifying an individual > paper format which fits the values from canvas.bbox(), right? Basically. Comming back to our original example you could do: from pyx import * g = graph.graphxy(width=10) g.plot(graph.data.function("y(x)=sin(x)", min=-1, max=1, points=1000)) g.writeEPSfile("fig", paperformat=document.paperformat(g.bbox().width(), g.bbox().height())) Note that this code is bad in that it leads to a multiple calculation of the same bbox which is an time consuming operation (and it can't be easily cached by the canvas). Beside that you'll find that the bbox still is off by one (PostScript point). This is due to the fact that we enlarge the bounding box written into the PostScript file, since we don't take into account the line widths and casps etc. in our bbox calculations. While this is not perfect, it seems to be a common way of doing that. Overall, if we want to add a positivebbox option in writeEPSfile, we should do it not by using some strange paperformat. André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Andre W. <wo...@us...> - 2006-03-09 09:26:05
|
Hi, On 09.03.06, Thomas Pohl wrote: > Andre sent me this solution: > You can provide a paper format in writeEPSfile. PyX will then center > the output on that page while the file remains useable EPS. When the > page size is large enough, the whole bounding box will be positive. > > I hope this still works with the current PyX version. Sure it does. And it'll continue work like that, because we really want it that way. Just a quick explanation: When you don't set a papersize, the coordinate system is not altered at all. Note that you can set the position of a graph (xpos and ypos in the constructor with the default being set to zero). There is *no* geneeral problem with negative bounding boxes (as far as I can tell -- except for buggy software). There is even an example with a bbox -100 -100 100 100 in the EPS spec from Adobe (#5002). AFAIK Illustrator can also create eps files with negative bbox-values. When you set a papersize, you're creating an eps file with your output being centered on the page. So PyX inserts a proper transformation for the whole output and properly adjusts the bbox. That way you can nicely print the eps file on a postscript printer directly and still embed the file into other files. Incidentally the bbox will then be positive (as long as your figure is small enough to fit the paper size; BTW there's also a rescaling and rotation possible to properly fit the whole papersize). Thus the feature might be used to prevent problems with negative bboxes. And I also like it very much to be able to just send an eps file to the printer. So I'm using the papersize most of the time. But it's *optional*. Best, André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Alan I. <ai...@am...> - 2006-03-09 14:56:24
|
On Thu, 09 Mar 2006, Thomas Pohl wrote: > maybe this problem is related to the negative > bounding boxes of EPS files generated by PyX which > has been discussed here: > http://sourceforge.net/mailarchive/forum.php?thread_id=7303626&forum_id=23700 And here: http://sourceforge.net/mailarchive/message.php?msg_id=12954494 Cheers, Alan Isaac |