You can subscribe to this list here.
2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(83) |
Nov
(57) |
Dec
(111) |
2004 |
Jan
(38) |
Feb
(121) |
Mar
(107) |
Apr
(241) |
May
(102) |
Jun
(190) |
Jul
(239) |
Aug
(158) |
Sep
(184) |
Oct
(193) |
Nov
(47) |
Dec
(68) |
2005 |
Jan
(190) |
Feb
(105) |
Mar
(99) |
Apr
(65) |
May
(92) |
Jun
(250) |
Jul
(197) |
Aug
(128) |
Sep
(101) |
Oct
(183) |
Nov
(186) |
Dec
(42) |
2006 |
Jan
(102) |
Feb
(122) |
Mar
(154) |
Apr
(196) |
May
(181) |
Jun
(281) |
Jul
(310) |
Aug
(198) |
Sep
(145) |
Oct
(188) |
Nov
(134) |
Dec
(90) |
2007 |
Jan
(134) |
Feb
(181) |
Mar
(157) |
Apr
(57) |
May
(81) |
Jun
(204) |
Jul
(60) |
Aug
(37) |
Sep
(17) |
Oct
(90) |
Nov
(122) |
Dec
(72) |
2008 |
Jan
(130) |
Feb
(108) |
Mar
(160) |
Apr
(38) |
May
(83) |
Jun
(42) |
Jul
(75) |
Aug
(16) |
Sep
(71) |
Oct
(57) |
Nov
(59) |
Dec
(152) |
2009 |
Jan
(73) |
Feb
(213) |
Mar
(67) |
Apr
(40) |
May
(46) |
Jun
(82) |
Jul
(73) |
Aug
(57) |
Sep
(108) |
Oct
(36) |
Nov
(153) |
Dec
(77) |
2010 |
Jan
(42) |
Feb
(171) |
Mar
(150) |
Apr
(6) |
May
(22) |
Jun
(34) |
Jul
(31) |
Aug
(38) |
Sep
(32) |
Oct
(59) |
Nov
(13) |
Dec
(62) |
2011 |
Jan
(114) |
Feb
(139) |
Mar
(126) |
Apr
(51) |
May
(53) |
Jun
(29) |
Jul
(41) |
Aug
(29) |
Sep
(35) |
Oct
(87) |
Nov
(42) |
Dec
(20) |
2012 |
Jan
(111) |
Feb
(66) |
Mar
(35) |
Apr
(59) |
May
(71) |
Jun
(32) |
Jul
(11) |
Aug
(48) |
Sep
(60) |
Oct
(87) |
Nov
(16) |
Dec
(38) |
2013 |
Jan
(5) |
Feb
(19) |
Mar
(41) |
Apr
(47) |
May
(14) |
Jun
(32) |
Jul
(18) |
Aug
(68) |
Sep
(9) |
Oct
(42) |
Nov
(12) |
Dec
(10) |
2014 |
Jan
(14) |
Feb
(139) |
Mar
(137) |
Apr
(66) |
May
(72) |
Jun
(142) |
Jul
(70) |
Aug
(31) |
Sep
(39) |
Oct
(98) |
Nov
(133) |
Dec
(44) |
2015 |
Jan
(70) |
Feb
(27) |
Mar
(36) |
Apr
(11) |
May
(15) |
Jun
(70) |
Jul
(30) |
Aug
(63) |
Sep
(18) |
Oct
(15) |
Nov
(42) |
Dec
(29) |
2016 |
Jan
(37) |
Feb
(48) |
Mar
(59) |
Apr
(28) |
May
(30) |
Jun
(43) |
Jul
(47) |
Aug
(14) |
Sep
(21) |
Oct
(26) |
Nov
(10) |
Dec
(2) |
2017 |
Jan
(26) |
Feb
(27) |
Mar
(44) |
Apr
(11) |
May
(32) |
Jun
(28) |
Jul
(75) |
Aug
(45) |
Sep
(35) |
Oct
(285) |
Nov
(99) |
Dec
(16) |
2018 |
Jan
(8) |
Feb
(8) |
Mar
(42) |
Apr
(35) |
May
(23) |
Jun
(12) |
Jul
(16) |
Aug
(11) |
Sep
(8) |
Oct
(16) |
Nov
(5) |
Dec
(8) |
2019 |
Jan
(9) |
Feb
(28) |
Mar
(4) |
Apr
(10) |
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(23) |
Dec
(3) |
2020 |
Jan
(19) |
Feb
(3) |
Mar
(22) |
Apr
(17) |
May
(10) |
Jun
(69) |
Jul
(18) |
Aug
(23) |
Sep
(25) |
Oct
(11) |
Nov
(20) |
Dec
(9) |
2021 |
Jan
(1) |
Feb
(7) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(6) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(23) |
2022 |
Jan
(23) |
Feb
(9) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(6) |
Aug
(8) |
Sep
(30) |
Oct
(5) |
Nov
(4) |
Dec
(6) |
2023 |
Jan
(2) |
Feb
(5) |
Mar
(7) |
Apr
(3) |
May
(8) |
Jun
(45) |
Jul
(8) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(7) |
Dec
(2) |
2024 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-26 16:50:09
|
On Tuesday 26 July 2005 08:41 am, Juergen Wieferink wrote: > Hi, > > I get a strange error message in recent CVS: > > ... > > Terminal type set to 'x11' > gnuplot> test palette > gnuplot> test palette > line 835: undefined variable: character Simpler example of breakage: gnuplot> set title offset 1,1 undefined variable: offset What has happened is that whenever the keyword "title" is seen, the parser calls try_to_get_string(), which then chokes if the next token on the line is a keyword rather than a string or an expression. I don't know when or how this broke - possibly at the time of Harald Harders' addition of the generalized "offset" keyword for all string positions. I'm not sure yet where to fix it. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Petr M. <mi...@ph...> - 2005-07-26 16:03:25
|
> I get a strange error message in recent CVS: > > ... > > Terminal type set to 'x11' > gnuplot> test palette > gnuplot> test palette > line 835: undefined variable: character It fails in command.c:test_palette_subcommand(). Firstly it does save_set(f), then load_file(f, NULL, FALSE); The error message is after/during the 2nd load. I had a look what is inside of these temporary files. "diff" says that the 1st file contains set style histogram clustered gap 2 title 0, 0, 0 while the 2nd set style histogram clustered gap 2 title character 0, 0, 0 This looks like a bug in the "set" or "save" of histogram. --- PM |
From: Juergen W. <wie...@fr...> - 2005-07-26 15:42:23
|
Hi, I get a strange error message in recent CVS: ... Terminal type set to 'x11' gnuplot> test palette gnuplot> test palette line 835: undefined variable: character gnuplot> Juergen |
From: Hans-Bernhard B. <br...@ph...> - 2005-07-24 14:40:05
|
Ga=EBl Varoquaux wrote: > I just saw a figure in an article that had been made with gnuplot > and the author did not bother move the key, that fell right in the curv= e > (try "plot [0:1] x" to see what I mean).=20 The pilot error happened even earlier. It's almost never a good idea to = have a key as part of the plot itself if the plot is to be used as a=20 figure in a larger document. The description of what's in the plot=20 should go into the figure caption. > It might be interesting to have by default an automatic choice of > where the key goes : top right by default, then an choice of top left, > top middle, bottom right, bottom left, with a small algorithm that woul= d > choose the least encumbered part of the graph. The problem is that this algorithm would have to be anything but small=20 to be usable. In a nutshell, every object handed over from the core to=20 the terminal API for display would have to be analyzed and its effect=20 recorded. To do it meaningfully, we'ld need to know the size of the key = area before we output anything to the terminal, which would entail a=20 re-design of the core drawing routines. |
From: V. <gae...@no...> - 2005-07-24 11:16:10
|
On Sat, Jul 23, 2005 at 11:25:40PM -0500, Daniel J Sebald wrote: > Certainly possible Gael (but little time).=20 Sure. I am aware of this as I am myself struggling to get my project moving forward. > set key auto > ? Or simply from now one have "default" mean ostensibly auto placement= ? Both, I think : "set key auto", as a default value. > But... I suggest not emarking on such a feature until key layout for 2D= and=20 > 3D is made more uniform. I am making some progress on the povray terminal. You can have a look at http://www.eleves.ens.fr/home/varoquau/gnuplot where you will find the current povray.trm, and the demo file render through the povray terminal. I use this to debug the terminal. I am finishing it : debugging it, adjusting its overall structure, improving the quality of the povray file generated. Most of the common features of a gnuplot terminal are already implemented. As for the key, the title, the colorbox, and other 2D elements that have not to be placed on the plot I think it might be interesting to deal with them in the camera's space, rather than in the plot's space. This is how I position the lights and this is how I want to orient the text (though this is still to do). I have defined a "x,y,z" space, which is the plot's space, and an "a,b,c" space, which is the camera's space. Maybe when we build the 3D terminal API it might be interesting to have different calls to position elements in one frame or the other. Indeed "set key auto" in 3D implies that gnuplot will have to project the points of the plots to position the key, which, with a 3D compatible driver means redoing twice the same work. Yes I agree that we have to wait for the 2D/3D code restructuring before implementing a "set key auto", however I think it is something that we must keep in mind. -- Ga=EBl |
From: Daniel J S. <dan...@ie...> - 2005-07-24 04:21:14
|
Ga=EBl Varoquaux wrote: > I just saw a figure in an article that had been made with gnuplot > and the author did not bother move the key, that fell right in the curv= e > (try "plot [0:1] x" to see what I mean).=20 >=20 > It might be interesting to have by default an automatic choice of > where the key goes : top right by default, then an choice of top left, > top middle, bottom right, bottom left, with a small algorithm that woul= d > choose the least encumbered part of the graph. Certainly possible Gael (but little time). An "optimization" algorithm s= eems rather difficult, i.e., one that identifies the least encumbered par= t of the graph. It is difficult to define that in the first place. However, one could take the approach that 1) Compute the size of the key before rendering the plot. 2) Compute the position where that key would land for all nine possible i= nterior. 3) Keep a C array of counts of how many times a point lands in each of th= e nine possible key areas. 4) Choose the smallest count to be the key location. If there is a tie, = impose the priority top right, top left, etc. It would mean some extra overhead (quite a bit actually) required at the = low level of laying out points. And I assume you would propose something= like: set key auto ? Or simply from now one have "default" mean ostensibly auto placement? But... I suggest not emarking on such a feature until key layout for 2D a= nd 3D is made more uniform. Dan |
From: V. <gae...@no...> - 2005-07-23 17:40:40
|
I just saw a figure in an article that had been made with gnuplot and the author did not bother move the key, that fell right in the curve (try "plot [0:1] x" to see what I mean).=20 It might be interesting to have by default an automatic choice of where the key goes : top right by default, then an choice of top left, top middle, bottom right, bottom left, with a small algorithm that would choose the least encumbered part of the graph. -- Ga=EBl |
From: Juergen W. <wie...@fr...> - 2005-07-22 16:35:25
|
Petr Mikulik wrote: > >> => the output is clearly full of lines (png16m) or dots (png256). The > >> pdf file does not raster at all under gs 8.5, and with empty area under > >> gs 7.07. > > > > I really struggled with this anti-aliasing problem until "with > > image" was introduced. > > Wow, that's a pity you haven't struggled to figure out & submit this bug > over that long time since "with image". Well, I didn't quite exactly submit a bug report but I actually have reported the problem: news:cd5ia0$rch$1...@sa... Juergen |
From: Ethan A M. <merritt@u.washington.edu> - 2005-07-22 15:28:59
|
On Friday 22 July 2005 12:09 am, you wrote: > > I have > > gs -v > > ESP Ghostscript 7.07.2 (2003-11-19) > > I have 7.07.1 and 8.50 > > > After running your suggested test script through the > > current cvs version of gnuplot, I do not see the > > artifacts you describe > > > > - viewing in gv works fine > > Try to change scaling. I have done so. No problems. Same for scaling in Acrobat after conversion to pdf. > > - converting to png via ImageMagick's "convert" command > > works fine. (This calls gs, but I don't know the specific > > options it uses). > > Try "convert -density 23" (play with the number) and it will appear. density less than 72 never works well. This has nothing to do with gnuplot. If you need to convert to a smaller image, you should do something like "convert -density 150 -geometry 20%" so that anti-aliasing is used. > It depends on the output image resolution. I believe you. But that suggests that the undesired white lines are 1 pixel wide, and as you reduce the resolution that "1 pixel" becomes proportionally larger. That does indeed sound like it could the result of fill-with-no-stroke. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Daniel J S. <dan...@ie...> - 2005-07-22 15:27:12
|
Petr Mikulik wrote: >>> => the output is clearly full of lines (png16m) or dots (png256). The >>> pdf >>> file does not raster at all under gs 8.5, and with empty area under gs >>> 7.07. >> >> >> I really struggled with this anti-aliasing problem until "with >> image" was introduced. > > > Wow, that's a pity you haven't struggled to figure out & submit this bug > over that long time since "with image". > >> Would it be possible to draw the colorbox using the "image" code? I >> know that this doesn't generally solve the problem, but its effects >> would be reduced significantly. > > > Then it would require WITH_IMAGE to be compiled in (is it the way > "term->filled_gradient" should be implemented?) Actually, one could still use an image concept for plotting terminals yet not have WITH_IMAGE. But I agree, it seems odd to have the plot constructed of overlapping, potentially aliasing polygons, but not the colorbox. Dan |
From: Petr M. <mi...@ph...> - 2005-07-22 15:02:24
|
>> => the output is clearly full of lines (png16m) or dots (png256). The pdf >> file does not raster at all under gs 8.5, and with empty area under gs >> 7.07. > > I really struggled with this anti-aliasing problem until "with > image" was introduced. Wow, that's a pity you haven't struggled to figure out & submit this bug over that long time since "with image". > Would it be possible to draw the colorbox using the "image" code? I know > that this doesn't generally solve the problem, but its effects would be > reduced significantly. Then it would require WITH_IMAGE to be compiled in (is it the way "term->filled_gradient" should be implemented?) I would like to see first comments from local postscript gurus, then fill in ghostscript bug report, and wait to their answer. --- PM |
From: Hans-Bernhard B. <br...@ph...> - 2005-07-22 14:15:42
|
Petr Mikulik wrote: > Please try it with other resolutions. *Which ones*? I tried with both resolution at 50 dpi (the one you used in your PNG tests), and it didn't make a difference. > Try also rastering to png. That almost certainly doesn't make a difference. The gaps are produced in ghostscript's rastering engine, not in the output to some file format. |
From: Hans-Bernhard B. <br...@ph...> - 2005-07-22 13:06:15
|
Petr Mikulik wrote: > It does not help. Try to play with /F in the attached example. Also > added blue background. And tested with different direction of stacked > boxes. On of this windows box (GSview 4.6, AFPL Ghostscript 8.14, resolution 300 dpi, "Zoom Resolution" 300 dpi), I get no gaps with the script as sent (third version of /F active) --- but they appear if I select the first version (no stroke), and they also re-appear if I reduce the 'setlinewidth' to zero. So yes, the fix does appear to work. |
From: Petr M. <mi...@ph...> - 2005-07-22 12:52:32
|
>> Please try it with other resolutions. > > *Which ones*? I tried with both resolution at 50 dpi (the one you used in > your PNG tests), and it didn't make a difference. 17, 23, 32, 75, ... whatever random sequence. For some of them, you will see it. At least I do. >> Try also rastering to png. > > That almost certainly doesn't make a difference. The gaps are produced in > ghostscript's rastering engine, not in the output to some file format. Not gnuplot's "set term png", but ghostscript's "-sDEVICE=pngXXXX -rNN". See the script (command) in a previous mail. --- PM |
From: Petr M. <mi...@ph...> - 2005-07-22 12:31:12
|
> Petr Mikulik wrote: >> It does not help. Try to play with /F in the attached example. Also added >> blue background. And tested with different direction of stacked boxes. > > On of this windows box (GSview 4.6, AFPL Ghostscript 8.14, resolution 300 > dpi, "Zoom Resolution" 300 dpi), I get no gaps with the script as sent (third > version of /F active) --- but they appear if I select the first version (no > stroke), and they also re-appear if I reduce the 'setlinewidth' to zero. So > yes, the fix does appear to work. Please try it with other resolutions. Try also rastering to png. --- PM |
From: Juergen W. <wie...@fr...> - 2005-07-22 08:17:28
|
On Thursday, 2005-07-21 14:04, Petr Mikulik wrote: > => the output is clearly full of lines (png16m) or dots (png256). The pdf > file does not raster at all under gs 8.5, and with empty area under gs > 7.07. I really struggled with this anti-aliasing problem until "with image" was introduced. Would it be possible to draw the colorbox using the "image" code? I know that this doesn't generally solve the problem, but its effects would be reduced significantly. Juergen |
From: Petr M. <mi...@ph...> - 2005-07-22 07:09:21
|
> I have > gs -v > ESP Ghostscript 7.07.2 (2003-11-19) I have 7.07.1 and 8.50 > After running your suggested test script through the > current cvs version of gnuplot, I do not see the > artifacts you describe > > - viewing in gv works fine Try to change scaling. > - converting to png via ImageMagick's "convert" command > works fine. (This calls gs, but I don't know the specific > options it uses). Try "convert -density 23" (play with the number) and it will appear. > evidence that the bug is restricted to some very specific > gs versions. I don't think so, it depends on the output image resolution. --- PM |
From: Ethan M. <merritt@u.washington.edu> - 2005-07-21 18:49:04
|
Petr: You mentioned problems with both gs 7.07 and 8.something. I have gs -v ESP Ghostscript 7.07.2 (2003-11-19) After running your suggested test script through the current cvs version of gnuplot, I do not see the artifacts you describe - viewing in gv works fine - converting to pdf via ps2pdf and viewing in acrobet works fine - converting to png via ImageMagick's "convert" command works fine. (This calls gs, but I don't know the specific options it uses). I don't what this means, exactly, but I offer it as possible evidence that the bug is restricted to some very specific gs versions. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
From: Theo H. <th...@ph...> - 2005-07-21 16:46:17
|
Hans-Bernhard Broeker wrote: > Petr Mikulik wrote: > >> Well, it looks to me that it must be a bug in ghostscript -- some >> rounding of positions or whatever. Below is a simplest postscript code >> that demonstrates spurious lines in a pm3d-like image: > > > I don't fully agree that those lines are "spurious". Since you only > fill-ed the paths, but didn't stroke them, there are technically > gaps of zero pixel width between adjacent tiles. And just like lines of > width zero are not exactly the same thing as no lines at all, gaps of > width zero are not the same as no gap at all. For this to be a > meaningful test, the paths could have to be both filled and stroked. I just tried this. Fill-ing and stroke-ing gives much better results: the lines occur less frequently, and with less intensity. It seems to me that if filled polygons were stroke-d with a line width just slightly over the nominal value, the anti-aliasing problem with Ghostscript could be worked around. Unfortunately, I don't know enough Postscript to be able to test this. THeo |
From: Petr M. <mi...@ph...> - 2005-07-21 14:32:55
|
>> Well, it looks to me that it must be a bug in ghostscript -- some rounding >> of positions or whatever. Below is a simplest postscript code that >> demonstrates spurious lines in a pm3d-like image: > > I don't fully agree that those lines are "spurious". Since you only > fill-ed the paths, but didn't stroke them, there are technically > gaps of zero pixel width between adjacent tiles. And just like lines of > width zero are not exactly the same thing as no lines at all, gaps of width > zero are not the same as no gap at all. For this to be a meaningful test, > the paths could have to be both filled and stroked. It does not help. Try to play with /F in the attached example. Also added blue background. And tested with different direction of stacked boxes. > Fill-ing and stroke-ing gives much better results: the lines occur less > frequently, and with less intensity. I don't think so. Try to render the result into a png file (command in my previous mail), not onto x11 display. --- PM |
From: Hans-Bernhard B. <br...@ph...> - 2005-07-21 13:46:06
|
Petr Mikulik wrote: > Well, it looks to me that it must be a bug in ghostscript -- some > rounding of positions or whatever. Below is a simplest postscript code > that demonstrates spurious lines in a pm3d-like image: I don't fully agree that those lines are "spurious". Since you only fill-ed the paths, but didn't stroke them, there are technically gaps of zero pixel width between adjacent tiles. And just like lines of width zero are not exactly the same thing as no lines at all, gaps of width zero are not the same as no gap at all. For this to be a meaningful test, the paths could have to be both filled and stroked. |
From: Robert H. <en...@no...> - 2005-07-21 13:32:01
|
On Thu, 2005-07-21 at 14:15 +0200, Petr Mikulik wrote: > Questions to postscript gurus: > 1. Is it a gs bug? Yes I think so. Acrobat Distiller seems to be able to do the right thing. I've also seen similar bugs in output from various other programs. > 2. Can gnuplot overcome it? (Ignore antialiasing, ...) In your example, I modified the coordinates to give a slight overlap (making each rectangle 100.1 points wide) Whether it would be practical to do this in the postscript terminal is another matter. (I guess you'd have to find the centroid of each polygon, and then scale all the coordinates. Maybe there are other approaches, but I suggest leaving it - people can either a) live with it b) turn of antialiasing or c) wait until ghostscript fix the bug. You might want to post a bug on bugs.gnuplot.com Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
From: Petr M. <mi...@ph...> - 2005-07-21 12:28:38
|
>> Example: I want to add one more to avoid codes like 'if (term->name=="pm") > > That's a bad example, because it only occurs in code segments that are > already conditional on OS2. Making it a terminal entry test instead would > not actually simplify the call sites. I.e. it would still have to be > #ifdef OS2 > ... other OS2-specific code ... > if (term->whatever) > (term->whatever)(foo); > #endif Better example is (see set.c: "set mouse" switches on relevant menu items in PM terminal): #if defined(USE_MOUSE) && defined(OS2) update_menu_items_PM_terminal(); #endif => #if defined(USE_MOUSE) if (term->interactive) { term->interactive("mouse", "is", "enabled"); term->interactive("cursor", "is", "whatever"); term->interactive("allow", "q", "hotkey closes window"); } #endif >>> /* Used by post.trm to optimize the color box (called from color.c) >>> * Could be generalized to draw arbitrary rectangles with gradient >>> * fill. >>> */ >>> term->gradient_fill(int xl, int xh, int yl, int yh, struct gradient *g) >> >> I don't think that's necessary. Only those few pieces needing this can use >> "if (terminal is postscript) ..." as it is now. > > Wait. Isn't that exactly the opposite of what you were arguing above > with respect to "if (terminal is pm)" ? > > Anyhow, if you think it is useful to optimize a gradient-filled > rectangle, why limit it to postscript? libgd and (I think) svg also > could support this. Now I see the point. It is OK with me. --- PM |
From: Petr M. <mi...@ph...> - 2005-07-21 12:16:03
|
Well, it looks to me that it must be a bug in ghostscript -- some rounding of positions or whatever. Below is a simplest postscript code that demonstrates spurious lines in a pm3d-like image: %! /M {moveto} bind def /L {lineto} bind def /R {rmoveto} bind def /V {rlineto} bind def /C {closepath} def % Change the position, and spurious lines may move!!! -50 20 translate 1 1 translate 1 setlinewidth 0.5 setgray /y {100} def newpath 100 y M 100 0 V 0 100 V -100 0 V closepath fill newpath 200 y M 100 0 V 0 100 V -100 0 V closepath fill newpath 300 y M 100 0 V 0 100 V -100 0 V closepath fill newpath 400 y M 100 0 V 0 100 V -100 0 V closepath fill newpath 500 y M 100 0 V 0 100 V -100 0 V closepath fill /y {300} def newpath 100 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill newpath 200 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill newpath 300 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill newpath 400 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill newpath 500 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill showpage You can change the resolution "-r50" and see how the spurious lines are moving. a=demo2.ps A="-dGraphicsAlphaBits=4" D=png16m #D=png256 gs -q -r50 $A -sDEVICE=$D \ -dSAFER -dNOPAUSE -dBATCH -sOutputFile=$a.png $a -quit gqview $a.png Questions to postscript gurus: 1. Is it a gs bug? 2. Can gnuplot overcome it? (Ignore antialiasing, ...) --- PM |
From: Petr M. <mi...@ph...> - 2005-07-21 12:04:47
|
> So, the combination of `set palette defined` _and_ special-case treatment of > postscript causes anti-aliasing problems. I did some tests and this proposed patch: -"/f {rlineto fill} bind def\n", +"/f {rlineto gsave stroke grestore fill} bind def\n", -"/h {rlineto rlineto rlineto gsave fill grestore} bind def\n", +"/h {rlineto rlineto rlineto gsave stroke grestore gsave fill grestore} bind def\n", does not fix it. Try: set pm3d map set samples 200,200 set isosamples 100,100 splot x set term post color; set out 'a.ps' replot set term pop; set out and then you see spurious lines also with "set palette gray" or whichever palette you want. Actually, it does not depend on the palette at all!!! Put this below the current definition of /g: /g { pop 0.5 setgray } bind def => you see a sputious network of lines again. Further try this shell script to convert the postscript file to png or pdf: a=a.ps #A="-dTextAlphaBits=4 -dGraphicsAlphaBits=4" #A="-dTextAlphaBits=4" A="-dGraphicsAlphaBits=4" # Choose either of two: D=png16m #D=png256 gs -q -r50 $A -sDEVICE=$D \ -dSAFER -dNOPAUSE -dBATCH -sOutputFile=$a.png $a -quit ps2pdf $A $a $a.pdf gqview $a.png => the output is clearly full of lines (png16m) or dots (png256). The pdf file does not raster at all under gs 8.5, and with empty area under gs 7.07. So, the question is what's the simplest postscript file showing this behaviour? See next mail... --- PM |