Hi everyone, As I was asked for - I'm reporting what has been done this week: I started with adding a skeleton plotter interface and kept completing it all the time. By now - almost all functions, besides bitmaps, of the plotter interface are done. I predict that still some corrections will have to be made, as harulib has some stronger requirements on the function arguments, which required me to normalize some values given by the rendering engine. Many of you have already tested it and I was working also in response to some guidelines / reported issues.
I got now through a quite big piece of the rendering code - mainly to find out how all the content is managed and what information it consists of. This all is because one of my coming goals is making the plotting aware of the type of the bitmap being plotted - to allow it to directly embed some types of images(as jpeg,png) into the pdf file. At the point I am - I have to ask for directions and/or your opinion. The case is: - To embed directly an image, we have to get access to its type(to know if we plot it pixel by pixel or embed its native file), and the file itself - By now, the plot_bitmap functions get only a pointer to the bitmap structure, which may not have any of the above (only pixbuf's in gtk) - the most times plot_bitmap is called, the pointer to the bitmap struct is extracted from the content struct, which includes the filetype and file - I think we should keep the generality of the sources - so don't distinguish plottings from each other in the rendering code ( so the changes should be transparent for gtk, riscos, save_draw ) I see some possible ways to provide the necessary data to the plot_bitmap function, mainly: - add another field to the bitmap - a pointer to the content - this would double some information, but would be probably the easiest (as it wouldn't require any changes for other plottings) - divide it into 2 functions: plotting a bitmap from a file(which would get the content struct as an argument,not only the bitmap) and plotting a pixmap from memory. Please respond if you have any thoughts about this. Any way - I will have to start working also on harulib, by adding some loadIMGTYPEfromMem functions - which, after going through haru's sources, I found to be quite easy ( this parts of its sources rely on quite universal streams ). Adam
