path: root/Docs
diff options
Diffstat (limited to 'Docs')
5 files changed, 0 insertions, 216 deletions
diff --git a/Docs/02-layout b/Docs/02-layout
deleted file mode 100644
index 7702366d3..000000000
--- a/Docs/02-layout
+++ /dev/null
@@ -1,57 +0,0 @@
-HTML processing and layout
-The modules in the render directory process and layout HTML pages.
-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 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
-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
-An additional pass after main layout positions and layouts all absolutely
-positioned boxes (see layout_position_absolute()).
diff --git a/Docs/04-errors b/Docs/04-errors
deleted file mode 100644
index 786c46374..000000000
--- a/Docs/04-errors
+++ /dev/null
@@ -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
- 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.
diff --git a/Docs/05-memory b/Docs/05-memory
deleted file mode 100644
index 478743393..000000000
--- a/Docs/05-memory
+++ /dev/null
@@ -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 autobuilder. Set the environment variable
-TLINK_MEMCHECK=dmalloc and re-link !RunImage.
- *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.
diff --git a/Docs/06-frames b/Docs/06-frames
deleted file mode 100644
index bf0a870c4..000000000
--- a/Docs/06-frames
+++ /dev/null
@@ -1,52 +0,0 @@
-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
-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() 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.
diff --git a/Docs/08-printing b/Docs/08-printing
deleted file mode 100644
index 772c29030..000000000
--- a/Docs/08-printing
+++ /dev/null
@@ -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.
-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
-- 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.
-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
-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 \ No newline at end of file