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

Re: Cannot change to 'C:\' (root) on Windows

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

> Nevertheless, so far as I can tell from testing, versions
> 3.7, 4.0, and 4.1 all behave the same way.
> Why is it suddenly a bug now, but not for the past 10 years?

It was always a bug, but nobody noticed.

---
PM

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

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

Ethan A Merritt wrote:

>>So, those familiar with png/gif/jpeg, are there issues of convenience
>>here for annotation?
> 
> 
> Not sure I understand the question.  You mean the application would
> be to use gnuplot to overlay a plot onto an existing image?
> That would be totaly backwards.  Surely the straightforward path
> is to create a gnuplot plot, then read both the plot and the
> image into ImageMagick/GIMP/Photoshop  to align, scale, and composite?

Yeah, how are people going to use this?  My use is raw monochrome spectrogram
images, time annotated along one axis, frequency along the other.  I think
of jpeg as being some kind of final image format for use in documents, html, etc.

On the other hand, it wouldn't be too absurd to use a jpeg image as a
portion of a plot.  Say I've some quantitative data from a particle accelerator
experiment and in one of the corners of the plot want to have the collision
photo it corresponds to.  Or say a company/lab has its trademark in jpeg
format and wants to put it in the corner of a plot.

Dan

Re: Cannot change to 'C:\' (root) on Windows

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

Nevertheless, so far as I can tell from testing, versions
3.7, 4.0, and 4.1 all behave the same way.
Why is it suddenly a bug now, but not for the past 10 years?



On Sunday 13 November 2005 11:04 am, Petr Mikulik wrote:
> >> Can be reproduced in this way:
> >>
> >> gnuplot> set title 'c:\'
> >> gnuplot> show title
> >>
> >>          title is "c:\\'", offset at ((character units) 0, 0, 0)
> >> It seems routine  try_to_get_string()  returns one superfluous '
> >> more.
> >
> > It has nothing to do with try_to_get_string().
> > The behaviour has been there since at least version 3.7
> > Backslash is an escape character, and you have escaped the trailing
> > single quote. This forces it to be kept in the string.
> > What you need to do is to escape the backslash itself,
> > and use double quotes:
>
> \ is an escape character in quotes " only, not in '
>
> See:
>
> gnuplot> set title 'c:\tmp'
> gnuplot> show title
>
>          title is "c:\\tmp", offset at ((character units) 0, 0, 0)
>
> gnuplot> set title 'c:\'
> gnuplot> show title
>
>          title is "c:\\'", offset at ((character units) 0, 0, 0)
>
>
> In the bug report example, gnuplot mistakenly adds an '
>
> > Does the original problem persist if you use double quotes?
> >
> > Can you use the cygwin syntax (forward slash) instead?
> > 	cd "c:/"
>
> This works.
>
> ---
> PM

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

Re: Cannot change to 'C:\' (root) on Windows

[Martin H. <mar...@gm...>]

>> Can you use the cygwin syntax (forward slash) instead?
>>     cd "c:/"
> 
> This works.
I can confirm this. Hence the "Change Folder" dialog (from the Windows
GUI menu) will not provide this. I assume that Windows users will stick
with the dialog instead of typing into the Gnuplot console... (as I do ;-).

I am just writing this to keep it in mind when searching for a solution...

With best regards,

Martin.

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

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

>> I don't agree this is a good solution. This form
>>      plot "< convert pic.jpeg rgb:-" PLENTY OF OPTIONS with image
>> 
>> I propose gnuplot reads png, gif and jpeg files directly using the GD 
>> library. This won't add any new code into gnuplot but it will make this 
>> feature portable to gnuplot for Windows, for OS/2, for Mac.
>
> So that I understand, you're saying that all the routines that would make it 
> easy to read png/gif/jpeg are already present in gnuplot because of the 
> library's use for generating these types of outputs on the terminal side?

Exactly.

> I like both ideas, really.  I'd say add the AVS support.  (It's only 20-30 
> lines of code.)

OK with me.

> I don't think one escapes the PLENTY_OF_OPTIONS problem with png/gif/jpeg 
> because there too there is no information about image position, pixel 
> spacing, and so on.  I think the primary reason for a person to put an image 
> into gnuplot is to provide axes, annotation and that sort of thing, requiring 
> more details than just the image.

Yes, the user can add these additional options.

> So, those familiar with png/gif/jpeg, are there issues of convenience here 
> for annotation?

Perhaps we can have one additional penguin from the "with image" demo in a 
png file instead of an .rgb.

Actually, scanned images (e.g. from microscopes) are usually in .tiff, so 
converting them into png and adding axes and label by gnuplot is an example 
of an application of png files.

---
PM

Re: Cannot change to 'C:\' (root) on Windows

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

>> Can be reproduced in this way:
>>
>> gnuplot> set title 'c:\'
>> gnuplot> show title
>>
>>          title is "c:\\'", offset at ((character units) 0, 0, 0)
>> It seems routine  try_to_get_string()  returns one superfluous ' more.
>
> It has nothing to do with try_to_get_string().
> The behaviour has been there since at least version 3.7
> Backslash is an escape character, and you have escaped the trailing
> single quote. This forces it to be kept in the string.
> What you need to do is to escape the backslash itself,
> and use double quotes:

\ is an escape character in quotes " only, not in '

See:

gnuplot> set title 'c:\tmp'
gnuplot> show title

         title is "c:\\tmp", offset at ((character units) 0, 0, 0)

gnuplot> set title 'c:\'
gnuplot> show title

         title is "c:\\'", offset at ((character units) 0, 0, 0)


In the bug report example, gnuplot mistakenly adds an '


> Does the original problem persist if you use double quotes?

> Can you use the cygwin syntax (forward slash) instead?
> 	cd "c:/"

This works.

---
PM

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

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

On Sunday 13 November 2005 10:29 am, Daniel J Sebald wrote:
> I don't think one escapes the PLENTY_OF_OPTIONS problem with
> png/gif/jpeg because there too there is no information about image
> position, pixel spacing, and so on.  I think the primary reason for a
> person to put an image into gnuplot is to provide axes, annotation and
> that sort of thing, requiring more details than just the image.

I don't think we'll get very far on choosing a solution until we
agree on what the problem is.  Why, indeed, would anyone want to
read in a jpeg image into gnuplot?  I'd like to have a real application
in mind before trying to guess the best way to support it.

> So, those familiar with png/gif/jpeg, are there issues of convenience
> here for annotation?

Not sure I understand the question.  You mean the application would
be to use gnuplot to overlay a plot onto an existing image?
That would be totaly backwards.  Surely the straightforward path
is to create a gnuplot plot, then read both the plot and the
image into ImageMagick/GIMP/Photoshop  to align, scale, and composite?

-- 
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...>]

Petr Mikulik wrote:
> 
> I don't agree this is a good solution. This form
>      plot "< convert pic.jpeg rgb:-" PLENTY OF OPTIONS with image
> 
> is really ugly and user unfriendly.

The master of scripts bucks the trend.  :-)

> I propose gnuplot reads png, gif and 
> jpeg files directly using the GD library. This won't add any new code 
> into gnuplot but it will make this feature portable to gnuplot for 
> Windows, for OS/2, for Mac.

So that I understand, you're saying that all the routines that would make it easy to read png/gif/jpeg are already present in gnuplot because of the library's use for generating these types of outputs on the terminal side?  Then sure, it is probably wise to support those directly, Petr.  I like that idea.

I like both ideas, really.  I'd say add the AVS support.  (It's only 20-30 lines of code.)  And put the script along with the other scripts on the web page.

I don't think one escapes the PLENTY_OF_OPTIONS problem with png/gif/jpeg because there too there is no information about image position, pixel spacing, and so on.  I think the primary reason for a person to put an image into gnuplot is to provide axes, annotation and that sort of thing, requiring more details than just the image.  The EDF format is the most complete format I've seen; I'm sure there are others.

So, those familiar with png/gif/jpeg, are there issues of convenience here for annotation?

Dan

Re: Cannot change to 'C:\' (root) on Windows

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

On Sunday 13 November 2005 06:27 am, Petr Mikulik wrote:
>
> It is a bug.
>
> Can be reproduced in this way:
>
> gnuplot> set title 'c:\'
> gnuplot> show title
>
>          title is "c:\\'", offset at ((character units) 0, 0, 0)
> It seems routine  try_to_get_string()  returns one superfluous ' more. 

It has nothing to do with try_to_get_string().  
The behaviour has been there since at least version 3.7
Backslash is an escape character, and you have escaped the trailing
single quote. This forces it to be kept in the string.
What you need to do is to escape the backslash itself,
and use double quotes:

gnuplot> set title "c:\\"
gnuplot> show title
        title is "c:\\", offset at ((character units) 0, 0, 0)

This time the first backslash is an escape for the second backslash.
When you use the title in a plot, you will get only one backslash printed.

Now, whether this has anything to do with windows command lines, I'm
not so sure.
Does the original problem persist if you use double quotes?
Can you use the cygwin syntax (forward slash) instead?
	cd "c:/"
 

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

Re: Cannot change to 'C:\' (root) on Windows

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

> I just compiled the current CVS HEAD to update my Gnuplot installation.
> Unfortunately I am unable to change to any root folder (on Windows). If
> I type in "cd 'C:\'" I get the following error:
> Can't change to this directory
> The same applies to D:\ etc. (any root folder). Is that only me or is it
> a bug?

It is a bug.

Can be reproduced in this way:

gnuplot> set title 'c:\'
gnuplot> show title

         title is "c:\\'", offset at ((character units) 0, 0, 0)


It seems routine  try_to_get_string()  returns one superfluous ' more. This 
routine calls  const_express()  ... fixing this needs an expert.

---
PM

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

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

>> Indeed. In fact, we should not add any code at all to gnuplot
>> if the conversion can be done externally. And it can, easily.
>> Since ImageMagick can convert almost anything to a raw RGB stream,
>> I'd think you can do it now with no extra code at all:
>>
>> 	plot "< convert pic.jpeg rgb:-" with image
>>
>> If you need to tweak the code to make that work, then please
>> do so and post a patch.  If it works already, just contribute
>> some documentation.
>
> This of course is a good solution. What is necessary are two things:
>
> A good documentation how to use this, and for Windows users who will not
> know a programme that outputs rgb data, a clear description how the input

I don't agree this is a good solution. This form
  	plot "< convert pic.jpeg rgb:-" PLENTY OF OPTIONS with image

is really ugly and user unfriendly. I propose gnuplot reads png, gif and 
jpeg files directly using the GD library. This won't add any new code into 
gnuplot but it will make this feature portable to gnuplot for Windows, for 
OS/2, for Mac. The ImageMagick is usually installed on modern Linux systems, 
but I doubt for elsewhere.

Look at zimg, which can also read directly these files thanks to the GD 
library (right, Johannes?):

---
PM

Cannot change to 'C:\' (root) on Windows

[Martin H. <mar...@gm...>]

Dear all,

I just compiled the current CVS HEAD to update my Gnuplot installation.
Unfortunately I am unable to change to any root folder (on Windows). If
I type in "cd 'C:\'" I get the following error:
Can't change to this directory
The same applies to D:\ etc. (any root folder). Is that only me or is it
a bug?

With regards,

Martin.

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

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

Ethan A Merritt wrote:
> On Saturday 12 November 2005 06:26 pm, Daniel J Sebald wrote:
> 
> 
>>If 
>>"convert" created a slightly more sophisticated format that contains the
>>array dimensions and data point format, we could support that format.
> 
> 
> You could write in an AVS input mode.
> AVS format is xsize, ysize and then a stream of Alpha/Red/Green/Blue
> pixels.
> 
> 

Attached is a patch for AVS format (*.avs *.x).  Here are some sample commands:

set datafile binary filetype=auto
plot "mandrill.x" binary with rgbimage

Let me know how it works with the "convert" script strategy.  Information about pixel width, height, image offset, etc. is of course lost using "convert" to avs file format.  Those values would have to be specified at the command line if needed.  And then there is the issue of monochrome images.

[BTW, there may be a bug in the binary code.  The command

plot "mandrill.x" binary format='%*uchar%uchar%uchar%uchar' u 1+2+3 with image

should work.  But it doesn't seem to be doing the expected thing.  I'll look for this later.]

This comes with a no warranty.  It is a start and I can do more in the future, but near term I'm very busy.  If you have some tweaks, let me know.

I used the test image at:

http://astronomy.swin.edu.au/~pbourke/dataformats/avs_x/

and it looks correct, except I don't if the x-axis direction is correct.  If you have images that you know after passing through convert come out the wrong x-direction, the following line of code in the patch:

    df_bin_record[0].scan_dir[0] = 1;

should be changed to 

    df_bin_record[0].scan_dir[0] = -1;

Dan

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

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

On Saturday 12 November 2005 06:26 pm, Daniel J Sebald wrote:

> If 
> "convert" created a slightly more sophisticated format that contains the
> array dimensions and data point format, we could support that format.

You could write in an AVS input mode.
AVS format is xsize, ysize and then a stream of Alpha/Red/Green/Blue
pixels.


-- 
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...>]

Ethan A Merritt wrote:
> On Saturday 12 November 2005 03:11 pm, Ethan A Merritt wrote:
> 
>>I'd think you can do it now with no extra code at all:
>>
>>	plot "< convert pic.jpeg rgb:-" with image
> 
> 
> Hey, it works!

Cool.

> 
>  plot '< convert tux.gif rgb:-' binary filetype=rgb array=60x70 \
>  format="%uchar %uchar %uchar" flipy u 1:2:3 with rgbimage
>  
> It would be nice if that long combination of options had some
> shorter form, though.

Yes, the array size is a manual thing... or Harald has shown another feature for extracting the dimensions that I was unaware of.

Well, that is nice.  Can some scripts solve this?  Or perhaps I could write a very generic routine based upon this concept.  Is there a way to send out a system command from within a C program and route the data back in somehow?  Would that be a (not very portable) solution?  If "convert" created a slightly more sophisticated format that contains the array dimensions and data point format, we could support that format.

Dan

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

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

On Sat, 12 Nov 2005, Ethan A Merritt wrote:

> On Saturday 12 November 2005 03:11 pm, Ethan A Merritt wrote:
> > I'd think you can do it now with no extra code at all:
> >
> > 	plot "< convert pic.jpeg rgb:-" with image
>
> Hey, it works!
>
>  plot '< convert tux.gif rgb:-' binary filetype=rgb array=60x70 \
>  format="%uchar %uchar %uchar" flipy u 1:2:3 with rgbimage

I'm not totally convinced. This is better:

plot '< convert tux.gif rgb:-' binary filetype=rgb \
  array=`identify -format '%wx%h' tux.gif` \
  format="%uchar %uchar %uchar" flipy u 1:2:3 with rgbimage notitle

> It would be nice if that long combination of options had some
> shorter form, though.

Oh yes! :-)

Best regards
Harald

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

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

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

On Saturday 12 November 2005 03:11 pm, Ethan A Merritt wrote:
> I'd think you can do it now with no extra code at all:
>
> 	plot "< convert pic.jpeg rgb:-" with image

Hey, it works!

 plot '< convert tux.gif rgb:-' binary filetype=rgb array=60x70 \
 format="%uchar %uchar %uchar" flipy u 1:2:3 with rgbimage
 
It would be nice if that long combination of options had some
shorter form, though.


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

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

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

On Sat, 12 Nov 2005, Ethan A Merritt wrote:

> On Saturday 12 November 2005 02:54 pm, Daniel J Sebald wrote:
> > Harald Harders wrote:
> > > On Fri, 11 Nov 2005, Daniel J Sebald wrote:
> > >>>Really?  You have code that reads in a jpeg file?
> > >>
> >
> > First, let me preface this to say that we shouldn't embark on adding
> > support for a lot of images too soon without discussion.  We don't want
> > to get a bloated plotting program.
>
> Indeed. In fact, we should not add any code at all to gnuplot
> if the conversion can be done externally. And it can, easily.
> Since ImageMagick can convert almost anything to a raw RGB stream,
> I'd think you can do it now with no extra code at all:
>
> 	plot "< convert pic.jpeg rgb:-" with image
>
> If you need to tweak the code to make that work, then please
> do so and post a patch.  If it works already, just contribute
> some documentation.

This of course is a good solution. What is necessary are two things:

A good documentation how to use this, and for Windows users who will not
know a programme that outputs rgb data, a clear description how the input
file format looks like. For example, the file starts with two 8-bit
unsigned ints containing the resolution in x and y direction, every pixel
contains of three 8-bit chars for rgb, ...

But this should be done by somebody who knows the image code.

Best regards
Harald

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

Overall approach for coordinate systems and clipping

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

On Sat, 12 Nov 2005, Daniel J Sebald wrote:

> > 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.
>
> I'm sort of in agreement with you, Harald.  [My pipe dream has always
> been to find the time to write a document "How to layout plots in
> gnuplot".] But I would say I think there are two distinct concepts here,
> one the size of the plot with respect to the convas and another the size
> of the canvas with respect to the plotting device's inherent coordinate
> system.

Right. I agree. And I think we should have both. At the moment, screen is
a mixture of both, depending on the terminal:

postscript:
- screen coordinate system has fixed size
- screen coordinates of upper right corner of canvas is changing according
  to 'set size'

png:
- screen coordinate system - scales with given size in 'set terminal'
- screen coordinates of upper right corner of canvas is changing according
  to 'set size', and image size scales with 'set size', too.

fig:
- acts as png

x11:
- screen coordinate system scales with window
- upper right corner always has screen 1,1.

> For example, with PostScript, if I were to make the _canvas_ size
> 2.0,2.0 without changing plot size, what I'd expect is font size, line
> thickness, etc. to "shrink" in a relativistic way.

You mean, the fonts shall stay the same size, but glyph height is only 5%
of the canvas height instead of 10%? This is the case, also for line
thickness etc.

> Similarly, if I set
> _plot_ size 0.5,0.5 without changing canvas size I'd expect font size,
> line thickness, etc. to "expand" in a relativistic way.

That's the case.

> Mantra?

???

> Clip to the canvas, not the plot?

Depends on what you are doing. Parts of the plot, e.g. lines, vectors etc.
should clip to the plot. But free given labels and arrows should be
clipped to the canvas because it can be useful to place things outside the
plot.

> Should "subplots" have a canvas size too?
> Am I confusing matters worse than already are?

Yes, you are.

Let me conclude what I think now:

1.) The screen coordinate system should not be changed anymore (with the
    exception that the clipping has to be fixed to the current 'set size'
    to canvas size relationship in all terminals.

2.) Some new coordinate systems should be introduced:
  - A canvas coordinate system that always runs from 0 to 1 on the canvas
  - A subcanvas coordinate system that always runs from 0 to 1 on the
    "single-multiplot-plot canvas"
  - One or more coordinate systems with absolute sizes, e.g., mm,
    inch=25.4mm, pt=1/72inch, pixel=(res in dpi)*inch.

3.) A resolution should be introduced which can be forwarded to the pixel
    terminals for the output files and be used by the other terminals to
    be able to calculate between pixel and the other absolute measures.

4.) The screen coordinate should be marked as 'deprecated'.

5.) 'set size' and 'set origin' before 'set terminal' should print a
    warning because they have strange behaviour.

6.) 'set size' and 'set origin' after 'set terminal' should only affect
    the plot, not the canvas. Sizes above 1 should be still allowed in
    case somebody likes to have a half plot on the screen.

7.) 'set size', 'set origin' and the size measures for the terminals
    should understand 'screen' coordinates (which size and origin do
    exclusively, now) and all absolute coordinate systems (mm, inch, pt,
    pixel, character). Not that character is the only absolute coordinate
    system we have at the moment. Its measure only depends on the chosen
    fontsize.

This approach has a couple of advantages:
- Compatibility to old scripts is maintained
- In future, we have a much clearer interface and it is possible to say "I
  want a plot of 5 x 3 inches" (and this for all terminals). What to do
  with the screen terminals is somehow unclear. But using the X server
  solution (which should be accessable), even mm, inch, pt should be
  possible.


What do you all think about this approach?

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...>]

Harald Harders wrote:

> I think this should be easy using the libraries libpng and jpeglib. But I
> will not start working on that. The only issue to me is that I did not
> understand how to use this function. What I would have needed was a
> programme that converts jpeg or png to one of the gnuplot formats.

I like Ethan's suggestion in the previous email.  RGB is as rudimentary as
it gets.  So if one converts to RGB there is the option of specifying at
the command line what the size (bytes) the pixel values are.

> 
> I believe that not may people will know how to deal with image support. By
> the way. Is there anything written in the Gnuplot documentation which
> exact file format is needed to put image data into the plot?

Maybe, maybe not.  We're just getting these ideas together.

 I have not
> found it yet.

Try

help datafile binary
help binary general filetype

Again, try Ethan's idea and specify the data point size if necessary.

Dan

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

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

On Saturday 12 November 2005 02:54 pm, Daniel J Sebald wrote:
> Harald Harders wrote:
> > On Fri, 11 Nov 2005, Daniel J Sebald wrote:
> >>>Really?  You have code that reads in a jpeg file?
> >>
>
> First, let me preface this to say that we shouldn't embark on adding
> support for a lot of images too soon without discussion.  We don't want
> to get a bloated plotting program.

Indeed. In fact, we should not add any code at all to gnuplot
if the conversion can be done externally. And it can, easily.
Since ImageMagick can convert almost anything to a raw RGB stream,
I'd think you can do it now with no extra code at all:

	plot "< convert pic.jpeg rgb:-" with image 

If you need to tweak the code to make that work, then please
do so and post a patch.  If it works already, just contribute
some documentation.

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

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

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

On Sat, 12 Nov 2005, Daniel J Sebald wrote:

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

Exactly.

> > 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.]

You are right. Gnuplot should not do any clipping for postscript, and the
terminal itself could add the postscript clipping on demand:

%%BoundingBox 50 50 350 250
[...]
/Clipping false def
gsave
Clipping {
  newpath
  moveto 50 50
  lineto 350 50
  lineto 350 250
  lineto 50 250
  closepath
  clip
} if
[... all the rest of the file ...]
grestore
%%Trailer

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 Sat, 12 Nov 2005, Daniel J Sebald wrote:

> First, let me preface this to say that we shouldn't embark on adding support
> for a lot of images too soon without discussion.  We don't want to get a
> bloated plotting program.  We'd need a well thought out strategy for
> incorporating file formats.  Petr and I put something together that we thought
> was a start, but I'd hope for input and concensus of how to build on that.

[...]

> But the sticking point is that there is compression or encoding for some
> of these formats.  Perhaps not difficult to deal with.  Create some
> intermediate, uncompressed file then fill in the details about that
> binary file and point gnuplot to it.  Or, one could choose some other
> binary file to always convert to.

I think this should be easy using the libraries libpng and jpeglib. But I
will not start working on that. The only issue to me is that I did not
understand how to use this function. What I would have needed was a
programme that converts jpeg or png to one of the gnuplot formats.

I believe that not may people will know how to deal with image support. By
the way. Is there anything written in the Gnuplot documentation which
exact file format is needed to put image data into the plot? I have not
found it yet.

At the moment, I have moved to the epslatex terminal with

set label '\includegraphics{asdf}' at ...

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...>]

Harald Harders wrote:
> 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.

I'm sort of in agreement with you, Harald.  [My pipe dream has always been to find the time to write a document "How to layout plots in gnuplot".]  But I would say I think there are two distinct concepts here, one the size of the plot with respect to the convas and another the size of the canvas with respect to the plotting device's inherent coordinate system.

For example, with PostScript, if I were to make the _canvas_ size 2.0,2.0 without changing plot size, what I'd expect is font size, line thickness, etc. to "shrink" in a relativistic way.  Similarly, if I set _plot_ size 0.5,0.5 without changing canvas size I'd expect font size, line thickness, etc. to "expand" in a relativistic way.  Mantra?  Clip to the canvas, not the plot?  Should "subplots" have a canvas size too?  Am I confusing matters worse than already are?

Dan

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:
> 
> 
>>>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?

First, let me preface this to say that we shouldn't embark on adding support
for a lot of images too soon without discussion.  We don't want to get a
bloated plotting program.  We'd need a well thought out strategy for
incorporating file formats.  Petr and I put something together that we thought
was a start, but I'd hope for input and concensus of how to build on that.

To give you a general concept, Harald, take a look at datafile.c for:

df_bin_filetype_table_struct df_bin_filetype_table[] = {
    {"gpbin", gpbin_filetype_function},
    {"raw", raw_filetype_function},
    {"rgb", raw_filetype_function},
    {"bin", raw_filetype_function},
#if 1
    {"edf", edf_filetype_function},
    {"ehf", edf_filetype_function},
#endif
    {"auto", raw_filetype_function}  /* "auto" is trapped, but if the actual file extension is "auto" then use raw. */
};
#define RAW_FILETYPE 1

What this does is tell gnuplot that when if finds a file of extension "gpbin", "raw", "rgb", etc. to run the designer function for that file type.  Petr's file breader.c gives an example for files of type EDF.

And the strategy is this:  OK, we now have this generic manner for handling binary files.  Aside from compression (a detail that needs to be worked out), if the data is in some type of rectangular format all you need do is fill in the structure for details about the data format.  In other words, "edf_filetype_function" fills in all the details that one would fill in at the command line, like size of header, bytes to skip per line, etc. etc.  Then just let the program continue onward.

So, we'd need a

{"png", png_filetype_function}
{"jpg", jpg_filetype_function}
{"jpeg", jpg_filetype_function}

But the sticking point is that there is compression or encoding for some of these formats.  Perhaps not difficult to deal with.  Create some intermediate, uncompressed file then fill in the details about that binary file and point gnuplot to it.  Or, one could choose some other binary file to always convert to.

Hopefully this gives you an idea why things should be thought out.  Are there better strategies?  The main thing that concerns me is we get more and more core code for every new file format.  Rather, I'd prefer some kind of "unix modules" or DLL approach.

Dan