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