Menu
▾
▴
gnuplot-beta
|
From: Christoph B. <us...@be...> - 2008-12-08 08:51:03
|
Hi, I haven't worked much with TikZ and I can speak only for myself as a gnuplot user: Mojca Miklavec wrote: > > Concerning the question about pstricks terminal: in my opinion it > would make much more sense to work on TikZ terminal than on PSTricks. I work on the PSTricks terminal because I do a lot with PSTricks. For myself I usually use the eps or epslatex terminal for most of my gnuplot diagrams. I just want the PSTricks terminal to be more complete and usable for the people who want to use it :-) > Fixing PSTricks terminal still makes sense if there are minor patches. > For the rest, I would claim that TikZ should become *the* (La)TeX > terminal of the future. As far as im in it, one of the ideas behind gnuplot is to be as portable as possible and to support a great variety of different output formats. So there will hardly ever be a discussion of favoring one format over another from the developer side. This choice is up to the user! For use with LaTeX you have a lot of different formats to choose from. Just to mention a possible drawbacks of pure TeX terminals: While working on the PSTricks terminal, I noticed that the pm3d support is very limited as the large number of polygons needed for the plot require a lot of TeX main memory. As TikZ is also TeX based, it could be that you run into similar problems also with this terminal. > Somebody already started the effort: > http://peter.affenbande.org/gnuplot/ > > My (context) terminal enables changing line style or colors on the fly > (after running gnuplot) - the feature that Christoph mentioned as one > thing that could be done with PSTricks. But it is not usable in LaTeX, > just as PSTricks is not usable with pdfTeX, so this makes it usable > for a much smaller audience. PSTricks can be used with pdflatex in dvi output mode (this is the default for 'latex' on most newer systems). Or, with the package 'pst-pdf', directly with pdflatex ;-) And again: it shouldn't be a developer decision which terminal the users 'want' to use. > However, one should *really* take a look at what Peter did on the link > above. I did not test the terminal too much. I want to send him some > patches, but really ... one should take a look and consider including > it. I think you should ask Peter why he did not contact the gnuplot developer for including his terminal. Maybe its an issue with the license?! (lua terminal is under GPL license) Christoph PS: I forwarded the mail to the gnuplot mailing list |
|
From: Juergen W. <wie...@fr...> - 2008-12-08 09:26:09
|
> > Fixing PSTricks terminal still makes sense if there are minor patches. > > For the rest, I would claim that TikZ should become *the* (La)TeX > > terminal of the future. > > As far as im in it, one of the ideas behind gnuplot is to be as portable > as possible and to support a great variety of different output formats. > So there will hardly ever be a discussion of favoring one format over > another from the developer side. This choice is up to the user! I think so, too. But nevertheless the TikZ terminal seems quite promising. > I think you should ask Peter why he did not contact the gnuplot > developer for including his terminal. Maybe its an issue with the > license?! (lua terminal is under GPL license) Peter has kindly uploaded his terminal to the patches tracker recently: http://sourceforge.net/tracker/index.php?func=detail&aid=2183264&group_id=2055&atid=302055 He writes that he has no objections in changing the license. > Just to mention a possible drawbacks of pure TeX terminals: > While working on the PSTricks terminal, I noticed that the pm3d support > is very limited as the large number of polygons needed for the plot > require a lot of TeX main memory. As TikZ is also TeX based, it could be > that you run into similar problems also with this terminal. TikZ is not really a pure TeX based solution. As I understand things it works mostly like PSTricks but with more than one back end, i.e. PS as well as PDF. Nevertheless I ran into exceeding memory when there were three images in TeX memory at the same time. Juergen |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-12-08 17:47:28
|
On Monday 08 December 2008 01:25:58 Juergen Wieferink wrote: > > > Fixing PSTricks terminal still makes sense if there are minor patches. > > > For the rest, I would claim that TikZ should become *the* (La)TeX > > > terminal of the future. > > > > As far as im in it, one of the ideas behind gnuplot is to be as portable > > as possible and to support a great variety of different output formats. > > So there will hardly ever be a discussion of favoring one format over > > another from the developer side. This choice is up to the user! > > I think so, too. But nevertheless the TikZ terminal seems quite > promising. > > > I think you should ask Peter why he did not contact the gnuplot > > developer for including his terminal. Maybe its an issue with the > > license?! (lua terminal is under GPL license) > > Peter has kindly uploaded his terminal to the patches tracker recently: > > http://sourceforge.net/tracker/index.php?func=detail&aid=2183264&group_id=2055&atid=302055 > > He writes that he has no objections in changing the license. I am afraid that I have no time to check out lua + TikZ myself, but I am certainly open to adding this new driver to CVS if multiple people agree that it is a useful addition, and if Peter confirms that we can include it under the gnuplot license. Do you think it is ready for inclusion in CVS? Does the ./configure script need to be modified for it (that is, should it try to autodetect lya and/or TikZ)? > > Just to mention a possible drawbacks of pure TeX terminals: > > While working on the PSTricks terminal, I noticed that the pm3d support > > is very limited as the large number of polygons needed for the plot > > require a lot of TeX main memory. As TikZ is also TeX based, it could be > > that you run into similar problems also with this terminal. > > TikZ is not really a pure TeX based solution. As I understand > things it works mostly like PSTricks but with more than one back > end, i.e. PS as well as PDF. Nevertheless I ran into exceeding > memory when there were three images in TeX memory at the same time. > > > Juergen > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Juergen W. <wie...@fr...> - 2008-12-08 18:05:35
|
Ethan Merritt wrote: > I am afraid that I have no time to check out lua + TikZ myself, > but I am certainly open to adding this new driver to CVS if > multiple people agree that it is a useful addition, and if Peter > confirms that we can include it under the gnuplot license. The terminal certainly is a very useful addition. > Do you think it is ready for inclusion in CVS? I think in almost all respects it is. The ./configure script has to be updated (see below) and there are some minor edges in the user interface; it does not "feel" very gnuplot'ish. For example, AFAICR the "set term" command line cannot make use of string expressions or even real valued expressions. To some degree this probably cannot be avoided because the parsing is done within the lua script. But some edges actually could be smoothed. That said, as long as it is marked EXPERIMENTAL and you are free to drop backwards compatibility, I think it is quite mature. > Does the ./configure script need to be modified for it (that is, > should it try to autodetect lya and/or TikZ)? Yes. But it should check for the lua library and build the terminal conditionally. I don't think it has to check for TikZ, as it is only needed for using the gnuplot output. Additionally the gnuplot.lua script has to be installed. As things are it is expected to reside along in the same directory as gnuplot_x11. I'd like to do more review on this but it seems I won't find much time within the next few months. Juergen |
|
From: Mojca M. <moj...@gm...> - 2008-12-09 22:48:31
|
On Mon, Dec 8, 2008 at 6:47 PM, Ethan Merritt wrote:
> On Monday 08 December 2008 01:25:58 Juergen Wieferink wrote:
>> > > Fixing PSTricks terminal still makes sense if there are minor patches.
>> > > For the rest, I would claim that TikZ should become *the* (La)TeX
>> > > terminal of the future.
>> >
>> > As far as im in it, one of the ideas behind gnuplot is to be as portable
>> > as possible and to support a great variety of different output formats.
>> > So there will hardly ever be a discussion of favoring one format over
>> > another from the developer side. This choice is up to the user!
I only meant that since resources are limited it's better to have one
really good terminal than having ten "broken"/nonfunctional ones.
So it makes senso to put some considerable amount of time into
creating one good terminal.
Having a 'preferred' terminal should by no means prevent developers
from applying patches to other terminals and it should not prevent
users from using them.
Gnuplot currently provides the following "TeX" terminals:
eepic EEPIC -- extended LaTeX picture environment
emtex LaTeX picture environment with emTeX specials
epslatex LaTeX picture environment using graphicx package
latex LaTeX picture environment
mf Metafont plotting standard
mp MetaPost plotting standard
pslatex LaTeX picture environment with PostScript \specials
pstex plain TeX with PostScript \specials
pstricks LaTeX picture environment with PSTricks macros
texdraw LaTeX texdraw environment
tpic TPIC -- LaTeX picture environment with tpic \specials
plus (also TeX-friendly)
pdf PDF (Portable Document File) file driver
postscript PostScript graphics, including EPSF embedded files (*.eps)
where there is no single one that would satisfy my expectations.
PS/PDF provides no TeX labels, pslatex doesn't work with pdftex,
pstricks have serious problems working with pdftex apart from the fact
that a lot of functionality is missing, latex looks ugly and doesn't
even have color output, mp is lacking functionality, all others are
old and not maintained. How should some newbie user know which
terminal to use?
Apart from that, colors and point shapes differ between terminals.
>> I think so, too. But nevertheless the TikZ terminal seems quite
>> promising.
>>
>> > I think you should ask Peter why he did not contact the gnuplot
>> > developer for including his terminal. Maybe its an issue with the
>> > license?! (lua terminal is under GPL license)
>>
>> Peter has kindly uploaded his terminal to the patches tracker recently:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=2183264&group_id=2055&atid=302055
>>
>> He writes that he has no objections in changing the license.
>
> I am afraid that I have no time to check out lua + TikZ myself,
> but I am certainly open to adding this new driver to CVS if multiple
> people agree that it is a useful addition, and if Peter confirms that
> we can include it under the gnuplot license.
>
> Do you think it is ready for inclusion in CVS?
As far as I know it's fully functional. There's only one thing that
I'm not sure about:
set term lua
It uses lua, but outputs tikz code. I would prefer to call the
terminal tikz or maybe set a synonym
set term lua tikz options = set term tikz options
If terminal is called lua, nobody will figure out that it's used for
generating TeX code. On the other hand, one can plug in any code to
generate any other kind of ouput from the lua interface, so the name
"lua" for terminal does make sense.
But that's up to gnuplot developers.
I wanted to suggest some modifications to enable compatibility with
ConTeXt (terminal only works with LaTeX at the moment), but this
should not prevent the code from being added to CVS. Functionality is
not frozen right after being added to CVS, and as long as you accept
patches from the author himself, it should be fine.
> Does the ./configure script need to be modified for it (that is,
> should it try to autodetect lya and/or TikZ)?
TikZ: definitely not. Firstly: it's literally impossible to figure out
whether it is installed or not. Secondly: gnuplot should not care.
Providing the right package in TeX is the responsibility of user.
Lua: yes. One could also *include* it into gnuplot itself. The whole
source is only 0.5MB. See also:
http://peter.affenbande.org/gnuplot/gnuplot_lua_terminal/INSTALL
Mojca
|
|
From: Juergen W. <wie...@fr...> - 2008-12-10 08:06:01
|
> Gnuplot currently provides the following "TeX" terminals: [...] > where there is no single one that would satisfy my expectations. > PS/PDF provides no TeX labels, pslatex doesn't work with pdftex, > pstricks have serious problems working with pdftex apart from the fact > that a lot of functionality is missing, latex looks ugly and doesn't > even have color output, mp is lacking functionality, all others are > old and not maintained. How should some newbie user know which > terminal to use? > > Apart from that, colors and point shapes differ between terminals. Have you tried epslatex recently? Harald Harders has completely reworked it. It has the look and feel of the postscript terminal with latex output for the textual parts. By converting the eps file into pdf you can even use pdflatex with it. Juergen |
|
From: Mojca M. <moj...@gm...> - 2008-12-09 23:26:58
|
On Mon, Dec 8, 2008 at 9:38 AM, Christoph Bersch wrote: > > Just to mention a possible drawbacks of pure TeX terminals: > While working on the PSTricks terminal, I noticed that the pm3d support is > very limited as the large number of polygons needed for the plot require a > lot of TeX main memory. As TikZ is also TeX based, it could be that you run > into similar problems also with this terminal. That's right. Sooner or later it does. I was unable to draw 100x100 matrix with some other (context) terminal as well. But it's also a problem to display too many polygons in any vector terminal/format. I currently need some scatter plots with possibly 1 million points and using pdf terminal wouldn't really help since my acrobat and/or printer would crash, so I need to use png terminal. I wish there was a way to plot with bitmap terminal and use TeX labels over it. One could then use 1000x1000 grid for 3D plots without a problem. >> My (context) terminal enables changing line style or colors on the fly >> (after running gnuplot) - the feature that Christoph mentioned as one >> thing that could be done with PSTricks. But it is not usable in LaTeX, >> just as PSTricks is not usable with pdfTeX, so this makes it usable >> for a much smaller audience. > > PSTricks can be used with pdflatex in dvi output mode I know, but I use pdftex in pdf output mode exclusively. > And again: it shouldn't be a developer decision which terminal the users > 'want' to use. Definitely not. But it helps to get a hint. I probably needed a year to discover other terminals besides "latex", and I was fighting with getting some outdated TeX-like terminals to work properly when they were actually using tricks that don't work in TeX packages any more or were using packages that are no longer part of TeX distributions.) > PS: I forwarded the mail to the gnuplot mailing list Thanks. Juergen Wieferink wrote: > TikZ is not really a pure TeX based solution. But it works with basically any existing engine and format. TikZ is fantastic. > As I understand > things it works mostly like PSTricks but with more than one back > end, i.e. PS as well as PDF. And also important: LaTeX as well as plain TeX and ConTeXt. > Nevertheless I ran into exceeding > memory when there were three images in TeX memory at the same time. I need to do some tests. When I was implementing the first draft of context terminal, it was only able to handle 10 graphs at most and it needed 10 minutes to process them. After some optimisation in ConTeXt core it was possible to do much more with 20 or 50-fold speedup. There are definitely limitations, but a pure TeX terminal has been serving me for two years without any major issues apart from the obvious memory limitation. Mojca |
|
From: Christoph B. <us...@be...> - 2008-12-10 11:54:32
|
Mojca Miklavec schrieb: > On Mon, Dec 8, 2008 at 9:38 AM, Christoph Bersch wrote: > >> And again: it shouldn't be a developer decision which terminal the users >> 'want' to use. > > Definitely not. But it helps to get a hint. I probably needed a year > to discover other terminals besides "latex", and I was fighting with > getting some outdated TeX-like terminals to work properly when they > were actually using tricks that don't work in TeX packages any more or > were using packages that are no longer part of TeX distributions.) Right! I think it would be nice to have something like a gnuplot-*TeX tutorial which aims exactly at this point. I don't know if I can find some time to write a quick overview on the *TeX-suited terminals, their advantages and disadvantages. But I could try :-) Christoph |
|
From: Petr M. <mi...@ph...> - 2008-12-10 05:50:42
|
> I wish there was a way to plot with bitmap terminal and use TeX labels > over it. That you can do. Use "set term png", unset border and tics, save the plot and then "plot with image" with additional labels. --- PM |
|
From: Juergen W. <wie...@fr...> - 2008-12-10 08:27:37
|
> What parser probs did you encounter? I don't see any problems in parsing > strings or numbers, as it is already done. But maybe we are just talking > about different things. Anyway, it shouldn't be a problem to extend the > parser if necessary. Well, not exactly problems. AFAIR the lua script has no access to the higher level parsing functions like try_to_get_string() and real_expression(). Thus you cannot use string variables or general expression evaluating to strings or numbers. Additionally no spaces are allowed between the number and the dimension, i.e. "5in" is allowed, "5 in" is not. As far as I am concerned "fulldoc" should be renamed into "standalone" to fit the corresponding option of the epslatex terminal. I agree with Mojca about the alias "tikz" for "lua". Additionally I'm not sure if "gnuplot.lua" is the right name for the TikZ terminal... These are of course minor issues. Having an autoconfiscated version would really help in testing. Juergen |
|
From: Mojca M. <moj...@gm...> - 2008-12-10 10:33:01
|
On Wed, Dec 10, 2008 at 9:27 AM, Juergen Wieferink wrote: >> What parser probs did you encounter? I don't see any problems in parsing >> strings or numbers, as it is already done. But maybe we are just talking >> about different things. Anyway, it shouldn't be a problem to extend the >> parser if necessary. > > Well, not exactly problems. AFAIR the lua script has no access to > the higher level parsing functions like try_to_get_string() and > real_expression(). Thus you cannot use string variables or general > expression evaluating to strings or numbers. This could be implemented, but I doubt that it is really worth the effort. You only need it to set monochrome/color, plot size, font size, ... And one doesn't really need complex gnuplot expressions to set the plot size. The defaults should already be OK. > Additionally no spaces > are allowed between the number and the dimension, i.e. "5in" is > allowed, "5 in" is not. That's not the problem. It could be changed, but the idea is that if one provides no number, it is treated as centimeters, and then "in" would be treated as the next option. > As far as I am concerned "fulldoc" should be renamed into > "standalone" to fit the corresponding option of the epslatex > terminal. I agree. The same is true for preamble that is called header in epslatex. > These are of course minor issues. Having an autoconfiscated version > would really help in testing. Right. Once the terminal is integrated, it would be easier for others to test. Mojca |
|
From: Mojca M. <moj...@gm...> - 2008-12-10 10:24:06
|
On Wed, Dec 10, 2008 at 6:50 AM, Petr Mikulik wrote: >> I wish there was a way to plot with bitmap terminal and use TeX labels >> over it. > > That you can do. Use "set term png", unset border and tics, save the plot > and then "plot with image" with additional labels. One question: is "with image" already able to read png images? I had an impression that it was only able to read some unusual binary formats (3 bytes per pixel). My idea was to unset labels and then draw the labels in metapost or TikZ, but this means that I still need to put all the labels there manually (for every plot the number must be adapted), but the really useful thing would be to do what epslatex does: draw everything with png terminal except for labels and then include the resulting png image into TeX document. (But I would need to learn a bit more about hacking terminals in order to do that mix.) Mojca |
|
From: Petr M. <mi...@ph...> - 2008-12-10 16:42:32
|
> >> I wish there was a way to plot with bitmap terminal and use TeX labels
> >> over it.
> >
> > That you can do. Use "set term png", unset border and tics, save the plot
> > and then "plot with image" with additional labels.
>
> One question: is "with image" already able to read png images? I had
> an impression that it was only able to read some
> unusual binary formats (3 bytes per pixel).
Ethan has shown it works this way:
plot '<convert table.png avs:-' binary filetype=avs with rgbimage
Actually, I have never met an .avs file in reality.
Nowadays gnuplot is typically compiled with the gd library. Therefore it
should be pretty easy to use the gd-library to load png/gif/jpg images
directly. I think it may not be too much code in breaders.c. Could somebody
contribute this feature?
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2008-12-11 17:57:16
|
On Wednesday 10 December 2008 08:42:21 Petr Mikulik wrote: > > > > One question: is "with image" already able to read png images? I had > > an impression that it was only able to read some > > unusual binary formats (3 bytes per pixel). > > Ethan has shown it works this way: > > plot '<convert table.png avs:-' binary filetype=avs with rgbimage > > Nowadays gnuplot is typically compiled with the gd library. Therefore it > should be pretty easy to use the gd-library to load png/gif/jpg images > directly. I think it may not be too much code in breaders.c. Could somebody > contribute this feature? I honestly don't see quite how that would work. Using libgd, or libpng for that matter, will result in an in-memory copy of the bitmap image. But that's not exactly what the binary file input code wants; it expects to read a stream of binary data on the input fd, so that it can filter, re-map, combine fields, etc. It seems to me that one would have to write a new input layer that dummies up access to an in-memory bitmap as successive reads to a fake pipe. What would we gain by adding all this extra code? Isn't it much better to let an external utility do this for us, as in the example you quote? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Mojca M. <moj...@gm...> - 2008-12-11 18:26:30
|
On Thu, Dec 11, 2008 at 6:56 PM, Ethan Merritt wrote: > On Wednesday 10 December 2008 08:42:21 Petr Mikulik wrote: >> > >> > One question: is "with image" already able to read png images? I had >> > an impression that it was only able to read some >> > unusual binary formats (3 bytes per pixel). >> >> Ethan has shown it works this way: >> >> plot '<convert table.png avs:-' binary filetype=avs with rgbimage >> >> Nowadays gnuplot is typically compiled with the gd library. Therefore it >> should be pretty easy to use the gd-library to load png/gif/jpg images >> directly. I think it may not be too much code in breaders.c. Could somebody >> contribute this feature? > > I honestly don't see quite how that would work. > Using libgd, or libpng for that matter, will result in an in-memory copy > of the bitmap image. But that's not exactly what the binary file input code > wants; it expects to read a stream of binary data on the input fd, so that it > can filter, re-map, combine fields, etc. It seems to me that one would > have to write a new input layer that dummies up access to an in-memory > bitmap as successive reads to a fake pipe. > > What would we gain by adding all this extra code? Isn't it much better to let > an external utility do this for us, as in the example you quote? One would gain readability. I would never have come to idea to use so complicated code to be able to read PNG images. It's perfectly OK if external tools are being used, but it would help a lot if calling external tools would happen automatically for specific types of images. Mojca |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-12-11 19:06:20
|
On Thursday 11 December 2008 10:26:24 Mojca Miklavec wrote: > On Thu, Dec 11, 2008 at 6:56 PM, Ethan Merritt wrote: > > On Wednesday 10 December 2008 08:42:21 Petr Mikulik wrote: > >> > > >> > One question: is "with image" already able to read png images? I had > >> > an impression that it was only able to read some > >> > unusual binary formats (3 bytes per pixel). > >> > >> Ethan has shown it works this way: > >> > >> plot '<convert table.png avs:-' binary filetype=avs with rgbimage > >> > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it > >> should be pretty easy to use the gd-library to load png/gif/jpg images > >> directly. I think it may not be too much code in breaders.c. Could somebody > >> contribute this feature? > > > > I honestly don't see quite how that would work. > > Using libgd, or libpng for that matter, will result in an in-memory copy > > of the bitmap image. But that's not exactly what the binary file input code > > wants; it expects to read a stream of binary data on the input fd, so that it > > can filter, re-map, combine fields, etc. It seems to me that one would > > have to write a new input layer that dummies up access to an in-memory > > bitmap as successive reads to a fake pipe. > > > > What would we gain by adding all this extra code? Isn't it much better to let > > an external utility do this for us, as in the example you quote? > > One would gain readability. I would never have come to idea to use so > complicated code to be able to read PNG images. Well, it is documented. And it is quite general. The same command works for any image type that ImageMagick knows about. There is nothing special about *.png in this regard. > It's perfectly OK if external tools are being used, but it would help > a lot if calling external tools would happen automatically for > specific types of images. Do you mean that a command like plot 'imagefile' binary filetype=auto with rgbimage should always be expanded to the equivalent plot '<convert imagefile avs:-' binary filetype=avs with rgbimage if there is no special rule for the filetype extension? That would work OK on any unix-ish system that has ImageMagick installed, but would fail for other configurations. Or are you suggesting that gnuplot should have a plugin mechanism of some sort, that would be locally configured to invoke an appropriate external converter? I have no objection to that, but I don't have the expertise to write one. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2008-12-11 20:07:23
|
> > >> plot '<convert table.png avs:-' binary filetype=avs with rgbimage > > >> > > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it > > >> should be pretty easy to use the gd-library to load png/gif/jpg images > > >> directly. I think it may not be too much code in breaders.c. Could somebody > > >> contribute this feature? > > > > > > I honestly don't see quite how that would work. > > > Using libgd, or libpng for that matter, will result in an in-memory copy > > > of the bitmap image. But that's not exactly what the binary file input code > > > wants; it expects to read a stream of binary data on the input fd, so that it > > > can filter, re-map, combine fields, etc. It seems to me that one would > > > have to write a new input layer that dummies up access to an in-memory > > > bitmap as successive reads to a fake pipe. The abstraction layer ... cannot be this done in some easy way? Currently there are fread(f, ..., bytes) ... so instead of fread() there would be memcpy(). > > > What would we gain by adding all this extra code? Isn't it much better to let > > > an external utility do this for us, as in the example you quote? > > > > One would gain readability. I would never have come to idea to use so > > complicated code to be able to read PNG images. The gain would be portability and speed. We could put lena.png and lena.jpg into demos/ and be sure that these demos can be run by Windows executables as well. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-12-11 20:36:02
|
On Thursday 11 December 2008 12:07:12 Petr Mikulik wrote: > > > >> plot '<convert table.png avs:-' binary filetype=avs with rgbimage > > > >> > > > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it > > > >> should be pretty easy to use the gd-library to load png/gif/jpg images > > > >> directly. I think it may not be too much code in breaders.c. Could somebody > > > >> contribute this feature? > > > > > > > > I honestly don't see quite how that would work. > > > > Using libgd, or libpng for that matter, will result in an in-memory copy > > > > of the bitmap image. But that's not exactly what the binary file input code > > > > wants; it expects to read a stream of binary data on the input fd, so that it > > > > can filter, re-map, combine fields, etc. It seems to me that one would > > > > have to write a new input layer that dummies up access to an in-memory > > > > bitmap as successive reads to a fake pipe. > > The abstraction layer ... cannot be this done in some easy way? Currently > there are fread(f, ..., bytes) ... so instead of fread() there would be > memcpy(). > > > > > > What would we gain by adding all this extra code? Isn't it much better to let > > > > an external utility do this for us, as in the example you quote? > > > > > > One would gain readability. I would never have come to idea to use so > > > complicated code to be able to read PNG images. > > The gain would be portability and speed. We could put lena.png and lena.jpg > into demos/ and be sure that these demos can be run by Windows executables > as well. I don't see how requiring ImageMagick limits the portability, and it is a much more general solution than one that accommodates only png images. I am dubious that the speed is enough different to notice. As to Windows, it would be of far more value to get the popen() filter mechanism working under Windows than it would be to add large chunks of code to make up for various individual things you can't do because of this shared fundamental flaw. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2008-12-11 22:50:04
|
> > > > >> plot '<convert table.png avs:-' binary filetype=avs with rgbimage > > > > >> > > > > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it > > > > >> should be pretty easy to use the gd-library to load png/gif/jpg images > > > > >> directly. I think it may not be too much code in breaders.c. Could somebody > > > > >> contribute this feature? > > > > > > > > > > I honestly don't see quite how that would work. > > > > > Using libgd, or libpng for that matter, will result in an in-memory copy > > > > > of the bitmap image. But that's not exactly what the binary file input code > > > > > wants; it expects to read a stream of binary data on the input fd, so that it > > > > > can filter, re-map, combine fields, etc. It seems to me that one would > > > > > have to write a new input layer that dummies up access to an in-memory > > > > > bitmap as successive reads to a fake pipe. > > > > The abstraction layer ... cannot be this done in some easy way? Currently > > there are fread(f, ..., bytes) ... so instead of fread() there would be > > memcpy(). > > > > The gain would be portability and speed. We could put lena.png and lena.jpg > > into demos/ and be sure that these demos can be run by Windows executables > > as well. > > I don't see how requiring ImageMagick limits the portability, and it is > a much more general solution than one that accommodates only png images. > I am dubious that the speed is enough different to notice. > > As to Windows, it would be of far more value to get the popen() filter > mechanism working under Windows than it would be to add large chunks of > code to make up for various individual things you can't do because of this > shared fundamental flaw. ImageMagick is no problem for Linux users. It is problem for Windows people. We cannot expect them to install any other tool. Gnuplot should not depend on outside filters, if we can organize it within gnuplot. popen() works on Windows, but wgnuplot_pipes.exe binary has to be run instead of wgnuplot.exe --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-12-11 23:09:17
|
On Thursday 11 December 2008 14:49:55 Petr Mikulik wrote: > > > > > >> plot '<convert table.png avs:-' binary filetype=avs with rgbimage > > > > > >> > > > > > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it > > > > > >> should be pretty easy to use the gd-library to load png/gif/jpg images > > > > > >> directly. I think it may not be too much code in breaders.c. Could somebody > > > > > >> contribute this feature? > > > > > > > > > > > > I honestly don't see quite how that would work. > > > > > > Using libgd, or libpng for that matter, will result in an in-memory copy > > > > > > of the bitmap image. But that's not exactly what the binary file input code > > > > > > wants; it expects to read a stream of binary data on the input fd, so that it > > > > > > can filter, re-map, combine fields, etc. It seems to me that one would > > > > > > have to write a new input layer that dummies up access to an in-memory > > > > > > bitmap as successive reads to a fake pipe. > > > > > > The abstraction layer ... cannot be this done in some easy way? Currently > > > there are fread(f, ..., bytes) ... so instead of fread() there would be > > > memcpy(). > > > > > > The gain would be portability and speed. We could put lena.png and lena.jpg > > > into demos/ and be sure that these demos can be run by Windows executables > > > as well. > > > > I don't see how requiring ImageMagick limits the portability, and it is > > a much more general solution than one that accommodates only png images. > > I am dubious that the speed is enough different to notice. > > > > As to Windows, it would be of far more value to get the popen() filter > > mechanism working under Windows than it would be to add large chunks of > > code to make up for various individual things you can't do because of this > > shared fundamental flaw. > > ImageMagick is no problem for Linux users. It is problem for Windows people. > We cannot expect them to install any other tool. Gnuplot should not depend > on outside filters, if we can organize it within gnuplot. That's nonsense. If they can install gnuplot, they can also install ImageMagick. Probably more easily, since we don't have a one-click Windows installer :-) Gnuplot already makes good use of external filters and tools including ghostscript, LaTeX, Fig, and lots of locally tailored scripts requiring perl, python, tcl, etc. Gnuplot's strength is the extent to which it complements and extends existing tools. The ability to pipe data in and out through filters is a key part of this. We should not re-invent the wheel, badly, rather than playing to our strength. > popen() works on Windows, but wgnuplot_pipes.exe binary has to be run > instead of wgnuplot.exe I understand that stdin/stdout are problematic if the program is run without a console window, but that is a different issue than reading data via a call to popen(). Why would you ever want to run a version that deliberately omits support for popen()? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2008-12-12 07:48:06
|
> > popen() works on Windows, but wgnuplot_pipes.exe binary has to be run > > instead of wgnuplot.exe > > Why would you ever want to run a version that deliberately omits support > for popen()? Because it needs to open an additional (usually empty) console window. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-18 04:32:02
|
I've uploaded a patchset to SourceForge that places the current contents
of your tarball into .../term/lua/ and .../term/,
and modifies thethe autoconf scripts to configure and install with no
additional intervention.
Comments:
- ./configure currently installs gnuplot-lua-tikz.sty to
/usr/local/share/gnuplot/<version>/ but of course TeX doesn't know to look
for it there. Where is the proper place to install this style file?
- Tested using TeXLive:
pdflatex works great. dvi output is still useless.
- dvips partially works, and may be fixable. It places 90% of the plot
off the bottom of the page, and then clips it so you can't recover
even by editing the BoundingBox.
- Tested using texmf:
Works fine using pdflatex except that I had to hunt for a copy of
ifxetex.sty
- I have not touched the code in lua.trm, but it needs a pass to remove
these warnings:
../term/lua.trm:132: warning: ISO C90 forbids mixed declarations and code
../term/lua.trm:190: warning: ISO C90 forbids mixed declarations and code
../term/lua.trm:532: warning: implicit declaration of function ‘luaL_openlibs’
../term/lua.trm:533: warning: implicit declaration of function ‘luaopen_debug’
../term/lua.trm:561: warning: ISO C90 forbids mixed declarations and code
../term/lua.trm:1023: warning: ISO C90 forbids mixed declarations and code
../term/lua.trm:125: warning: ‘LUA_stack_dump’ defined but not used
- set term lua should accept at least the following options:
size XX, YY # units of inches or cm
dashed/solid
color/monochrome
and it needs to echo back the options string to the user to confirm it
was accepted
But that's all minor stuff, and can be fixed up after the code goes into
cvs.
What do you think - should the whole lot go into cvs more or less
immediately?
--
Ethan A Merritt
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-18 06:02:12
|
On Wednesday 10 December 2008, Juergen Wieferink wrote: > > Having an autoconfiscated version would really help in testing. It's there now. Let me know if it should go into CVS proper. I have another question from testing: Is it supposed to handle UTF8 characters? I get mixed results. For instance, in processing transparent.dem it handles μ (\mu) correctly, but throws an error on σ (\sigma). -- Ethan A Merritt |
|
From: Mojca M. <moj...@gm...> - 2008-12-18 10:40:07
|
On Thu, Dec 18, 2008 at 7:02 AM, Ethan A Merritt wrote: > > I have another question from testing: > > Is it supposed to handle UTF8 characters? Yes, to a certain extent. > I get mixed results. > For instance, in processing transparent.dem it handles > μ (\mu) correctly, but throws an error on σ (\sigma). That's up to TeX, not up to the terminal. The terminal should not modify input (at least in my opinion). Users are supposed to either use the right package in TeX to hadle the encoding or use whatever character or command that works in TeX. If one uses XeTeX, UTF-8 should work out-of-the-box. In pdflatex there are several packages to handle UTF-8, but maybe they work slightly differently. Mojca |
|
From: Mojca M. <moj...@gm...> - 2008-12-18 10:43:09
|
On Thu, Dec 18, 2008 at 11:40 AM, Mojca Miklavec wrote: > >> I get mixed results. >> For instance, in processing transparent.dem it handles >> μ (\mu) correctly, but throws an error on σ (\sigma). > > That's up to TeX, not up to the terminal. I wanted to say: I don't consider it broken if σ fails to work and I would not try to convert that to \sigma. When compiling the document with XeTeX or when loading the right macros, σ should work just fine. Mojca |
