view release on metacpan or  search on metacpan

Gnuplot.pm  view on Meta::CPAN

    _graphics()
      _linewidth(lw)
      _linetype(lt)
      _move(x,y)
      _vector(x,y)
      _pointsize(size)
      _point(x,y,point)
      _text_angle(angle)
      _justify(mode)
      _set_font(font)
      _put_text(x,y,text)
      _arrow(sx,sy,ex,ey)
    _text()
    _graphics()
      .
    _suspend()
    _set_pointsize()
    _resume()
      .
    _text()
  _reset()


------------------------------------

BITMAP DEVICES

A file bitmap.c is provided, implementing a generic set of bitmap
routines. It provides all the routines required to generate a
bitmap in memory, drawing lines and writing text. A simple driver
need provide only a text() entry point, which converts and outputs
the stored bitmap in the format required by the device.

Internally, the bitmap is built of one or more planes of 1
bit per pixel. In fact, I think the library would be easier to
use if it offered one or more planes of pixels with 1,2,4 or 8
bits per pixel, since not all bitmap devices are based on planes,
and the planes have to be recombined at the end at present.
In general, a device would use either planes or bits-per-pixel,
though I guess a 24-bit bitmap could use 3 planes of 8 bits
per pixel..?


The pixels are currently organised horizontally packed into bytes.

ie

  ********%%%%%%%%$$$$$$$$!!!!!!!! etc
  ^^^^^^^^@@@@@@@@########++++++++ etc

where like symbols are stored in one byte. Vertical packing can be
arranged by reversing x and y dimensions and setting the global
b_rastermode to TRUE.  (eg epson 8-pin dot-matrix printer)


Functions provided are

(internal fns ? - should probably be static, not external ?)

  b_setpixel(x,y,value)     
  b_setmaskpixel(x,y,value)
  b_putc(x,y,char,angle)
  b_setvalue(size)

setting up stuff

  b_makebitmap(x,y,planes)  - make a bitmap of size x * y
  b_freebitmap()            - free bitmap
  b_charsize(size)


gnuplot driver interface functions  (can go straight into gnuplot structure)

  b_setlinetype(linetype)
  b_move(x,y)
  b_vector(x,y)
  b_put_text(x,y,*str)
  b_text_angle(ang)



I think that the library could be made easier to use if we defined
a structure which described the bitmap (raster mode, planes, bits-per-pixel,
colours, etc) and then added to the gnuplot term struct a pointer to
this structure. Then we could have b_graphics() routine which did all
the initialisation that presently has to be done by the driver graphics()
entry point.  Also, one day I would like to have parsing, including
terminal driver options, table-driven, but I'm getting ahead of myself
here.


At present, bitmap.c is linked into gnuplot unconditionally. Perhaps
it should be put into a library, so that it is linked in only if
any of the user-selected drivers require bitmap support.

There may be scope to do similar things with some of the other
stuff that is shared by several drivers. Rather than requiring,
for example, that LATEX driver is required if EMTEX is to be used,
the shared routines could be extracted to a library and linked
if any of the drivers which use them are used.  Just a thought...

------------------------------------

FILE LAYOUT
-----------

I think a file layout like the following will leave most flexibility
to the gnuplot maintainers. I use REGIS for example.


  #include "driver.h"


  #ifdef TERM_REGISTER
  register_term(regis) /* no ; */
  #endif


  #ifdef TERM_PROTO
  TERM_PUBLIC void REGISinit __PROTO((void));
  TERM_PUBLIC void REGISgraphics __PROTO((void));