On 27.07.2010, at 21:47, Roman Kantor wrote: > Another possibility to generate postscript or pdf through CAIRO as a backend. > > I have quite a lot of of working code (all fltk drawing primitives except/but > images only partially) using CAIRO implementation. The implementation used > #idfef(s) and I was waiting for the FLTK device api to be stabilised to make > full port. It uses "toy api" for fonts but this api seems sufficient for fltk > needs > and it accepts utf-8 strings out of the box - so also international text by > postscript-through-cairo should work.
That's really interesting... What I'm seeing now is that a full PostScript and maybe also PDF implementation would take too much time for our small team to do it right. Thus, if we could use Cairo to do this job, that would be a great advantage, although it would introduce a new dependency for printing. We should check this and see what can be done. > Now when Fl_Device is in 1.3 it might be the right time to start to play with > it again. Unfortunately I am very busy this days/weeks/months but it should > be now > much easier to implement Fl_Cairo_Device independent of fltk and maybe later > to include it in fltk core as some fltk_cairo library when it is stable and > tested. > > Once this cairo implementation is in place, output to postscriot/pdf/whatever > should be relatively easy by swapping cairo backends. I am not sure how > Fl_Device > and Fl_Printer classes inheritance is implemented so it might require some > tweaking to reuse the code for both screen and stream outputs. IMHO that should be doable. > With regards to printing of Fl_Help_View content: Fl_Help_View must export > some additional api - at leas make format() or something similar public to > allow to > reformat (eg with regard to the page width) and also allow to draw() of > sequence of blocks (lines) to allow paging etc. It also should export some > measurement > functions (like the height of block sequence) to calculate position on the > page, number of pages... True. I don't think that the page width and (re)formatting would be a big problem (because you can probably adjust the widget's width accordingly), but page breaks would indeed be difficult to find. > The code was tested only on windows/VC - all test programs worked nicely > with exception of images which were not drawn. There are no X or mac drawables > implemented but as there is now cairo drawable within fltk itself this should > further simplify the implementation. > Note that this fork also includes the cairo source within fltk (similar to > zlib/jpeg/png libraries) and custom VC project to build it to keep it > independent of > external libraries. The cairo version is very ancient though and should be > replaced or completely removed from the tree. > > I will try to dig-out this code during the weekend if somebody wants to play > with it. If I remember it was based on fltk-1.1.9 so making diff against > 1.1.9 tree > or searching for #ifdef USE_CAIRO should get you to the cairo-specific code. > If somebody is interested, please let me know and I will put this fork on my > server. I'd like to take a look at it, but I don't know when I'll find any time to do it. But if you can put it on your server anyway, that would be great. TIA. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
