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

Re: Success!

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

Ethan Merritt wrote:

>On Tuesday 18 November 2003 12:30, you wrote:
>  
>
>>If it seems to be working now, I will leave it as is and upload
>>it to SourceForge.  If anything seems strange, let me know.
>>    
>>
>
>Quick status update:
>
>I started over again on the alpha with the current cvs source
>patched with your  with_image_111603.diff
>It failed.
>I then started introducing changes one by one from my
>working version.  The key lines were ones you had identified
>earlier:
>#if (0)  /* Doesn't work on alpha */
>#define SET_COLOR_CODE_CHAR      '\x005'
>#define FILLED_POLYGON_CODE_CHAR '\x005'
>#define IMAGE_CODE_CHAR          '\x001'
>#else
>#define SET_COLOR_CODE_CHAR      '5'
>#define FILLED_POLYGON_CODE_CHAR '5'
>#define IMAGE_CODE_CHAR          '1'
>#endif
>

Good, good.  I wonder if the DEC cc compiler thinks that '\x001'
means 'x', when it really is supposed to mean 1.

>With this change on top of the 111603 patch, the alpha
>version can communicate with itself just fine.  How I managed
>to screw this up while testing from home, I do not know.
>

This could be a case of the compilation not appropriately
checking dependence.  x11.trm is dependent upon gplt_x11.h
but since x11.trm is compiled through term.c, it may not
recompile when gplt_x11.h is changed.  I'm not positive on
that.

>It's water under the bridge at this point, I suppose.
>
>However, the 32-bit and 64-bit streams are still not
>interchangeable. In fact they are not even the same length.
>

I will have a look at how these differ.

Thanks,

Dan

Re: Success!

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

On Tuesday 18 November 2003 12:30, you wrote:
> If it seems to be working now, I will leave it as is and upload
> it to SourceForge.  If anything seems strange, let me know.

Quick status update:

I started over again on the alpha with the current cvs source
patched with your  with_image_111603.diff
It failed.
I then started introducing changes one by one from my
working version.  The key lines were ones you had identified
earlier:
#if (0)  /* Doesn't work on alpha */
#define SET_COLOR_CODE_CHAR      '\x005'
#define FILLED_POLYGON_CODE_CHAR '\x005'
#define IMAGE_CODE_CHAR          '\x001'
#else
#define SET_COLOR_CODE_CHAR      '5'
#define FILLED_POLYGON_CODE_CHAR '5'
#define IMAGE_CODE_CHAR          '1'
#endif

With this change on top of the 111603 patch, the alpha
version can communicate with itself just fine.  How I managed
to screw this up while testing from home, I do not know.
It's water under the bridge at this point, I suppose.

However, the 32-bit and 64-bit streams are still not
interchangeable. In fact they are not even the same length.
I attach two output streams for the impersonations demo.
Each works on the machine it was generated on, but not
on the other machine.  I'd say it's OK to call the code
"working" at this point, since it does work on any given
machine.  But if your goal is data interchange, then some
further investigation and cleanup is still needed.

=09Ethan


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: test palette rgb -- Re: show palette palette <n> savergb

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

On Tuesday 18 November 2003 03:44, Petr Mikulik wrote:
>
> I propose
> =09test palette {{rgb | grb | bgr | rbg | ...}}
>
> to get the user chance to distinguish which R,G,B profiles overlap in
> e.g. gray palette.

I'm afraid I don't understand what you are saying here.
Probably a picture is worth a thousand words of explaination.
What is the difference between
=09test palette rgb
and
=09test palette grb
in the resulting output?

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: unlimited windows patch

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

On Tuesday 18 November 2003 06:00, Petr Mikulik wrote:
> > Patch 774822 Unlimited plot windows for X11 terminals.
>
> I think the patch has been carefully tested by several people and it
> works fine. What about if I move it to cvs?

OK by me.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: unlimited windows patch

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

> that I'd like people to test and consider for integration into Gnuplot.  One
> is a moderate length patch for unlimited X11 windows.  The other is the
> longer patch for image and binary data file support.  I will briefly discuss
> the two in separate emails...
>
> Patch 774822 Unlimited plot windows for X11 terminals.
>
> linked_list_103003.diff


I think the patch has been carefully tested by several people and it works
fine. What about if I move it to cvs?

---
Petr

test palette rgb -- Re: show palette palette <n> savergb

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

> > Also, would it not be equally (or even more) useful to have a
> >     'test rgbpalette'
> > that displays in the plot window an indexed array of the
> > palette colors?
>
> That would be really nice. It could be done most easily like that:
>   - save rgb table with 256 samples into a temporary file
>   - plot it by a call to "do_string"

I have it working exactly that above-mentioned way. So, what should be the
syntax?

I propose
	test palette {{rgb | grb | bgr | rbg | ...}}

to get the user chance to distinguish which R,G,B profiles overlap in e.g.
gray palette.

---
Petr Mikulik

Re: Universal enhanced text mode!

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

> I have added reference implementations for
>     post   gd   pdf   x11   dumb

I've tried OS/2 PM terminal, and it still works -- it is not touched by the
patch. This terminal, 'set term pm enha' has an independent implementation
of postscript enhanced features in gclient.c:ParseText() for years.

Would there be some profits for this terminal if it uses your new scheme?
Can you make a patch for it? (I can try to test it.)


> The postscript output is character-for-character identical to
> the output the original version.
> Implementations for gd, pdf, and x11 are 99% complete.

I just wonder: would not it be possible to need less new API functions? For
example, to pass some structure of parameters, and call the same API several
time for slightly different purposes. I remember the discussion here few
years ago, that there are too many API there ... and some could be grouped
together, and those for text properties are good candidates.


BTW, there is a small bug:

set term x11 enha
set title '{/*10 x_2}'
  ... it shifts subscript too much down

Petr

Re: Purpose of xlib terminal ?

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

> On Mon, 17 Nov 2003, Hans-Bernhard Broeker wrote:
> > Xlib output is supposed to be to the x11 driver what the
> > EMF driver would be for the Windows driver.  It's essentially a
> > metafile, i.e. a stored record of drawing commands. In theory, this
> > lets you run gnuplot itself and gnuplot_x11 on different machines.
> >
> > =09rsh somebox gnuplot scriptfile | gnuplot_x11

On Monday 17 November 2003 05:13, Jonathan Thornburg wrote:
> I have used a slight variant a lot:
>
>     set term gnuplot_x11
>     set output 'movie.gnuplot-x11'
> then copy to another machine and play the movie there via
>     gnuplot_x11 <movie.gnuplot-x11


OK. Then I propose to replace the existing xlib.trm code with a
minimal xlib.trm that has its own term->init to set up the output
file, but uses the normal x11.trm routines for everything else.
That way it stays current with x11 when changes are made,
yet takes up virtually no space on its own.
Already tested.  It works as expected.


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: Purpose of xlib terminal ?

[Jonathan T. <jt...@ae...>]

On Mon, 17 Nov 2003, Hans-Bernhard Broeker wrote:
> Not really.  Xlib output is supposed to be to the x11 driver what the EMF
> driver would be for the Windows driver.  It's essentially a metafile, i.e.
> a stored record of drawing commands. In theory, this lets you run gnuplot
> itself and gnuplot_x11 on different machines. E.g.:
> 
> 	rsh somebox gnuplot scriptfile | gnuplot_x11
> 
> would run gnuplot remotely, but gnuplot_x11 on the local machine. This
> might be useful in setups where X11 traffic is not allowed from the remote
> "somebox" to your local one, or where the remote machine doesn't even have
> X11.
> 
> I don't think anyone in the current team has even the slightest idea how
> often this feature was ever used by anyone, or even if it ever was used at
> all.

I have used a slight variant a lot:

    set term gnuplot_x11
    set output 'movie.gnuplot-x11'
    load 'gnuplot script (probably generated by a perl program) which
          will read gigabytes of data files and produce a 1000-frame movie'
    set output

then copy movie.gnuplot-x11 to another machine (which doesn't have the
data files accessible), and play the movie there via
    gnuplot_x11 <movie.gnuplot-x11

ciao,
 
--
-- Jonathan Thornburg <jt...@ae...>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"      http://www.aei.mpg.de/~jthorn/home.html
   "It is analogous to saying that if I put a detour sign in the middle of
    the freeway to direct traffic to my shopping mall, that I am obeying
    the traffic sign protocols." -- Henry Minsky, commenting on what was
                                    wrong with Verisign's "Site Finder"

Re: Purpose of xlib terminal ?

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

On Sun, 16 Nov 2003, Ethan A Merritt wrote:

> Can someone fill me in on the intended use of the xlib terminal?
> Is it primarily just a debugging aid for x11, or a mechanism for piping
> x11 output to something other than gnuplot_x11?

Not really.  Xlib output is supposed to be to the x11 driver what the EMF
driver would be for the Windows driver.  It's essentially a metafile, i.e.
a stored record of drawing commands. In theory, this lets you run gnuplot
itself and gnuplot_x11 on different machines. E.g.:

	rsh somebox gnuplot scriptfile | gnuplot_x11

would run gnuplot remotely, but gnuplot_x11 on the local machine. This
might be useful in setups where X11 traffic is not allowed from the remote
"somebox" to your local one, or where the remote machine doesn't even have
X11.

I don't think anyone in the current team has even the slightest idea how
often this feature was ever used by anyone, or even if it ever was used at
all.

> 'help set term xlib' leads one to believe that the xlib terminal driver
> is the same as x11 except that the output is controlled by 'set output'.

Exactly.  And at the time that was written, this probably was correct.
Since then, bit-rot has done its work.

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

Purpose of xlib terminal ?

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

Can someone fill me in on the intended use of the xlib terminal?
Is it primarily just a debugging aid for x11, or a mechanism for piping
x11 output to something other than gnuplot_x11?

'help set term xlib' leads one to believe that the xlib terminal driver is
the same as x11 except that the output is controlled by 'set output'.
Maybe this used to be true, but there are now many options and
capabilities in x11.trm that are not in xlib.trm

It would be trivial to replace the current xlib.trm code with a
simple TERM_TABLE that duplicates the entries in x11.trm except
for term->init, which would set the output device appropriately.
This would be perfect, if the idea is to use it as a debugger for x11.

But if xlib is exists for compatibility with some other display
program (not gnuplot_x11) then maybe it needs to keep its
limited command set?

Or it could be removed altogether, or replaced with a
terminal option in the x11 terminal
	'set term x11 debug'

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: image/binary patch updated

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

Ethan Merritt wrote:

>On Friday 14 November 2003 13:31, Ethan Merritt wrote:
>  
>
>>On Friday 14 November 2003 13:36, you wrote:
>>    
>>
>>>That crash you are describing with the
>>>swap bytes, it may be that that is not a problem
>>>with the code, but perhaps the fact that the
>>>internal floating point code for DEC cc can't
>>>handle bogus floating point numbers.
>>>      
>>>
>>But yes, there are various compiler options
>>to treat floating point errors differently.
>>I'll try again with a different set of floating
>>point settings.
>>    
>>
>
>OK.  l've rebuilt everything using IEEE floating
>point rather than the alpha native floating point.
>The crashes go away, and the postscript output
>is rather more informative (attached).
>

Glad that is accounted for.  Interesting problem I didn't anticipate.

>Note in particular that the test plot labeled 
>"Closeup of pixels having grid points ...."
>is missing the lower two boxes. That must mean
>something.... if we only recognized what.
>

The data is still not correctly ASCII85 encoded.  That example
with the close up works because with so little data it happens that
the bad coding ends up being valid ASCII85 characters still.  Of
course, the image is incorrect.

I think I see what the issue is.  It is a bug.  The ASCII85 encoding
uses 4 bytes as the input to its mapping.  That is 32 bits.  It is a
series of shift operations in which a 'long' is filled with bits by shifting
left.  When the long is 4 bytes, successive codings will simply shift
the old value out past the length of the long.  But when a long is
8 bytes, the old value is shifted into the more significant bytes of the
variable which, consequently, makes a mess of the coding.  I will update
this on SourceForge, but if you want a quick fix, search in `post.trm'
for the first use of PS_encode85() and put "tuple4 = 0;" after it.  I.e.,

        PS_encode85(tuple4, tuple5);
        tuple4 = 0;

This will clear the tuple4 value so that garbage isn't shifted upward.

>If you really require some particular floating
>point behavior then you need to figure out some
>way of testing for this and at least issue a warning
>when ./configure is run.
>

I'm going to cede to suggestions from you and the list on this one.
My experience with the innards of floating point numbers in
compilers is minimal.  I just assumed that any binary floating
point numbers read in will translate to some valid number and the
user would recognize that plotted results are invalid.  I hadn't
anticipated the possibility of a program crash.

That leaves the shredded X11 images problem unresolved.  I'll
keep thinking.

Thanks,

Dan

Universal enhanced text mode!

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

I have abstracted the enhanced text mode from the postscript
terminal so that it can be used by other terminal types as well.
The core code moves into term.c. Each terminal wanting enhanced
text support must add 3  call-back routines to its TERM_TABLE.=20

Patch is on SourceForge (#842303).
Please check it out before I add it to CVS.

I have added reference implementations for
    post   gd   pdf   x11   dumb

The postscript output is character-for-character identical to
the output the original version.
Implementations for gd, pdf, and x11 are 99% complete.

Implementation of enhanced text for the dumb terminal is
admittedly frivolous, but I wanted to show that the new
mechanism is general enough to apply to any terminal driver.
The commented code for the ENHdumb_ callbacks can serve
as a model for other drivers.

Since the core code is shared, and was already present in
the original postscript driver, adding support to new drivers
does not substantially add to the size of gnuplot.=20
Enabling support for the dumb terminal, for example,
adds only 1500 bytes. More complicated terminals may need=20
larger call-back routines, of course, but the total size increase
of the gnuplot executable after adding the full patch is  about
0.7% on my machine.

A quick demo:

set term dumb enhanced
set title "Dumb is 10^2 less dumb than before"
set label 1 "Sum@_0^{big} fun(x_k)"
set label 1 at -.4, .4
set xrange [-1:0.5]
set xtics nomirror
set ytics nomirror
set tmargin 5
set border 3
plot x*x title "x^2"
#
pause -1


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: Terminal driver cleanup

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

On Wed, 12 Nov 2003, Ethan Merritt wrote:

> Any objections if I update all terminal drivers in the CVS tree to
> explicitly enumerate all entries in TERM_TABLE?
[...]

I don't actually see a need for this (the compiler could almost certainly
catch any errors in this area), but if you feel like doing it, go right
ahead ;-)

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

Re: Terminal driver cleanup

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

> Any objections if I update all terminal drivers in the CVS tree to
> explicitly enumerate all entries in TERM_TABLE?

For me it is OK.

Petr

Terminal driver cleanup

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

Any objections if I update all terminal drivers in the CVS tree to
explicitly enumerate all entries in TERM_TABLE?

For example:
diff -urNP gnuplot/term/aed.trm gnuplot-enhanced/term/aed.trm
--- gnuplot/term/aed.trm        1999-06-22 04:54:13.000000000 -0700
+++ gnuplot-enhanced/term/aed.trm       2003-11-10 20:35:38.000000000 -08=
00
@@ -183,7 +183,15 @@
     AED_VTIC, AED_HTIC, options_null, AED_init, AED_reset,
     AED_text, null_scale, AED_graphics, AED_move, AED_vector,
     AED_linetype, AED_put_text, null_text_angle,
-    null_justify_text, do_point, do_arrow, set_font_null
+    null_justify_text, do_point, do_arrow, set_font_null, NULL,
+    0, /* flags */
+    NULL, NULL, NULL, NULL
+#ifdef MOUSE
+    , NULL, NULL, NULL, NULL, NULL
+#endif
+#ifdef PM3D
+    , NULL, NULL, NULL, NULL
+#endif
 TERM_TABLE_END(aed512_driver)
=20
The reason for doing this is that I would like to add a new
set of TERM_TABLE entries to support enhanced mode
text.  I've split out the driver-independent parts and moved them
to term.c. This requires driver-callbacks to do the actual=20
output.  There is no particular reason that a driver couldn't
support enhanced text without supporting MOUSE or PM3D,
and leaving the various TERM_TABLEs incompletely
specified is just asking for trouble if someone later tries to=20
implement the new call-backs at the end of an incomplete
table.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: show palette palette <n> savergb

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

On Wed, 12 Nov 2003, Petr Mikulik wrote:

> Now, I have it working that way.

Congratulations and thanks for that.

> However, I wonder about the documentation syntax above. Yes, there are some
> commands with help written as
> 	set xxxxx {
> 			{ opt 1 | opt2 }
> 			{ opt3 | opt5 }
> 		}
> 
> but is this somewhere documented that {{bla1 | bla2}} means something
> an additional option, instead of a compulsory of {bla1 bla2}? I don't see
> it -- from 'help':
> 
>  In this document, curly braces ({}) denote optional arguments and a
>  vertical bar (|) separates mutually exclusive choices.  
[...]

Let's put it like this:  there has to be _some_ way to distinguish between
"either a or b" and "either a or b or nothing" in the Syntax description.
We need some kind of braces around the series of alternatives separated by
| to have proper grouping, which means that {a|b} should really mean
"either a or b".  So "either a or b or nothing" has to be expressed in
some other way.  Using the existing meaning of "{}" as "optional
argument", {{a|b}} does have that meaning.  As does {|a|b}.


> Looking to help of some commands, it does not seem very unified. 

Well, the docs has been written by many people over a long time, and it's
pretty hard to get all the fine print right.  So I wouldn't put too much
weight in examples from it.  

> It would be worth if someone goes through gnuplot.doc and makes it all
> right.

Right.  But who has all that time and determination?

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

Re: show palette palette <n> savergb

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

> > 	show palette palette <n> {float | int}
>
> 	show palette palette <n> { | float | int }
> 	show palette palette <n> {{float | int}}
>
> to indicate that {float|int} is optional.

Now, I have it working that way.

However, I wonder about the documentation syntax above. Yes, there are some
commands with help written as
	set xxxxx {
			{ opt 1 | opt2 }
			{ opt3 | opt5 }
		}

but is this somewhere documented that {{bla1 | bla2}} means something
an additional option, instead of a compulsory of {bla1 bla2}? I don't see
it -- from 'help':

 In this document, curly braces ({}) denote optional arguments and a
 vertical
 bar (|) separates mutually exclusive choices.  `gnuplot` keywords or `help`
 topics are indicated by backquotes or `boldface` (where available).  Angle
 brackets (<>) are used to mark replaceable tokens.  In many cases, a
 default
 value of the token will be taken for optional arguments if the token is
 omitted, but these cases are not always denoted with braces around the
 angle brackets.


Looking to help of some commands, it does not seem very unified. See e.g.
'help format' vs 'help log'.

It would be worth if someone goes through gnuplot.doc and makes it all
right.

---
Petr Mikulik

Re: image/binary patch updated

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

[Folks... tell me if this email is too big to be submitting
to the mailing list.  Are people able to see the PNG
images in their browsers?]

Ethan Merritt wrote:

>On Monday 10 November 2003 09:30, you wrote:
>  
>
>>Ethan A Merritt wrote:
>>    
>>
>>>I'll try to test it on an alpha next week (other endian, 64-bit).
>>>      
>>>
>>That will be interesting.  Let me know how it goes.
>>    
>>
>
>First report:  not so good.
>

Well, not too bad either.  I'm encouraged the images
look reasonable.

>There are additional warnings during compilation for datafile.c and gplt_x11.c
>
>cc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/3.8j\" -DCONTACT=\"bug...@da...\" -DHELPFILE=\"/usr/local/share/gnuplot/3.8j/gnuplot.gih\" -I/usr/local/include    -g -c datafile.c
>cc: Warning: datafile.c, line 3156: In this statement, the expression "*pchar=*++pchar" modifies "pchar", and fetches its value in a computation that is not used to produce the modified value without an intervening sequence point.  This behavior is undefined.
>                        *pchar = *++pchar;
>------------------------^
>

I will change that in the code.  But if you want, try
changing, in your code, the three lines in that loop to

            char temp = *pchar;
            *pchar  = *(pchar+1);
            *++pchar = temp;

>cc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/3.8j\" -DCONTACT=\"bug...@da...\" -DHELPFILE=\"/usr/local/share/gnuplot/3.8j/gnuplot.gih\" -I/usr/local/include    -g -c gplt_x11.c
>cc: Warning: gplt_x11.c, line 2435: In this statement, the referenced type of the pointer value "&R_rshift" is "short", which is not compatible with "unsigned short".
>                            R_msb_mask = BitMaskDetails(vis->red_mask, &R_rshift, &R_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2435: In this statement, the referenced type of the pointer value "&R_lshift" is "short", which is not compatible with "unsigned short".
>                            R_msb_mask = BitMaskDetails(vis->red_mask, &R_rshift, &R_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2436: In this statement, the referenced type of the pointer value "&G_rshift" is "short", which is not compatible with "unsigned short".
>                            G_msb_mask = BitMaskDetails(vis->green_mask, &G_rshift, &G_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2436: In this statement, the referenced type of the pointer value "&G_lshift" is "short", which is not compatible with "unsigned short".
>                            G_msb_mask = BitMaskDetails(vis->green_mask, &G_rshift, &G_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2437: In this statement, the referenced type of the pointer value "&B_rshift" is "short", which is not compatible with "unsigned short".
>                            B_msb_mask = BitMaskDetails(vis->blue_mask, &B_rshift, &B_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2437: In this statement, the referenced type of the pointer value "&B_lshift" is "short", which is not compatible with "unsigned short".
>                            B_msb_mask = BitMaskDetails(vis->blue_mask, &B_rshift, &B_lshift);
>-----------------------------------------^
>

The above warnings I can fix by just declaring chars and
uchars correctly.  I can get to it this evening.  But the
graphics card details you printed below look reasonable.

>Attached are some screen shots from the X11 output.
>Tux starts out looking a bit ill, and gets worse from there.
>
>Terminal output during the first demo (tux_1) is
>  vis->visualid: 0x23   vis->class: 4   vis->bits_per_rgb: 8
>  vis->red_mask: ff0000   vis->green_mask: ff00   vis->blue_mask: ff
>  ImageByteOrder:  0
>

There certainly is a problem with the graphics mapping.
(The sort of thing seen before.)  It looks like the usual
masks, but there seems to be a lot of variation just exactly
what bits within that mask do what.  And the mangled
image is not good.  (Not seen before.)  I can only assume
that has to do with the decoding of data.  These may all
have something to do with the signed/unsigned warnings
above.

The blue channel seems to come out correctly.  No
surprise since that is the one with the mask associate
with the rightmost bits.

>The PNG output looks OK, so I think this part of it is due to problems in 
>gplt_x11.c
>

Yes, definitely.

>However, the program then dies on a floating exception from the
>1st binary data demo, right after printing:
>

Not so good.  But these usually aren't so hard to
track down.  Gnuplot crashes for PNG as well I assume.
That particular example is a rather innocuous one.  I wonder
what happened.  Could you please try a few things in
image.dem to isolate the problem just a bit more?  Try
inputting the lines one at a time.  Try skipping that example.
Etc.

>        The following binary data sizes are machine dependent:
>
>          name (size in bytes)
>
>          "char" "schar" "c" (1)
>          "uchar" (1)
>          "short" (2)
>          "ushort" (2)
>          "int" "sint" "i" "d" (4)
>          "uint" "u" (4)
>          "long" "ld" (8)
>          "ulong" "lu" (8)
>          "float" "f" (4)
>          "double" "lf" (8)
>
>        The following binary data sizes attempt to be machine independent:
>
>          name (size in bytes)
>
>          "int8" "byte" (1)
>          "uint8" "ubyte" (1)
>          "int16" "word" (2)
>          "uint16" "uword" (2)
>          "int32" (4)
>          "uint32" (4)
>          "float32" (4)
>          "float64" (8)
>

Well hey!  This is very nice.  This is probably the first case
where the doubles, longs and ulongs are 8 bytes.  Also, notice
that the "machine independent" code did what it is supposed
to do.  However, it looks like an "int64" and "uint64" are needed.

>I am not sure yet whether this is due to the error message from
>datafile.c, or whether it is something more fundamental.
>

At first glance, it doesn't look like that command would
be the problem.  That is part of the PDP endian, which
I suspect isn't being reached in this case.

Let me think these over.

Thanks,

Dan


>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

image/binary patch updated

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

I've updated the image/binary patch (694789) to include Ethan's
drivers for PDF and PNG/JPEG.  (I'm intending that to be the
last update.)

-------

I'm now going to offer some comments about ways I feel Gnuplot
can be improved in terms of code and enhanced in terms of
features.  (Call it a harangue if you like, but I'm not intending this
to be critical.)  No one need respond because the suggestions
are more long term.  Or should I say post 4.0?  Maybe just keep
this post around for future ideas.

1)  Convergence of 2D and 3D plots:  I'm not sure how Gnuplot
developed in terms of 2D and 3D plots.  Perhaps they were
coded separately and then combined.  Perhaps there was a
bifurcation along the way for some reason.  In any case it seems
there is some duplication of code for plotting in 2D and in 3D.

For example, there is "plot_lines()" in "graphics.c" and "plot3d_lines()"
in "graph3d.c".  But are these really that different?  (Perhaps someone
knows better than I do if in fact they are drastically different.)  It
seems to me that "map3d_xy" is the most important detail.  But
couldn't this just be "map_xy()" and if the current mode is PLOT_MODE
as opposed to SPLOT_MODE, say, the map_xy() routine does a simple
unity mapping?

Another example is the image drawing routine I put in
the patch, which  is designed to work for 2D or 3D plots.  If a
Boolean variable indicates that a 3D mapping should be done
then the code will call "map3d_xy()".  [I pause to make a point that
this mapping has to be at the point right where the data is utilized.
The reason is that the data stored in 3d plots is before mapping
because the viewing angle can be changed and the splot redrawn.
The only other way is to map all data and store in a temporary chunk
of memory and pass that in.  But I don't think anyone would think
that is a good idea.]  This image plotting routine is in "graphics.c".

Also in "graphics.c" I see some notes left by Hans such as

> /* FIXME HBB 20020225: this is shared with graph3d.c, so it shouldn't
>  * be in this module */


so I'm guessing he's been faced with trying to adhere to the practice
of code reuse as well.

The point, I believe, is that when it boils down to the actual process
of plotting something, it is always in the 2D viewing plane that this
is done.  Whether this means first mapping from the 3D space or not
is a minor detail, I think.

So a bit contrary to Hans remark in the code, I would contend that
graphics.c is the appropriate spot for all graphic object drawing
routines.  Then the dimension-specific details should go into
"graph3d.c" and a new file "graph2d.c".  Furthermore, consider that
there are two different structures for 2D plots and 3D plots,
"curve_points" and "surface_points".  An argument could be made
for having just one structure.  But even if that shouldn't be the case,
it is the

    int p_count;            /* count of points in points */
    struct coordinate GPHUGE *points;

which are important to the actual graphics drawing routines.  So
my suggestion would be to make all graphics drawing routines
operate on a pointer to the points and number of points or combine them in
their own structure and pass that into the routine.  In fact, if one were to
think about this, I bet if these were packed together and put at the
start of both the "curve_points" and "surface_points" structures the
pointers to these plots could be passed in and there would be no need to
distinguish between the two types of pointers because the important data
would have the same offset in the structures.  The graphics routines would
have a "map_xy()" right before they are used.  (The conditional done
inside the "map_xy()" function to conserve code space.)  So I guess that
means the mode would also need to be packed with those two.  Anyway,
I hope you get my point.

2) Not too far removed from #1, with the image stuff I've added a
a short bit of code to allow a colorbox in 2D plots.  It became clear
to Petr and me that the "3d" associated with colorboxes should be
dropped.  So, it seems that a nice consistent method of adding a colorbox
to a plot, either 2D or 3D, is in order.  Right now they are separate.
However, they should essentially use the same code when laying out
the plot.  Petr had some ideas for enhancing the positioning of the color
box and it is logical to not have to change that in multiple spots.  Also,
the slick routine should place the colorbox at the side of the plot.  Petr
and I have agreed that having the colorbox embedded in the splot 3D
space, so that it moves and changes shape when panning the view, is
a bit lacking.  We contemplated fixing that, but I think it is better 
for the
group to think that one through.

3)  Add the capability of RGB to polygons:  Currently polygons use palette
lookup for generating the fill color.  However, I don't see why there can't
be RGB components just like for images.  I personally can't think right
now what the applications might be, but it doesn't seem too far fetched that
such a thing could find a use.  (I don't know, contouring for landscapes,
color image warping, etc.)  One might argue that would require altering
so many of the terminal drivers so the term->polygon has one extra
variable.  But with xemacs, something like "xemacs *.trm" at the command
line will open all files and a replace function could get the job done in an
hour or two.  Sure it would take some more work to add functionality to
the drivers, but various people could choose their favorite and make the
alterations.

4)  Memory usage for storing data points:  This one probably has the
least chance of being addressed.  The "struct coordinate GPHUGE"
is a bit wasteful of memory if only a few columns of it store data that
is actually used.  It would be nice to have a scheme not so wasteful,
say using a "void" pointer and store just the number of columns actually
used.  However, this is some very "advanced" programming, especially
when there is a group of developers.  Many would make the "worst
case scenario" argument for not doing this.  So, ey, just an idea and
I wonder how many feel this is important.

5)  There are some routines in "show" and "set" that list the options
for plot styles, etc.  The strings for these always have to be updated
and some times may become out of date.  Would a little routine be
worthwhile to simple go to the table and pull out the style strings and
print them?  The routine would have to know when there is no more
room on an 80 character line to show the next string and first enter a
carriage return.

6)  How about a simple "help search <text>" routine that searches through
all the gnuplot.doc strings and dumps out the headings of all subtopics that
contain <text>?

Dan

Re: Color structures

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

In summary:

**************** color.h **************

*** this we keep:

/* Contains a colour in RGB scheme.
   Values of  r, g and b  are all in range [0;1] */
typedef struct {
    double r, g, b;
} rgb_color;


*** new structure:

/* Contains a colour in RGB scheme.
   Values of  r, g and b  are all in range [0;255] */
typedef struct {
    unsigned char r, g, b;
} rgb255_color;



**************** getcolor.h **************

void color_from_gray( double gray, rgb_color *color )

=> will be renamed to

void rgb1_from_gray( double gray, rgb_color *color )


New routine:

void rgb255_from_rgb1( rgb_color *color1, rgb255_color *color255 )
{
    *color255.r = (unsigned char)(255 * color1.r + 0.5);
    *color255.g = (unsigned char)(255 * color1.g + 0.5);
    *color255.b = (unsigned char)(255 * color1.b + 0.5);
}


void rgb_from_gray( double gray,
	unsigned char *r, unsigned char *g, unsigned char *b )

=> will be renamed and changed to

void rgb255_from_gray( double gray, rgb255_color *color )
{
	rgb_color color1;
	color_from_gray( gray, &color1 );
	rgb255_from_rgb1( &color1, color );
}


> I think it should be bundled up into a separate patch so that it can be
> tested independent of your pixel/image stuff.

It is code cleanup, so I will put it directly into cvs (sending you the
patch in advance for test).


Further, I remember: the other candidate for rename is
	set_pm3d_zminmax()	=>	set_cbminmax()

---
Petr Mikulik

Re: Color structures [ was Re: image and binary data file]

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

Ethan Merritt wrote:

>On Tuesday 04 November 2003 13:39, Daniel J Sebald wrote:
>  
>
>>So I would propose in the header file have two types of structures
>>
>>/* Contains a colour in RGB scheme.
>>   Values of  r, g and b  are all in range [0;1] */
>>typedef struct {
>>    double r, g, b;
>>} rgb1_color;
>>    
>>
>
>We already have such a structure defined in color.h
>

Right.  I was thinking of just adding a "1" to "rgb" for clarity.
It could be left as is.

>I'm all in favor code cleanups, up to a certain point.
>But this potentially touches a lot of code,
>

There are only about 20 occurrences in 4 files.  Not too bad using
a "replace" edit function...

> so I think it
>should be bundled up into a separate patch so that 
>it can be tested independent of your pixel/image stuff.
>

I agree.

Dan

Color structures [ was Re: image and binary data file]

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

On Tuesday 04 November 2003 13:39, Daniel J Sebald wrote:
> So I would propose in the header file have two types of structures
>
> /* Contains a colour in RGB scheme.
>    Values of  r, g and b  are all in range [0;1] */
> typedef struct {
>     double r, g, b;
> } rgb1_color;

We already have such a structure defined in color.h

> /* Contains a colour in RGB scheme.
>    Values of  r, g and b  are all in range [0;255] */
> typedef struct {
>     uchar r, g, b;
> } rgb255_color;

OK.

[snip description of passing the structure to subroutines,
 rather than passing the individual r,g,b components]

> I sort of don't like large numbers of arguments in high
> level programming, only at the driver and assembly level.

I'm all in favor code cleanups, up to a certain point.
But this potentially touches a lot of code, so I think it
should be bundled up into a separate patch so that=20
it can be tested independent of your pixel/image stuff.

=09Ethan


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: show palette palette <n> savergb

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

> as a function that prints its output.  So the command sequence
> would become
> 	set print '<palettefile>'
> 	print palette(n)

Result of palette(n) would be a matrix, not a number, so I don't like this
syntax.

> As to the float/int option, can't we just write both into the file?
> Each line would have an integer triplet and a float triplet.
> So output of 'print palette(n)' would be 8 numbers per line:
> <index> <grey value> <r> <g> <b> <ir> <ig> <ib>

Only one triplet has to be saved into the file so that 3rd party
applications can read that gnuplot palette. That was the main idea for
implementing this feature (gnuplot palette models are really extremely
powerful).


BTW, there are also binary palette ".lut" files accepted by some
applications, e.g. ImageJ. Does somebody know their structure?

---
Petr Mikulik

Re[4]: arrowheads too long in PostScript terminal

[Alan G I. <ai...@am...>]

> On Sat, 1 Nov 2003, Alan G Isaac wrote:
>> I would still expect the ink not
>> to pass the point the arrow is drawn "to" (in the direction
>> of the arrow).

On Sat, 01 Nov 2003, Hans-Bernhard Broeker apparently wrote:
> I don't think so.  The question is why you drew an arrow, and how the
> average reader would read the resulting plot.  If the tip is visibly
> rounded, the most obvious position to be read out of it would indeed be
> the center of that arc, not some point on it, because it'd be hard to tell
> where on the arc that should be.

If we were talking about headless arrows with rounded caps,
I would agree with this.  (In otherwords, I am certainly
not arguing that the caps should be offset for a line 
segment.) But an arrowhead pins down a sense
of direction that eliminates the problem you raise.
Consider the attached EPS file.

Cheers,
Alan

%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 71 49 313 149
%%Pages: 1
%%EndComments
%%Page: 1 1
%%BeginDocument: C:/temp.ps
%!PS
/Helvetica 20 selectfont
72 120 moveto
(Which line do I point to?)show
72 72 moveto
288 72 lineto
72 100 moveto
288 100 lineto
6 setlinewidth
stroke
288 72 moveto
0 setgray
gsave
currentpoint translate
0 -12 lineto
24 0 0 12 4 arct
0 12 lineto
closepath
fill
grestore
288 100 moveto
0 -12 rlineto
24 12 rlineto
-24 12 rlineto
closepath
fill
312 50 moveto
0 100 rlineto
307.2 50 moveto
0 100 rlineto
305.5 50 moveto
0 100 rlineto
0.1 setlinewidth
0.5 setgray
[3 2] 0 setdash
stroke
showpage
%%EndDocument
%%Trailer