Menu
▾
▴
gnuplot-beta
|
From: <mi...@ph...> - 2004-08-10 06:04:25
|
I had a look to changes in gnuplot cvs code over last >month. I'd to present few comments: *** There are new features in gnuplot. It would be nice to keep the NEWS file up-to-date (write new features and list new files added to demo). Also, a section "What is new in gnuplot 4.1" should be added to gnuplot.doc (containing a short form of news with links to docs). *** File ChangeLog.0: I propose it contains the following text on the first lines saying: This is ChangeLog for period from 1998 until gnuplot 4.0 release in April 2004============================================================================== *** Bug: On x11 (well, I haven't look to other terminals), points in the points and linepoints styles are "handicapped" -- look by a screen magnificator (xmag, kmag) to points obtained by: set size ratio 1 plot sin(x)/x w point pt 2 *** "help filledcurves" is not very well understandable. I propose the following: The `filledcurves` style is only relevant to 2-d plotting. Three variants are possible. The first two take a function or two columns of input data file, and may be tuned by options (see below). The default is `closed`, which treats the curve itself as a closed polygon. The second variant is to fill the area between the curve and a given axis, a horizontal or a vertical line, or a point. The third variant requires three columns of input data file: the x coordinate and two corresponding y coordinates (two curves); then, the area between the two curves is filled. Syntax: ... where the option (the first two variants only) can be ... Example for the third variant: plot 'data.dat' using 1:3:4 with filledcurves Note: ... *** postscript terminal contains new option "level2". I propose to add (or rather change to) option "level1" -- I guess it is more natural to restrict to PS Level 1 printer by saying "set term post level1" rather than "set term post nolevel2". (Also, it may become confusing whether "PS Level 3" printer is "level2" or "nolevel2"). **** When "make tutorial" (under Linux): File $HOME/.gnuplot should not be read -- it may contain an offending command which breaks the make process. Could the particular pieces of tutorial/Makefile[.am?] contain something like HOME=/dev/null gnuplot ... ? **** gnuplot.doc contains an example for using new features "title and xticlabels": 1. plot 'datafile' using 1:(f($2)/$4) title 2 with lines I guess that a more transparent example could be the same as few lines above: plot 'datafile' using 3:4 title 2 with lines (it is not clear what is f($2), and the result is obviously division, not remainder?) 2. In gnuplot.doc, I propose that "help xticlabels" go (reference) to the same entry as "help using xticlabels". *** Currently I have only web access to internet, so I cannot do any change into cvs. Thus I'd like to ask others to submit my proposed features, if agreed. Thanks. --- Petr |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-08-10 08:32:55
|
On Tue, 10 Aug 2004 mi...@ph... wrote: [I'll only comment some of the lots of issues...] > "help filledcurves" is not very well understandable. Well, since you wrote that originally, I guess it's yours to fix it up. ;-) > postscript terminal contains new option "level2". I propose to add (or > rather change to) option "level1" -- I guess it is more natural to restrict > to PS Level 1 printer by saying "set term post level1" rather than > "set term post nolevel2". (Also, it may become confusing whether > "PS Level 3" printer is "level2" or "nolevel2"). Agreed. > When "make tutorial" (under Linux): File $HOME/.gnuplot should not be read > -- it may contain an offending command which breaks the make process. > > Could the particular pieces of tutorial/Makefile[.am?] contain something > like > HOME=/dev/null gnuplot ... Feels more like there should be a '--no-startup-files' option (like emacs' -q one) to gnuplot. Futzing around with $HOME, even on a temporary basis doesn't feel like a good idea. > Currently I have only web access to internet, so I cannot do any change into > cvs. How long is "currently" expected to last? -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Lars H. <lhe...@us...> - 2004-08-10 08:54:47
|
> > When "make tutorial" (under Linux): File $HOME/.gnuplot should not be read > > -- it may contain an offending command which breaks the make process. > > > > Could the particular pieces of tutorial/Makefile[.am?] contain something > > like > > HOME=/dev/null gnuplot ... > > Feels more like there should be a '--no-startup-files' option (like emacs' > -q one) to gnuplot. Futzing around with $HOME, even on a temporary basis > doesn't feel like a good idea. Agreed, except that I don't want to see long options in order to be consistent with what is there already. |
|
From: <mi...@ph...> - 2004-08-11 06:14:22
|
>> "help filledcurves" is not very well understandable. > > Well, since you wrote that originally, I guess it's yours to fix it up. Originally yes, later edited by Ethan. Now I have reread the text and proposed changes, but I cannot commmit them myself :-( >> When "make tutorial" (under Linux): File $HOME/.gnuplot should not be >> read -- it may contain an offending command which breaks the make >> process. >> >> Could the particular pieces of tutorial/Makefile[.am?] contain >> something like >> HOME=/dev/null gnuplot ... > > Feels more like there should be a '--no-startup-files' option (like > emacs' -q one) to gnuplot. Futzing around with $HOME, even on a > temporary basis doesn't feel like a good idea. Probably only --no-startup-file, or --no-gnuplot-ini (there is always only one gnuplot.ini / .gnuplot read). --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-08-11 21:37:43
|
On Tuesday 10 August 2004 01:32 am, Hans-Bernhard Broeker wrote: > On Tue, 10 Aug 2004 mi...@ph... wrote: > > > postscript terminal contains new option "level2". I propose to add (or > > rather change to) option "level1" -- I guess it is more natural to restrict > > to PS Level 1 printer by saying "set term post level1" rather than > > "set term post nolevel2". (Also, it may become confusing whether > > "PS Level 3" printer is "level2" or "nolevel2"). > > Agreed. All the names I could think of are mis-leading. The option does not really turn off all Level 2 features, only some related to pattern-fill. I thought about making the command nopatternfill but that isn't right either because it can still handle pattern-fill for simple rectangles using Level 1 code. This all started as part of an attempt to make the PostScript output compatible with older versions of Adobe Illustrator. Maybe the option should just be: set term post ai The documentation can mention that the same work-around that allows Illustrator to handle the output may also be useful for some old printers that do not support Level 2 pattern definitions. Which brings us all the way around to the original question - if this option works (under whatever name), do we still need a separate driver ai.trm? -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-08-11 19:55:12
|
On Monday 09 August 2004 11:04 pm, mi...@ph... wrote: > Bug: > On x11 (well, I haven't look to other terminals), points in the points and > linepoints styles are "handicapped" -- look by a screen magnificator (xmag, > kmag) to points obtained by: > > set size ratio 1 > plot sin(x)/x w point pt 2 That is one strange bug you have found. The odd thing is that it seems to be a bug in the X server. I can run the same gnuplot_x11 executable on two different machines and get two different results. My best guess at the moment is that the key difference is which version of X11 is running, although it is also possible that it is a difference in the video driver rather than the version. The issue is whether the rendering engine does, or does not, draw the final pixel in a line segment that is at 45 degrees. Changing the drawing style from CapButt to CapRound while drawing points fixes this, at least on the machines I have tested. I can't think of any bad effects from this so I will make the change. I'm sure someone will speak up if it uncovers some complementary bug on other X11 display setups. Meanwhile I notice that the aspect ratio of the plot symbols scales with that of the current x11 window. This seems ugly to me, so I propose to also change the code so that the cross/plus/star/etc always has a 1:1 aspect ratio, even if the plot in which it lies does not. > > *** > > "help filledcurves" is not very well understandable. > I propose the following: > > The `filledcurves` style is only relevant to 2-d plotting. Three variants > are possible. The first two take a function or two columns of input data > file, and may be tuned by options (see below). The default is `closed`, which > treats the curve itself as a closed polygon. The second variant is to fill the area > between the curve and a given axis, a horizontal or a vertical line, or a > point. The third variant requires three columns of input data file: the x > coordinate and two corresponding y coordinates (two curves); then, the area between the > two curves is filled. > > Syntax: > ... > > where the option (the first two variants only) can be > > ... > > Example for the third variant: > plot 'data.dat' using 1:3:4 with filledcurves > > Note: ... > > *** > > postscript terminal contains new option "level2". I propose to add (or > rather change to) option "level1" -- I guess it is more natural to restrict > to PS Level 1 printer by saying "set term post level1" rather than > "set term post nolevel2". (Also, it may become confusing whether > "PS Level 3" printer is "level2" or "nolevel2"). > > **** > > When "make tutorial" (under Linux): File $HOME/.gnuplot should not be read > -- it may contain an offending command which breaks the make process. > > Could the particular pieces of tutorial/Makefile[.am?] contain something > like > HOME=/dev/null gnuplot ... > ? > > **** > > gnuplot.doc contains an example for using new features "title and > xticlabels": > 1. > plot 'datafile' using 1:(f($2)/$4) title 2 with lines > > I guess that a more transparent example could be the same as few lines > above: > > plot 'datafile' using 3:4 title 2 with lines > > (it is not clear what is f($2), and the result is obviously division, not > remainder?) > > > 2. In gnuplot.doc, I propose that "help xticlabels" go (reference) to the > same entry as "help using xticlabels". > > *** > > > Currently I have only web access to internet, so I cannot do any change into > cvs. Thus I'd like to ask others to submit my proposed features, if > agreed. Thanks. > --- > Petr > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > > -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-08-11 20:50:40
|
Ethan Merritt wrote: >On Monday 09 August 2004 11:04 pm, mi...@ph... wrote: > > >>Bug: >>On x11 (well, I haven't look to other terminals), points in the points and >>linepoints styles are "handicapped" -- look by a screen magnificator (xmag, >>kmag) to points obtained by: >> >>set size ratio 1 >>plot sin(x)/x w point pt 2 >> >> > >That is one strange bug you have found. The odd thing is that it seems >to be a bug in the X server. I can run the same gnuplot_x11 executable >on two different machines and get two different results. My best guess >at the moment is that the key difference is which version of X11 is >running, although it is also possible that it is a difference in the video >driver rather than the version. The issue is whether the rendering >engine does, or does not, draw the final pixel in a line segment that is >at 45 degrees. Changing the drawing style from CapButt to CapRound >while drawing points fixes this, at least on the machines I have tested. >I can't think of any bad effects from this so I will make the change. >I'm sure someone will speak up if it uncovers some complementary >bug on other X11 display setups. > >Meanwhile I notice that the aspect ratio of the plot symbols >scales with that of the current x11 window. This seems ugly to me, >so I propose to also change the code so that the cross/plus/star/etc >always has a 1:1 aspect ratio, even if the plot in which it lies does not. > I'm seeing the same kind of thing for the + (pluses) as well as the crosses. It appears like the last pixel is not being drawn. This *is* very odd. How could this have gone unnoticed when who every programmed it, programmed it? Dan > > |
|
From: Dave D. <dde...@es...> - 2004-08-12 10:44:47
|
Ethan Merritt <merritt@u.washington.edu> writes:
> On Monday 09 August 2004 11:04 pm, mi...@ph... wrote:
>> Bug:
>> On x11 (well, I haven't look to other terminals), points in the points and
>> linepoints styles are "handicapped" -- look by a screen magnificator (xmag,
>> kmag) to points obtained by:
>>
>> set size ratio 1
>> plot sin(x)/x w point pt 2
>
> That is one strange bug you have found. The odd thing is that it seems
> to be a bug in the X server. I can run the same gnuplot_x11 executable
> on two different machines and get two different results. My best guess
> at the moment is that the key difference is which version of X11 is
> running, although it is also possible that it is a difference in the video
> driver rather than the version. The issue is whether the rendering
> engine does, or does not, draw the final pixel in a line segment that is
> at 45 degrees. Changing the drawing style from CapButt to CapRound
> while drawing points fixes this, at least on the machines I have tested.
> I can't think of any bad effects from this so I will make the change.
> I'm sure someone will speak up if it uncovers some complementary
> bug on other X11 display setups.
>
Does gnuplot use zero-width lines for these ? I have a vague
recollection that if linewidth is set to 0, the X server can use a
device-specific algorithm for drawing the pixels. A linewidth of 1
specifies the exact semantics which must be followed.
Yeah - looks like :
else if (*buffer == 'P') {
/* linux sscanf does not like %1d%4d%4d" with Oxxxxyyyy */
/* sscanf(buffer, "P%1d%4d%4d", &point, &x, &y); */
point = buffer[1] - '0';
sscanf(buffer + 2, "%4d%4d", &x, &y);
if (point == 7) {
/* set point size */
px = (int) (x * xscale * pointsize);
py = (int) (y * yscale * pointsize);
} else {
if (type != LineSolid || width != 0) { /* select solid line */
XSetLineAttributes(dpy, gc, 0, LineSolid, CapButt, JoinBevel);
}
- try setting the linewidth param to 1 in the XSetLineAttributes call.
dd
--
Dave Denholm <dde...@es...> http://www.esmertec.com
|
|
From: Daniel J S. <dan...@ie...> - 2004-08-12 12:35:54
|
Dave Denholm wrote:
>Ethan Merritt <merritt@u.washington.edu> writes:
>
>
>
>>On Monday 09 August 2004 11:04 pm, mi...@ph... wrote:
>>
>>
>>>Bug:
>>>On x11 (well, I haven't look to other terminals), points in the points and
>>>linepoints styles are "handicapped" -- look by a screen magnificator (xmag,
>>>kmag) to points obtained by:
>>>
>>>set size ratio 1
>>>plot sin(x)/x w point pt 2
>>>
>>>
>>That is one strange bug you have found. The odd thing is that it seems
>>to be a bug in the X server. I can run the same gnuplot_x11 executable
>>on two different machines and get two different results. My best guess
>>at the moment is that the key difference is which version of X11 is
>>running, although it is also possible that it is a difference in the video
>>driver rather than the version. The issue is whether the rendering
>>engine does, or does not, draw the final pixel in a line segment that is
>>at 45 degrees. Changing the drawing style from CapButt to CapRound
>>while drawing points fixes this, at least on the machines I have tested.
>>I can't think of any bad effects from this so I will make the change.
>>I'm sure someone will speak up if it uncovers some complementary
>>bug on other X11 display setups.
>>
>>
>>
>
>
>Does gnuplot use zero-width lines for these ? I have a vague
>recollection that if linewidth is set to 0, the X server can use a
>device-specific algorithm for drawing the pixels. A linewidth of 1
>specifies the exact semantics which must be followed.
>
>
>Yeah - looks like :
>
> else if (*buffer == 'P') {
> /* linux sscanf does not like %1d%4d%4d" with Oxxxxyyyy */
> /* sscanf(buffer, "P%1d%4d%4d", &point, &x, &y); */
> point = buffer[1] - '0';
> sscanf(buffer + 2, "%4d%4d", &x, &y);
> if (point == 7) {
> /* set point size */
> px = (int) (x * xscale * pointsize);
> py = (int) (y * yscale * pointsize);
> } else {
> if (type != LineSolid || width != 0) { /* select solid line */
> XSetLineAttributes(dpy, gc, 0, LineSolid, CapButt, JoinBevel);
> }
>
>
>- try setting the linewidth param to 1 in the XSetLineAttributes call.
>
I printed out the numbers and verified that
plot->lwidth
is 1. I've concluded, like Ethan, that the behavior of this routine
doesn't match what the documentation says. (It's as though there is
some confusion between CapButt and CapNotLast.) Also, I think CapRound,
i.e. the endpoints of the lines are rounded when they get thicker would
look just as good as not rounding when dealing with symbols.
Dan
|
|
From: Dave D. <dde...@es...> - 2004-08-12 13:54:23
|
Daniel J Sebald <dan...@ie...> writes:
> Dave Denholm wrote:
>
>>Ethan Merritt <merritt@u.washington.edu> writes:
>>
>>
>>>On Monday 09 August 2004 11:04 pm, mi...@ph... wrote:
>>>
>>>>Bug:
>>>>On x11 (well, I haven't look to other terminals), points in the points and
>>>>linepoints styles are "handicapped" -- look by a screen magnificator (xmag,
>>>>kmag) to points obtained by:
>>>>
>>>>set size ratio 1
>>>>plot sin(x)/x w point pt 2
>>>>
>>>That is one strange bug you have found. The odd thing is that it seems
>>>to be a bug in the X server. I can run the same gnuplot_x11 executable
>>>on two different machines and get two different results. My best guess
>>>at the moment is that the key difference is which version of X11 is
>>>running, although it is also possible that it is a difference in the video
>>>driver rather than the version. The issue is whether the rendering
>>>engine does, or does not, draw the final pixel in a line segment that is
>>>at 45 degrees. Changing the drawing style from CapButt to CapRound
>>>while drawing points fixes this, at least on the machines I have tested.
>>>I can't think of any bad effects from this so I will make the change.
>>>I'm sure someone will speak up if it uncovers some complementary
>>>bug on other X11 display setups.
>>>
>>>
>>
>>
>>Does gnuplot use zero-width lines for these ? I have a vague
>>recollection that if linewidth is set to 0, the X server can use a
>>device-specific algorithm for drawing the pixels. A linewidth of 1
>>specifies the exact semantics which must be followed.
>>
>>
>>Yeah - looks like :
>>
>> else if (*buffer == 'P') {
>> /* linux sscanf does not like %1d%4d%4d" with Oxxxxyyyy */
>> /* sscanf(buffer, "P%1d%4d%4d", &point, &x, &y); */
>> point = buffer[1] - '0';
>> sscanf(buffer + 2, "%4d%4d", &x, &y);
>> if (point == 7) {
>> /* set point size */
>> px = (int) (x * xscale * pointsize);
>> py = (int) (y * yscale * pointsize);
>> } else {
>> if (type != LineSolid || width != 0) { /* select solid line */
>> XSetLineAttributes(dpy, gc, 0, LineSolid, CapButt, JoinBevel);
>> }
>>
>>
>>- try setting the linewidth param to 1 in the XSetLineAttributes call.
>>
>
> I printed out the numbers and verified that
>
> plot->lwidth
>
> is 1. I've concluded, like Ethan, that the behavior of this routine
> doesn't match what the documentation says. (It's as though there is
> some confusion between CapButt and CapNotLast.) Also, I think
> CapRound, i.e. the endpoints of the lines are rounded when they get
> thicker would look just as good as not rounding when dealing with
> symbols.
>
Sorry, I should have been clearer. I don't mean the gnuplot line
width. I mean the X linewidth set into the GC when drawing the symbol.
X allows a linewidth of 0 to mean a fast line draw, not necessarily
conforming to all the specs. ie it is allowed to be different on
different X servers.
You need to set the X GC linewidth to 1 to get a fully-conforming
line.
dd
--
Dave Denholm <dde...@es...> http://www.esmertec.com
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-08-12 16:29:49
|
On Thursday 12 August 2004 03:44 am, Dave Denholm wrote:
> if (type != LineSolid || width != 0) { /* select solid line */
> XSetLineAttributes(dpy, gc, 0, LineSolid, CapButt, JoinBevel);
> }
>
> - try setting the linewidth param to 1 in the XSetLineAttributes call.
Thanks for the tip. The change I actually made was to unconditionally call
/* Force line type to solid, with round ends */
XSetLineAttributes(dpy, *current_gc, plot->lwidth, LineSolid, CapRound, JoinRound);
I was under the impression that passing plot->lwidth was essentially a no-op,
since that should have been the current state anyhow. I made it unconditional
in order to force the CapRound attribute. But if I understand your summary of
X oddities, it may actually be the explicit linewidth rather than the CapRound
that causes the observed problem to go away.
Daniel, do you care enough to investigate further?
I'm happy just to leave it as it is, since it seems to work.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Dave D. <dde...@es...> - 2004-08-12 16:34:56
|
Ethan Merritt <merritt@u.washington.edu> writes:
> On Thursday 12 August 2004 03:44 am, Dave Denholm wrote:
>> if (type != LineSolid || width != 0) { /* select solid line */
>> XSetLineAttributes(dpy, gc, 0, LineSolid, CapButt, JoinBevel);
>> }
>>
>> - try setting the linewidth param to 1 in the XSetLineAttributes call.
>
> Thanks for the tip. The change I actually made was to unconditionally call
>
> /* Force line type to solid, with round ends */
> XSetLineAttributes(dpy, *current_gc, plot->lwidth, LineSolid, CapRound, JoinRound);
>
> I was under the impression that passing plot->lwidth was essentially a no-op,
> since that should have been the current state anyhow. I made it unconditional
> in order to force the CapRound attribute. But if I understand your summary of
> X oddities, it may actually be the explicit linewidth rather than the CapRound
> that causes the observed problem to go away.
>
I don't think plot->lwidth is appropriate for drawing symbols - if
you've got a very wide (gnuplot) line width, the outline of the points
will be drawn with a wide line.
But maybe that is what you want.
> Daniel, do you care enough to investigate further?
> I'm happy just to leave it as it is, since it seems to work.
>
> --
> Ethan A Merritt merritt@u.washington.edu
> Biomolecular Structure Center
> Mailstop 357742
> University of Washington, Seattle, WA 98195
--
Dave Denholm <dde...@es...> http://www.esmertec.com
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-08-12 17:04:57
|
On Thursday 12 August 2004 09:34 am, Dave Denholm wrote: > > I don't think plot->lwidth is appropriate for drawing symbols - if > you've got a very wide (gnuplot) line width, the outline of the points > will be drawn with a wide line. > > But maybe that is what you want. I would think the normal expectation if you set a default line width is that everything, including point symbols, will use this default width. If you really want to mix linewidths in the linespoints style, you can instead use plot '<foo>' with lines lw <n>, '' with points lw 0 -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-08-12 17:12:42
|
Dave Denholm wrote:
>Ethan Merritt <merritt@u.washington.edu> writes:
>
>
>
>>On Thursday 12 August 2004 03:44 am, Dave Denholm wrote:
>>
>>
>>> if (type != LineSolid || width != 0) { /* select solid line */
>>> XSetLineAttributes(dpy, gc, 0, LineSolid, CapButt, JoinBevel);
>>> }
>>>
>>>- try setting the linewidth param to 1 in the XSetLineAttributes call.
>>>
>>>
>>Thanks for the tip. The change I actually made was to unconditionally call
>>
>> /* Force line type to solid, with round ends */
>> XSetLineAttributes(dpy, *current_gc, plot->lwidth, LineSolid, CapRound, JoinRound);
>>
>>I was under the impression that passing plot->lwidth was essentially a no-op,
>>since that should have been the current state anyhow. I made it unconditional
>>in order to force the CapRound attribute. But if I understand your summary of
>>X oddities, it may actually be the explicit linewidth rather than the CapRound
>>that causes the observed problem to go away.
>>
>>
>>
>
>
>I don't think plot->lwidth is appropriate for drawing symbols - if
>you've got a very wide (gnuplot) line width, the outline of the points
>will be drawn with a wide line.
>
>But maybe that is what you want.
>
I think it's fine so long as independent control, as it currently
exists, is there, i.e. that example
plot '-' w points lw 10 pt 1 ps 10
0 0
end
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2004-08-12 17:10:36
|
Ethan Merritt wrote:
>On Thursday 12 August 2004 03:44 am, Dave Denholm wrote:
>
>
>> if (type != LineSolid || width != 0) { /* select solid line */
>> XSetLineAttributes(dpy, gc, 0, LineSolid, CapButt, JoinBevel);
>> }
>>
>>- try setting the linewidth param to 1 in the XSetLineAttributes call.
>>
>>
>
>Thanks for the tip. The change I actually made was to unconditionally call
>
> /* Force line type to solid, with round ends */
> XSetLineAttributes(dpy, *current_gc, plot->lwidth, LineSolid, CapRound, JoinRound);
>
>I was under the impression that passing plot->lwidth was essentially a no-op,
>since that should have been the current state anyhow. I made it unconditional
>in order to force the CapRound attribute. But if I understand your summary of
>X oddities, it may actually be the explicit linewidth rather than the CapRound
>that causes the observed problem to go away.
>
>Daniel, do you care enough to investigate further?
>I'm happy just to leave it as it is, since it seems to work.
>
Well, I looked at this. The value that gnuplot_x11 was putting in for
plot->lwidth is 1, not zero. So that means the following property of
CapNotLast should *not* apply.
CapNotLast This is equivalent to CapButt except that for a line-width of
zero the final endpoint is not drawn.
Still, originally it was CapButt, which shouldn't have this "final
endpoint is not drawn" property, anyway. I also tried "XDrawLine"
instead of the "XDrawSegments". That worked the same way. But I see
that if one sets the "ps 2", it appears to fix the problem. So again,
I'm confused (very) and I agree with Ethan that there is a bug in the
X11 software. CapButt is not being interpretted according to
documentation, and a the line width of one is treated as though it were
line width zero.
Anyway, if you want to get an idea of what Ethan's change has done, try
plot '-' w points lw 10 pt 1 ps 10
0 0
end
And try it with "pt 2". I'm fine with that rounding (although the X11
routines don't seem to have the radius around the ends of lines just
right), unless someone wants to argue the WYSIWYG principle that it
should match the style the other terminals use. With a line size of 1
or 2, these effects are hardly noticable.
However, if the rounded line ends are not acceptable, another
alternative to get around this bug would be the "CapProjecting" option.
That has square line ends that extend half line width past the end
point. It doesn't appear to have this problem that line width of 1 that
is occuring with CapButt. I've a feeling that most will prefer the
CapProjecting option over CapRound because, as I've noticed, the rounded
part seems a little askew for some reason.
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-08-12 17:22:52
|
On Thursday 12 August 2004 10:35 am, Daniel J Sebald wrote: > Well, I looked at this. The value that gnuplot_x11 was putting in for > plot->lwidth is 1, not zero. So that means the following property of > CapNotLast should *not* apply. Yes, but Dave's point was that the call used to look like this: XSetLineAttributes(dpy, gc, 0, LineSolid, CapButt, JoinBevel); so the linewidth was set to 0 no matter what the value of plot->lwidth. He also says that x11 apparently interprets this as a license to use whatever line style is fastest. So if it thinks CapNotLast is faster, it will use that. If that is the correct analysis, then it is indeed a property of x11 itself but since it is documented that way I guess we don't get to call it a bug. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-08-12 17:29:30
|
Ethan Merritt wrote: >On Thursday 12 August 2004 10:35 am, Daniel J Sebald wrote: > > >>Well, I looked at this. The value that gnuplot_x11 was putting in for >>plot->lwidth is 1, not zero. So that means the following property of >>CapNotLast should *not* apply. >> >> > >Yes, but Dave's point was that the call used to look like this: > XSetLineAttributes(dpy, gc, 0, LineSolid, CapButt, JoinBevel); > >so the linewidth was set to 0 no matter what the value of plot->lwidth. >He also says that x11 apparently interprets this as a license to use >whatever line style is fastest. So if it thinks CapNotLast is faster, it >will use that. > Oh, now I see what Dave was saying. But still, CapButt with point->lwidth = 1 removes the last pixel. That doesn't agree with the documentation. Dan |
×
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