gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Argh: Why are arrows clipped to the graph?

[Daniel J S. <dan...@ie...>]

Harald Harders wrote:
> On Fri, 11 Nov 2005, Daniel J Sebald wrote:
> 
> 
>>>set size 2,2
>>>set terminal png
>>>set output 'asdf.png'
>>>plot sin(x)
>>>set output
>>>
>>>Have of the tic marks are missing.
> 
> 
> sed s/Have/Half/.
> 
> 
>>Hmm.  Not right of course, but this seems as though it may be a
>>different bug.  I see all the tic marks, but the annotation is what is
>>missing.
> 
> 
> That's what I meant. It's easy: All text that is requested with a screen
> coordinate above 1 is not printed. It does not have to do with negative or
> positive numbers. Just try another size than 2,2.

Oh, I see what you are saying.  (Got to explain a bit more.)  The text
clips, but not the lines.  Yeah.

> 
> 
>>>>Also, write a nicer do_arrow(), as Ethan suggests.  I think I could do
>>>>it fairly easily, but I simply don't have time now.  It would have to
>>>>wait until after the holidays.
>>>
>>>What do you want to improve? For me, the Postscript arrows are good
>>>enough.
>>
>>I'd thought I'd read in the thread somewhere that better PostScript
>>arrows clipped at the edge of the canvas were desired.  Sorry.
> 
> 
> If the line and the filled-path code supports correct clipping and the
> original arrow code uses these clipped lines and filled paths,
> parly clipping of arrow heads will be supported by every terminal.

OK, here we get into a philosophical debate.  If you have a full-featured
resource like PostScript, shouldn't you allow the arrows to extend past the
edge and let PostScript do the clipping?  I can imagine some users who don't
do things exactly right, but then can correct matters with an offset in
there word processor or whatever.  Someone shifts their EPS file into view
and lo-and-behold, the arrow or line is cropped in a funny way.  [Not too
much different than the example you've shown for PNG.]

[continued...]

Re: Argh: Why are arrows clipped to the graph?

[Harald H. <h.h...@tu...>]

On Sat, 12 Nov 2005, Petr Mikulik wrote:

> >>> Yes, of course. Postscript can do nearly everything except translucent
> >>> objects.
>
> I was always wondering how OpenOffice.org makes transparency in its
> postscript or pdf files. (When you print such presentations, it says "the
> file may be bigger" or a message like that.)

PDF is capable of translucency, at least in recent versions.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

[Petr M. <mi...@ph...>]

>>> Yes, of course. Postscript can do nearly everything except translucent
>>> objects.

I was always wondering how OpenOffice.org makes transparency in its 
postscript or pdf files. (When you print such presentations, it says "the 
file may be bigger" or a message like that.)

---
PM

Re: Argh: Why are arrows clipped to the graph?

[Harald H. <h.h...@tu...>]

On Fri, 11 Nov 2005, Daniel J Sebald wrote:

> > set size 2,2
> > set terminal png
> > set output 'asdf.png'
> > plot sin(x)
> > set output
> >
> > Have of the tic marks are missing.

sed s/Have/Half/.

> Hmm.  Not right of course, but this seems as though it may be a
> different bug.  I see all the tic marks, but the annotation is what is
> missing.

That's what I meant. It's easy: All text that is requested with a screen
coordinate above 1 is not printed. It does not have to do with negative or
positive numbers. Just try another size than 2,2.

> >>Also, write a nicer do_arrow(), as Ethan suggests.  I think I could do
> >>it fairly easily, but I simply don't have time now.  It would have to
> >>wait until after the holidays.
> >
> > What do you want to improve? For me, the Postscript arrows are good
> > enough.
>
> I'd thought I'd read in the thread somewhere that better PostScript
> arrows clipped at the edge of the canvas were desired.  Sorry.

If the line and the filled-path code supports correct clipping and the
original arrow code uses these clipped lines and filled paths,
parly clipping of arrow heads will be supported by every terminal.

For postscript of course, no clipping code will be necessary at all:

%!PS-Adobe-2.0 EPSF-2.0
%%BoundingBox: 0 0 100 100
%%EndProlog
gsave
% Introduce clipping
newpath
30 30 moveto
70 30 lineto
70 70 lineto
30 70 lineto
closepath
clip
% Some tests
newpath
1 0 0 setrgbcolor
0 0 moveto
100 100 lineto
stroke
10 50 moveto
(Times-Roman) findfont 10 scalefont setfont
(Hello world, this is clipped) show
% Remove clipping again
grestore
showpage
%%Trailer


> > Yes, of course. Postscript can do nearly everything except translucent
> > objects.
>
> (Really?  I'd been guessing, or hoping, it would.  Oh well.)

Maybe it can't cook coffee.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

[Harald H. <h.h...@tu...>]

On Fri, 11 Nov 2005, Daniel J Sebald wrote:

> > Really?  You have code that reads in a jpeg file?
>
> Sorry.  No.  Right after I sent the email I thought I hadn't worded that
> too well... and I was right.  What I meant was that we've organized the
> code so that it wouldn't be difficult for someone to add support for
> different image types.  I recall debate about whether we should get to
> the point of supporting the myriad different image file formats.  (And
> that was never my original intent.  The original intent was for computer
> programs to exchange data through a pipe.)

When the image code was new, I started a little effort to use it to put a
scanned image in a plot. After some reading I decided not to continue the
work on it because I did not even know how to convert, say a png, to the
specific gnuplot image format. Thus, I failed to use the image support. In
my opinion, adding at least two common image formats, png (loss-less) and
jpg (with losses), would really be helpful. At the moment, gnuplot only
supports a "private" format, right?

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

[Harald H. <h.h...@tu...>]

On Fri, 11 Nov 2005, Ethan A Merritt wrote:

> On Friday 11 November 2005 05:11 pm, Daniel J Sebald wrote:
> >
> > I don't know if it is even that complicated.  Certainly one can do that.
> >  But I'm constantly making the mistake of creating a plot half off
> > screen in ghostview, then I expand out to some other page size beside
> > "encapsulated" and there is the rest of the plot.
>
> And right there you have the reason why the PostScript driver is
> different from all the others - it let's you draw "off the screen".
> If you come to rely on that, you will eventually find that some
> other driver will be extremely unhappy that you are trying to
> draw outside the pre-allocated space.
>
> > > set size 2,2
>     ^^^^^^^^^^^^^
> Don't do that.

Oh no, not again. For all postscript terminals, it's the only way to
produce large plots. And for some other terminals, it also works as scale
factor for the canvas. If you are allowed to reduce the canvas size using
'set size 0.7,0.7' you also have to be allowed to increase it by using
'set size 2.0,2.0'. And to maintain compatibility (to the old code where
no clipping was done in most terminals) we will have to handle sizes above
1, too.

Have you had a look at the new patch, #1353539? Here, correct clipping
works for postscript, png, and fig. It sets term->canvas in all terminals,
now.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Friday 11 November 2005 05:11 pm, Daniel J Sebald wrote:
> 
>>I don't know if it is even that complicated.  Certainly one can do that.
>> But I'm constantly making the mistake of creating a plot half off
>>screen in ghostview, then I expand out to some other page size beside
>>"encapsulated" and there is the rest of the plot.
> 
> 
> And right there you have the reason why the PostScript driver is
> different from all the others - it let's you draw "off the screen".
> If you come to rely on that, you will eventually find that some
> other driver will be extremely unhappy that you are trying to 
> draw outside the pre-allocated space.

I don't know what we are disagreeing on here.  :-)


>> For me, it would be much more interesting to enable gnuplot to
>>read in common picture files as jpg or png.
>>
>>Noted.  (And list members should note.)  The capability to do so exists
>>as part of the code.  But there is debate on whether to allow this.
> 
> 
> Really?  You have code that reads in a jpeg file?

Sorry.  No.  Right after I sent the email I thought I hadn't worded that too well... and I was right.  What I meant was that we've organized the code so that it wouldn't be difficult for someone to add support for different image types.  I recall debate about whether we should get to the point of supporting the myriad different image file formats.  (And that was never my original intent.  The original intent was for computer programs to exchange data through a pipe.)

Dan

Re: Argh: Why are arrows clipped to the graph?

[Ethan A M. <merritt@u.washington.edu>]

On Friday 11 November 2005 05:11 pm, Daniel J Sebald wrote:
>
> I don't know if it is even that complicated.  Certainly one can do that.
>  But I'm constantly making the mistake of creating a plot half off
> screen in ghostview, then I expand out to some other page size beside
> "encapsulated" and there is the rest of the plot.

And right there you have the reason why the PostScript driver is
different from all the others - it let's you draw "off the screen".
If you come to rely on that, you will eventually find that some
other driver will be extremely unhappy that you are trying to 
draw outside the pre-allocated space.

> > set size 2,2
    ^^^^^^^^^^^^^
Don't do that.

>  For me, it would be much more interesting to enable gnuplot to
> read in common picture files as jpg or png.
>
> Noted.  (And list members should note.)  The capability to do so exists
> as part of the code.  But there is debate on whether to allow this.

Really?  You have code that reads in a jpeg file?


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Argh: Why are arrows clipped to the graph?

[Daniel J S. <dan...@ie...>]

Harald Harders wrote:
> On Fri, 11 Nov 2005, Daniel J Sebald wrote:

> 
>>The thing is, in PostScript I don't think
>>one has to worry at all about plotting beyond the "view port".  (Sorry,
>>P.S. terminology isn't fresh in my mind right now.)  It automatically
>>takes care of that, doesn't it?  Why impose some inferior clipping
>>method?
> 
> 
> No, not really automatically. But it is fairly easy to define a clipping
> path inside the produced Postscript file. Thus, only for Postscript we
> would not have this problem. But the problem also applies for other
> terminals. Try

I don't know if it is even that complicated.  Certainly one can do that.  But I'm constantly making the mistake of creating a plot half off screen in ghostview, then I expand out to some other page size beside "encapsulated" and there is the rest of the plot.

> 
> set size 2,2
> set terminal png
> set output 'asdf.png'
> plot sin(x)
> set output
> 
> Have of the tic marks are missing.

Hmm.  Not right of course, but this seems as though it may be a different bug.  I see all the tic marks, but the annotation is what is missing.  Furthermore, it is only the non-negative numbers that are missing (probably the key to the bug).  But wouldn't the non-negative numbers take up less space than the negative numbers?  And if so, wouldn't those extend toward or past the edge _less_ than the negative numbers.  Anyone?

> 
>>Also, write a nicer do_arrow(), as Ethan suggests.  I think I could do
>>it fairly easily, but I simply don't have time now.  It would have to
>>wait until after the holidays.
> 
> 
> What do you want to improve? For me, the Postscript arrows are good
> enough.

I'd thought I'd read in the thread somewhere that better PostScript arrows clipped at the edge of the canvas were desired.  Sorry.

> 
> 
>>[...]  Believe it or not,
>>PostScript can have a viewing angle for rectangular images.  I think for
>>now, the generic pixel (parallelogram) by pixel (parallelogram) method
>>will have to do.
> 
> 
> Yes, of course. Postscript can do nearly everything except translucent
> objects.

(Really?  I'd been guessing, or hoping, it would.  Oh well.)

 For me, it would be much more interesting to enable gnuplot to
> read in common picture files as jpg or png.

Noted.  (And list members should note.)  The capability to do so exists as part of the code.  But there is debate on whether to allow this.

Dan

Re: wxWidgets terminal : new round

[Petr M. <mi...@ph...>]

>> - "set pm3d; splot x*y" produces a strange surface
>
> What do you mean by "strange surface" ? Are other plot commands working
> properly ?

It is flipped vertically (along a vertical axis).

>>> apart from mousing mode since under windows term->waitforinput
>>> doesn't seemed to be used...
>>
>> No, do_string() is called directly (both gnuplot and its windows
>> terminal are in the same binary, contrary to X11 or OS/2 terminals).
>
> As waitforinput is set to 0 in the windows terminal table, I can maybe
> add the use of waitforinput under windows, with a check such as "if
> (term->waitforinput)" (as it is done under other platforms). What do you
> think of it ?

I don't (needed to) understand the meaning of term->waitforinput (I 
considered it an x11 kludge).

---
PM

Re: wxWidgets terminal : new round

[<tim...@en...>]

Petr Mikulik wrote:

>> well-suited for text. Moreover, I have convinced myself that pango
>> and cairo are almost as cross-platform as wxWidgets.
>
> Thanks for the description.
>
>> As a proof ;-), here are screenshots taken from windows XP running
>> the wxWidgets terminal, using Cairo and Pango:
>>
>> Moreover, here is a zip archive containing gnuplot binary for windows
>> compiled statically with wxWidgets, and dynamically with cairo and
>> pango. Dlls are included so you don't need to add anything : it
>> "should" work out-of-the-box.
>>
>> (3MB zipped archive) http://tipote.free.fr/Gnuplot4.1.zip
>
>
> Please add also libintl.dll.

I have figured it out too. Will add the version provided by the GnuWin32
project.

> I've added some 2001-12-27, 43 786 B, and then tried this new wgnuplot
> under Wine 2005-06-28 (SUSE 9.2). There, the "normal" wgnuplot.exe 4.1
> runs with all features. With wxterminal, there were few problems:
> - it needs unicode fonts =3D> wine wants Win NT/2K/XP

> - switched wine to XP, but there are no fonts

Well, it's something that I need to work on. The actual code does only
work with a unicode-enabled wxWidgets, because pango wants utf8 strings,
and I use wxWidgets conversion routines. So there can be two suspects :
pango which may not find well-suited fonts (unicode...), and wxWidgets
which fails to convert to utf8.
As pango depends on glib, I should maybe use directly glib functions to
convert encodings.

> - "set pm3d; splot x*y" produces a strange surface

What do you mean by "strange surface" ? Are other plot commands working
properly ?

>
>> apart from mousing mode since under windows term->waitforinput
>> doesn't seemed to be used...
>
>
> No, do_string() is called directly (both gnuplot and its windows
> terminal are in the same binary, contrary to X11 or OS/2 terminals).

As waitforinput is set to 0 in the windows terminal table, I can maybe
add the use of waitforinput under windows, with a check such as "if
(term->waitforinput)" (as it is done under other platforms). What do you
think of it ?

Timoth=E9e Lecomte

Re: Argh: Why are arrows clipped to the graph?

[Harald H. <h.h...@tu...>]

On Fri, 11 Nov 2005, Aapo Lankinen wrote:

> On Wed, 2005-11-09 at 16:13 -0800, Ethan Merritt wrote:
> > Well, in this particular case it is caused by the fact that when
> > post.trm expands its drawing limits, it does not change the values
> > of term->xmax and term->ymax.   Therefore if you clip against them,
> > it doesn't work.  So far as I know, other terminal drivers
> > correctly report what their actual limiting coordinates are.
>
> What is the exact reason that prevents fixing post.trm (and maybe other
> broken terminals) so that it would correctly update term->xmax and
> term->ymax?  I would imagine that it wouldn't be terribly difficult to
> change accordingly the values of these two variables when the postscript
> internal canvas grow.  Is it somehow a problem with backward
> compatibility?

The problem is that xmax and ymax are the positions of the screen
coordinates 1,1. And they are not equal to the upper right corner in all
cases. To change this would mean to do incompatible changes.

> I wonder if the problem with the inconsistencies between different
> terminals and backward compatibility is so severe that a new global
> option "set terminalmode {old|new}" is needed.  I believe that option
> would be quite horrible from the maintaining point of view.

I would prefer to add a new coordinate system, e.g., canvas, that scales
with the canvas of the plot.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

[Harald H. <h.h...@tu...>]

On Fri, 11 Nov 2005, Daniel J Sebald wrote:

> > What is the exact reason that prevents fixing post.trm (and maybe other
> > broken terminals) so that it would correctly update term->xmax and
> > term->ymax?  I would imagine that it wouldn't be terribly difficult to
> > change accordingly the values of these two variables when the postscript
> > internal canvas grow.  Is it somehow a problem with backward
> > compatibility?
>
> I don't see why things have to be done this way.  Does "canvas" have the
> same meaning as "view port".

Yes.

> The thing is, in PostScript I don't think
> one has to worry at all about plotting beyond the "view port".  (Sorry,
> P.S. terminology isn't fresh in my mind right now.)  It automatically
> takes care of that, doesn't it?  Why impose some inferior clipping
> method?

No, not really automatically. But it is fairly easy to define a clipping
path inside the produced Postscript file. Thus, only for Postscript we
would not have this problem. But the problem also applies for other
terminals. Try

set size 2,2
set terminal png
set output 'asdf.png'
plot sin(x)
set output

Have of the tic marks are missing.

> Instead, in the case of P.S., interpret term->xmax and term->ymax as
> simply boundaries of where the plot is viewed.  Or, if those aren't the
> appropriate variables, conceptually I hope you understand my point.

The point is that term->xmax and term->ymax denote the position where the
screen coordinate system has the values 1,1. They do not denote the upper
right corner of the canvas (view port or BoundingBox).

> Also, write a nicer do_arrow(), as Ethan suggests.  I think I could do
> it fairly easily, but I simply don't have time now.  It would have to
> wait until after the holidays.

What do you want to improve? For me, the Postscript arrows are good
enough.

> [...]  Believe it or not,
> PostScript can have a viewing angle for rectangular images.  I think for
> now, the generic pixel (parallelogram) by pixel (parallelogram) method
> will have to do.

Yes, of course. Postscript can do nearly everything except translucent
objects. For me, it would be much more interesting to enable gnuplot to
read in common picture files as jpg or png.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: wxWidgets terminal : new round

[Petr M. <mi...@ph...>]

> well-suited for text. Moreover, I have convinced myself that pango and ca=
iro=20
> are almost as cross-platform as wxWidgets.

Thanks for the description.

> As a proof ;-), here are screenshots taken from windows XP running the=20
> wxWidgets terminal, using Cairo and Pango:
>
> Moreover, here is a zip archive containing gnuplot binary for windows=20
> compiled statically with wxWidgets, and dynamically with cairo and pango.=
=20
> Dlls are included so you don't need to add anything : it "should" work=20
> out-of-the-box.
>
> (3MB zipped archive) http://tipote.free.fr/Gnuplot4.1.zip

Please add also libintl.dll.
I've added some 2001-12-27, 43=A0786 B, and then tried this new wgnuplot un=
der=20
Wine 2005-06-28 (SUSE 9.2). There, the "normal" wgnuplot.exe 4.1 runs with=
=20
all features. With wxterminal, there were few problems:
- it needs unicode fonts =3D> wine wants Win NT/2K/XP
- switched wine to XP, but there are no fonts
- "set pm3d; splot x*y" produces a strange surface

> apart from mousing mode since under windows term->waitforinput doesn't=20
> seemed to be used...

No, do_string() is called directly (both gnuplot and its windows terminal=
=20
are in the same binary, contrary to X11 or OS/2 terminals).

---
PM

Re: Argh: Why are arrows clipped to the graph?

[Daniel J S. <dan...@ie...>]

Aapo Lankinen wrote:
> On Wed, 2005-11-09 at 16:13 -0800, Ethan Merritt wrote:
> 
>>Well, in this particular case it is caused by the fact that when
>>post.trm expands its drawing limits, it does not change the values
>>of term->xmax and term->ymax.   Therefore if you clip against them,
>>it doesn't work.  So far as I know, other terminal drivers
>>correctly report what their actual limiting coordinates are.
> 
> 
> What is the exact reason that prevents fixing post.trm (and maybe other
> broken terminals) so that it would correctly update term->xmax and
> term->ymax?  I would imagine that it wouldn't be terribly difficult to
> change accordingly the values of these two variables when the postscript
> internal canvas grow.  Is it somehow a problem with backward
> compatibility?

I don't see why things have to be done this way.  Does "canvas" have the same meaning as "view port".  The thing is, in PostScript I don't think one has to worry at all about plotting beyond the "view port".  (Sorry, P.S. terminology isn't fresh in my mind right now.)  It automatically takes care of that, doesn't it?  Why impose some inferior clipping method?

Instead, in the case of P.S., interpret term->xmax and term->ymax as simply boundaries of where the plot is viewed.  Or, if those aren't the appropriate variables, conceptually I hope you understand my point.  Also, write a nicer do_arrow(), as Ethan suggests.  I think I could do it fairly easily, but I simply don't have time now.  It would have to wait until after the holidays.

Now, although that doesn't seem too difficult, there is a similar thing with the new image code.  One starts out writing a generic thing, but I now know--after having looked at PostScript books in the process of working on PostScript images--that eventually improvements can be made for PostScript images plotted at an angle.  Believe it or not, PostScript can have a viewing angle for rectangular images.  I think for now, the generic pixel (parallelogram) by pixel (parallelogram) method will have to do.

[Ethan, I hope that adding a view angle or such to the image terminal routine down the road doesn't cause any problems.  If so, perhaps we should think about that before the next release.]

Dan

Re: Argh: Why are arrows clipped to the graph?

[Aapo L. <aap...@gm...>]

On Wed, 2005-11-09 at 16:13 -0800, Ethan Merritt wrote:
> Well, in this particular case it is caused by the fact that when
> post.trm expands its drawing limits, it does not change the values
> of term->xmax and term->ymax.   Therefore if you clip against them,
> it doesn't work.  So far as I know, other terminal drivers
> correctly report what their actual limiting coordinates are.

What is the exact reason that prevents fixing post.trm (and maybe other
broken terminals) so that it would correctly update term->xmax and
term->ymax?  I would imagine that it wouldn't be terribly difficult to
change accordingly the values of these two variables when the postscript
internal canvas grow.  Is it somehow a problem with backward
compatibility?

I wonder if the problem with the inconsistencies between different
terminals and backward compatibility is so severe that a new global
option "set terminalmode {old|new}" is needed.  I believe that option
would be quite horrible from the maintaining point of view.

						Aapo

Re:[gnuplot-Patches-1353539] Fix clipping for plots with canvas size != 1,1

[Harald H. <h.h...@tu...>]

On Thu, 10 Nov 2005, Ethan Merritt wrote:

> In the general case, don't we need to know all four
> corners of the canvas?  So far as I understand the
> code in the postscript driver, it uses both
> "set size ..." and "set offset ..." to generate the
> true canvas.  For instance:

You are right. I have never used that function and I did not know that it
even works.

> Don't we really want these same values, or at least their
> unscaled equivalents, available to the core code?
> E.g.:
>
> 	term->canvas.xleft  = xmin_t * PS_SC;
> 	term->canvas.xright = xmax_t * PS_SC;
> 	term->canvas.ybot   = ymin_t * PS_SC;
> 	term->canvas.ytop   = ymax_t * PS_SC;
>
> (give or take a factor of 2).

Yes, you are right. And we should use the canvas struct as you showed in
your example. xleft and ybot default to zero, and xright and ytop default
to xmax and ymax, respectively.

But do you agree that this method is the right one, in general?

Best regards
Harald, who really has to go to bed now.

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re:[gnuplot-Patches-1353539] Fix clipping for plots with canvas size != 1,1

[Ethan M. <merritt@u.washington.edu>]

> Submitted By: Harald Harders (harders)
> 
> Depending on the terminal, either
> 
> term->xcanvas = term->xmax * xsize;
> term->ycanvas = term->ymax * ysize;
> (when 'set size' changes the canvas)
> 
> or
> 
> term->xcanvas = term->xmax;
> term->ycanvas = term->ymax;
> (when 'set size' does not change the canvas)
> 
> will be appropriate.

In the general case, don't we need to know all four 
corners of the canvas?  So far as I understand the
code in the postscript driver, it uses both 
"set size ..." and "set offset ..." to generate the
true canvas.  For instance:


    switch (ps_params->psformat) {
    case PSTERM_EPS:
        term->xmax = PS_XMAX;
        if (ps_params->oldstyle)
            term->ymax = PS_YMAX_OLDSTYLE;
        else
            term->ymax = PS_YMAX;
        xmin_t = term->xmax * xoffset / (2*PS_SC);
        xmax_t = term->xmax * (xsize + xoffset) / (2*PS_SC);
        ymin_t = term->ymax * yoffset / (2*PS_SC);
        ymax_t = term->ymax * (ysize + yoffset) / (2*PS_SC);
        break;


Don't we really want these same values, or at least their
unscaled equivalents, available to the core code?
E.g.:

	term->canvas.xleft  = xmin_t * PS_SC;
	term->canvas.xright = xmax_t * PS_SC;
	term->canvas.ybot   = ymin_t * PS_SC;
	term->canvas.ytop   = ymax_t * PS_SC;

(give or take a factor of 2).


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Argh: Why are arrows clipped to the graph?

[Juergen W. <wie...@fr...>]

Harald Harders wrote:
> I definitely do not agree. I agree that the default way should be to have
> upper right canvas corner has screen coordinates 1,1. And it is definitely
> nonsense to allow reduction of size below 1.0 but to disallow an increase.

As I see it, the screen coordinates just belong to the canvas, the
latter being the overall drawing area.  Then, sizes above 1.0 do not
make any sense.  Sizes smaller than 1.0 are essential for
multiplots.  Outside of multiplots, they are probably much less
useful.  Therefor, we indeed need some "set canvas" or "set size
canvas".  I like the idea of adding additional coordinate systems.
Maybe the current "screen" could split in a backward compatible
"screen" and a correct "canvas" coordinate system?


Juergen

Re: Argh: Why are arrows clipped to the graph?

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 09 November 2005 04:14 pm, Harald Harders wrote:
> 
>>On Wed, 9 Nov 2005, Ethan Merritt wrote:
>>
>>
>>>What you are now finding is that this generic clipping doesn't always
>>>work the way you would like, because the individual terminal drivers
>>>are not consistent.
>>
>>But that's not caused by generic or specific clipping. It is caused by the
>>fact that the clipping boundary is in the middle of the canvas in many
>>cases.
> 
> 
> 
> Well, in this particular case it is caused by the fact that when
> post.trm expands its drawing limits, it does not change the values
> of term->xmax and term->ymax.   Therefore if you clip against them,
> it doesn't work.  So far as I know, other terminal drivers
> correctly report what their actual limiting coordinates are.

PostScript, I'm almost certain, will have better clipping than any
other utility.

> 
>>I hope so. The most important thing for me is to combine both correct
>>clipping with saving compatibility with my old postscript/epslatex plots.
> 
> 
> Good luck on that.  As I keep pointing out, you cannot both have
> compability across terminals and compatibility with old versions,
> because in the old (and current) version the terminals themselves
> are not compatible.

Add a better do_arrow() to the PostScript terminal, that's all.  Effort
in that is more worthwhile.

Dan

Re: Argh: Why are arrows clipped to the graph?

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 09 November 2005 03:04 pm, Daniel J Sebald wrote:
> 
>>I don't know if I agree on that one.  Are you saying that one
>>can't have a fraction of an arrow at the edge of the canvas
>>(i.e., say the tip extends just past the canvas limit, but is
>>not visible)?  That has to be allowed, otherwise one can't use
>>the many features of PostScript.
> 
> 
> If you try this with the pdf terminal, it will crash.

They are aware of this, I assume.  (I guess I remember now that
you wrote the developers.)  That's clearly a bug in the utility.

 
>>Maybe
>>a "legacy terminal" is in order... something to prevent the need
>>for coding up "if terminal has this feature, then this, otherwise
>>that" all over the place in the core code.
> 
> 
> We have that now.  These are the routines  do_XXX() in  term.c.
> They provide a generic fallback for terminals that don't
> supply their own routine to do XXX.
> 
> In the case of arrows, the generic code is called do_arrow(),
> and is supposed to be usable by all terminals
> that do not provide their own specific arrow drawing routine.
> That is precisely what we are now fighting with; it isn't generic
> enough, because it causes some terminals to segfault, or abort,
> or draw garbage if the arrows go outside the current canvas.

Oh, I see.  Between a rock and a hard place, then.

> If you, or Harald, feel that the generic code is not appropriate
> for the PostScript driver, then of course you are free to write
> a terminal-specific PS_arrow() routine.  I'm sure you could draw
> nicer looking arrows that way, just as the metapost driver does,
> for example.

Yeah.  This is the way to go; solve the problem by avoiding it.
Arrows in PostScript must be fairly easy.

Dan

Re: Argh: Why are arrows clipped to the graph?

[Ethan M. <merritt@u.washington.edu>]

> >
> > The "Fix buggy clipping" patch does not touch any terminal drivers.
> 
> And what do the patches
> 
>         /* EAM FIXME - Is this a sufficient test for out-of-bounds? */
> -       if (x < 0 || x > term->xmax || y < 0 || y > term->ymax) {
> +       if ((x < 0) ||
> +           (multiplot && (x > term->xmax * global_xsize)) ||
> +           (!multiplot && (x > term->xmax * xsize)) ||
> +           (y < 0) ||
> +           (multiplot && (y > term->ymax * global_ysize)) ||
> +           (!multiplot && (y > term->ymax * ysize))) {
> 
> and
> 
> -    if ((0 < x && x < term->xmax) && (0 < y && y < term->ymax))
> +    FPRINTF((stderr,"on_page(): %d,%g   %d,%g\n",
> +            term->xmax,global_xsize,term->ymax,global_ysize));
> +    if ((0 < x && x < term->xmax * global_xsize)
> +       && (0 < y && y < term->ymax * global_ysize))
> 
> do? They affect clipping due to a 'set size' before 'set terminal'.

Well, they for sure do not corrent for the fact that term-xmax
and term->ymax do not in fact contain the correct clipping limits.
At least, not for post.trm.

> Or what does
> 
> -    xleft += t->xmax * xoffset;
> -    xright += t->xmax * xoffset;
> -    ytop += t->ymax * yoffset;
> -    ybot += t->ymax * yoffset;
> +    xleft += xpagemax * xoffset;
> +    xright += xpagemax * xoffset;
> +    ytop += ypagemax * yoffset;
> +    ybot += ypagemax * yoffset;
> 
> and
> 
> -    if (*sx < 0 || *sx > term->xmax || *sy < 0 || *sy > term->ymax)
> +    if (*sx < 0 || *sx > xpagemax ||
> +       *sy < 0 || *sy > ypagemax) {
> +       FPRINTF((stderr,"place_arrow3d: skipping out-of-bounds arrow\n"));
> 
> do? Yes, clipping. 


but but but...  
There is nothing in here that correctly sets the
canvas bounds for the current terminal. 
Isn't that what we're talking about?

Multiplying a previous value by {xy}pagesize doesn't help if the
previous value is wrong to begin with.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Argh: Why are arrows clipped to the graph?

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 09 November 2005 04:14 pm, Harald Harders wrote:
> On Wed, 9 Nov 2005, Ethan Merritt wrote:
> 
> > What you are now finding is that this generic clipping doesn't always
> > work the way you would like, because the individual terminal drivers
> > are not consistent.
> 
> But that's not caused by generic or specific clipping. It is caused by the
> fact that the clipping boundary is in the middle of the canvas in many
> cases.


Well, in this particular case it is caused by the fact that when
post.trm expands its drawing limits, it does not change the values
of term->xmax and term->ymax.   Therefore if you clip against them,
it doesn't work.  So far as I know, other terminal drivers
correctly report what their actual limiting coordinates are.


> I hope so. The most important thing for me is to combine both correct
> clipping with saving compatibility with my old postscript/epslatex plots.

Good luck on that.  As I keep pointing out, you cannot both have
compability across terminals and compatibility with old versions,
because in the old (and current) version the terminals themselves
are not compatible.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Argh: Why are arrows clipped to the graph?

[Harald H. <h.h...@tu...>]

On Wed, 9 Nov 2005, Ethan Merritt wrote:

> What you are now finding is that this generic clipping doesn't always
> work the way you would like, because the individual terminal drivers
> are not consistent.

But that's not caused by generic or specific clipping. It is caused by the
fact that the clipping boundary is in the middle of the canvas in many
cases.

> I'm glad we are now in agreement :-)

I hope so. The most important thing for me is to combine both correct
clipping with saving compatibility with my old postscript/epslatex plots.

Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Argh: Why are arrows clipped to the graph?

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 09 November 2005 03:59 pm, Harald Harders wrote:
> 
> Why do so many routines have clipping? In my opinion we have about four
> things that have to be clipped, in most terminals:
> 
> points
	gadgets.c:170:clip_point(unsigned int x, unsigned int y)
> lines
	gadgets.c:192:draw_clip_line(int x1, int y1, int x2, int y2)
> filled polygons
	We don't have this one
> text
	term.c:941:write_multiline()

> Since arrows are produced by lines and filled polygons in most terminals,
> clipping would be done automatically by the routines producing the lines
> and the polygons. As a positive side effect, only the part of the arrow
> head would be cut off that is outside the canvas.

Guess what?  That is exactly the change I made to do_arrow() which you
have been complaining about.  It now uses the routine draw_clip_line()
to draw all the lines in the arrow, which means that they get clipped
automatically.

What you are now finding is that this generic clipping doesn't always
work the way you would like, because the individual terminal drivers
are not consistent.

I'm glad we are now in agreement :-)




-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195