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

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

Harald Harders wrote:
> On Wed, 9 Nov 2005, Ethan Merritt wrote:

>>Finally, we need to agree on what is or is not enforced with
>>regards to plotting outside the canvas limits.  I continue
>>to maintain that this should be categorically prevented, by
>>clipping to the current canvas in the core routines.
> 
> 
> I agree.

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.

There is a bit of a conundrum with gnuplot's "terminal" concept.
The throw back to the time it was conceptualized makes me think
"rudimentary terminal".  I don't know about other people's
opinions, but I just don't like the idea of not striving to
utilize the features of plotting utilities, like were mentioned,
PostScript, png, jpg, pdf, etc.  The philosophy (which really
wasn't a big issue ten years ago because of limited utilities)
seems to be implement things generically with the most rudimentary
elements.  If development slows down because people don't have
the time, that's one thing.  Bottlenecks is something different.

As a brainstorm kind of thing, I sort of like the strategy of
having a "fallback prototype".  Use an arrow as an example.  Say
there is some legacy gnuplot code that draws an arrow using just
lines and/or fill.  But there are a number of drawing utilities
that support arrows outright.  It would be nice to set aside the
legacy code as a "fallback prototype" and have a new terminal
routine for arrows.  The fallback prototype would have the same
arguments as the new terminal routine.  The concept would hold
true for a large number of items in ever-evolving software.  It'd
basically be an organized way to allow new things to work their
way into the code instead of running into these headaches.  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.

Dan