On Sat, 31 May 2008, Adam Blokus wrote:
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.
This is nice work :)
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)
It won't. The bitmap structure is purely a platform-specific buffer of
pixel data in 32bpp ABGR format.
- 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 )
Yes, I agree that preserving the generality is good.
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.
Of these, I think the first is best. You'll have to add some API to
image/bitmap.h (which is where the core bitmap API is defined) to allow
you to extract the content pointer.
Another option might be to add the content pointer as a parameter to the
plot_bitmap(_tile) API, which would avoid making the bitmap structure
depend upon a content. There are some cases (e.g. page thumbnailing) where
bitmap structures are created but not backed by an image content.
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 ).
Cool. Serialising to file only to load back in again sucks :)
J.
