Menu
▾
▴
gnuplot-beta
|
From: Mojca M. <moj...@gm...> - 2006-07-14 21:52:32
|
Hello, Can you please take a look at http://pub.mojca.org/gnuplot/bug/box-offset.png? The source is available in the same folder. Some boxes have an additional frame offset by 1 pixel, which seems pretty strange to me. This only happens at some specific sizes and some specific plots. When I tried the same example with the ConTeXt terminal (might be just any text-based terminal) I spotted the following in the output: fill unitsquare xyscaled (2.04,32.09) shifted (52.15,18.03); draw (52.15,18.03)--(52.15,50.11)--(54.18,50.11)--(54.18,18.03) --(52.15,18.03)--cycle; 32.09+18.03=50.12, but the rectangle is filled up to 50.11 There seems to be a round-off problem. Mojca |
|
From: <tim...@en...> - 2006-07-14 22:02:21
|
Mojca Miklavec wrote: > Hello, > > Can you please take a look at http://pub.mojca.org/gnuplot/bug/box-offs= et.png? > > The source is available in the same folder. Some boxes have an > additional frame offset by 1 pixel, which seems pretty strange to me. > This only happens at some specific sizes and some specific plots. > > When I tried the same example with the ConTeXt terminal (might be just > any text-based terminal) I spotted the following in the output: > > fill unitsquare xyscaled (2.04,32.09) shifted (52.15,18.03); > draw (52.15,18.03)--(52.15,50.11)--(54.18,50.11)--(54.18,18.03) > --(52.15,18.03)--cycle; > > 32.09+18.03=3D50.12, but the rectangle is filled up to 50.11 > > There seems to be a round-off problem. > > Mojca > =20 I think I have seen the same problem when trying to make the wxWidgets=20 terminal handle fillboxes correctly. I could not make 'test' and 'load=20 "fillstyle.dem"' work correctly at the same time. I chose to make 'test'=20 not to work, i.e. give the offset as you see in your graph, but make=20 fillstyle.dem work, as the latter is the real use case. (To see it in=20 the wxWidgets terminal, you have to disable the oversampling, otherwise=20 the offset is a decimal and is negligible in the output). Best regards, Timoth=E9e |
|
From: <tim...@en...> - 2006-07-14 22:35:44
|
Timoth=E9e Lecomte wrote: > Mojca Miklavec wrote: > =20 >> Hello, >> >> Can you please take a look at http://pub.mojca.org/gnuplot/bug/box-off= set.png? >> >> The source is available in the same folder. Some boxes have an >> additional frame offset by 1 pixel, which seems pretty strange to me. >> This only happens at some specific sizes and some specific plots. >> >> When I tried the same example with the ConTeXt terminal (might be just >> any text-based terminal) I spotted the following in the output: >> >> fill unitsquare xyscaled (2.04,32.09) shifted (52.15,18.03); >> draw (52.15,18.03)--(52.15,50.11)--(54.18,50.11)--(54.18,18.03) >> --(52.15,18.03)--cycle; >> >> 32.09+18.03=3D50.12, but the rectangle is filled up to 50.11 >> >> There seems to be a round-off problem. >> >> Mojca >> =20 >> =20 > I think I have seen the same problem when trying to make the wxWidgets=20 > terminal handle fillboxes correctly. I could not make 'test' and 'load=20 > "fillstyle.dem"' work correctly at the same time. I chose to make 'test= '=20 > not to work, i.e. give the offset as you see in your graph, but make=20 > fillstyle.dem work, as the latter is the real use case. (To see it in=20 > the wxWidgets terminal, you have to disable the oversampling, otherwise= =20 > the offset is a decimal and is negligible in the output). > > Best regards, > > Timoth=E9e > =20 And these offsets are also present in the X11 terminal. They are just=20 hidden most of the time by the two-pixels-thick lines. Look closely at=20 fillstyle.dem when it is using the one-pixel-thick lines, and you will=20 see them. Timoth=E9e |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-07-14 22:37:59
|
On Friday 14 July 2006 02:52 pm, Mojca Miklavec wrote: > > Can you please take a look at > http://pub.mojca.org/gnuplot/bug/box-offset.png? Interesting. I wonder if that is the same bug as reported in http://sourceforge.net/tracker/index.php?func=detail&aid=1515265&group_id=2055&atid=102055 > The source is available in the same folder. Some boxes have an > additional frame offset by 1 pixel, which seems pretty strange to me. > This only happens at some specific sizes and some specific plots. > > When I tried the same example with the ConTeXt terminal (might be > just any text-based terminal) I spotted the following in the output: > > fill unitsquare xyscaled (2.04,32.09) shifted (52.15,18.03); > draw (52.15,18.03)--(52.15,50.11)--(54.18,50.11)--(54.18,18.03) > --(52.15,18.03)--cycle; > > 32.09+18.03=50.12, but the rectangle is filled up to 50.11 > > There seems to be a round-off problem. > > Mojca > > > --------------------------------------------------------------------- >---- Using Tomcat but need to do more? Need to support web services, > security? Get stuff done quickly with pre-integrated technology to > make your job easier Download IBM WebSphere Application Server > v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121 >642 _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <tim...@en...> - 2006-07-15 05:17:27
|
Ethan Merritt wrote: > On Friday 14 July 2006 02:52 pm, Mojca Miklavec wrote: > =20 >> Can you please take a look at >> http://pub.mojca.org/gnuplot/bug/box-offset.png? >> =20 > > Interesting. > I wonder if that is the same bug as reported in > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1515265&gr= oup_id=3D2055&atid=3D102055 > =20 I don't think so. Your code for drawing the rectangles=20 (graphics.c:1452:place_rectangles) uses term->filled_polygon, not=20 term->fillbox. Mojca is seeing a problem with term->fillbox. Best regards, Timoth=E9e |
|
From: Mojca M. <moj...@gm...> - 2006-07-14 22:39:59
|
On 7/15/06, Timoth=E9e Lecomte wrote:
> Mojca Miklavec wrote:
> > On 7/15/06, Timoth=E9e Lecomte wrote:
> >> (To see it in the wxWidgets terminal, you have to disable the
> >> oversampling,
> >> otherwise the offset is a decimal and is negligible in the output).
> >
> > What does "disable oversampling" mean?
> It's a rendering option that can be set in the little configuration
> dialog in the wxWidgets terminal.
OK, a terminal-specific thing then. I do a similar thing as well
(units are 1/100 of a point), but that's because one point is simply
too big on a vector-based terminal.
> > (But this case could be handled properly/fixed with a simple "if-else"
> > case, I suppose.)
> Do you mean :
> If ("test") do something; else do something else;
> ?
>
> No, it's rather a rounding bug, as you said, and if it can be confirmed
> it has to be fixed in the gnuplot core.
Well, sure it has to be fixed in the core. I just wanted to say that
it probably can't be that difficult to solve. However increasing the
resolution is not the solution.
Imagine that you have a rectangular with x axes equal to 0.6 and 10.4.
This will draw
(1,y)--(10,y)
but
(10,y) shifted (1,y)
which results in
(1,y)--(11,y)
Mojca
(sorry for mixing off-list posts inbetween)
|
|
From: <tim...@en...> - 2006-07-14 23:14:11
|
Just to confirm the differences between the way the core uses fillboxes,=20 here is the code for one patterned rectangle generated by "test" to the=20 debug terminal : fillbox/clear at (418d,0d), area (12d,48d), style 146) move 418, 0 vect 418, 48 (0, 48) vect 430, 48 (12, 0) vect 430, 0 (0, -48) vect 418, 0 (-12, 0) to compare with what Mojca pointed out : > When I tried the same example with the ConTeXt terminal (might be just > any text-based terminal) I spotted the following in the output: > > fill unitsquare xyscaled (2.04,32.09) shifted (52.15,18.03); > draw (52.15,18.03)--(52.15,50.11)--(54.18,50.11)--(54.18,18.03) > --(52.15,18.03)--cycle; > > 32.09+18.03=3D50.12, but the rectangle is filled up to 50.11 > =20 In addition to this remark, here are some extract of the output of=20 fillstyle.dem : Legends of "plots ... with boxes" : fillbox/clear at (445d,348d), area (34d,5d), style 0) move 445, 348 vect 479, 348 (34, 0) =3D> 34 =3D area.x move 479, 348 (0, 0) vect 479, 352 (0, 4) =3D> 4 =3D area.y - 1 move 479, 352 (0, 0) vect 445, 352 (-34, 0) move 445, 352 (0, 0) vect 445, 348 (0, -4) (Hmm, and a couple of useless "move", by the way) Fillboxes in the plot : fillbox/clear at (88d,14d), area (21d,7d), style 1601) move 88, 14 vect 88, 20 (0, 6) =3D> 6 =3D area.y -1 vect 108, 20 (20, 0) =3D> 20 =3D area.x -1 vect 108, 14 (0, -6) vect 88, 14 (-20, 0) or fillbox/clear at (365d,14d), area (20d,12d), style 1601) line -2 move 365, 14 vect 365, 25 (0, 11) =3D> 11 =3D area.y -1 vect 384, 25 (19, 0) =3D> 19=3D area.x -1 vect 384, 14 (0, -11) vect 365, 14 (-19, 0) Conclusion : "test", fillboxes from plots with boxes, and fillboxes from=20 the legend of plots with boxes have to be harmonized. Timoth=E9e |
|
From: Mojca M. <moj...@gm...> - 2006-07-15 00:23:51
|
On 7/15/06, Timoth=E9e Lecomte wrote: > Legends of "plots ... with boxes" : > > fillbox/clear at (445d,348d), area (34d,5d), style 0) > move 445, 348 > vect 479, 348 (34, 0) =3D> 34 =3D area.x > move 479, 348 (0, 0) > vect 479, 352 (0, 4) =3D> 4 =3D area.y - 1 > move 479, 352 (0, 0) > vect 445, 352 (-34, 0) > move 445, 352 (0, 0) > vect 445, 348 (0, -4) > > (Hmm, and a couple of useless "move", by the way) I pointed that out already some time ago during the discussion about a separate command for "cycle"-ing the line (finishing it) in PostScript for example. Another similar discussion was started about color handling and all those unnecessary color specifications in epslatex. I filter out (some of) such commands in my terminal "manually", but this filtertering could be done for all terminals at once with some help of an additional clever layer between the core and terminals. (The optimisation of output code takes me quite some time and ugly code. This could be all handled in an additional layer and my code for the terminal would be much shorter then.) Mojca |
|
From: <tim...@en...> - 2006-07-15 07:04:43
|
Timoth=C3=A9e Lecomte a =C3=A9crit :
> Just to confirm the differences between the way the core uses fillboxes=
,
> here is the code for one patterned rectangle generated by "test" to the
> debug terminal :
>
> fillbox/clear at (418d,0d), area (12d,48d), style 146)
> move 418, 0
> vect 418, 48 (0, 48)
> vect 430, 48 (12, 0)
> vect 430, 0 (0, -48)
> vect 418, 0 (-12, 0)
This comes from the code (term.c:2032) :
(*t->fillbox) ( style, x, y, xl, yl );
(*t->move) (x,y);
(*t->vector)(x,y+yl);
(*t->vector)(x+xl,y+yl);
(*t->vector)(x+xl,y);
(*t->vector)(x,y);
which looks reasonable.
>
> to compare with what Mojca pointed out :
> (...)
> Legends of "plots ... with boxes" :
>
> fillbox/clear at (445d,348d), area (34d,5d), style 0)
> move 445, 348
> vect 479, 348 (34, 0) =3D> 34 =3D area.x
> move 479, 348 (0, 0)
> vect 479, 352 (0, 4) =3D> 4 =3D area.y - 1
> move 479, 352 (0, 0)
> vect 445, 352 (-34, 0)
> move 445, 352 (0, 0)
> vect 445, 348 (0, -4)
This comes from the code (graphics.c:4132) :
(*t->fillbox)(style_from_fill(fs),
xl + key_sample_left, yl - key_entry_height/4,
key_sample_right - key_sample_left,
key_entry_height/2);
(*t->move) (xl + key_sample_left, yl - key_entry_height/4);
(*t->vector)(xl + key_sample_right, yl - key_entry_height/4);
(*t->vector)(xl + key_sample_right, yl + key_entry_height/4);
(*t->vector)(xl + key_sample_left, yl + key_entry_height/4);
(*t->vector)(xl + key_sample_left, yl - key_entry_height/4);
And the heights are different because key_entry_height/2 !=3D=20
2*(key_entry_height/4) as soon as key_entry_height is not a multiple of=20
4. This one is easy to fix.
>
> (Hmm, and a couple of useless "move", by the way)
>
> Fillboxes in the plot :
>
> fillbox/clear at (88d,14d), area (21d,7d), style 1601)
> move 88, 14
> vect 88, 20 (0, 6) =3D> 6 =3D area.y -1
> vect 108, 20 (20, 0) =3D> 20 =3D area.x -1
> vect 108, 14 (0, -6)
> vect 88, 14 (-20, 0)
And this one comes from graphics.c:3408 :
x =3D xl;
y =3D yb;
w =3D xr - xl + 1;
h =3D yt - yb + 1;
(*t->fillbox) (style, x, y, w, h);
(*t->move) (xl, yb);
(*t->vector) (xl, yt);
(*t->vector) (xr, yt);
(*t->vector) (xr, yb);
(*t->vector) (xl, yb);
And the "+1" have been here since the fillbox style appeared in the CVS.
I think these "+1" should be removed for consistency with the other uses.=
I'll write a patch tomorrow or sunday. However, it will be needed to giv=
e a look to most (all?) of the terminals, and I am not sure I can do that=
in a short time.
Pre- or Post- 4.2 ?
Timoth=C3=A9e
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-16 18:44:32
|
On Saturday 15 July 2006 01:04 am, Timoth=C3=A9e Lecomte wrote: > this one comes from graphics.c:3408 : >=20 > x =3D xl; > y =3D yb; > w =3D xr - xl + 1; > h =3D yt - yb + 1; > (*t->fillbox) (style, x, y, w, h); > (*t->move) (xl, yb); > (*t->vector) (xl, yt); > (*t->vector) (xr, yt); > (*t->vector) (xr, yb); > (*t->vector) (xl, yb); >=20 > I think these "+1" should be removed for consistency with the other uses. I'm not so sure. The length in pixels of a line that starts at pixel x1 and ends at pixel x2 is (x2-x1)+1. So this code looks correct to me. It may well be that some terminals interpret w and h incorrectly, but that would be an error in the individual terminal driver, not the core code.=20 I guess the fundamental question is whether "width" should be interpreted as "number of horizontal pixels" or "x_right - x_left". These are not the same number. The former makes sense if you are thinking in terms of terminal coords (pixels); the latter makes sense if you are thinking in=20 terms of a continuous variable (plot x coordinate). Either way, we need to audit the code to be consistent. IMHO an off-by-one-pixel error is not release-critical, however. If there's a simple fix to the core code that makes things more consistent, fine. But if we need to poke about in all the individuals drivers, let's not do this for 4.2. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <br...@ph...> - 2006-07-17 21:42:11
|
Ethan A Merritt wrote: > The length in pixels of a line that starts at pixel x1 and ends at pixel x2 > is (x2-x1)+1. So this code looks correct to me. It may well be that some > terminals interpret w and h incorrectly, but that would be an error in the > individual terminal driver, not the core code. It can't really be an error --- for the simple, if somewhat shameful reason that the terminal API fails to actually specify what the 'width' paramter of the fillbox call is supposed to mean. In other words, we're staring directly into the face of a serious design flaw. That'll need to be ironed out. The only open question is: is it urgent enough to warrant delaying the release? I don't think so, based on the ratio of exposure versus complaints about this feature. > IMHO an off-by-one-pixel error is not release-critical, however. On the GUI terminals, it rather probably isn't --- they all effectively oversample, so the error is actually smaller than one pixel. The critical ones are the pure pixel formats (which don't oversample), and the vector-based ones (because they may get zoomed up uncontrollably, later). Which reminds me: in a certain light, this is a re-play of that bug concerning microscopic gaps in pm3d maps and colourboxes caused by aliasing artefacts, in our PostScript output rendered by Ghostscript. > If there's a simple fix to the core code that makes things more consistent, > fine. I doubt there can be. Such a fix would almost certainly be wrong for about as many terminal drivers as it might help. > But if we need to poke about in all the individuals drivers, let's > not do this for 4.2. Good point. This can become a first TODO list item for post-4.2. |
|
From: <tim...@en...> - 2006-07-17 22:13:28
|
Hans-Bernhard Br=F6ker wrote: > Ethan A Merritt wrote: > > =20 >> The length in pixels of a line that starts at pixel x1 and ends at pix= el x2 >> is (x2-x1)+1. So this code looks correct to me. It may well be that= some >> terminals interpret w and h incorrectly, but that would be an error in= the >> individual terminal driver, not the core code.=20 >> =20 > > It can't really be an error --- for the simple, if somewhat shameful=20 > reason that the terminal API fails to actually specify what the 'width'= =20 > paramter of the fillbox call is supposed to mean. In other words, we'r= e=20 > staring directly into the face of a serious design flaw. That'll need=20 > to be ironed out. The only open question is: is it urgent enough to=20 > warrant delaying the release? I don't think so, based on the ratio of > exposure versus complaints about this feature. > =20 I agree that it's not worth a delay. > =20 >> IMHO an off-by-one-pixel error is not release-critical, however. >> =20 > > On the GUI terminals, it rather probably isn't --- they all effectively= =20 > oversample, so the error is actually smaller than one pixel. The=20 > critical ones are the pure pixel formats (which don't oversample), and=20 > the vector-based ones (because they may get zoomed up uncontrollably,=20 > later). > =20 As far as I can tell, the X11 and Windows terminal are "pure pixel=20 formats". I think the offsets are not visible in the X11 terminal=20 because the default line style "-3" is two-pixel-thick. For sure, the=20 aqua and wxWidgets terminals oversample. > Which reminds me: in a certain light, this is a re-play of that bug=20 > concerning microscopic gaps in pm3d maps and colourboxes caused by=20 > aliasing artefacts, in our PostScript output rendered by Ghostscript. > =20 That's another problem. Antialiasing is rocket science, and when it=20 comes to adjacent polygons, most coverage-based algorithms will give=20 visible seams (look at the pm3d output for the aqua terminal as an=20 example : http://aquaterm.sourceforge.net/aqt/img/gnuplot1.png). Those=20 algorithms need additional information to perform well in this=20 particular case. Others which are more brute force, like=20 full-scene-anti-aliasing, may give a satisfying result at the price of=20 being more computation intensive. > This can become a first TODO list item for post-4.2. > =20 Ok. Post-4.2 will be exciting ! Best regards, Timoth=E9e |
.){kind=link}
|
From: <br...@ph...> - 2006-07-15 19:44:26
|
Mojca Miklavec wrote: > 32.09+18.03=50.12, ... only in a mathematically perfect world. In the real world, those numbers 32.09 and 18.03 just as probably are 32.086 and 18.026 (rounded for display) --- now you check beck if they really add up to 50.12. One of the reasons the terminal interface uses integers, not floating-point numbers, is exactly this: that's virtually impossible to get floating-point numbers to equal each other exactly and avoid round-off. |
|
From: Daniel J S. <dan...@ie...> - 2006-07-16 18:55:58
|
Ethan A Merritt wrote: > On Saturday 15 July 2006 01:04 am, Timoth=C3=A9e Lecomte wrote: >=20 >>this one comes from graphics.c:3408 : >> >>x =3D xl; >>y =3D yb; >>w =3D xr - xl + 1; >>h =3D yt - yb + 1; >>(*t->fillbox) (style, x, y, w, h); >>(*t->move) (xl, yb); >>(*t->vector) (xl, yt); >>(*t->vector) (xr, yt); >>(*t->vector) (xr, yb); >>(*t->vector) (xl, yb); >> >>I think these "+1" should be removed for consistency with the other use= s. >=20 >=20 > I'm not so sure. > The length in pixels of a line that starts at pixel x1 and ends at pixe= l x2 > is (x2-x1)+1. So this code looks correct to me. It may well be that = some > terminals interpret w and h incorrectly, but that would be an error in = the > individual terminal driver, not the core code.=20 >=20 > I guess the fundamental question is whether "width" should be interpret= ed > as "number of horizontal pixels" or "x_right - x_left". These are not > the same number. The former makes sense if you are thinking in terms o= f > terminal coords (pixels); the latter makes sense if you are thinking in= =20 > terms of a continuous variable (plot x coordinate). My initial preference would be to think along the lines of "plot x coordi= nate", perhaps for the simple reason of however this thread got started. = If you plot a series of rectangles to "cover" a range staying with x_rig= ht - x_left avoids there being an overlap of one pixel. E.g., series of incremented ranges: 0-9 10-19 20-29 etc. For histograms or whatever. Saying that the width of the rectangle shoul= d be 11 instead of 10 would mean that there is going to be one rectangle = of the bunch that is 9 pixels and one which is 11 pixels. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-07-16 19:09:45
|
Daniel J Sebald wrote: > My initial preference would be to think along the lines of "plot x coordinate", perhaps for the simple reason of however this thread got started. If you plot a series of rectangles to "cover" a range staying with x_right - x_left avoids there being an overlap of one pixel. > > E.g., series of incremented ranges: > > 0-9 > 10-19 > 20-29 > etc. > > For histograms or whatever. Saying that the width of the rectangle should be 11 instead of 10 would mean that there is going to be one rectangle of the bunch that is 9 pixels and one which is 11 pixels. Of course, I should say this is the principle. Gnuplot may have been done this way to address some rouding effects of the plotting operation. That is, this +1 may fix the problem of sometimes dropping a pixel because of some floating point round of, which would result in a "blank pixel" or "blank line". (However, this rounding issue should really should be addressed directly by the mathematics of the process, not by compensating via a line segment one pixel wider than it should be.) For example, I haven't look closely at what is at issue here, but say gnuplot is drawing a series of line segments. It should not recompute the start and finish points for each new segment. Rather, it should use the previous computed finish point for the last segment as the start point for the next segment. Again, not sure of what exactly is happening in this particular case. Just making a point. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-16 20:15:21
|
On Sunday 16 July 2006 12:05 pm, Daniel J Sebald wrote: > > the fundamental question is whether "width" should be interpreted > > as "number of horizontal pixels" or "x_right - x_left". These are not > > the same number. The former makes sense if you are thinking in terms of > > terminal coords (pixels); the latter makes sense if you are thinking in > > terms of a continuous variable (plot x coordinate). > > If you plot a series of rectangles to "cover" a range staying with > x_right - x_left avoids there being an overlap of one pixel. But then you have the discordance that if you simply draw the rectangle bounded by (x1,y1) (x2,y2) with vectors, the bottom and left edges are part of the fill area, but the top and right edges are not. Isn't that the problem being observed - that the fill area and the bounding lines do not agree? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2006-07-16 20:42:10
|
Ethan A Merritt wrote: > On Sunday 16 July 2006 12:05 pm, Daniel J Sebald wrote: > >>>the fundamental question is whether "width" should be interpreted >>>as "number of horizontal pixels" or "x_right - x_left". These are not >>>the same number. The former makes sense if you are thinking in terms of >>>terminal coords (pixels); the latter makes sense if you are thinking in >>>terms of a continuous variable (plot x coordinate). >> >>If you plot a series of rectangles to "cover" a range staying with >>x_right - x_left avoids there being an overlap of one pixel. > > > But then you have the discordance that if you simply draw the > rectangle bounded by (x1,y1) (x2,y2) with vectors, the bottom and > left edges are part of the fill area, but the top and right edges > are not. Isn't that the problem being observed - that the fill > area and the bounding lines do not agree? Hmmm, yeah... Well, maybe the bounding lines should also be drawn one less. I'm getting this feeling of an analog with the bounding box issue of images. We had that discussion (enlightening to me) a while back about how to deal with this sort of thing in images. I recall the gist being that when one does computations translating the images, one should work with the bounding box values, not the location of the first and last pixel are... I think there was a one pixel difference. Perhaps the same kind of thinking applies here. Dan |
