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
Done
> - 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
are:
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 :
http://www.derrickcomedy.com/videos/ ) . Not so wide sites can be handled
with scaling the page a little ( as Konqueror does with
www.netsurf-browser.org/downloads, 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.
Adam
