Re: smooth shading & terminal specialities

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

Ethan Merritt wrote:
> On Monday 08 May 2006 12:26 pm, Daniel J Sebald wrote:
> 
>>My opinion is that this "gppsfile" variable should be eliminated.  
>>From what I understand, the purpose of this is a flag in the main 
>>code that indicates a PostScript comment can be added to the file 
>>for later use.  
> 
> 
> Your understanding is wrong.  No post-processing is involved.
> The gppsfile is the PostScript output stream itself.
> If the current terminal driver is "post", this is only output
> stream (gppsfile == gpoutfile).  But for epslatex, pslatex, etc,
> it is a secondary output stream parallel to the TeX output.

Well, that's true.  But ultimately, I think the purpose here is more one of being a flag, i.e.,

    /* for pm3dCompress.awk */
    if (gppsfile)
	fputs("%pm3d_map_begin\n", gppsfile);

[snip]

    /* for pm3dCompress.awk */
    if (gppsfile)
	fputs("%pm3d_map_end\n", gppsfile);

> 
> 
>>PostScript is the most feature rich language I'm aware of.  
>>(The Adobe language reference should be consulted first.) 
> 
> 
> It's beginning to show its age.  Poor support for UTF8 for
> one thing, but more to the point in the present discussion --
> it doesn't support gradient fill.  That puts it behind 
> several of the other output drivers.

OK.  How about PDF, does that have more features like gradient fill than does P.S.?

...  Forgot to mention desires for compression in images that have come up.  (That really has no significance to recent discussion about terminal commands.)  And also the colorbox can be done with an image.

> 
> 
>>I guess I've never completely understood the convention of 
>>"default routine" in the terminal driver concept.  
>>Someone will have to explain this.
> 
> 
> Easy.  Some output devices have special requirements, or
> special capabilities. So the corresponding terminal driver
> needs a private routine to implement these requirements
> or features.  But it would be silly to write a private
> routine for every single driver, because most of them can
> share a generic default routine.
> 
> For instance, some of the TeX variants support a "draw arrow"
> command as a native operation, and can produce snazzier arrows
> than gnuplot's generic do_arrow() routine.

Let's see if I can fit the image stuff into this context.  The terminal specific driver is "image_for_term" in which we add some angle.  (We're still in "experimental stage", right?):

->image_for_term(<current vars>, angle_struct)

where <current vars> is the current list of variables.  Then I supply the routine in cases where a driver can't use projection:

generic_image_with_rhombus()
{

  /* If projection implies pixels will be rectangular then can use the terminal driver's image drawing routine, but how to now access this?

  if (<rectangular projection tests>)
    term->rectangular_image_for_term()  /* Some other terminal routine? */
  else
    <this code already exists in plot2d.c and would simply need repackaging in function form>

}

Then the terminal driver could put ->generic_image_with_rhombus() in place of ->image_for_term()?

My quandary is that the slot in the terminal driver list gets used by the generic function, but there is still some terminal specific code to come after that.  Then what?  The result would be two slightly different terminal image routines?

The alternative would be, as you say, each terminal driver has it's own test like "generic_image_with_rhombus()" does above.  It's a repetitive way of addressing that, but not too bad.  In fact, that <rectangular projection tests> code could be gathered as a simply routine and reused to make things more compact.

I have no strong opinion on how it should be; just not certain on how to go about this.

Dan