Re: Engines are started; first car is out the gate

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

Hans-Bernhard Broeker wrote:

>>>The patch I'm proposing is the "wth image", "with rgbimage", and "binary
>>>datafile" stuff, but I should probably say a few things about it on the
>>>list so people know what to expect.
>>>      
>>>
>>My main concern is that you carefully check that your patch does not
>>undo some of the code changes that my recent round of patches added.   
>>
>>In fact, I suggest that is a general requirement for patches added in
>>this current round.  Major changes on top of other major changes
>>are a bit tricky.  Big patches should come with a demo/test-case so
>>that it is easy to verify it still works later on.  For my recent patches
>>these are:
>>	fillbetween.dem
>>	datatstrings.dem
>>	histograms.dem
>>	histograms2.dem	(currently shows a minor bug is present) 
>>

I just confirmed that the patch doesn't alter any of your new additions.

>>We also might want a policy that new features default to 
>>--enable-<feature>  to insure that they are well-tested for compatibility.
>>

OK...  BTW, currently the default for "histograms" is disabled.

...

Well, here are some comments:

1)  With contributions from Ethan and Per, there are a good number of 
drivers covered so far:  x11, postscript family (postscript, epslatex, 
pstex), png, pdf, aqua.  The one main one not covered is probably 
Windows in some form.  However, the software should at least default to 
using filled polygons for that case if pm3d is available.

2)  There are some messages in the patch that come up the first time a 
feature is used that eventually can be weeded out.  For example, the 
first time an image is drawn in X11, information about the graphics 
display is put on the screen.  This is in case someone runs across the 
situation where their color scheme looks incorrect.  They can then pass 
that info along to me for a bug fix.

3)  I think Petr and I have come up with a fairly good syntax for all 
the options to bring in raw data files.  However, feedback is welcome.

4)  I believe the code is clean, compact and efficient.  Some of it may 
look bulky, like all the arrays constructed to extract the variable data 
size info from the compiler.  However, once that is passed through the 
compiler, the result is a compact set of tables.  But on the original 
note, I'm probably a weaker programmer than the group and with perhaps 
different style (although I've learned and adapted a lot), so if anyone 
someday realizes "hey that could be done better like this", feel free to 
alter things.  Or if there is question, just ask.

5)  In the reading of raw data, I've intermixed code in the 
"df_readline()" routine so that the changes I've made have a small 
probability of altering the way any file entry current behaved. 
 However, I look at "df_readline()" as being the workhorse of the file 
reading routines.  As such, it could maybe be cleaned up later on when 
all is said and done.  In fact, I'm wondering if just a couple extra 
conditional statements within this routine could achieve reading 
"gnuplot binary" files so that a special routine for gnuplot binary is 
not needed.

6)  There is one small detail within the software that I've left undone. 
 It is the clipping of pixels for images that are skewed, drawn with 
polygons.  That is, the pixels at the edges of the image which extend 
partial into a non-visible region are currently not clipped into 3 sided 
or 5 sided polygons as they should be.  This happens when zooming.  I 
thought it a bit tedious to go through that, not knowing if the 
arbitrary angle feature were to end up in the final product.  After some 
evaluation if people think "let's keep that", then I can patch the fix. 
 It shouldn't be that difficult.

7)  I'll ask Petr to make the change in the source.  But, I just noticed 
I left some "Enable ..." messages out of the config file.  I'll add that 
quick.

Dan