imacarthur wrote:
> About 20-plus years ago, I wrote a PS to CGM "interpreter" for a
> display unit we had.
Yikes -- sounds like a big project to parse postscript and convert..!
Parsing postscript is surely a lot harder than generating it..
generating it is fairly easy; I'd imagine fl_rect() can probably be
implemented in postscript with a single fprintf() for the vector
equivalent. Though I'm not sure how complicated it gets to include
eg. the FLTK clipping stack. (unless PS has a clip stack of its own?)
Things like line width and line caps might be tricky when you start
closely comparing FLTK's raster output vs. the PS vector image.
Things that might look 'perfect' in raster might look odd in vector.
(Possibly a reason to simply convert everything to a PS 'hex image')
I guess it depends how things are implemented. For vector, you'd surely
want a linewidth that approximates the width of a pixel, so that eg.
adjacent lines 'touch' to yield a solid area. (Some widgets render this
way)
Images/icons would have to carefully be scaled to match the vectors.
But if everything were converted to a PS image, it might be slow,
but it'd be most likely more true to what we see on the screen.
Never having seen it, I figure our existing 'offscreen raster image'
drawing stuff might easily be dumped out as a PS image. Probably the
intention of all that, IIRC.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
