GSoC report

Adam Blokus adamblokus at
Mon Jun 16 00:09:40 BST 2008

Hi everyone,
This weeks goals were:
> - adjust the width of the content to the width of the page, not keeping it
> at window-width, and
Done, but still causing issue 1) from below and without handling of issue 2)
> - make the pdf-plotting output the whole document, not just the first page
> - get some idea of how to fix the problems that are reported for the
> current riscos printing (as single lines of text being split horizontally
> on the edge of pages)
I discuss it as issue 3)

	Also - I have created a conception of a printer interface, that will allow to 
deal with any later paged-output formats - either a printer or another file 
format. By now it implies adding at least four new files to the sources. I am 
still not sure if I'm fitting with what I'm doing in your conventions for 
locations and naming, but I hope that I'm at least close to them ;)

	Although it is working, I see the code done this week mainly as a 
conception-sketch or a skeleton to fill with further changes - most 
importantly separating the window's content from anything that printing does. 
By now it is working similar to the RiscOS printing that is included in 
NetSurf - it is just spread into some functions with the improvements to be 
done pointed out in the comments.

I have been going through some problems with my IP - that is why I don't show 
up at #netsurf lately - I am available via email (I check it at least once a 
day), in case you would like to contact me.

The current issues that I see also as guidelines for the following week or two 

1) Window content is affected by printing:
	That's what took me a lot of time - digging through the sources to get a 
better understanding of all the functions related to my ideas for solving 
this issue. Firstly, I wanted to just block redrawing the window content for 
the time printing is done (or redraw the window from a pixbuf it would be 
previously stored into). This solution would allow to save some memory 
otherwise needed to duplicate the resized content (duplication would probably, 
but not necessarily require in most cases more memory than a 
pixbuff-screenshot). Now I believe, that at least the box-tree should be 
duplicated, so we could later modify the presentation more dramatically, when 
printing stylesheets will be taken into consideration. I am still thinking at 
which moment the duplication should be done ( surely not refetching, most 
surely building a box tree, maybe doing it by dfs-walking through the 
window-content's boxes and duplicating them - but this wouldn't allow us to 
apply printstyles, too).
I must admit that I am under greatly influenced by your "Memory is valuable" 
guideline for RiscOS and don't yet have any intuition of what amounts of it 
are vital and how much I should be careful of it;)

2) Content to wide to fit a page is truncated at page width:
	After looking how other browsers (mainly Fx and Konqueror) handle it, I found 
that fitting content into pages is done in most cases by making the layout 
very loose (for a good example - see print previews of : ) . Not so wide sites can be handled 
with scaling the page a little ( as Konqueror does with, that has a loose layout in Firefox), but 
this is not a general solution. Most probably I will have to go into the 
layouting code and add some paged alternatives to it.

3) Text is cut on edges of pages:
	Here I see two solutions, and I want to try both of them. Firstly, for 
reasonable small text - a kind off 'fuzzy' clipping. That is - apply two 
bottom margin lines: one impassable for every kind of content and one 
conventional. If the plotted text does not reach behind the first one - it 
should be plotted uncut. If it would be drawn even behind the impassable 
margin - we raise the bottom clipping line for this page just above this text 
and print it on the top of the next page.
	For bigger text sizes this would result in permanently rising the lower 
margin, so I think that such text should either be treated as a "cuttable" 
element or, if it is not really huge and it's densely enough surrounded by 
other elements  - this could be solved as a case for the mentioned earlier 
loose layout. This will require a little research, and that's why I want to 
start with writing the 'fuzzy' clipping this week.


More information about the netsurf-dev mailing list