Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-05 12:48:44
|
On Sun, 4 Jul 2004, Ethan A Merritt wrote:
> I have encountered a nasty bug that has been around since forever.
> It is not obvious to me what is the best way to deal with it.
>
> The basic problem is that the 3D mapping routine map3d_xy() in util3d.c
> stuffs its output into (unsigned int) terminal coordinates.
> But it does so without ever checking that the results are positive numbers.
Going negative isn't the only possible error. Going beyond term->xmax or
term->ymax is just as wrong. Granted, the terminal drivers don't usually
crash or run into endless loops because of it, but it's wrong nonetheless.
And it's not only map3d_xy that does that. Traditionally, there has been
next to *no* clipping of positions to visible or allowable ranges anywhere
in gnuplot. Some terminal drivers do their own clipping, and some
graphics elements did learn to clip properly over time. But generally
it's still a "you get what you asked for" world down there.
See, e.g. the 'set arrow to far away points causes garbage' bug registered
at SF. In more technical terms, that bug's title should be "arrows don't
clip".
> - Have map3d_xy() call int_error() if the coordinates go negative?
No. map3d_xy is far too deep in the basement of gnuplot to output a
meaningful int_error() message.
> - Have map3d_xy() siliently truncate to zero?
> - Have map3d_xy() truncate, but not so silently?
No to both. For the same reason: map3d_xy() has no way of knowing how to
properly clip positions. E.g. if the actual thing being drawn is a line
segment, clipping the out-of-range endpoint to the nearest point on the
viewport border will rotate the entire edge. I'm quite sure that's not
sensible behaviour.
Anyway, IMHO if map3d_xy() were to clip, it should clip *before* it
transforms, i.e. it should clip points to the boundary of its input
coordinate system (the 3D graph box). But that would kill time-honoured
hacks like 'set view ,,1.2', which deliberately produce points outside
that volume.
gnuplot is consistently inconsistent in the way it uses signed vs.
unsigned data types. E.g. in the context at hand, map3d_xy uses
unsigned int for its result:
*xt = (unsigned int) ((res[0] * xscaler / w) + xmiddle);
*yt = (unsigned int) ((res[1] * yscaler / w) + ymiddle);
whereas the other major conversion method from normalized, or "view" 3D
coordinate space (x and y those of the page, z orthogonal to it, origin in
the center of it), to terminal coordinates is the TERMCOORD macro:
/* Maps from normalized space to terminal coordinates */
#define TERMCOORD(v,xvar,yvar) \
{ \
xvar = ((int)((v)->x * xscaler)) + xmiddle; \
yvar = ((int)((v)->y * yscaler)) + ymiddle; \
}
-Wsign-compare is by far the most frequently issued warning you get
building gnuplot with a picky compiler setting:
1 might be used uninitialized in this function
1 comparison of unsigned expression < 0 is always false
2 argument might be clobbered by or
4 signed and unsigned type in conditional expression
10 unused parameter
21 cast discards qualifiers from pointer target type
54 (near initialization for )
54 missing initializer
111 comparison between signed and unsigned
(The 54 "missing initializer" ones are caused by shortened terminal
structs, i.e. they're completely harmless).
> The cleanest is probably to return an error from map3d_xy,
Agreed.
> but since there are roughly 100 call sites this would be a *lot* of
> extra code to handle error checking.
Not really. map3d_xy() is called 41 times:
gnuplot/src $ cscope -L3 map3d_xy | wc -l
41
The companion function map3d_xyz() doesn't convert all the way to terminal
coordinates, so it doesn't have this particular problem.
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.
--
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.
|
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-05 13:05:45
|
On Mon, 5 Jul 2004, Daniel J Sebald wrote: > Can signed ints be passed back to avoid the use of floating point? They can, but that would only delay the problem, not really solve it. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-05 23:27:20
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2004-07-06 00:45:35
|
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 > > |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-05 23:29:18
|
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. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-05 23:35:28
|
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. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-06 11:48:31
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2004-07-06 15:55:54
|
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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-06 12:10:46
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2004-07-05 17:14:18
|
Hans-Bernhard Broeker wrote:
>>- Have map3d_xy() call int_error() if the coordinates go negative?
>>
>>
>
>No. map3d_xy is far too deep in the basement of gnuplot to output a
>meaningful int_error() message.
>
Right.
>>- Have map3d_xy() siliently truncate to zero?
>>
>>
>
>
>
>>- Have map3d_xy() truncate, but not so silently?
>>
>>
>
>No to both. For the same reason: map3d_xy() has no way of knowing how to
>properly clip positions. E.g. if the actual thing being drawn is a line
>segment, clipping the out-of-range endpoint to the nearest point on the
>viewport border will rotate the entire edge. I'm quite sure that's not
>sensible behaviour.
>
I agree with that.
>>The cleanest is probably to return an error from map3d_xy,
>>
>>
>
>Agreed.
>
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.
>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.
>
I agree with that. 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. The analogy would be like
the base routine of an object oriented language; a base routine that can
be overridden. A couple examples: Take clipping a line segment at the
border. There are probably some terminal drivers which handle this
cleanly, and perhaps some that don't. Well, it's a simple routine, and
all the terminals that can't handle clipping should instead access a
single gnuplot routine that does the clipping (and of course that
routine would in turn call the terminal driver for plotting line
segments that are within bounds). The second example might be the image
routines. I've recently noticed in PostScript and PDF that "skews" can
be put in images. That is, rather than use the PM3D routines to plot an
image with a skew, all that simply need be done for PostScript and PDF
is give the appropriate parameters, resulting in a more efficient PS or
PDF file. My guess is that not all terminals can do this, so gnuplot or
terminal drivers should default to using PM3D elements for this option.
So here would be the alternatives:
1) Forget about fairly advanced features as this in PostScript where
images can be given skew.
2) At the driver level have some type of default routine containing the
PM3D method (i.e., little paralellograms for pixels).
3) At the gnuplot level (graphics.c) deal with this, but have the
terminal indicate if it can handle skewed images, e.g.
if (term->parameters(HAVE_SKEWED_IMAGES)) {
} else {
}
Another one in this category might be the arrow head/line thickness
problem. I'm in the camp who think lines with arrows should have the
head of the arrow stop exactly at the point given to gnuplot. The code
to do this isn't too bad provided one knew the thickness of the line in
question. One would want to reuse that code. Should it be at the
driver level in an object oriented model (2) or should it be at the
gnuplot level (3) and get the line thickness from the terminal, e.g.,
term->parameters(LINE_THICKNESS)? I mean, provided it was pressing
enough to address the issue?
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-05 17:45:57
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2004-07-05 20:03:17
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2004-07-05 20:12:54
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-05 17:45:30
|
On Monday 05 July 2004 05:43 am, Hans-Bernhard Broeker wrote:
> On Sun, 4 Jul 2004, Ethan A Merritt wrote:
> > The cleanest is probably to return an error from map3d_xy,
> > but since there are roughly 100 call sites this would be a *lot* of
> > extra code to handle error checking.
>
> Not really. map3d_xy() is called 41 times:
Oops. I used grep, and caught a bunch of 'map3d_xyz' instances as well.
> 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.
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.
Well, clipping labels is easier than clipping line segments.
I could add an error return code to map3d_xy() and check for it in
the label-handling code.
Is everyone OK with the idea "if a label is out of bounds don't
try to draw it at all"? 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.
|
|
From: Daniel J S. <dan...@ie...> - 2004-07-05 20:19:32
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2004-07-05 20:50:45
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-05 21:40:53
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2004-07-05 22:23:48
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-05 21:48:36
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2004-07-05 22:33:29
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2004-07-05 23:03:09
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-06 00:09:19
|
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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X