Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-06-08 04:42:16
|
Thanks to Andrzej W=C4=85sowski and Dan Luecking, I now know how to=20 run the output of 'set term mp' through mpost + latex + dvips to see what it is doing. With their guidance I have patched the terminal to support text rotation and filled boxes. I do not know how to add pattern-fill, but for the mom= ent I have dummied it up with different solid fill densities. However, I notice that the line colors and point styles do not match those of other terminal types. We changed many (though not all) terminals a year ago to match each other as closely as possible at least for the first 8 line colors and first 12 point styles. In particula= r, almost all terminals supporting color assign linetypes 1, 2, 3 to be red, green, blue. Metapost uses instead black, red, blue. While I can see the logic behind having "lt 1" produce a black line, the other terminal types don't do it that way. Instead, all terminal type= s that I know of provide black (or at least "foreground") as linetype -1. Should I re-order the line and point types in the metapost driver to match other drivers? =20 --=20 Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
|
From: Andrzej <wa...@ga...> - 2004-06-08 22:42:23
|
Ethan A Merritt <merritt <at> u.washington.edu> writes: > With their guidance I have patched the terminal to support text rotation > and filled boxes. I do not know how to add pattern-fill, but for the moment > I have dummied it up with different solid fill densities. This is actually the reason, why I have not followed-up yet. It is not straightforward to do pattern fills with metapost. I think one needs to draw the patterns (generate metapost code to do it) and then clip the to the box. So the first thing is to get the patterns. Where can I get the patterns that are supposed to be supported? Is it only boxes that we need to support with patterns? I have noticed also another difference. The grid lines are solid in metapost output and dashed (dotted?) in postscript output. Shall I look into making those the same? > However, I notice that the line colors and point styles do not match > those of other terminal types. We changed many (though not all) > terminals a year ago to match each other as closely as possible at > least for the first 8 line colors and first 12 point styles. In particular, > almost all terminals supporting color assign linetypes 1, 2, 3 to be > red, green, blue. Metapost uses instead black, red, blue. I think it is better to have consistent colors, although I find metapost driver colors much, much, much, oh so much, more appealing than postscript colors (at least the first 8). Since metapost supports RGB colors I think it should be easy to get exactly the same colors in both drivers (all 64 AFAIR). I hope that current metapost colors are among these. Andrzej |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-06-09 11:21:22
|
On Tue, 8 Jun 2004, Andrzej [utf-8] W=C4=85sowski wrote: > Ethan A Merritt <merritt <at> u.washington.edu> writes: >=20 > > With their guidance I have patched the terminal to support text r= otation > > and filled boxes. I do not know how to add pattern-fill, but for= the moment > > I have dummied it up with different solid fill densities. >=20 > This is actually the reason, why I have not followed-up yet. It is = not > straightforward to do pattern fills with metapost. I think one need= s to draw the > patterns (generate metapost code to do it) and then clip the to the= box.=20 Not necessarily. The general method for platforms that don't support patterns in some native way is to draw them as lots of individual lin= es. That's possible because we do pattern-filling only for boxes. > I have noticed also another difference. The grid lines are solid in > metapost output and dashed (dotted?) in postscript output. Shall I = look > into making those the same? Not necessary. As long as the grid line style is noticably lighter t= han the borders, you're OK. Some terminals dot it, some draw it in gray,= some others combine those two. --=20 Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Andrzej <wa...@ga...> - 2004-06-09 17:15:59
|
Hans-Bernhard Broeker <broeker <at> physik.rwth-aachen.de> writes: > Not necessarily. The general method for platforms that don't support > patterns in some native way is to draw them as lots of individual lines. > That's possible because we do pattern-filling only for boxes. Do you mean that there is some software level option that can be set in the terminal driver to make the calling code use primitive line drawing commands of the terminal to draw the patterns? If this less automatic, i.e. the driver has to do it itself, then indeed it should be fairly easy to write metapost macros filling boxes with patterns. In fact in metapost it is not that much harder to do it for any shapes. The main issue for me now is to know what are the patterns to be drawn. What is the chance that gnuplot will support pattern filling for other shapes than boxes in future? > > I have noticed also another difference. The grid lines are solid in > > metapost output and dashed (dotted?) in postscript output. Shall I look > > into making those the same? > > Not necessary. As long as the grid line style is noticably lighter than > the borders, you're OK. Some terminals dot it, some draw it in gray, some > others combine those two. The distinction between grid line style and other lines is fairly good with on screen postscript previewers, but it is much less clear on the printout IMHO. Personally I prefer solid grid to the dotted one, but I would make it slightly thinner. Andrzej |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-06-09 20:18:01
|
On Wednesday 09 June 2004 10:15 am, Andrzej W=C4=85sowski wrote: > > Do you mean that there is some software level option that can be set in > the terminal driver to make the calling code use primitive line drawing > commands of the terminal to draw the patterns? No. That's too hard. I found a pattern-fill extension to metapost on the web, but it requires a whole new wrapper layer on top of metapost which is probably more trouble than it is worth for this purpose. http://www.tug.org/tex-archive/graphics/metapost/macros/mpattern/ Also there is this document, which I am sure you can evaluate better than I can :-) http://www.gust.org.pl/PDF/BIUL/09/06-pb.pdf > What is the chance that gnuplot will support pattern filling for other > shapes than boxes in future? There's already a patch on SourceForge (#908456) that extends it to general polygons and filled curves. But has only been implemented for the cgm gd pdf post svg and x11 terminal types. > Personally I prefer solid grid to the dotted one, but I > would make it slightly thinner. That sounds fine. =2D-=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Andrzej <wa...@ga...> - 2004-06-10 07:58:52
|
Ethan Merritt <merritt <at> u.washington.edu> writes: > I found a pattern-fill extension to metapost on the web, but it requires > a whole new wrapper layer on top of metapost which is probably more > trouble than it is worth for this purpose. > http://www.tug.org/tex-archive/graphics/metapost/macros/mpattern/ > Also there is this document, which I am sure you can evaluate > better than I can > http://www.gust.org.pl/PDF/BIUL/09/06-pb.pdf I have seen these sites last weekend, in my initial investigation on what is available around. But know I have seen what kind of patterns we are talking about (like those at the output of test in x11 terminal aren't we?). I think drawing such simple pattern is sufficiently easy with basic commands, to avoid dependency on this extra packages. > > What is the chance that gnuplot will support pattern filling for other > > shapes than boxes in future? > > There's already a patch on SourceForge (#908456) that extends > it to general polygons and filled curves. But has only been implemented > for the cgm gd pdf post svg and x11 terminal types. Then I think I will do my "pattern" patch so that it is easily used for filling other shapes. In MetaPost one basically needs to fill in a bounding box instead of the box, and then clip. I guess that I should add pattern-filled polygons to this function: TERM_PUBLIC void MP_filled_polygon __PROTO((int, gpiPoint *)); But what is the interface for filled curves? Oh, and I will have to learn using pm3d to test this :). Andrzej |
|
From: Ethan A. M. <merritt@u.washington.edu> - 2004-06-11 00:46:32
|
On Thursday 10 June 2004 00:58, Andrzej W=C4=85sowski wrote: > I guess that I should add pattern-filled polygons to this function: > > TERM_PUBLIC void MP_filled_polygon __PROTO((int, gpiPoint *)); Correct. > But what is the interface for filled curves? The patch (#908456) adds a "style" parameter to the above function. The core routines all know about the current style already, via "set style fill <options>", so it's just a matter of teaching individual drivers to pay attention to this style when filling a polygon.=20 > Oh, and I will have to learn using pm3d to test this :). pm3d doesn't use pattern fill, so this is a separate question. To test the code you would use something like set style fill pattern 1 set style function filledcurve plot func1, func2, .... |
|
From: Arun P. <ape...@lb...> - 2004-06-09 21:33:49
|
Hi, Andrzej Wa;sowski wrote: > [...]I think it is better to have consistent colors, although I find metapost driver > colors much, much, much, oh so much, more appealing than postscript colors (at > least the first 8). [...] I hope that current metapost colors are among these. Me too, is there a way to keep the metapost colors somewhere in the colormap? As for the filled pattern it shouldn't be too hard to have the metapost driver add some code to the output that generates a pattern and clips it to the path (either box or polygon) if needed. just my two cents ARUN |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-06-09 21:54:48
|
On Wednesday 09 June 2004 02:30 pm, Arun Persaud wrote: > Hi, > > Andrzej Wa;sowski wrote: > > [...]I think it is better to have consistent colors, although I find > > metapost driver colors much, much, much, oh so much, more appealing > > than postscript colors (at least the first 8). [...] I hope that > > current metapost colors are among these. > > Me too, is there a way to keep the metapost colors somewhere in the > colormap? I wasn't proposing to change the nature of the colors, just re-arrange them into the order (names approximate) red green blue magenta cyan brown yellow to match other terminals like x11, png, and so on. I'd probably add an 8th color since black is removed from the list. The rationale is that if you compose a figure interactively and then change terminal types to save a permanent copy you want the colors to stay more or less as you saw them on the screen. But not all terminal types agree on colors anyhow, and I will leave them alone if metapost users prefer it that way. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2004-06-10 07:04:40
|
> The rationale is that if you compose a figure interactively > and then change terminal types to save a permanent copy > you want the colors to stay more or less as you saw them on > the screen. But not all terminal types agree on colors anyhow, > and I will leave them alone if metapost users prefer it that way. Colors in most/some terminals were reorganized in previous year(s) to match postscript as much as possible. You are welcome to match it for those still unchanged terminals as well. --- PM |
|
From: Lars H. <lhe...@us...> - 2004-06-09 11:58:32
|
Who switched on the "[gnuplot-beta]" tag in the subject: line (and did it wrong)? Please remove it. |
|
From: Andrzej <wa...@ga...> - 2004-06-12 09:51:51
|
Ethan A Merritt <merritt <at> u.washington.edu> writes: > Thanks to Andrzej Wąsowski and Dan Luecking, [...] > > With their guidance I have patched the terminal to support text rotation > and filled boxes. I do not know how to add pattern-fill, but for the moment > I have dummied it up with different solid fill densities. I got some time to make the pattern stuff, but I got a bit lost against what ptach should I code. Should I grab your "integrated" patch you posted some days ago? or perhaps you have made some other changes in potentially conflictful places in the metapost driver and want to repost? Or should I just cvs up and code against that? Andrzej |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X