Remove the docs that have been moved to the wiki.
svn path=/trunk/netsurf/; revision=8889
This commit is contained in:
Michael Drake
parent
623808380a
commit
0d5c1eada9
|
|
@ -1,57 +0,0 @@
|
|||
HTML processing and layout
|
||||
==========================
|
||||
|
||||
The modules in the render directory process and layout HTML pages.
|
||||
|
||||
Overview
|
||||
--------
|
||||
This is the process to render an HTML document:
|
||||
|
||||
First the HTML is parsed to a tree of xmlNodes using the HTML parser in libxml.
|
||||
This happens simultaneously with the fetch [html_process_data()].
|
||||
|
||||
Any stylesheets which the document depends on are fetched and parsed.
|
||||
|
||||
The tree is converted to a 'box tree' by xml_to_box(). The box tree contains a
|
||||
node for each block, inline element, table, etc. The aim of this stage is to
|
||||
determine the 'display' or 'float' CSS property of each element, and create the
|
||||
corresponding node in the box tree. At this stage the style for each element is
|
||||
also calculated (from CSS rules and element attributes). The tree is normalised
|
||||
so that each node only has children of permitted types (eg. TABLE_CELLs must be
|
||||
within TABLE_ROWs) by adding missing boxes.
|
||||
|
||||
The box tree is passed to the layout engine [layout_document()], which finds the
|
||||
space required by each element and assigns coordinates to the boxes, based on
|
||||
the style of each element and the available width. This includes formatting
|
||||
inline elements into lines, laying out tables, and positioning floats. The
|
||||
layout engine can be invoked again on a already laid out box tree to reformat it
|
||||
to a new width. Coordinates in the box tree are relative to the position of the
|
||||
parent node.
|
||||
|
||||
The box tree can then be rendered using each node's coordinates.
|
||||
|
||||
Lists
|
||||
-----
|
||||
Lists are one or more elements with 'display: list-item' (which is set for 'li'
|
||||
by the default CSS). A list-item is constructed as a BLOCK box and a box for the
|
||||
marker attached at block->list_marker. The marker contains the bullet, number,
|
||||
or similar, depending on the list-style-type.
|
||||
|
||||
Layout of the block is as normal. A pass of layout after main layout places list
|
||||
marker boxes to the left of their block (see layout_lists()).
|
||||
|
||||
Absolute positioning
|
||||
--------------------
|
||||
Absolutely positioned boxes are constructed in the box tree in the same place as
|
||||
if they were not absolutely positioned. Inline boxes are created as
|
||||
INLINE_BLOCK, tables as TABLE, and other boxes as BLOCK (see
|
||||
box_solve_display()).
|
||||
|
||||
During layout, absolutely positioned boxes in block context (BLOCK or TABLE) are
|
||||
given a position in layout_block_context(), but treated as having no height. In
|
||||
inline context (INLINE_BLOCK), they are given a position in layout_line(), but
|
||||
treated as having no width or height. This is done to determine the static
|
||||
position.
|
||||
|
||||
An additional pass after main layout positions and layouts all absolutely
|
||||
positioned boxes (see layout_position_absolute()).
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
Error handling
|
||||
==============
|
||||
|
||||
This section describes error handling in the code.
|
||||
|
||||
The most common serious error is memory exhaustion. If malloc(), strdup(), etc.
|
||||
fails, clean up and free any partially complete structures leaving data in a
|
||||
consistent state, and return a value which indicates failure, eg. 0 for
|
||||
functions which return a pointer (document the value in the function
|
||||
documentation). The caller should then propagate the failure up in the same way.
|
||||
At some point, the error should stop being passed up and be reported to the user
|
||||
using
|
||||
|
||||
warn_user("NoMemory", 0);
|
||||
|
||||
The other common error is one returned by a RISC OS SWI. Always use "X" SWIs,
|
||||
something like this:
|
||||
|
||||
os_error *error;
|
||||
error = xwimp_get_pointer_info(&pointer);
|
||||
if (error) {
|
||||
LOG(("xwimp_get_pointer_info: 0x%x: %s\n",
|
||||
error->errnum, error->errmess));
|
||||
warn_user("WimpError", error->errmess);
|
||||
return false;
|
||||
}
|
||||
|
||||
If an error occurs during initialisation, in most cases exit immediately using
|
||||
die(), since this indicates that there is already insufficient memory, or a
|
||||
resource file is corrupted, etc.
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
Memory management
|
||||
=================
|
||||
|
||||
This section describes memory management. See Error handling for how memory
|
||||
exhaustion is handled.
|
||||
|
||||
Finding leaks on RISC OS
|
||||
------------------------
|
||||
Memory allocation can be traced and leaks can be found using dmalloc.
|
||||
|
||||
Install dmalloc from the riscos.info autobuilder. Set the environment variable
|
||||
TLINK_MEMCHECK=dmalloc and re-link !RunImage.
|
||||
|
||||
On RISC OS,
|
||||
|
||||
*Set DMALLOC_OPTIONS debug=0x2,log=dmalloc_log
|
||||
|
||||
set the working directory to a RAM disc, and run NetSurf. When it quits,
|
||||
dmalloc_log will contain a list of unfreed blocks.
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
Frames
|
||||
======
|
||||
|
||||
Frames cut across many parts of the browser.
|
||||
|
||||
Representation in content
|
||||
-------------------------
|
||||
During box-tree construction (box_construct.c), frameset, frame, and iframe
|
||||
elements are converted into structures in the 'struct content' for the HTML
|
||||
document.
|
||||
|
||||
Framesets and frames form a tree of 'struct content_html_frames' at
|
||||
content->data.html.frameset. For example, the source
|
||||
|
||||
<frameset rows="50%,50%">
|
||||
<frameset cols="40,200">
|
||||
<frame name="A" src="aaa">
|
||||
<frame name="B" src="bbb">
|
||||
</frameset>
|
||||
<frameset cols="3*,*">
|
||||
<frame name="C" src="ccc">
|
||||
<frame name="D" src="ddd">
|
||||
</frameset>
|
||||
</frameset>
|
||||
|
||||
results in the tree
|
||||
|
||||
0x6099f2f4 (2 1) w0px h0px (margin w0 h0) (scrolling no)
|
||||
(0 0): 0x608b730c (1 2) w100% h50% (margin w0 h0) (scrolling no)
|
||||
(0 0): 0x608dae74 (0 0) w40px h100% (margin w0 h0) 'A' <aaa> (scrolling auto) border 0
|
||||
(0 1): 0x608daeb0 (0 0) w200px h100% (margin w0 h0) 'B' <bbb> (scrolling auto) border 0
|
||||
(1 0): 0x608b7348 (1 2) w100% h50% (margin w0 h0) (scrolling no)
|
||||
(0 0): 0x608d9b4c (0 0) w3* h100% (margin w0 h0) 'C' <ccc> (scrolling auto) border 0
|
||||
(0 1): 0x608d9b88 (0 0) w1* h100% (margin w0 h0) 'D' <ddd> (scrolling auto) border 0
|
||||
|
||||
(output from html_dump_frameset()).
|
||||
|
||||
Creation of browser windows
|
||||
---------------------------
|
||||
When a document containing frames is displayed in a browser window, child
|
||||
windows are created for frames and iframes. This occurs when a browser window
|
||||
receives a CONTENT_MSG_READY in browser_window_callback(), which calls
|
||||
browser_window_create_frameset().
|
||||
|
||||
browser_window_create_frameset() constructs a tree of 'struct browser_window'
|
||||
corresponding to the tree of 'struct content_html_frames'. For each new
|
||||
browser_window, it calls gui_create_browser_window() to create and open the
|
||||
actual platform-specific window (represented by a 'struct gui_window').
|
||||
|
||||
When this is completed it calls browser_window_recalculate_frameset() which
|
||||
calculates the positions of each frame in pixels and calls
|
||||
gui_window_position_frame() to position each one.
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
Adding paged output
|
||||
===================
|
||||
|
||||
This document is supposed to be a short guide of adding paged output to Netsurf.
|
||||
Currently the two pieces of code using the print implementation are PDF export
|
||||
and GTK printing.
|
||||
|
||||
|
||||
printer.h
|
||||
---------
|
||||
The first thing the new paged output has to do is implementing the printer
|
||||
interface located in printer.h. It consists of four elements:
|
||||
|
||||
- plotter. This are the plotters which will be used while redrawing the
|
||||
content.
|
||||
|
||||
- print_begin. This function is called right after the set up and should
|
||||
manage all the remaining user-specific initialisation stuff.
|
||||
|
||||
- print_next_page. This function is called before the actual printing of each
|
||||
page allowing to prepare the content to be printed.
|
||||
|
||||
- print_end. This function is called right before the printing routines clean
|
||||
after themselves and should be used for saving the output to a file, freeing
|
||||
previously allocated memory, relesing document handles etc.
|
||||
|
||||
|
||||
print.h
|
||||
-------
|
||||
The provided print interface consists of a set of functions which can be used
|
||||
seperately and one integrating them all making the print a matter of one call.
|
||||
If it is enough you can just call print_basic_run and wait for it to return.
|
||||
However, for the case you can't accompish the printing task this way the print
|
||||
interface gives you the possiblity of calling the print steps individually.
|
||||
|
||||
Only if you are using print_basic_run you can omit specifying the print settings.
|
||||
If this is the case the default ones will be used.
|
||||
|
||||
As you will notice the functions correspond to those you had to implement in the
|
||||
printer. The reason for this is adding some flexibility to the system which
|
||||
occured necessary i.e in the GTK print implementation.
|
||||
|
||||
- print_set_up. This sets the printing system up and calls print_begin
|
||||
- print_draw_next_page. Here after calling print_next_page one full page of the
|
||||
dimensions given in the print settings is plotted
|
||||
- print_cleanup. This function is responsible for freeing all used resources
|
||||
right after calling print_end
|
||||
|
||||
|
||||
Settings
|
||||
--------
|
||||
This is where the besic information about the print job is held. You can use one
|
||||
of the predifined sets(DEFAULT and OPTIONS) or add your own. In order to do that
|
||||
you have to follow this steps:
|
||||
|
||||
- add your entry to the print_configuration enum
|
||||
- add handling of it to the switch in print_make_settings
|
||||
- add the entry name to this document
|
||||
Loading…
Reference in New Issue