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

Re: Keyboard input losses also on MS Windows

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

Ethan Merritt wrote:

>On Monday 05 July 2004 06:34 pm, Daniel J Sebald wrote:
>  
>
>>On the topic of plot window location, anyone
>>else find it kind of irksome that a newly created plot window is always
>>situated on top of the command line window and completely covering it?
>> I'd prefer it to be created as far away from the command line as
>>possible, 
>>    
>>
>
>
>So?  Tell your window manager that.
>Or put it in your Xresources file.
>My plot windows stack in the upper right corner of the screen.
>

OK, I've tried a bit of this now.  I have SawFish.  There are plenty of 
settings but some have undesirable behavior.  One of them is not too 
bad, called "first-fit", placing windows in corners of the screen and 
seems to avoid the parent's space.  Pretty much what I want, thanks.

The focus is a different matter.  Someone who uses the gnuplot_x11 
window hot keys a lot probably doesn't mind the created plot grabbing 
the focus.  Changing the window manager settings so that "focus on 
display" is not active helps in gnuplot... but it alters all other 
window behavior too.  The thing is, in most applications you want to 
grab focus upon display.  Say one creates an editor window with "xemacs 
junk &"; well you're going to type in the editor right away so, yes, 
"grab focus".  But in gnuplot, one isn't going to type in the plot 
window (unless hot key user) so, no, don't grab focus.

I tried creating a patch with XGetInputFocus() and XSetInputFocus() to 
restore the focus to the parent, i.e., gnuplot command line.  But I 
couldn't get it to work...  Not that important.

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

Hans-Bernhard Broeker wrote:

>On Mon, 5 Jul 2004, Daniel J Sebald wrote:
>
>  
>
>>I tried a hack test to not cast from unsigned int (variable defined) to 
>>float (PDF_xxx() argument), but rather treat it as signed.  
>>    
>>
>
>I'm a bit uneasy about that change, as described, but that may be because
>the description has been a bit vague.  Please note you may absolutely
>*not* change the signatures of the terminal API entry point functions from
>unsigned int to int.  That would cause undefined behaviour.  What you do
>at the interface layer between pdf.trm and libpdf doesn't matter, as long
>as it improves things, but the interface between pdf.trm and the rest of
>gnuplot should be considered cast in stone.
>
>Could you please mail me (or the list) that patch for inspection?
>

No patch.  I called it a hack test because it was never intended to be 
used.  It was simply a quick and dirty way of testing whether the PDF 
driver could handle negative numbers as coordinates (as opposed to the 
outrageously large wrapped number), which appears to be the case.  I 
think in most C compilers a cast from a signed to unsigned or vice-versa 
doesn't change the value of the variable in memory, it simply changes 
how the variable is interpretted by the compiler when it used.  So, the 
number passes all the way to the driver level and it is only when 
changed to a float as an argument to the PDF_xxx() routines that it is 
interpretted.

I think Ethan's point at the last email was just what you are saying, 
addressing the signed/unsigned issue is a major alteration and would 
have to wait a bit.

Dan

Re: General bug - No out of bounds checking on 3D coordinates

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jul 2004, Ethan Merritt wrote:

> Is everyone OK with the idea "if a label is out of bounds don't 
> try to draw it at all"?   

Not as a global change affecting all terminals.  This is a decision
to be made either by the individual driver (if its output format
can't allow otherwise), or in terms of user-defined entities.  

> This would be change, as right now some drivers will draw the piece of
> the label that is in-bounds even though the label coordinates themselves
> are out of bounds.

Exactly.  And that is behaviour which long-time users may well be relying
on, so it should be preserved, at least as a default.  Looks like we
need another extention to the 'set clip' control: 

	set clip text

or, equivalently, a "clip" option to 'set label' that explicitly request 
the label to not be output if the reference point is out of bounds.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jul 2004, Ethan Merritt wrote:

> On Monday 05 July 2004 05:07 pm, Hans-Bernhard Broeker wrote:
> >
> > But now I've found a truly ghastly factor influencing one of the problems
> > I described: it depends on where the gnuplot text window pops up, relative
> > to the current position of the mouse.  If the mouse pointer is at rest
> > while starting wgnuplot.exe (current version) via the keyboard, and it
> > happens to be sitting *inside* the newly popped-up wgnuplot text window,
> > the first keypress will be lost.  This is insane.
> 
> OK.  So it takes one event (does Windows call them "events"?) before
> focus is given to the new text window.  

I'm sure it's not quite that simple.  By the time I press a key, at least
a dozen events must have been sent to that window (WM_CREATE, WM_PAINT,
WM_SETFOCUS, ...).  I'm not quite sure, but it *seems* that it also makes
a difference if I move the mouse around a bit before hitting that key.

> first event is something other than a keypress.  Or maybe there is an
> explicit "gain focus" call?

There is --- it just doesn't seem to take effect.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: General bug - No out of bounds checking on 3D coordinates

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jul 2004, Daniel J Sebald wrote:

> I tried a hack test to not cast from unsigned int (variable defined) to 
> float (PDF_xxx() argument), but rather treat it as signed.  

I'm a bit uneasy about that change, as described, but that may be because
the description has been a bit vague.  Please note you may absolutely
*not* change the signatures of the terminal API entry point functions from
unsigned int to int.  That would cause undefined behaviour.  What you do
at the interface layer between pdf.trm and libpdf doesn't matter, as long
as it improves things, but the interface between pdf.trm and the rest of
gnuplot should be considered cast in stone.

Could you please mail me (or the list) that patch for inspection?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Keyboard input losses also on MS Windows

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

On Monday 05 July 2004 05:07 pm, Hans-Bernhard Broeker wrote:
>
> But now I've found a truly ghastly factor influencing one of the problems
> I described: it depends on where the gnuplot text window pops up, relative
> to the current position of the mouse.  If the mouse pointer is at rest
> while starting wgnuplot.exe (current version) via the keyboard, and it
> happens to be sitting *inside* the newly popped-up wgnuplot text window,
> the first keypress will be lost.  This is insane.

OK.  So it takes one event (does Windows call them "events"?) before
focus is given to the new text window.  That sounds like a Windows bug,
pure and simple.  Why did it not strike before?  I don't know.  But the
work-around would seem to be to have gnuplot itself generate a 
junk event of some sort on entry, so that the first event is something
other than a keypress.  Or maybe there is an explicit "gain focus" call?

Re: Keyboard input losses also on MS Windows

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

On Monday 05 July 2004 06:34 pm, Daniel J Sebald wrote:
> On the topic of plot window location, anyone
> else find it kind of irksome that a newly created plot window is always
> situated on top of the command line window and completely covering it?
>  I'd prefer it to be created as far away from the command line as
> possible, 


So?  Tell your window manager that.
Or put it in your Xresources file.
My plot windows stack in the upper right corner of the screen.

> and not grab focus if not in "raise" mode. 

I tell KDE not to give focus to a window unless the mouse
is in it.  If your window manager doesn't allow that, then
look for a better one.

Re: Keyboard input losses also on MS Windows

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

> That is a strange one...  On the topic of plot window location, anyone 
> else find it kind of irksome that a newly created plot window is 
> always situated on top of the command line window and completely 
> covering it? I'd prefer it to be created as far away from the command 
> line as possible, and not grab focus if not in "raise" mode. 


In X11, that is -- D

Re: Keyboard input losses also on MS Windows

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

Hans-Bernhard Broeker wrote:

>On Mon, 5 Jul 2004, Hans-Bernhard Broeker wrote:
>
>  
>
>>>Does the problem still happen if gnuplot is configured with
>>>#undef USE_MOUSE ?
>>>      
>>>
>>To be experimented with.  I'm not even sure the Windows version
>>still builds in that configuration...
>>    
>>
>
>Testing...  it almost does.  (wpause assumes paused_for_mouse, had to
>#ifdef USE_MOUSE that).  But it doesn't help to prevent the problem.
>
>But now I've found a truly ghastly factor influencing one of the problems
>I described: it depends on where the gnuplot text window pops up, relative
>to the current position of the mouse.  If the mouse pointer is at rest
>while starting wgnuplot.exe (current version) via the keyboard, and it
>happens to be sitting *inside* the newly popped-up wgnuplot text window,
>the first keypress will be lost.  This is insane.
>

That is a strange one...  On the topic of plot window location, anyone 
else find it kind of irksome that a newly created plot window is always 
situated on top of the command line window and completely covering it? 
 I'd prefer it to be created as far away from the command line as 
possible, and not grab focus if not in "raise" mode.

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

Hans-Bernhard Broeker wrote:

>On Mon, 5 Jul 2004, Daniel J Sebald wrote:
>
>  
>
>>I don't understand why negative coordinates is an error.  Conceptually, 
>>it's as though our view port is from (0, 0) to (x_max, y_max). 
>> Certainly there are some situations where the graphical element may 
>>make no sense to be outside that range.  But the decision if that is a 
>>problem or not lies at the very last use, inside the driver.
>>    
>>
>
>Not really.  The terminal driver can only do what I would refer to as
>"emergency clipping".  I.e. if a point passed to the driver is outside the
>viewport, but the output format can't handle that, the gnuplot terminal
>driver will have to deal with that, probably by discarding the entire
>primitive being drawn.
>

I agree with that.  That's sort of what I was driving at before.

>  That appears to be the case for our PDF driver.
>

I tried a hack test to not cast from unsigned int (variable defined) to 
float (PDF_xxx() argument), but rather treat it as signed.  It seemed to 
work.  So perhaps no extra code will be needed to discard primitives if 
we are lucky.

>[On a side note:]
>  
>
>>There is one thing about the terminal scheme that 
>>doesn't have a solid concept, or at least I don't recognize it.  It is 
>>how to have "default" routines of a driver.  
>>    
>>
>
>That's what the do_whatever() routines in term.c are for.  For functions
>that are required, a driver can register those directly.  It can even
>just supply a zero (i.e. a NULL function pointer) and change_term() will
>fill in the right default handler.
>

Ah.  I've looked at the term.c file in passing but it never registered 
with me.

>Unfortunately the NULL pointer replacement aspect of this scheme is only
>good for one level of inheritance, i.e. there's a single, somewhat virtual
>"base" terminal driver, using only the fallback routines, and a given
>driver can either use those, or implement its own overrides.   For doing
>real inheritance, we have to refer to what in C++ parlance would be
>caused "mangled" method names, e.g. in epslatex.trm, which registers
>the postscript driver's PM3D functions to itself, turning itself into
>something of a derived class of post.trm.  
>

Right.

Dan

>  
>

Re: General bug - No out of bounds checking on 3D coordinates

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

On Monday 05 July 2004 05:43 am, Hans-Bernhard Broeker wrote:
> IMHO clipping has to be the duty of the callers of map3d_xy, because only
> they can possibly know what the right reaction should be, or at least
> output an intelligible errors message if they can't seem to find a
> reasonable reaction.

For now I have put tests for wrap-around (negative value stored in
unsigned int) into the two high-level callers place_labels3d() and 
place_arrows3d().  If wrap-around  has occurred, the arrow or label
is skipped altogether.

This is not true clipping, but it does catch a potentially fatal error that
has already been made.  Retro-fitting general tests against the current
plot boundaries, coupled with proper clipping of line segments, will
have to wait for a more general overhaul.

Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jul 2004, Hans-Bernhard Broeker wrote:

> > Does the problem still happen if gnuplot is configured with
> > #undef USE_MOUSE ?
> 
> To be experimented with.  I'm not even sure the Windows version
> still builds in that configuration...

Testing...  it almost does.  (wpause assumes paused_for_mouse, had to
#ifdef USE_MOUSE that).  But it doesn't help to prevent the problem.

But now I've found a truly ghastly factor influencing one of the problems
I described: it depends on where the gnuplot text window pops up, relative
to the current position of the mouse.  If the mouse pointer is at rest
while starting wgnuplot.exe (current version) via the keyboard, and it
happens to be sitting *inside* the newly popped-up wgnuplot text window,
the first keypress will be lost.  This is insane.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: General bug - No out of bounds checking on 3D coordinates

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jul 2004, Daniel J Sebald wrote:

> 
> 
> Ethan Merritt wrote:
> 
> >Is everyone OK with the idea "if a label is out of bounds don't 
> >try to draw it at all"?
> >
> 
> Not totally.  It would be nice that if a partial text string were 
> supposed to show it would. 

Unfortunately gnuplot can't do that for the general case.  It has no way
of knowing which part of a text string will be on the page (--> open bug
about decenders getting clipped off of the xlabel text...).

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: General bug - No out of bounds checking on 3D coordinates

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jul 2004, Ethan Merritt wrote:

> On Monday 05 July 2004 10:38 am, Daniel J Sebald wrote:
> > I don't understand why negative coordinates is an error.
> 
> The error is not the fact that it's negative.  The error is that after 
> stuffing it into an (unsigned int) it looks like a huge positive number
> instead.

Not quite, IMHO.  The fact that casting a negative will result in
ridiculously large positive coordinates passed to terminal functions is a
*second* error, which is a consequence of the original one: that stuff was
output outside the page boundary.

> That would be a big change, though. 

I'm aware of that.  If it weren't, I would have insisted on getting that
fixed before considering the thing fit for the 4.0 release.  But if now
isn't the time for big changes, when is?

> The problem I've run into is that the PDF library doesn't clip in
> these cases, it just causes the program to exit.  

So our PDF driver *must* do its own "emergency" clipping, no matter
what we do in the core routines.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: General bug - No out of bounds checking on 3D coordinates

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jul 2004, Daniel J Sebald wrote:

> I don't understand why negative coordinates is an error.  Conceptually, 
> it's as though our view port is from (0, 0) to (x_max, y_max). 
>  Certainly there are some situations where the graphical element may 
> make no sense to be outside that range.  But the decision if that is a 
> problem or not lies at the very last use, inside the driver.

Not really.  The terminal driver can only do what I would refer to as
"emergency clipping".  I.e. if a point passed to the driver is outside the
viewport, but the output format can't handle that, the gnuplot terminal
driver will have to deal with that, probably by discarding the entire
primitive being drawn.  That appears to be the case for our PDF driver.

But the globally missing clipping is one that has to be done by the core
of gnuplot.  It has to be done at a layer of the program where information
about what the user intended is still available.

Summing it up, map3d_xy would be exactly the wrong place to try and do
clipping in: it knows neither the terminal, nor the user's intention.
About the only thing this function can do is detect the problem, but
it can't administer the cure.

[On a side note:]
> There is one thing about the terminal scheme that 
> doesn't have a solid concept, or at least I don't recognize it.  It is 
> how to have "default" routines of a driver.  

That's what the do_whatever() routines in term.c are for.  For functions
that are required, a driver can register those directly.  It can even
just supply a zero (i.e. a NULL function pointer) and change_term() will
fill in the right default handler.

Unfortunately the NULL pointer replacement aspect of this scheme is only
good for one level of inheritance, i.e. there's a single, somewhat virtual
"base" terminal driver, using only the fallback routines, and a given
driver can either use those, or implement its own overrides.   For doing
real inheritance, we have to refer to what in C++ parlance would be
caused "mangled" method names, e.g. in epslatex.trm, which registers
the postscript driver's PM3D functions to itself, turning itself into
something of a derived class of post.trm.  

Hmmm... now that I'm thinking about it, it could be a neat idea to move
these "base class" functions into a *.trm driver of their own, if only to
get them out of term.c.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: General bug - No out of bounds checking on 3D coordinates

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

Ethan Merritt wrote:

>That would be mean changing many lines of code, but other than that
>I don't see any intrinsic problem with it.  Of course, only a subset
>of drivers could actually do anything useful with the negative numbers.
>

Ethan,

As a crude test, I did a mass replace of "unsigned int" by "signed int" 
in the pdf.trm file and the datastirngs.dem demo seems to run fine. 
 (The conversion to a float in the PDF_xxx() routines is where the 
wrap-around of the number occurs.)...  There are a lot of occurrences of 
"unsinged int" throughout the software, aren't there?

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

Ethan Merritt wrote:

>On Monday 05 July 2004 02:14 pm, you wrote:
>  
>
>>Ethan Merritt wrote:
>>    
>>
>>>Is everyone OK with the idea "if a label is out of bounds don't
>>>try to draw it at all"?
>>>      
>>>
>>Not totally.  It would be nice that if a partial text string were
>>supposed to show it would.  
>>    
>>
>
>That happens now for some drivers, but only for labels whose
>coordinates are out of bounds but still positive.  If they go negative
>then nothing good can happen.
>
>  
>
>>I would say that if you pin this down as the 
>>actual problem and it seems that there is no easy solution, then OK.
>>    
>>
>
>Huh?  I know exactly what the problem is.  By the time the coordinates
>for the label are passed to libpdf they have already been mangled by
>converting them to (unsigned int).
>

OK, now that I'm getting the PDF float too large error, I see that is 
the problem.

>If you want to allow the general case of labels that start off-screen
>but extend into view then we would (I think) have to change all the
>coordinates passed to terminal drivers from unsigned to signed.
>
>That would be mean changing many lines of code, but other than that
>I don't see any intrinsic problem with it.  Of course, only a subset
>of drivers could actually do anything useful with the negative numbers.
>

That is the first step I would vote for.  There will still be some 
issues, but this idea of constructing a plot with (0,0) as the reference 
point kind of suggests that negative numbers should be allowed as "work 
room".  Otherwise, it's like an artist starting his or her drawing in 
the bottom left corner of the canvas.

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

Ethan Merritt wrote:

>On Monday 05 July 2004 02:14 pm, you wrote:
>  
>
>>If it seems like it is the PDF utilities fault, then it should be fixed
>>there by someone else.
>>    
>>
>
>I think the chance of us changing the behaviour of a commercial
>product, even the free subset of a commercial product, is near
>zero.  Besides, it offends my sense of aesthetics to screw up the
>negative coordinates by wrapping around to huge positive numbers.
>Once that happens you can't even clip them properly.
>

I agree.

>>I notice that the 3D case for X11 clips off the bottom
>>three labels.  I notice that the PostScript output file shows the bottom
>>three.  I notice that inside the 'test.ps' file the bottom three labels
>>(the ones that X11 truncates) have negative y positions associated with
>>them.  (So, is PostScript expanding the screen to include everything?)
>>    
>>
>
>That is under the control of your viewer program.
>PostScript specifies a bounding box, but the viewer can ignore
>that if it chooses to.  In ghostview/gv you can toggle the this option
>from a menu somewhere.
>

Oh yeah, I forgot about that?

>> I notice that ps2pdf on 'test.ps' produces a 'test.pdf' that works fine
>>in Acroread.  (Does that imply that translating negative numbers for PDF
>>may not really pose a problem?) 
>>    
>>
>
>The problem is not in the PDF file format itself, it's in the libpdf
>library routines.  ps2pdf doesn't use libpdf.
>
>  
>
>>I notice in both X11 and PostScript 
>>that the labels at the very bottom and very top do not have red lines
>>drawn to them.  Is gnuplot treating the "extent" of the plot to the
>>portion inside the labels, and anything beyond that is clipped?
>>    
>>
>
>Wasn't it you who said just upthread that you thought clipping
>should be left to the individual drivers?  They don't all do it the same
>way (or do it at all, in some cases).  If you want a consistent clipping
>policy then we would have to move it into the core gnuplot routines
>rather than leaving it to the terminal drivers and associated support
>libraries.
>

Yes, but (the politician in me says) I think there are two different 
issues.  In one case you have the consistency of how gnuplot constructs 
the plot, what that should be I'm not completely sure.  At the driver 
level we are talking a sanity check, and that is where I'm saying 
map3d_xy() shouldn't be doing that.

As for the particular method, I don't know.  Maybe if the plot borders 
are drawn on the plot, then everything should be clipped at the borders. 
 If the borders are not drawn, maybe everything should be clipped at the 
viewport (or not at all).  An option?

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

On Monday 05 July 2004 02:14 pm, you wrote:
> Ethan Merritt wrote:
> >Is everyone OK with the idea "if a label is out of bounds don't
> >try to draw it at all"?
>
> Not totally.  It would be nice that if a partial text string were
> supposed to show it would.  

That happens now for some drivers, but only for labels whose
coordinates are out of bounds but still positive.  If they go negative
then nothing good can happen.

> I would say that if you pin this down as the 
> actual problem and it seems that there is no easy solution, then OK.

Huh?  I know exactly what the problem is.  By the time the coordinates
for the label are passed to libpdf they have already been mangled by
converting them to (unsigned int).

If you want to allow the general case of labels that start off-screen
but extend into view then we would (I think) have to change all the
coordinates passed to terminal drivers from unsigned to signed.

That would be mean changing many lines of code, but other than that
I don't see any intrinsic problem with it.  Of course, only a subset
of drivers could actually do anything useful with the negative numbers.

Re: General bug - No out of bounds checking on 3D coordinates

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

On Monday 05 July 2004 02:14 pm, you wrote:
> If it seems like it is the PDF utilities fault, then it should be fixed
> there by someone else.

I think the chance of us changing the behaviour of a commercial
product, even the free subset of a commercial product, is near
zero.  Besides, it offends my sense of aesthetics to screw up the
negative coordinates by wrapping around to huge positive numbers.
Once that happens you can't even clip them properly.

> I notice that the 3D case for X11 clips off the bottom
> three labels.  I notice that the PostScript output file shows the bottom
> three.  I notice that inside the 'test.ps' file the bottom three labels
> (the ones that X11 truncates) have negative y positions associated with
> them.  (So, is PostScript expanding the screen to include everything?)

That is under the control of your viewer program.
PostScript specifies a bounding box, but the viewer can ignore
that if it chooses to.  In ghostview/gv you can toggle the this option
from a menu somewhere.

>  I notice that ps2pdf on 'test.ps' produces a 'test.pdf' that works fine
> in Acroread.  (Does that imply that translating negative numbers for PDF
> may not really pose a problem?) 

The problem is not in the PDF file format itself, it's in the libpdf
library routines.  ps2pdf doesn't use libpdf.

> I notice in both X11 and PostScript 
> that the labels at the very bottom and very top do not have red lines
> drawn to them.  Is gnuplot treating the "extent" of the plot to the
> portion inside the labels, and anything beyond that is clipped?

Wasn't it you who said just upthread that you thought clipping
should be left to the individual drivers?  They don't all do it the same
way (or do it at all, in some cases).  If you want a consistent clipping
policy then we would have to move it into the core gnuplot routines
rather than leaving it to the terminal drivers and associated support
libraries.

Re: General bug - No out of bounds checking on 3D coordinates

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

Ethan Merritt wrote:

>Is everyone OK with the idea "if a label is out of bounds don't 
>try to draw it at all"?
>

Not totally.  It would be nice that if a partial text string were 
supposed to show it would.  I would say that if you pin this down as the 
actual problem and it seems that there is no easy solution, then OK.  If 
it seems like it is the PDF utilities fault, then it should be fixed 
there by someone else.

>   This would be change, as right now some
>drivers will draw the piece of the label that is in-bounds even though
>the label coordinates themselves are out of bounds.
>

This would be preferred, I think.

A few things about the datastrings.dem, because I'm not sure my 
observations agree with the problem you are describing.  First, the demo 
looks nice.  I notice that the 3D case for X11 clips off the bottom 
three labels.  I notice that the PostScript output file shows the bottom 
three.  I notice that inside the 'test.ps' file the bottom three labels 
(the ones that X11 truncates) have negative y positions associated with 
them.  (So, is PostScript expanding the screen to include everything?) 
 I notice that ps2pdf on 'test.ps' produces a 'test.pdf' that works fine 
in Acroread.  (Does that imply that translating negative numbers for PDF 
may not really pose a problem?)  I notice in both X11 and PostScript 
that the labels at the very bottom and very top do not have red lines 
drawn to them.  Is gnuplot treating the "extent" of the plot to the 
portion inside the labels, and anything beyond that is clipped?  I would 
say that the clipping should be part of the visible plot *or* the 
"plotting region" plot, but not a combination of both as is the case 
with the labels being visible at the outer regions but not the red lines.

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

Ethan Merritt wrote:

>In principle I agree.  But I was hoping for some sort of quick fix for the
>blatant error of stuffing negative numbers into an unsigned int.
>
>An easy example of the current error is the demo I just added.
>    set term pdf
>    set output 'test.pdf'
>    load 'datastrings.dem'
>
>will exit when it hits the 3D plotting example because one of the labels is
>off the bottom of the plot in the initial view setting. 
>

<cr> to plot again using x2ticlabels
<cr> to plot again using x2ticlabels
<cr> to plot same data from table format
<cr> continue
PDFlib I/O error: Resource configuration file 'pdflib.upr' not found

I'm probably missing something (but my system's been pretty much trouble 
free with the PDF stuff).  This is failing before the 3D plotting 
example, when everything appears to be visible on the screen.

Anyway, I've updated the 'with_image' patch on sourceForge against 
Ethan's additions.  A bit more work integrating the two this time. 
 (Ethan maybe give it a whirl and check if I broke any of your stuff... 
the 'datastring.dem' demo looks fine as far as I can tell.)

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

Daniel J Sebald wrote:

> What I'm wondering is if you feed the PDF routines, say, -25 instead 
> of 4294967270 it will know how to properly clip instead of aborting. 


Or does the PDF library only accept unsigned numbers?

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

Ethan Merritt wrote:

>On Monday 05 July 2004 10:38 am, Daniel J Sebald wrote:
>  
>
>>I don't understand why negative coordinates is an error.
>>    
>>
>
>The error is not the fact that it's negative.  The error is that after 
>stuffing it into an (unsigned int) it looks like a huge positive number
>instead.
>

That I understand.  But Hans seems to be implying that even a negative 
value should be an error.  (Or is that not correct Hans?)

>>>IMHO clipping has to be the duty of the callers of map3d_xy, because only
>>>they can possibly know what the right reaction should be, or at least
>>>output an intelligible errors message if they can't seem to find a
>>>reasonable reaction.
>>>      
>>>
>
>That would be a big change, though.  Right now we leave a lot of
>the clipping to the individual terminal drivers.
>

Where it should be, I think.  (With some type of internal default for 
drivers that can't handle the clip, but this doesn't exist right now.)

>The problem I've run into is that the PDF library doesn't clip in
>these cases, it just causes the program to exit.  
>*Any* solution that leaves you inside gnuplot is better than what
>it is doing now.
>

What I'm wondering is if you feed the PDF routines, say, -25 instead of 
4294967270 it will know how to properly clip instead of aborting.

Dan

Re: General bug - No out of bounds checking on 3D coordinates

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

On Monday 05 July 2004 10:38 am, Daniel J Sebald wrote:
> I don't understand why negative coordinates is an error.

The error is not the fact that it's negative.  The error is that after 
stuffing it into an (unsigned int) it looks like a huge positive number
instead.

> >IMHO clipping has to be the duty of the callers of map3d_xy, because only
> >they can possibly know what the right reaction should be, or at least
> >output an intelligible errors message if they can't seem to find a
> >reasonable reaction.

That would be a big change, though.  Right now we leave a lot of
the clipping to the individual terminal drivers.

The problem I've run into is that the PDF library doesn't clip in
these cases, it just causes the program to exit.  
*Any* solution that leaves you inside gnuplot is better than what
it is doing now.