My GSoC - Progress report

Adam Blokus adamblokus at
Fri May 30 23:16:08 BST 2008

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 
- 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 ).


More information about the netsurf-dev mailing list