BlueGreycalmElegant

Català-Valencià – Catalan中文 – Chinese (Simplified)中文 – Chinese (Traditional)Česky – CzechDansk – DanishNederlands – DutchEnglish – EnglishSuomi – FinnishFrançais – FrenchDeutsch – Germanעברית – Hebrewहिंदी – HindiMagyar – HungarianBahasa Indonesia – IndonesianItaliano – Italian日本語 – Japanese한국어 – KoreanМакедонски – Macedonianमराठी – MarathiNorsk – NorwegianPolski – PolishPortuguês – PortuguesePortuguês – Portuguese (Brazil)Русский – RussianSlovenčina – SlovakSlovenščina – SlovenianEspañol – SpanishSvenska – SwedishTürkçe – TurkishУкраїнська – UkrainianOëzbekcha – Uzbek

Compare Revisions

• This comparison shows the changes necessary to convert path

  → /contrib/network/netsurf/netsurf/Docs/ @ 4363

  → /contrib/network/netsurf/netsurf/Docs/ @ 4364

  ↔ Reverse comparison

• Compare Path:	Rev

  With Path:	Rev

Regard whitespace Rev 4363 → Rev 4364

/contrib/network/netsurf/netsurf/Docs/BUILDING-AmigaCross
0,0 → 1,87
to install an Amiga cross-compiler in a Linux distribution, there are instructions at
http://utilitybase.com/article/show/2007/06/23/231/Installing+an+AmigaOS+4+cross+compiler
a more Mac-oriented article [though of potentially general utility] is at
http://utilitybase.com/article/show/2006/05/21/188/Building+Amiga+OS+4+GCC+Cross+Compiler+for+UNIX%252FMAC
more background at
http://cross.zerohero.se/os4.html
cross-compile additional libs/tools
SDK
http://www.hyperion-entertainment.biz/
newlib
http://sources.redhat.com/newlib/
clib2
http://sourceforge.net/projects/clib2/
ixemul
http://strohmayer.org/sfs/
libnix
http://sourceforge.net/projects/libnix/
though newlib / clib2 are apparently already included in the ppc-amigaos-gcc tarball
lha utility is debian package lha
then install linked libs in the correct place
[normally /usr/local/amiga]
so
sudo chmod --recursive 775 /usr/local/amiga
sudo chmod --recursive +s /usr/local/amiga
sudo chown --recursive `whoami` /usr/local/amiga
sudo chgrp --recursive root /usr/local/amiga
[mkdir /usr/local/amiga/include]
[may need to set ppc-amigaos-gcc libpaths]
zlib
download tarball from project homepage, untar in a storage directory /
download source from your distribution's repository [zlib1g in Ubuntu]
[cd to top-level directory of zlib containing configure script]
CC=ppc-amigaos-gcc AR=ppc-amigaos-ar RANLIB=ppc-amigaos-ranlib \
CFLAGS="-DNO_FSEEKO" ./configure --prefix=/usr/local/amiga
make
make install
regex [pre-compiled]
http://aminet.net/dev/lib/libregex-4.4.3.lha
libcurl
download the tarball from the project's homepage, untar in a storage directory /
download source from your distribution's repository
cd into the directory containing the configure file
./configure --prefix=/usr/local/amiga --host=ppc-amigaos
$ make
[you MUST have either POSIX or glibc strerror_r if strerror_r is found]
$ make install
alternative
http://www.aminet.net/dev/lib/libcurl.lha
libiconv [unnecessary as a non-overridable limited version is included in newlib]
openssl
libpng
libmng
http://www.aminet.net/dev/lib/libmng_so.lha
http://www.aminet.net/dev/lib/libmng.lha
liblcms
http://www.aminet.net/dev/lib/liblcms_so.lha
http://www.aminet.net/dev/lib/liblcms_so.lha
libjpeg
libparserutils
libhubbub
libcss
libnsbmp
libnsgif

/contrib/network/netsurf/netsurf/Docs/BUILDING-AmigaOS
0,0 → 1,159
--------------------------------------------------------------------------------
Build Instructions for AmigaOS NetSurf 13 February 2010
--------------------------------------------------------------------------------
This document provides instructions for building the AmigaOS version of
NetSurf and provides guidance on obtaining NetSurf's build dependencies.
AmigaOS NetSurf has been tested on AmigaOS 4.0 July 2007 Update and AmigaOS
4.1. It will require modification for AmigaOS 3.9 or earlier, or other
Amiga-like platforms.
AmigaOS NetSurf will build against newlib by default, building against
clib2 has not been tested.
Building and executing NetSurf
================================
First of all, you should examine the contents of Makefile.defaults
and enable and disable relevant features as you see fit by creating
a Makefile.config. Some of these options can be automatically
detected and used, although it is better to explicitly enable or
disable options.
You should then obtain NetSurf's dependencies, keeping in mind which options
you have enabled in the configuration file. See the next section for
specifics.
Once done, to build AmigaOS NetSurf on OS4, simply run:
1> gmake
If that produces errors, you probably don't have some of NetSurf's build
dependencies installed. See "Obtaining NetSurf's dependencies" below, or turn
off the complaining features in a Makefile.config.
Running NetSurf from the build tree requires some setup:
1> makelink resources amiga/resources force
1> copy amiga/resources/themes/default/NetSurf.info NetSurf.info
It should then be possible to run NetSurf by executing NetSurf from the
Shell or by double-clicking on the icon.
Obtaining NetSurf's build dependencies
========================================
Many of NetSurf's dependencies are included with the OS4 SDK or available
from Aminet or OS4Depot. The remainder must be built manually.
The NetSurf project's libraries
---------------------------------
The NetSurf project has developed several libraries which are required by
the browser. To fetch each of these libraries, run the appropriate commands
from the Docs/LIBRARIES file.
To build and install these libraries, simply enter each of their directories
and run:
1> gmake install
| Note: We advise enabling iconv() support in libparserutils, which vastly
| increases the number of supported character sets. To do this,
| create a file called Makefile.config.override in the libparserutils
| directory, containing the following lines:
|
| CFLAGS += -DWITH_ICONV_FILTER
| LDFLAGS += -liconv
|
| This requires libiconv as iconv support in newlib.library is buggy.
|
| For more information, consult the libparserutils README file.
| Note: Building libsvgtiny requires gperf, which is available from Aminet:
|
| http://www.aminet.net/package/dev/c/gperf
cURL
------
A version of libcurl built for newlib is available from Aminet
http://www.aminet.net/package/dev/lib/libcurl
There is a shared object version included with some OWB releases. To use
this when compiling with Cairo support, a link must be made:
1> makelink sdk:local/newlib/lib/libcurl.so sobjs:libcurl-7.16.so soft
libmng
--------
NetSurf uses libMNG to display MNG and PNG files.
It builds without any problems on OS4, or available from Aminet:
http://www.aminet.net/package/dev/lib/libmng_so
OpenSSL
---------
NetSurf uses OpenSSL for encrypted transfers.
http://www.os4depot.net/share/development/library/misc/libopenssl.lha
There is a shared object version included with some OWB releases. To use
this when compiling with Cairo support, a link must be made:
1> makelink sdk:local/newlib/lib/libssl.so sobjs:libssl-0.9.8.so soft
1> makelink sdk:local/newlib/lib/libcrypto.so sobjs:libssl-0.9.8.so soft
Libharu
---------
NetSurf can use Haru PDF to enable PDF export. Haru PDF can be obtained
from http://libharu.org/. We require libharu 2.2 or later.
| Note: libharu cannot be auto-detected by the Makefile. If you wish to
| enable it, do so by creating a Makefile.config file.
libregex
----------
A version of the regular expression library can be obtained from Aminet:
http://www.aminet.net/package/dev/lib/libregex-4.4.3
openurl.library
-----------------
The AmigaOS mailto: URL support uses openurl.library, this and the includes
can be obtained from Aminet:
http://www.aminet.net/package/comm/www/OpenURL-OS4
General requirements
----------------------
SDK:newlib/include/strings.h needs to be modified by adding the following:
extern int strcasecmp(const char *, const char *);
extern int strncasecmp(const char *, const char *, size_t);
amiga/version.c is generated by version.rexx using the SVN command. If
the source has not been checked out from SVN, or is being cross-compiled,
this file will need to be created by hand. See the end of version.rexx
for the variables that are defined in the file.
Please note that building with Cairo (option NETSURF_AMIGA_USE_CAIRO) will
link NetSurf against shared objects, and require the OS4.1 SDK to build and
AmigaOS 4.1 to run.

/contrib/network/netsurf/netsurf/Docs/BUILDING-BeOS
0,0 → 1,127
--------------------------------------------------------------------------------
Build Instructions for BeOS and Haiku NetSurf 13 February 2010
--------------------------------------------------------------------------------
This document provides instructions for building the BeOS and Haiku version
of NetSurf and provides guidance on obtaining NetSurf's build dependencies.
BeOS NetSurf has been tested on Zeta only for now. There are still some
issues to sort out for other BeOS versions.
There are still pending fixes against SVN before it can be build from BeOS
or Haiku.
Building and executing NetSurf
================================
To build NetSurf on a BeOS or Haiku, provided you have the relevant
build dependencies installed, simply run:
$ make
If that produces errors, you probably don't have some of NetSurf's build
dependencies installed. See "Obtaining NetSurf's dependencies" below. You
may need to "make clean" before attempting to build after installing the
dependencies. Also note BeOS has an old make command that won't work, see
below.
Obtaining NetSurf's dependencies
==================================
Many of NetSurf's dependencies are either installed or available for BeOS and
Haiku. The remainder must be installed manually.
The NetSurf project's libraries
---------------------------------
The NetSurf project has developed several libraries which are required by
the browser. To fetch each of these libraries, run the appropriate commands
from the Docs/LIBRARIES file.
To build and install these libraries, simply enter each of their directories
and run:
$ make install
| Note: We advise enabling iconv() support in libparserutils, which vastly
| increases the number of supported character sets. To do this,
| create a file called Makefile.config.override in the libparserutils
| directory, containing the following line:
|
| CFLAGS += -DWITH_ICONV_FILTER
|
| For more information, consult the libparserutils README file.
TODO: add some more here.
rc
----
Building NetSurf needs the Haiku resource compiler (rc), that allows
importing files from resource definitions (.rdef).
$ cd <haiku-trunk-directory>
$ TARGET_PLATFORM=r5 jam -q rc
$ cp generated/objects/dano/x86/release/tools/rc/rc /boot/home/config/bin/
GNU make 3.81
---------------
BeOS has an old make tool, which won't work when building NetSurf.
Haiku has 3.81 which is the one that works. For BeOS, one has to replace
the original make with one built from the Haiku tree, or install it as gmake:
$ cd <haiku-trunk-directory>
$ TARGET_PLATFORM=r5 jam -q make
$ cp generated/objects/r5/x86/release/bin/make/make /boot/home/config/bin/gmake
cURL
------
NetSurf uses cURL to fetch files from the network.
There is a patch against the official version on HaikuPorts.
TODO
libmng
--------
NetSurf uses libMNG to display MNG and PNG files.
It should build just fine on BeOS.
libjpeg
---------
NetSurf uses libjpeg to display JPEG files.
It should already be available in your dev kit.
OpenSSL
----------
NetSurf uses OpenSSL for encrypted transfers.
General requirements
----------------------
There is currently an issue on stdbool.h (unsigned char bool vs enum bool)
which needs to be fixed, for now one can use the Haiku version of the header
and copy it over the gcc-provided one.
$ cd <haiku-trunk-directory>
$ cp headers/build/gcc-2.95.3/stdbool.h /boot/develop/tools/gnupro/lib/gcc-lib/i586-pc-beos/2.95.3-beos-060710/include/stdbool.h
NetSurf might build on BeOS R5 but probably won't work on anything else than
BONE.
This will pull in loads of things, like all the GTK dev libraries, the PNG
and JPEG libraries, colour management libraries, zlib, OpenSSL etc that
NetSurf also depends on.

/contrib/network/netsurf/netsurf/Docs/BUILDING-Cocoa
0,0 → 1,87
--------------------------------------------------------------------------------
Build Instructions for Cocoa NetSurf 13 January 2011
--------------------------------------------------------------------------------
This document provides instructions for building the Cocoa version of NetSurf
and provides guidance on obtaining NetSurf's build dependencies.
Cocoa NetSurf has been tested on Mac OS X 10.6 on Intel and on Mac OS X 10.5
on ppc.
Building NetSurf
==================
After installing the dependencies NetSurf can be built either using the Xcode
project file 'cocoa/NetSurf.xcodeproj' or on the command line using the
Makefile:
$ make TARGET=cocoa
In both cases the actual build process is controlled by the Makefile.
Obtaining NetSurf's build dependencies
========================================
Many of NetSurf's dependencies are packaged on various operating systems.
The remainder must be installed manually. Currently, some of the libraries
developed as part of the NetSurf project have not had official releases.
Hopefully they will soon be released with downloadable tarballs and packaged
in common distros. For now, you'll have to make do with Git checkouts.
Package installation
----------------------
For building the other NetSurf libraries and for configuring NetSurf the
"pkg-config" tool is required. It can be installed either via fink, macports
or homebrew or from source.
OpenSSL, LibPNG, curl, iconv and zlib are provided by Mac OS X.
The curl library provided by Mac OS X 10.6 causes a crash while fetching
https resources, so you should install version 7.21.4 (or newer) of libcurl
if you are running on 10.6.
LibJPEG and LibMNG can be installed from source or using one of the mentioned
package managers.
The NetSurf project's libraries
---------------------------------
The NetSurf project has developed several libraries which are required by
the browser. These are:
LibParserUtils -- Parser building utility functions
LibWapcaplet -- String internment
Hubbub -- HTML5 compliant HTML parser
LibCSS -- CSS parser and selection engine
LibNSGIF -- GIF format image decoder
LibNSBMP -- BMP and ICO format image decoder
LibROSprite -- RISC OS Sprite format image decoder
To fetch each of these libraries, run the appropriate commands from the
Docs/LIBRARIES file.
$ make
$ sudo make install
This command builds the libraries only for the active architecture. To build
universal binaries use those commands:
$ make UNIVERSAL="i386 x86_64 ppc ppc64"
$ sudo make install
If you are building NetSurf for using it on only one computer this is not
necessary, but if you want to distribute your binary you should build
universal binaries. You can also leave some of the platform names out, if
you don't require them.
| Note: We advise enabling iconv() support in libparserutils, which vastly
| increases the number of supported character sets. To do this,
| create a file called Makefile.config.override in the libparserutils
| directory, containing the following line:
|
| CFLAGS += -DWITH_ICONV_FILTER
|
| For more information, consult the libparserutils README file.

/contrib/network/netsurf/netsurf/Docs/BUILDING-Framebuffer
0,0 → 1,281
--------------------------------------------------------------------------------
Build Instructions for Framebuffer NetSurf 13 February 2010
--------------------------------------------------------------------------------
This document provides instructions for building the Framebuffer version of
NetSurf and provides guidance on obtaining NetSurf's build dependencies.
Framebuffer NetSurf has been tested on Ubuntu and Debian.
Building and executing NetSurf
================================
First of all, you should examine the contents of Makefile.defaults
and enable and disable relevant features as you see fit in a
Makefile.config file. Some of these options can be automatically
detected and used, and where this is the case they are set to such.
Others cannot be automatically detected from the Makefile, so you
will either need to install the dependencies, or set them to NO.
You should then obtain NetSurf's dependencies, keeping in mind which options
you have enabled in the configuration file. See the "Obtaining NetSurf's
dependencies" section for specifics.
Once done, to build Framebuffer NetSurf on a UNIX-like platform, simply run:
$ make TARGET=framebuffer
If that produces errors, you probably don't have some of NetSurf's build
dependencies installed. See "Obtaining NetSurf's dependencies" below.
Or turn off the complaining features in your Makefile.config. You may
need to "make clean" before attempting to build after installing the
dependencies.
Run NetSurf by executing the "nsfb" program:
$ ./nsfb
| Note: NetSurf uses certain resources at run time. In order to find these
| resources, it searches three locations:
|
| 1. ~/.netsurf/
| 2. $NETSURFRES/
| 3. /usr/share/netsurf/
|
| In the build tree, the resources are located at
|
| framebuffer/res
|
| Setting $NETSURFRES to point at the resources in the build tree
| will enable you to run NetSurf from here without installation.
| To do this, run:
|
| export NETSURFRES=`pwd`/framebuffer/res
Fonts
=======
The framebuffer port currently has two choices for font
handling. The font handler may be selected at compile time by using
the NETSURF_FB_FONTLIB configuration key. Currently supported values
are internal and freetype
Internal
----------
The internal font system has a single built in monospaced face with
CP467 encoding. The internal font plotter requires no additional
resources and is very fast, it is also aesthetically unappealing.
Freetype
----------
The freetype font system (freetype version 2 API is used) has
support for a number of different font file formats and faces. The
framebuffer font handler takes advantage of the freetype library
caching system to give good performance.
The font glyphs are, by default, rendered as 256 level transparency
which gives excellent visual results even on small font sizes.
The default font is the DejaVu trutype font set. The default path they
are sourced from is /usr/share/fonts/truetype/ttf-dejavu/ .
The compiled in default paths may be altered by setting values in
the user configuration makefile Makefile.config. These values must
be set to teh absolute path of the relevant font file including its
.ttf extension. The variables are:
NETSURF_FB_FONT_SANS_SERIF
NETSURF_FB_FONT_SANS_SERIF_BOLD
NETSURF_FB_FONT_SANS_SERIF_ITALIC
NETSURF_FB_FONT_SANS_SERIF_ITALIC_BOLD
NETSURF_FB_FONT_SERIF
NETSURF_FB_FONT_SERIF_BOLD
NETSURF_FB_FONT_MONOSPACE
NETSURF_FB_FONT_MONOSPACE_BOLD
NETSURF_FB_FONT_CURSIVE
NETSURF_FB_FONT_FANTASY
The font selection may be changed by placing truetype font files
in the resources path. The resource files will be the generic names
sans_serif.ttf, sans_serif_bold.ttf etc.
The font system is configured at runtime by several options. The
fb_font_monochrome option causes the renderer to use monochrome
glyph rendering which is faster to plot but slower to render and
much less visually appealing.
The remaining seven options control the files to be used for font faces.
fb_face_sans_serif - The sans serif face
fb_face_sans_serif_bold - The bold sans serif face
fb_face_sans_serif_italic - The italic sans serif face
fb_face_sans_serif_italic_bold - The bold italic sans serif face.
fb_face_serif - The serif font
fb_serif_bold - The bold serif font
fb_face_monospace - The monospaced font
fb_face_monospace_bold - The bold monospaced font
fb_face_cursive - The cursive font
fb_face_fantasy - The fantasy font
Old Freetype
--------------
The framebuffer port Freetype font implementation was constructed
using a modern version of the library (2.3.5) to use versions 2.2.1
and prior the following patch is necessary.
Index: framebuffer/font_freetype.c
===================================================================
--- framebuffer/font_freetype.c (revision 6750)
+++ framebuffer/font_freetype.c (working copy)
@@ -311,6 +311,7 @@
FT_Glyph glyph;
FT_Error error;
fb_faceid_t *fb_face;
+ FTC_ImageTypeRec trec;
fb_fill_scalar(style, &srec);
@@ -318,15 +319,24 @@
glyph_index = FTC_CMapCache_Lookup(ft_cmap_cache, srec.face_id, fb_face->cidx, ucs4);
- error = FTC_ImageCache_LookupScaler(ft_image_cache,
- &srec,
- FT_LOAD_RENDER |
- FT_LOAD_FORCE_AUTOHINT |
- ft_load_type,
- glyph_index,
- &glyph,
- NULL);
+ trec.face_id = srec.face_id;
+ if (srec.pixel) {
+ trec.width = srec.width;
+ trec.height = srec.height;
+ } else {
+ /* Convert from 1/64 pts to pixels */
+ trec.width = srec.width * css_screen_dpi / 64 / srec.x_res;
+ trec.height = srec.height * css_screen_dpi / 64 / srec.y_res;
+ }
+ trec.flags = FT_LOAD_RENDER | FT_LOAD_FORCE_AUTOHINT | ft_load_type;
+
+ error = FTC_ImageCache_Lookup(ft_image_cache,
+ &trec,
+ glyph_index,
+ &glyph,
+ NULL);
+
return glyph;
}
Selecting a frontend and appropriate options
==============================================
The framebuffer port interfaces to its input and output devices
using the NetSurf Framebuffer library (libnsfb). This library
provides an abstraction layer to input and output devices.
The surface used by libnsfb is selected by using the -f switch to
NetSurf when executed. A surface in this context is simply the
combination of input and output devices.
A surface output device may be any linearly mapped area of
memory. The framebuffer may be treated as values at 32, 16 or 8 bits
per pixel. The input device is typically selected to complement the
output device and is completely specific to the surface.
There are several configuration options which may influence the
framebuffer surfaces. These are:
fb_refresh - The refresh rate (for physical displays)
fb_depth - The depth (in bits per pixel) of the framebuffer
window_width - The width of the framebuffer
window_height - The height of the framebuffer
The defaults are for 800 by 600 pixels at 16bpp and 70Hz refresh rate.
The documentation of libnsfb should be consulted for futher
information about supported frontends and their configuration.
Obtaining NetSurf's build dependencies
========================================
Many of NetSurf's dependencies are packaged on various operating systems.
The remainder must be installed manually. Currently, some of the libraries
developed as part of the NetSurf project have not had official releases.
Hopefully they will soon be released with downloadable tarballs and packaged
in common distros. For now, you'll have to make do with Git checkouts.
Package installation
----------------------
Debian-like OS:
$ apt-get install libcurl3-dev libmng-dev
Recent OS versions might need libcurl4-dev instead of libcurl3-dev but
note that when it has not been built with OpenSSL, the SSL_CTX is not
available and results that certification details won't be presented in case
they are invalid. But as this is currently unimplemented in the Framebuffer
flavour of NetSurf, this won't make a difference at all.
Fedora:
$ yum install curl-devel libmng-devel lcms-devel
Other:
You'll need to install the development resources for libcurl3 and libmng.
Note that if you don't require MNG or JNG image support, NetSurf can be
configured to use libpng instead of libmng. If you wish to do this, install
the libpng development package instead.
The NetSurf project's libraries
---------------------------------
The NetSurf project has developed several libraries which are required by
the browser. These are:
LibParserUtils -- Parser building utility functions
LibWapcaplet -- String internment
Hubbub -- HTML5 compliant HTML parser
LibCSS -- CSS parser and selection engine
LibNSGIF -- GIF format image decoder
LibNSBMP -- BMP and ICO format image decoder
LibROSprite -- RISC OS Sprite format image decoder
LibNSFB -- Framebuffer abstraction
To fetch each of these libraries, run the appropriate commands from the
Docs/LIBRARIES file.
To build and install these libraries, simply enter each of their directories
and run:
$ sudo make install
| Note: We advise enabling iconv() support in libparserutils, which vastly
| increases the number of supported character sets. To do this,
| create a file called Makefile.config.override in the libparserutils
| directory, containing the following line:
|
| CFLAGS += -DWITH_ICONV_FILTER
|
| For more information, consult the libparserutils README file.
General requirements
----------------------
Depending on the frontend selected the build may need specific
libraries installed, e.g. the SDL port requires SDL1.2 or later
Installing these libraries will often will pull in loads of things,
like the PNG and JPEG libraries, colour management libraries, zlib,
OpenSSL etc that NetSurf also depends on.

/contrib/network/netsurf/netsurf/Docs/BUILDING-GTK
0,0 → 1,146
--------------------------------------------------------------------------------
Build Instructions for GTK NetSurf 8 April 2010
--------------------------------------------------------------------------------
This document provides instructions for building the GTK version of NetSurf
and provides guidance on obtaining NetSurf's build dependencies.
GTK NetSurf has been tested on Debian, Ubuntu, Fedora 8, FreeBSD, NetBSD and
Solaris 10.
Building and executing NetSurf
================================
First of all, you should examine the contents of Makefile.defaults
and enable and disable relevant features as you see fit by creating
a Makefile.config file. Some of these options can be automatically
detected and used, and where this is the case they are set to such.
Others cannot be automatically detected from the Makefile, so you
will either need to install the dependencies, or set them to NO.
You should then obtain NetSurf's dependencies, keeping in mind which options
you have enabled in the configuration file. See the next section for
specifics.
Once done, to build GTK NetSurf on a UNIX-like platform, simply run:
$ make
If that produces errors, you probably don't have some of NetSurf's
build dependencies installed. See "Obtaining NetSurf's dependencies"
below. Or turn off the complaining features in a Makefile.config
file. You may need to "make clean" before attempting to build after
installing the dependencies.
Run NetSurf by executing the "test-nsgtk" shell script:
$ ./test-nsgtk
This script makes it easy to run the nsgtk binary from the build tree. It
sets up some environment variables which enable NetSurf to find its
resources.
If you are packaging NetSurf, see the PACKAGING-GTK document.
Obtaining NetSurf's build dependencies
========================================
Many of NetSurf's dependencies are packaged on various operating systems.
The remainder must be installed manually. Currently, some of the libraries
developed as part of the NetSurf project have not had official releases.
Hopefully they will soon be released with downloadable tarballs and packaged
in common distros. For now, you'll have to make do with Git checkouts.
Some of NetSurf's own libraries will be installed in /usr/local/ by default.
Fedora, and perhaps some other distributions of Linux, do not ship a
pkg-config that will search here, so you will either need to change where
these libraries install, or do the following before building NetSurf itself;
$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
$ export PKG_CONFIG_PATH
Package installation
----------------------
Debian-like OS:
$ apt-get install libglade2-dev libcurl3-dev libmng-dev
$ apt-get install librsvg2-dev liblcms1-dev libjpeg-dev
Recent OS versions might need libcurl4-dev instead of libcurl3-dev but
note that when it has not been built with OpenSSL, the SSL_CTX is not
available and results that certification details won't be presented in case
they are invalid. But as this is currently unimplemented in the GTK
flavour of NetSurf, this won't make a difference at all.
For experimental javascript support the mozilla spiermonkey library
is required:
$ apt-get install libmozjs-dev
Fedora:
$ yum install libglade2-devel curl-devel libmng-devel
$ yum install librsvg2-devel lcms-devel
Other:
You'll need to install the development resources for libglade2, libcurl3,
libmng and librsvg.
Note that if you don't require MNG or JNG image support, NetSurf can be
configured to use libpng instead of libmng. If you wish to do this, install
the libpng development package instead.
The NetSurf project's libraries
---------------------------------
The NetSurf project has developed several libraries which are required by
the browser. These are:
LibParserUtils -- Parser building utility functions
LibWapcaplet -- String internment
Hubbub -- HTML5 compliant HTML parser
LibCSS -- CSS parser and selection engine
LibNSGIF -- GIF format image decoder
LibNSBMP -- BMP and ICO format image decoder
LibROSprite -- RISC OS Sprite format image decoder
To fetch each of these libraries, run the appropriate commands from the
Docs/LIBRARIES file.
To build and install these libraries, simply enter each of their directories
and run:
$ sudo make install
| Note: We advise enabling iconv() support in libparserutils, which vastly
| increases the number of supported character sets. To do this,
| create a file called Makefile.config.override in the libparserutils
| directory, containing the following line:
|
| CFLAGS += -DWITH_ICONV_FILTER
|
| For more information, consult the libparserutils README file.
Libharu
---------
NetSurf can use Haru PDF to enable PDF export. Haru PDF can be obtained
from http://libharu.org/. We require libharu 2.2 or later.
| Note: libharu cannot be auto-detected by the Makefile. If you wish to
| enable it, do so by creating a Makefile.config file.
General requirements
----------------------
NetSurf requires at minimum GTK 2.12. Earlier versions will not work. It also
depends on Cairo for rendering, but you should have this already with
versions of GTK 2.12 or later.
This will pull in loads of things, like all the GTK dev libraries, the PNG
and JPEG libraries, colour management libraries, zlib, OpenSSL etc that
NetSurf also depends on.

/contrib/network/netsurf/netsurf/Docs/BUILDING-Monkey
0,0 → 1,104
--------------------------------------------------------------------------------
Build Instructions for Monkey NetSurf 13 March 2011
--------------------------------------------------------------------------------
This document provides instructions for building the Monkey
automation version of NetSurf and provides guidance on obtaining
NetSurf's build dependencies.
Monkey NetSurf has been tested on Ubuntu 10.10/amd64.
Building and executing NetSurf
==============================
First of all, you should examine the contents of Makefile.defaults
and enable and disable relevant features as you see fit by creating
a Makefile.config file. Some of these options can be automatically
detected and used, and where this is the case they are set to such.
Others cannot be automatically detected from the Makefile, so you
will either need to install the dependencies, or set them to NO.
You should then obtain NetSurf's dependencies, keeping in mind which options
you have enabled in the configuration file. See the next section for
specifics.
Once done, to build Monkey NetSurf on a UNIX-like platform, simply run:
$ make TARGET=monkey
If that produces errors, you probably don't have some of NetSurf's
build dependencies installed. See "Obtaining NetSurf's dependencies"
below. Or turn off the complaining features in a Makefile.config
file. You may need to "make clean" before attempting to build after
installing the dependencies.
Run NetSurf by executing the "nsmonkey" command from within the build tree.
$ ./nsmonkey
If you are packaging NetSurf, do NOT package nsmonkey. It is a debug tool.
Obtaining NetSurf's build dependencies
======================================
Many of NetSurf's dependencies are packaged on various operating systems.
The remainder must be installed manually. Currently, some of the libraries
developed as part of the NetSurf project have not had official releases.
Hopefully they will soon be released with downloadable tarballs and packaged
in common distros. For now, you'll have to make do with Git checkouts.
Some of NetSurf's own libraries will be installed in /usr/local/ by default.
Fedora, and perhaps some other distributions of Linux, do not ship a
pkg-config that will search here, so you will either need to change where
these libraries install, or do the following before building NetSurf itself;
$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
$ export PKG_CONFIG_PATH
Package installation
----------------------
Debian-like OS:
$ apt-get install libcurl3-dev
Recent OS versions might need libcurl4-dev instead of libcurl3-dev but
note that when it has not been built with OpenSSL, the SSL_CTX is not
available and results that certification details won't be presented in case
they are invalid. But as this is currently unimplemented in the GTK
flavour of NetSurf, this won't make a difference at all.
The NetSurf project's libraries
-------------------------------
The NetSurf project has developed several libraries which are required by
the browser. These are:
LibParserUtils -- Parser building utility functions
LibWapcaplet -- String internment
Hubbub -- HTML5 compliant HTML parser
LibCSS -- CSS parser and selection engine
LibNSGIF -- GIF format image decoder
LibNSBMP -- BMP and ICO format image decoder
LibROSprite -- RISC OS Sprite format image decoder
To fetch each of these libraries, run the appropriate commands from the
Docs/LIBRARIES file.
To build and install these libraries, simply enter each of their directories
and run:
$ sudo make install
| Note: We advise enabling iconv() support in libparserutils, which vastly
| increases the number of supported character sets. To do this,
| create a file called Makefile.config.override in the libparserutils
| directory, containing the following line:
|
| CFLAGS += -DWITH_ICONV_FILTER
|
| For more information, consult the libparserutils README file.

/contrib/network/netsurf/netsurf/Docs/BUILDING-RISC_OS
0,0 → 1,121
--------------------------------------------------------------------------------
Build Instructions for RISC OS NetSurf 16 July 2012
--------------------------------------------------------------------------------
This document provides instructions for building the RISC OS NetSurf
natively on a RISC OS computer and provides guidance on obtaining NetSurf's
build dependencies.
RISC OS NetSurf should work on RISC OS 4.02 and above.
| Note: This guide assumes that you have the RISC OS SVN client installed,
| and that you have used it to fetch the NetSurf source. It also
| assumes that you have the following requirements installed:
|
| + OSLib 6.80 or later
| + Perl 5.8.8 or later
| + GCC 3.4.6 release 3 or later
| + The latest NSTools
If you want to cross-compile NetSurf for RISC OS, use the BUILDING-ROCross
document.
Building and executing NetSurf
================================
| Note: The version of make supplied with RISC OS GCC 3 is old and has a bug
| that prevents NetSurf from building. Either ensure that NSTools is
| seen before GCC, or replace the make inside "!GCC.bin" with the make
| from "!NSTools.bin".
| The minimum version of make that works is v3.81. You can check what
| version you have by running, '*make --version'.
| Note: The pre-built libraries currently supplied in NSTools are AOF format,
| and will not work with GCC4, which requires them to be in ELF format.
| If you want to build NetSurf with GCC4, you will need to build the
| libraries yourself. See "Obtaining NetSurf's dependencies" below for
| details.
You can examine the contents of Makefile.defaults and enable and disable
features as you see fit by creating a Makefile.config file. The default
settings will work fine.
You should then obtain NetSurf's dependencies, keeping in mind which options
you have enabled in the configuration file. See the next section for
specifics.
Once done, to build RISC OS NetSurf on a RISC OS system, set the CSD to the
directory containing the NetSurf sources, set the next slot to at least
6000K, and in a TaskWindow, simply run:
*make
If that produces errors, you probably don't have some of NetSurf's build
dependencies installed, or your libraries may be out of date.
See "Obtaining NetSurf's dependencies" below. Or turn off the complaining
features in a Makefile.config file. You may need to "make clean" before
attempting to build after installing the dependencies.
Once NetSurf is compiled, the !RunImage is put into the !NetSurf
application directory, so you can simply double click it as normal.
To confirm that you're running your own development NetSurf build, view the
Info window from the NetSurf iconbar menu. The Version string should read
#.0 (Development)
where # is the next major release version number.
Obtaining NetSurf's build dependencies
========================================
NSTools contains all of the tools needed to build NetSurf, such as make,
uname and ccres. It also contains pre-built libraries.
Currently NSTools contains libraries which are in a format that are in a
format which is compatible with RISC OS GCC3 but not RISC OS GCC4. Until
NSTools is updated with GCC4 compatible libraries, it is recommended that
you use GCC3 for native builds.
The NSTools on the web site is not auto-built, so it may not always have
the latest versions of the NetSurf project's own libraries. In this case
you will need to build the libraries yourself and update your copy of
NSTools.
Fetching the sources
----------------------
Use SVN to obtain the latest versions of each of the libraries. To do this,
set the CSD to a directory where you want to keep your copies of the library
sources, and run the appropriate commands from the Docs/LIBRARIES file.
The above will create a directory for each of the libraries containing their
sources.
| Note: We advise enabling iconv() support in libparserutils, which vastly
| increases the number of supported character sets. To do this,
| create a file called Makefile.config.override in the libparserutils
| directory, containing the following line:
|
| CFLAGS += -DWITH_ICONV_FILTER
|
| For more information, consult the libparserutils README file.
Updating NSTools' copies of the libraries
-------------------------------------------
Set the CSD to the directory of the library you want to build, set your next
slot to at least 6000K and in a TaskWindow, run
*svn update
This updates your local copy of the source to the latest version. To build
and install the library into NSTools, run:
*make install
| Note: If you are using GCC3, you may get a warning from AR when you run
| make. This can be ignored.

/contrib/network/netsurf/netsurf/Docs/BUILDING-ROCross
0,0 → 1,116
--------------------------------------------------------------------------------
Creating a cross-compilation environment for RISC OS NetSurf
--------------------------------------------------------------------------------
| Note: If you want to do a native RISC OS build, on a RISC OS computer,
| consult the BUILDING-RISC_OS file.
These instructions assume that you're starting from ~.
They also assume that you've got GCCSDK's prerequisites installed.
Building the toolchain
========================
Run the following commands.
$ svn co svn://svn.riscos.info/gccsdk/trunk/ gccsdk
$ cd gccsdk/gcc4
$ ./build-world
$ export GCCSDK_INSTALL_CROSSBIN=/home/riscos/cross/bin
$ export GCCSDK_INSTALL_ENV=/home/riscos/env
Creating the environment
==========================
A. Autobuilder packages
-------------------------
$ cd ../
$ mkdir build-ab
$ cat > build-ab/build-setvars
GCCSDK_INSTALL_CROSSBIN=/home/riscos/cross/bin
GCCSDK_INSTALL_ENV=/home/riscos/env
RO_SHAREDLIBS=no
AB_ELFBUILD=yes
$ cd build-ab
$ ../autobuilder/build zlib1g
$ ../autobuilder/build c-ares
$ ../autobuilder/build libssl0.9.8
$ ../autobuilder/build libcurl3
$ ../autobuilder/build libjpeg62
$ ../autobuilder/build liblcms1
$ ../autobuilder/build libpng12-0
$ ../autobuilder/build libmng1
$ ../autobuilder/build oslib
B. NetSurf libraries
----------------------
Install the NetSirf project's libraries as follows.
$ cd ~
$ svn co svn://svn.netsurf-browser.org/trunk netsurf
$ (cd netsurf/libnsbmp ; make TARGET=riscos install)
$ (cd netsurf/libnsgif ; make TARGET=riscos install)
$ (cd netsurf/libsvgtiny ; make TARGET=riscos install)
$ (cd netsurf/rufl ; make install)
$ (cd netsurf/pencil ; make install)
$ (cd netsurf/libharu ; make TARGET=riscos PREFIX=$GCCSDK_INSTALL_ENV)
$ cd netsurf/libparserutils
$ cat >Makefile.config.override
CFLAGS += -DWITH_ICONV_FILTER
$ make TARGET=riscos install
$ cd ~
$ (cd netsurf/hubbub ; make TARGET=riscos install)
$ (cd netsurf/libwapcaplet ; make TARGET=riscos install)
$ (cd netsurf/libcss ; make TARGET=riscos install)
C. Ancilliary tools
---------------------
$ svn co svn://svn.riscos.info/ccres/trunk ccres
$ (cd ccres ; make install)
$ (cd netsurf/tools/makerun ; make install)
Compiling NetSurf
===================
Finally, to cross-compile NetSurf for RISC OS, do the following.
$ cd netsurf/netsurf
$ make TARGET=riscos

/contrib/network/netsurf/netsurf/Docs/BUILDING-Windows
0,0 → 1,203
--------------------------------------------------------------------------------
Build Instructions for Windows NetSurf 13 February 2010
--------------------------------------------------------------------------------
This document provides instructions for building the Windows version
of NetSurf and provides guidance on obtaining NetSurf's build
dependencies.
Windows NetSurf has been tested on Wine and Vista.
Building and executing NetSurf
================================
The windows netsurf port uses the MinGW (Minimal GNU on Windows)
system as its build infrastructure. This allows the normal netsurf
build process to be used.
The method outlined here to create executables cross compiles
windows executable from a Linux OS host.
First of all, you should examine the contents of Makefile.defaults
and enable and disable relevant features as you see fit by creating
a Makefile.config file. Some of these options can be automatically
detected and used, and where this is the case they are set to such.
Others cannot be automatically detected from the Makefile, so you
will either need to install the dependencies, or set them to NO.
You should then obtain NetSurf's dependencies, keeping in mind which
options you have enabled in the configuration file. See the next
section for specifics.
Once done, to build windows NetSurf on a UNIX-like platform, simply run:
$ export MINGW_PREFIX=i586-mingw32msvc-
$ export MINGW_INSTALL_ENV=/usr/i586-mingw32msvc/
$ make TARGET=windows
If that produces errors, you probably don't have some of NetSurf's
build dependencies installed. See "Obtaining NetSurf's dependencies"
below. Or turn off the complaining features in a Makefile.config
file. You may need to "make clean" before attempting to build after
installing the dependencies.
You will need the libgnurx-0.dll from /usr/i586-mingw32msvc/bin/
copied next to the exe and the windows/res directory available, also
next to the executable.
Run NetSurf by executing it:
$ wine NetSurf.exe
The staticaly linked binary which is generated may be several
megabytes in size, this can be reduced by stripping the binary.
$ i586-mingw32msvc-strip NetSurf.exe
Obtaining NetSurf's build dependencies
========================================
Package installation
----------------------
Debian-based OS:
The mingw cross compilation tools are required. These can be
installed as pakages on Debian/Ubuntu systems:
$ sudo apt-get install mingw32 mingw32-binutils mingw32-runtime
These provide a suitable set of compilers and headers including the win32 API.
The includes and associated libraries are installed in
/usr/i586-mingw32msvc/ Which is where the build system will include
files from by default. The packages at time of writing only target
32bit windows builds.
Other:
For other OS the apropriate packages and environment must be installed.
pkg-config
------------
A pkg-config wrapper script is required to make things easier
cat > /usr/i586-mingw32msvc/bin/pkg-config <<EOF
#!/bin/bash
export PKG_CONFIG_LIBDIR=/usr/i586-mingw32msvc/lib/pkgconfig
/usr/bin/pkg-config $*
EOF
Base libraries
----------------
Unlike other OS the base libraries and their dependancies need to be
built and installed.
The instructions given here assume you will be installing on a
Debian derived OS using the mingw32 packages. The libraries should
be unpacked and built from a suitable temporary directory.
zlib:
$ apt-get source zlib1g
$ cd zlib-1.2.3.3.dfsg
$ CC=i586-mingw32msvc-gcc AR=i586-mingw32msvc-ar RANLIB=i586-mingw32msvc-ranlib CFLAGS="-DNO_FSEEKO" ./configure --prefix=/usr/i586-mingw32msvc/
$ make
$ sudo make install
libiconv:
$ wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.13.1.tar.gz
$ tar -zxf libiconv-1.13.1.tar.gz
$ cd libiconv-1.13.1
$ ./configure --prefix=/usr/i586-mingw32msvc/ --host=i586-mingw32msvc --disable-shared
$ make
$ sudo make install
regex:
$ wget http://kent.dl.sourceforge.net/project/mingw/Other/UserContributed/regex/mingw-regex-2.5.1/mingw-libgnurx-2.5.1-src.tar.gz
$ tar -zxf mingw-libgnurx-2.5.1-src.tar.gz
$ cd mingw-libgnurx-2.5.1
$ ./configure --prefix=/usr/i586-mingw32msvc/ --host=i586-mingw32msvc
$ make
$ sudo make install
openssl:
$ wget http://www.openssl.org/source/openssl-1.0.0a.tar.gz
$ tar -zxf openssl-1.0.0a.tar.gz
$ cd openssl-1.0.0a
$ PATH=/usr/i586-mingw32msvc/bin/:$PATH ./Configure no-shared disable-capieng --prefix=/usr/i586-mingw32msvc/ mingw
$ PATH=/usr/i586-mingw32msvc/bin/:$PATH make CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib
$ sudo make install
libcurl:
$ wget http://curl.haxx.se/download/curl-7.26.0.tar.gz
$ tar -zxf curl-7.26.0.tar.gz
$ cd curl-7.26.0
$ LDFLAGS=-mwindows ./configure --prefix=/usr/i586-mingw32msvc/ --host=i586-mingw32msvc --disable-shared --disable-ldap --without-random
$ make
$ sudo make install
libpng:
$ wget http://kent.dl.sourceforge.net/project/libpng/libpng14/1.4.12/libpng-1.4.12.tar.gz
$ tar -zxf libpng-1.4.12.tar.gz
$ cd libpng-1.4.12
$ ./configure --prefix=/usr/i586-mingw32msvc/ --host=i586-mingw32msvc
$ make
$ sudo make install
libjpeg:
$ wget http://www.ijg.org/files/jpegsrc.v8d.tar.gz
$ tar -zxf jpegsrc.v8d.tar.gz
$ cd jpeg-8d
$ ./configure --prefix=/usr/i586-mingw32msvc/ --host=i586-mingw32msvc --disable-shared
$ make
$ sudo make install
The NetSurf project's libraries
---------------------------------
The NetSurf project has developed several libraries which are required by
the browser. These are:
LibParserUtils -- Parser building utility functions
LibWapcaplet -- String internment
Hubbub -- HTML5 compliant HTML parser
LibCSS -- CSS parser and selection engine
LibNSGIF -- GIF format image decoder
LibNSBMP -- BMP and ICO format image decoder
LibROSprite -- RISC OS Sprite format image decoder
To fetch each of these libraries, run the appropriate commands from the
Docs/LIBRARIES file.
To build and install these libraries.
Ensure the MINGW_INSTALL_ENV variable is correctly set.
$ export MINGW_INSTALL_ENV=/usr/i586-mingw32msvc/
Then simply enter each of their directories and run:
$ make TARGET=windows PREFIX=/usr/i586-mingw32msvc/
$ sudo make TARGET=windows PREFIX=/usr/i586-mingw32msvc/ install
Resources
-----------
The windows resources may be rebuilt. Currently there is 1 object
file included in the Git distribution of NetSurf that could be
manually compiled
$ cd windows/res
$ i586-mingw32msvc-windres resource.rc -O coff -o resource.o

/contrib/network/netsurf/netsurf/Docs/Doxyfile
0,0 → 1,1828
# Doxyfile 1.8.1.1
# This file describes the settings to be used by the documentation system
# doxygen (www.doxygen.org) for a project.
#
# All text after a hash (#) is considered a comment and will be ignored.
# The format is:
# TAG = value [value, ...]
# For lists items can also be appended using:
# TAG += value [value, ...]
# Values that contain spaces should be placed between quotes (" ").
#---------------------------------------------------------------------------
# Project related configuration options
#---------------------------------------------------------------------------
# This tag specifies the encoding used for all characters in the config file
# that follow. The default is UTF-8 which is also the encoding used for all
# text before the first occurrence of this tag. Doxygen uses libiconv (or the
# iconv built into libc) for the transcoding. See
# http://www.gnu.org/software/libiconv for the list of possible encodings.
DOXYFILE_ENCODING = UTF-8
# The PROJECT_NAME tag is a single word (or sequence of words) that should
# identify the project. Note that if you do not use Doxywizard you need
# to put quotes around the project name if it contains spaces.
PROJECT_NAME = NetSurf
# The PROJECT_NUMBER tag can be used to enter a project or revision number.
# This could be handy for archiving the generated documentation or
# if some version control system is used.
PROJECT_NUMBER =
# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer
# a quick idea about the purpose of the project. Keep the description short.
PROJECT_BRIEF =
# With the PROJECT_LOGO tag one can specify an logo or icon that is
# included in the documentation. The maximum height of the logo should not
# exceed 55 pixels and the maximum width should not exceed 200 pixels.
# Doxygen will copy the logo to the output directory.
PROJECT_LOGO =
# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
# base path where the generated documentation will be put.
# If a relative path is entered, it will be relative to the location
# where doxygen was started. If left blank the current directory will be used.
OUTPUT_DIRECTORY =
# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
# 4096 sub-directories (in 2 levels) under the output directory of each output
# format and will distribute the generated files over these directories.
# Enabling this option can be useful when feeding doxygen a huge amount of
# source files, where putting all generated files in the same directory would
# otherwise cause performance problems for the file system.
CREATE_SUBDIRS = NO
# The OUTPUT_LANGUAGE tag is used to specify the language in which all
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all constant output in the proper language.
# The default language is English, other supported languages are:
# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German,
# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English
# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian,
# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak,
# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese.
OUTPUT_LANGUAGE = English
# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
# include brief member descriptions after the members that are listed in
# the file and class documentation (similar to JavaDoc).
# Set to NO to disable this.
BRIEF_MEMBER_DESC = YES
# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
# the brief description of a member or function before the detailed description.
# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
# brief descriptions will be completely suppressed.
REPEAT_BRIEF = YES
# This tag implements a quasi-intelligent brief description abbreviator
# that is used to form the text in various listings. Each string
# in this list, if found as the leading text of the brief description, will be
# stripped from the text and the result after processing the whole list, is
# used as the annotated text. Otherwise, the brief description is used as-is.
# If left blank, the following values are used ("$name" is automatically
# replaced with the name of the entity): "The $name class" "The $name widget"
# "The $name file" "is" "provides" "specifies" "contains"
# "represents" "a" "an" "the"
ABBREVIATE_BRIEF =
# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
# Doxygen will generate a detailed section even if there is only a brief
# description.
ALWAYS_DETAILED_SEC = NO
# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
# inherited members of a class in the documentation of that class as if those
# members were ordinary class members. Constructors, destructors and assignment
# operators of the base classes will not be shown.
INLINE_INHERITED_MEMB = NO
# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
# path before files name in the file list and in the header files. If set
# to NO the shortest path that makes the file name unique will be used.
FULL_PATH_NAMES = YES
# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
# can be used to strip a user-defined part of the path. Stripping is
# only done if one of the specified strings matches the left-hand part of
# the path. The tag can be used to show relative paths in the file list.
# If left blank the directory from which doxygen is run is used as the
# path to strip.
STRIP_FROM_PATH =
# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
# the path mentioned in the documentation of a class, which tells
# the reader which header file to include in order to use a class.
# If left blank only the name of the header file containing the class
# definition is used. Otherwise one should specify the include paths that
# are normally passed to the compiler using the -I flag.
STRIP_FROM_INC_PATH =
# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
# (but less readable) file names. This can be useful if your file system
# doesn't support long names like on DOS, Mac, or CD-ROM.
SHORT_NAMES = NO
# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
# will interpret the first line (until the first dot) of a JavaDoc-style
# comment as the brief description. If set to NO, the JavaDoc
# comments will behave just like regular Qt-style comments
# (thus requiring an explicit @brief command for a brief description.)
JAVADOC_AUTOBRIEF = YES
# If the QT_AUTOBRIEF tag is set to YES then Doxygen will
# interpret the first line (until the first dot) of a Qt-style
# comment as the brief description. If set to NO, the comments
# will behave just like regular Qt-style comments (thus requiring
# an explicit \brief command for a brief description.)
QT_AUTOBRIEF = NO
# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
# treat a multi-line C++ special comment block (i.e. a block of //! or ///
# comments) as a brief description. This used to be the default behaviour.
# The new default is to treat a multi-line C++ comment block as a detailed
# description. Set this tag to YES if you prefer the old behaviour instead.
MULTILINE_CPP_IS_BRIEF = NO
# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
# member inherits the documentation from any documented member that it
# re-implements.
INHERIT_DOCS = YES
# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
# a new page for each member. If set to NO, the documentation of a member will
# be part of the file/class/namespace that contains it.
SEPARATE_MEMBER_PAGES = NO
# The TAB_SIZE tag can be used to set the number of spaces in a tab.
# Doxygen uses this value to replace tabs by spaces in code fragments.
TAB_SIZE = 8
# This tag can be used to specify a number of aliases that acts
# as commands in the documentation. An alias has the form "name=value".
# For example adding "sideeffect=\par Side Effects:\n" will allow you to
# put the command \sideeffect (or @sideeffect) in the documentation, which
# will result in a user-defined paragraph with heading "Side Effects:".
# You can put \n's in the value part of an alias to insert newlines.
ALIASES =
# This tag can be used to specify a number of word-keyword mappings (TCL only).
# A mapping has the form "name=value". For example adding
# "class=itcl::class" will allow you to use the command class in the
# itcl::class meaning.
TCL_SUBST =
# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
# sources only. Doxygen will then generate output that is more tailored for C.
# For instance, some of the names that are used will be different. The list
# of all members will be omitted, etc.
OPTIMIZE_OUTPUT_FOR_C = YES
# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
# sources only. Doxygen will then generate output that is more tailored for
# Java. For instance, namespaces will be presented as packages, qualified
# scopes will look different, etc.
OPTIMIZE_OUTPUT_JAVA = NO
# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
# sources only. Doxygen will then generate output that is more tailored for
# Fortran.
OPTIMIZE_FOR_FORTRAN = NO
# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
# sources. Doxygen will then generate output that is tailored for
# VHDL.
OPTIMIZE_OUTPUT_VHDL = NO
# Doxygen selects the parser to use depending on the extension of the files it
# parses. With this tag you can assign which parser to use for a given extension.
# Doxygen has a built-in mapping, but you can override or extend it using this
# tag. The format is ext=language, where ext is a file extension, and language
# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C,
# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make
# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions
# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
EXTENSION_MAPPING =
# If MARKDOWN_SUPPORT is enabled (the default) then doxygen pre-processes all
# comments according to the Markdown format, which allows for more readable
# documentation. See http://daringfireball.net/projects/markdown/ for details.
# The output of markdown processing is further processed by doxygen, so you
# can mix doxygen, HTML, and XML commands with Markdown formatting.
# Disable only in case of backward compatibilities issues.
MARKDOWN_SUPPORT = YES
# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
# to include (a tag file for) the STL sources as input, then you should
# set this tag to YES in order to let doxygen match functions declarations and
# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
# func(std::string) {}). This also makes the inheritance and collaboration
# diagrams that involve STL classes more complete and accurate.
BUILTIN_STL_SUPPORT = NO
# If you use Microsoft's C++/CLI language, you should set this option to YES to
# enable parsing support.
CPP_CLI_SUPPORT = NO
# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only.
# Doxygen will parse them like normal C++ but will assume all classes use public
# instead of private inheritance when no explicit protection keyword is present.
SIP_SUPPORT = NO
# For Microsoft's IDL there are propget and propput attributes to indicate getter
# and setter methods for a property. Setting this option to YES (the default)
# will make doxygen replace the get and set methods by a property in the
# documentation. This will only work if the methods are indeed getting or
# setting a simple type. If this is not the case, or you want to show the
# methods anyway, you should set this option to NO.
IDL_PROPERTY_SUPPORT = YES
# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
# tag is set to YES, then doxygen will reuse the documentation of the first
# member in the group (if any) for the other members of the group. By default
# all members of a group must be documented explicitly.
DISTRIBUTE_GROUP_DOC = NO
# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
# the same type (for instance a group of public functions) to be put as a
# subgroup of that type (e.g. under the Public Functions section). Set it to
# NO to prevent subgrouping. Alternatively, this can be done per class using
# the \nosubgrouping command.
SUBGROUPING = YES
# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and
# unions are shown inside the group in which they are included (e.g. using
# @ingroup) instead of on a separate page (for HTML and Man pages) or
# section (for LaTeX and RTF).
INLINE_GROUPED_CLASSES = NO
# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and
# unions with only public data fields will be shown inline in the documentation
# of the scope in which they are defined (i.e. file, namespace, or group
# documentation), provided this scope is documented. If set to NO (the default),
# structs, classes, and unions are shown on a separate page (for HTML and Man
# pages) or section (for LaTeX and RTF).
INLINE_SIMPLE_STRUCTS = NO
# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
# is documented as struct, union, or enum with the name of the typedef. So
# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
# with name TypeT. When disabled the typedef will appear as a member of a file,
# namespace, or class. And the struct will be named TypeS. This can typically
# be useful for C code in case the coding convention dictates that all compound
# types are typedef'ed and only the typedef is referenced, never the tag name.
TYPEDEF_HIDES_STRUCT = NO
# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to
# determine which symbols to keep in memory and which to flush to disk.
# When the cache is full, less often used symbols will be written to disk.
# For small to medium size projects (<1000 input files) the default value is
# probably good enough. For larger projects a too small cache size can cause
# doxygen to be busy swapping symbols to and from disk most of the time
# causing a significant performance penalty.
# If the system has enough physical memory increasing the cache will improve the
# performance by keeping more symbols in memory. Note that the value works on
# a logarithmic scale so increasing the size by one will roughly double the
# memory usage. The cache size is given by this formula:
# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
# corresponding to a cache size of 2^16 = 65536 symbols.
SYMBOL_CACHE_SIZE = 0
# Similar to the SYMBOL_CACHE_SIZE the size of the symbol lookup cache can be
# set using LOOKUP_CACHE_SIZE. This cache is used to resolve symbols given
# their name and scope. Since this can be an expensive process and often the
# same symbol appear multiple times in the code, doxygen keeps a cache of
# pre-resolved symbols. If the cache is too small doxygen will become slower.
# If the cache is too large, memory is wasted. The cache size is given by this
# formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range is 0..9, the default is 0,
# corresponding to a cache size of 2^16 = 65536 symbols.
LOOKUP_CACHE_SIZE = 0
#---------------------------------------------------------------------------
# Build related configuration options
#---------------------------------------------------------------------------
# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
# documentation are documented, even if no documentation was available.
# Private class members and static file members will be hidden unless
# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
EXTRACT_ALL = YES
# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
# will be included in the documentation.
EXTRACT_PRIVATE = YES
# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal scope will be included in the documentation.
EXTRACT_PACKAGE = NO
# If the EXTRACT_STATIC tag is set to YES all static members of a file
# will be included in the documentation.
EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
# defined locally in source files will be included in the documentation.
# If set to NO only classes defined in header files are included.
EXTRACT_LOCAL_CLASSES = YES
# This flag is only useful for Objective-C code. When set to YES local
# methods, which are defined in the implementation section but not in
# the interface are included in the documentation.
# If set to NO (the default) only methods in the interface are included.
EXTRACT_LOCAL_METHODS = NO
# If this flag is set to YES, the members of anonymous namespaces will be
# extracted and appear in the documentation as a namespace called
# 'anonymous_namespace{file}', where file will be replaced with the base
# name of the file that contains the anonymous namespace. By default
# anonymous namespaces are hidden.
EXTRACT_ANON_NSPACES = NO
# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
# undocumented members of documented classes, files or namespaces.
# If set to NO (the default) these members will be included in the
# various overviews, but no documentation section is generated.
# This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_MEMBERS = NO
# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
# undocumented classes that are normally visible in the class hierarchy.
# If set to NO (the default) these classes will be included in the various
# overviews. This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_CLASSES = NO
# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
# friend (class|struct|union) declarations.
# If set to NO (the default) these declarations will be included in the
# documentation.
HIDE_FRIEND_COMPOUNDS = NO
# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
# documentation blocks found inside the body of a function.
# If set to NO (the default) these blocks will be appended to the
# function's detailed documentation block.
HIDE_IN_BODY_DOCS = NO
# The INTERNAL_DOCS tag determines if documentation
# that is typed after a \internal command is included. If the tag is set
# to NO (the default) then the documentation will be excluded.
# Set it to YES to include the internal documentation.
INTERNAL_DOCS = NO
# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
# file names in lower-case letters. If set to YES upper-case letters are also
# allowed. This is useful if you have classes or files whose names only differ
# in case and if your file system supports case sensitive file names. Windows
# and Mac users are advised to set this option to NO.
CASE_SENSE_NAMES = YES
# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
# will show members with their full class and namespace scopes in the
# documentation. If set to YES the scope will be hidden.
HIDE_SCOPE_NAMES = NO
# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
# will put a list of the files that are included by a file in the documentation
# of that file.
SHOW_INCLUDE_FILES = YES
# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen
# will list include files with double quotes in the documentation
# rather than with sharp brackets.
FORCE_LOCAL_INCLUDES = NO
# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
# is inserted in the documentation for inline members.
INLINE_INFO = YES
# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
# will sort the (detailed) documentation of file and class members
# alphabetically by member name. If set to NO the members will appear in
# declaration order.
SORT_MEMBER_DOCS = YES
# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
# brief documentation of file, namespace and class members alphabetically
# by member name. If set to NO (the default) the members will appear in
# declaration order.
SORT_BRIEF_DOCS = NO
# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen
# will sort the (brief and detailed) documentation of class members so that
# constructors and destructors are listed first. If set to NO (the default)
# the constructors will appear in the respective orders defined by
# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS.
# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO
# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO.
SORT_MEMBERS_CTORS_1ST = NO
# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the
# hierarchy of group names into alphabetical order. If set to NO (the default)
# the group names will appear in their defined order.
SORT_GROUP_NAMES = NO
# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
# sorted by fully-qualified names, including namespaces. If set to
# NO (the default), the class list will be sorted only by class name,
# not including the namespace part.
# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
# Note: This option applies only to the class list, not to the
# alphabetical list.
SORT_BY_SCOPE_NAME = NO
# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to
# do proper type resolution of all parameters of a function it will reject a
# match between the prototype and the implementation of a member function even
# if there is only one candidate or it is obvious which candidate to choose
# by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen
# will still accept a match between prototype and implementation in such cases.
STRICT_PROTO_MATCHING = NO
# The GENERATE_TODOLIST tag can be used to enable (YES) or
# disable (NO) the todo list. This list is created by putting \todo
# commands in the documentation.
GENERATE_TODOLIST = YES
# The GENERATE_TESTLIST tag can be used to enable (YES) or
# disable (NO) the test list. This list is created by putting \test
# commands in the documentation.
GENERATE_TESTLIST = YES
# The GENERATE_BUGLIST tag can be used to enable (YES) or
# disable (NO) the bug list. This list is created by putting \bug
# commands in the documentation.
GENERATE_BUGLIST = YES
# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
# disable (NO) the deprecated list. This list is created by putting
# \deprecated commands in the documentation.
GENERATE_DEPRECATEDLIST= YES
# The ENABLED_SECTIONS tag can be used to enable conditional
# documentation sections, marked by \if sectionname ... \endif.
ENABLED_SECTIONS =
# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
# the initial value of a variable or macro consists of for it to appear in
# the documentation. If the initializer consists of more lines than specified
# here it will be hidden. Use a value of 0 to hide initializers completely.
# The appearance of the initializer of individual variables and macros in the
# documentation can be controlled using \showinitializer or \hideinitializer
# command in the documentation regardless of this setting.
MAX_INITIALIZER_LINES = 30
# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
# at the bottom of the documentation of classes and structs. If set to YES the
# list will mention the files that were used to generate the documentation.
SHOW_USED_FILES = YES
# Set the SHOW_FILES tag to NO to disable the generation of the Files page.
# This will remove the Files entry from the Quick Index and from the
# Folder Tree View (if specified). The default is YES.
SHOW_FILES = YES
# Set the SHOW_NAMESPACES tag to NO to disable the generation of the
# Namespaces page.
# This will remove the Namespaces entry from the Quick Index
# and from the Folder Tree View (if specified). The default is YES.
SHOW_NAMESPACES = YES
# The FILE_VERSION_FILTER tag can be used to specify a program or script that
# doxygen should invoke to get the current version for each file (typically from
# the version control system). Doxygen will invoke the program by executing (via
# popen()) the command <command> <input-file>, where <command> is the value of
# the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file
# provided by doxygen. Whatever the program writes to standard output
# is used as the file version. See the manual for examples.
FILE_VERSION_FILTER =
# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
# by doxygen. The layout file controls the global structure of the generated
# output files in an output format independent way. To create the layout file
# that represents doxygen's defaults, run doxygen with the -l option.
# You can optionally specify a file name after the option, if omitted
# DoxygenLayout.xml will be used as the name of the layout file.
LAYOUT_FILE =
# The CITE_BIB_FILES tag can be used to specify one or more bib files
# containing the references data. This must be a list of .bib files. The
# .bib extension is automatically appended if omitted. Using this command
# requires the bibtex tool to be installed. See also
# http://en.wikipedia.org/wiki/BibTeX for more info. For LaTeX the style
# of the bibliography can be controlled using LATEX_BIB_STYLE. To use this
# feature you need bibtex and perl available in the search path.
CITE_BIB_FILES =
#---------------------------------------------------------------------------
# configuration options related to warning and progress messages
#---------------------------------------------------------------------------
# The QUIET tag can be used to turn on/off the messages that are generated
# by doxygen. Possible values are YES and NO. If left blank NO is used.
QUIET = NO
# The WARNINGS tag can be used to turn on/off the warning messages that are
# generated by doxygen. Possible values are YES and NO. If left blank
# NO is used.
WARNINGS = YES
# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
# automatically be disabled.
WARN_IF_UNDOCUMENTED = YES
# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
# potential errors in the documentation, such as not documenting some
# parameters in a documented function, or documenting parameters that
# don't exist or using markup commands wrongly.
WARN_IF_DOC_ERROR = YES
# The WARN_NO_PARAMDOC option can be enabled to get warnings for
# functions that are documented, but have no documentation for their parameters
# or return value. If set to NO (the default) doxygen will only warn about
# wrong or incomplete parameter documentation, but not about the absence of
# documentation.
WARN_NO_PARAMDOC = YES
# The WARN_FORMAT tag determines the format of the warning messages that
# doxygen can produce. The string should contain the $file, $line, and $text
# tags, which will be replaced by the file and line number from which the
# warning originated and the warning text. Optionally the format may contain
# $version, which will be replaced by the version of the file (if it could
# be obtained via FILE_VERSION_FILTER)
WARN_FORMAT = "$file:$line: $text"
# The WARN_LOGFILE tag can be used to specify a file to which warning
# and error messages should be written. If left blank the output is written
# to stderr.
WARN_LOGFILE =
#---------------------------------------------------------------------------
# configuration options related to the input files
#---------------------------------------------------------------------------
# The INPUT tag can be used to specify the files and/or directories that contain
# documented source files. You may enter file names like "myfile.cpp" or
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
INPUT = windows \
atari \
atari/plot \
gtk \
gtk/dialogs \
css \
cocoa \
monkey \
render \
desktop \
desktop/save_pdf \
amiga \
amiga/stringview \
content \
content/fetchers \
framebuffer \
framebuffer/fbtk \
riscos \
riscos/configure \
riscos/gui \
riscos/content-handlers \
riscos/templates \
riscos/scripts \
beos \
javascript \
javascript/jsapi \
utils \
utils/http
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
# also the default input encoding. Doxygen uses libiconv (or the iconv built
# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for
# the list of possible encodings.
INPUT_ENCODING = UTF-8
# If the value of the INPUT tag contains directories, you can use the
# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank the following patterns are tested:
# *.c *.cc *.cxx *.cpp *.c++ *.d *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh
# *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py
# *.f90 *.f *.for *.vhd *.vhdl
FILE_PATTERNS = *.c \
*.h \
*.y \
*.l
# The RECURSIVE tag can be used to turn specify whether or not subdirectories
# should be searched for input files as well. Possible values are YES and NO.
# If left blank NO is used.
RECURSIVE = NO
# The EXCLUDE tag can be used to specify files and/or directories that should be
# excluded from the INPUT source files. This way you can easily exclude a
# subdirectory from a directory tree whose root is specified with the INPUT tag.
# Note that relative paths are relative to the directory from which doxygen is
# run.
EXCLUDE = css/css_enum.c \
css/css_enum.h \
css/parser.c \
css/parser.h \
css/scanner.c \
css/scanner.h
# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
# directories that are symbolic links (a Unix file system feature) are excluded
# from the input.
EXCLUDE_SYMLINKS = NO
# If the value of the INPUT tag contains directories, you can use the
# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
# certain files from those directories. Note that the wildcards are matched
# against the file with absolute path, so to exclude all test directories
# for example use the pattern */test/*
EXCLUDE_PATTERNS =
# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
# (namespaces, classes, functions, etc.) that should be excluded from the
# output. The symbol name can be a fully qualified name, a word, or if the
# wildcard * is used, a substring. Examples: ANamespace, AClass,
# AClass::ANamespace, ANamespace::*Test
EXCLUDE_SYMBOLS =
# The EXAMPLE_PATH tag can be used to specify one or more files or
# directories that contain example code fragments that are included (see
# the \include command).
EXAMPLE_PATH =
# If the value of the EXAMPLE_PATH tag contains directories, you can use the
# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
# and *.h) to filter out the source-files in the directories. If left
# blank all files are included.
EXAMPLE_PATTERNS =
# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
# searched for input files to be used with the \include or \dontinclude
# commands irrespective of the value of the RECURSIVE tag.
# Possible values are YES and NO. If left blank NO is used.
EXAMPLE_RECURSIVE = NO
# The IMAGE_PATH tag can be used to specify one or more files or
# directories that contain image that are included in the documentation (see
# the \image command).
IMAGE_PATH =
# The INPUT_FILTER tag can be used to specify a program that doxygen should
# invoke to filter for each input file. Doxygen will invoke the filter program
# by executing (via popen()) the command <filter> <input-file>, where <filter>
# is the value of the INPUT_FILTER tag, and <input-file> is the name of an
# input file. Doxygen will then use the output that the filter program writes
# to standard output.
# If FILTER_PATTERNS is specified, this tag will be
# ignored.
INPUT_FILTER =
# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
# basis.
# Doxygen will compare the file name with each pattern and apply the
# filter if there is a match.
# The filters are a list of the form:
# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
# info on how filters are used. If FILTER_PATTERNS is empty or if
# non of the patterns match the file name, INPUT_FILTER is applied.
FILTER_PATTERNS =
# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
# INPUT_FILTER) will be used to filter the input files when producing source
# files to browse (i.e. when SOURCE_BROWSER is set to YES).
FILTER_SOURCE_FILES = NO
# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
# pattern. A pattern will override the setting for FILTER_PATTERN (if any)
# and it is also possible to disable source filtering for a specific pattern
# using *.ext= (so without naming a filter). This option only has effect when
# FILTER_SOURCE_FILES is enabled.
FILTER_SOURCE_PATTERNS =
#---------------------------------------------------------------------------
# configuration options related to source browsing
#---------------------------------------------------------------------------
# If the SOURCE_BROWSER tag is set to YES then a list of source files will
# be generated. Documented entities will be cross-referenced with these sources.
# Note: To get rid of all source code in the generated output, make sure also
# VERBATIM_HEADERS is set to NO.
SOURCE_BROWSER = YES
# Setting the INLINE_SOURCES tag to YES will include the body
# of functions and classes directly in the documentation.
INLINE_SOURCES = NO
# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
# doxygen to hide any special comment blocks from generated source code
# fragments. Normal C, C++ and Fortran comments will always remain visible.
STRIP_CODE_COMMENTS = NO
# If the REFERENCED_BY_RELATION tag is set to YES
# then for each documented function all documented
# functions referencing it will be listed.
REFERENCED_BY_RELATION = YES
# If the REFERENCES_RELATION tag is set to YES
# then for each documented function all documented entities
# called/used by that function will be listed.
REFERENCES_RELATION = YES
# If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
# link to the source code.
# Otherwise they will link to the documentation.
REFERENCES_LINK_SOURCE = YES
# If the USE_HTAGS tag is set to YES then the references to source code
# will point to the HTML generated by the htags(1) tool instead of doxygen
# built-in source browser. The htags tool is part of GNU's global source
# tagging system (see http://www.gnu.org/software/global/global.html). You
# will need version 4.8.6 or higher.
USE_HTAGS = NO
# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
# will generate a verbatim copy of the header file for each class for
# which an include is specified. Set to NO to disable this.
VERBATIM_HEADERS = YES
#---------------------------------------------------------------------------
# configuration options related to the alphabetical class index
#---------------------------------------------------------------------------
# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
# of all compounds will be generated. Enable this if the project
# contains a lot of classes, structs, unions or interfaces.
ALPHABETICAL_INDEX = NO
# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
# in which this list will be split (can be a number in the range [1..20])
COLS_IN_ALPHA_INDEX = 5
# In case all classes in a project start with a common prefix, all
# classes will be put under the same header in the alphabetical index.
# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
# should be ignored while generating the index headers.
IGNORE_PREFIX =
#---------------------------------------------------------------------------
# configuration options related to the HTML output
#---------------------------------------------------------------------------
# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
# generate HTML output.
GENERATE_HTML = YES
# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `html' will be used as the default path.
HTML_OUTPUT = codedocs
# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
# doxygen will generate files with .html extension.
HTML_FILE_EXTENSION = .html
# The HTML_HEADER tag can be used to specify a personal HTML header for
# each generated HTML page. If it is left blank doxygen will generate a
# standard header. Note that when using a custom header you are responsible
# for the proper inclusion of any scripts and style sheets that doxygen
# needs, which is dependent on the configuration options used.
# It is advised to generate a default header using "doxygen -w html
# header.html footer.html stylesheet.css YourConfigFile" and then modify
# that header. Note that the header is subject to change so you typically
# have to redo this when upgrading to a newer version of doxygen or when
# changing the value of configuration settings such as GENERATE_TREEVIEW!
HTML_HEADER =
# The HTML_FOOTER tag can be used to specify a personal HTML footer for
# each generated HTML page. If it is left blank doxygen will generate a
# standard footer.
HTML_FOOTER =
# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
# style sheet that is used by each HTML page. It can be used to
# fine-tune the look of the HTML output. If the tag is left blank doxygen
# will generate a default style sheet. Note that doxygen will try to copy
# the style sheet file to the HTML output directory, so don't put your own
# style sheet in the HTML output directory as well, or it will be erased!
HTML_STYLESHEET =
# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
# other source files which should be copied to the HTML output directory. Note
# that these files will be copied to the base HTML output directory. Use the
# $relpath$ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
# files. In the HTML_STYLESHEET file, use the file name only. Also note that
# the files will be copied as-is; there are no commands or markers available.
HTML_EXTRA_FILES =
# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output.
# Doxygen will adjust the colors in the style sheet and background images
# according to this color. Hue is specified as an angle on a colorwheel,
# see http://en.wikipedia.org/wiki/Hue for more information.
# For instance the value 0 represents red, 60 is yellow, 120 is green,
# 180 is cyan, 240 is blue, 300 purple, and 360 is red again.
# The allowed range is 0 to 359.
HTML_COLORSTYLE_HUE = 220
# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of
# the colors in the HTML output. For a value of 0 the output will use
# grayscales only. A value of 255 will produce the most vivid colors.
HTML_COLORSTYLE_SAT = 100
# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to
# the luminance component of the colors in the HTML output. Values below
# 100 gradually make the output lighter, whereas values above 100 make
# the output darker. The value divided by 100 is the actual gamma applied,
# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2,
# and 100 does not change the gamma.
HTML_COLORSTYLE_GAMMA = 80
# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
# page will contain the date and time when the page was generated. Setting
# this to NO can help when comparing the output of multiple runs.
HTML_TIMESTAMP = YES
# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
# documentation will contain sections that can be hidden and shown after the
# page has loaded.
HTML_DYNAMIC_SECTIONS = NO
# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of
# entries shown in the various tree structured indices initially; the user
# can expand and collapse entries dynamically later on. Doxygen will expand
# the tree to such a level that at most the specified number of entries are
# visible (unless a fully collapsed tree already exceeds this amount).
# So setting the number of entries 1 will produce a full collapsed tree by
# default. 0 is a special value representing an infinite number of entries
# and will result in a full expanded tree by default.
HTML_INDEX_NUM_ENTRIES = 100
# If the GENERATE_DOCSET tag is set to YES, additional index files
# will be generated that can be used as input for Apple's Xcode 3
# integrated development environment, introduced with OSX 10.5 (Leopard).
# To create a documentation set, doxygen will generate a Makefile in the
# HTML output directory. Running make will produce the docset in that
# directory and running "make install" will install the docset in
# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find
# it at startup.
# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
# for more information.
GENERATE_DOCSET = NO
# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the
# feed. A documentation feed provides an umbrella under which multiple
# documentation sets from a single provider (such as a company or product suite)
# can be grouped.
DOCSET_FEEDNAME = "Doxygen generated docs"
# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that
# should uniquely identify the documentation set bundle. This should be a
# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen
# will append .docset to the name.
DOCSET_BUNDLE_ID = org.doxygen.Project
# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify
# the documentation publisher. This should be a reverse domain-name style
# string, e.g. com.mycompany.MyDocSet.documentation.
DOCSET_PUBLISHER_ID = org.doxygen.Publisher
# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher.
DOCSET_PUBLISHER_NAME = Publisher
# If the GENERATE_HTMLHELP tag is set to YES, additional index files
# will be generated that can be used as input for tools like the
# Microsoft HTML help workshop to generate a compiled HTML help file (.chm)
# of the generated HTML documentation.
GENERATE_HTMLHELP = NO
# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
# be used to specify the file name of the resulting .chm file. You
# can add a path in front of the file if the result should not be
# written to the html output directory.
CHM_FILE =
# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
# be used to specify the location (absolute path including file name) of
# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
# the HTML help compiler on the generated index.hhp.
HHC_LOCATION =
# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
# controls if a separate .chi index file is generated (YES) or that
# it should be included in the master .chm file (NO).
GENERATE_CHI = NO
# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING
# is used to encode HtmlHelp index (hhk), content (hhc) and project file
# content.
CHM_INDEX_ENCODING =
# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
# controls whether a binary table of contents is generated (YES) or a
# normal table of contents (NO) in the .chm file.
BINARY_TOC = NO
# The TOC_EXPAND flag can be set to YES to add extra items for group members
# to the contents of the HTML help documentation and to the tree view.
TOC_EXPAND = NO
# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated
# that can be used as input for Qt's qhelpgenerator to generate a
# Qt Compressed Help (.qch) of the generated HTML documentation.
GENERATE_QHP = NO
# If the QHG_LOCATION tag is specified, the QCH_FILE tag can
# be used to specify the file name of the resulting .qch file.
# The path specified is relative to the HTML output folder.
QCH_FILE =
# The QHP_NAMESPACE tag specifies the namespace to use when generating
# Qt Help Project output. For more information please see
# http://doc.trolltech.com/qthelpproject.html#namespace
QHP_NAMESPACE = org.doxygen.Project
# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
# Qt Help Project output. For more information please see
# http://doc.trolltech.com/qthelpproject.html#virtual-folders
QHP_VIRTUAL_FOLDER = doc
# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to
# add. For more information please see
# http://doc.trolltech.com/qthelpproject.html#custom-filters
QHP_CUST_FILTER_NAME =
# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the
# custom filter to add. For more information please see
# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters">
# Qt Help Project / Custom Filters</a>.
QHP_CUST_FILTER_ATTRS =
# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
# project's
# filter section matches.
# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes">
# Qt Help Project / Filter Attributes</a>.
QHP_SECT_FILTER_ATTRS =
# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can
# be used to specify the location of Qt's qhelpgenerator.
# If non-empty doxygen will try to run qhelpgenerator on the generated
# .qhp file.
QHG_LOCATION =
# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files
# will be generated, which together with the HTML files, form an Eclipse help
# plugin. To install this plugin and make it available under the help contents
# menu in Eclipse, the contents of the directory containing the HTML and XML
# files needs to be copied into the plugins directory of eclipse. The name of
# the directory within the plugins directory should be the same as
# the ECLIPSE_DOC_ID value. After copying Eclipse needs to be restarted before
# the help appears.
GENERATE_ECLIPSEHELP = NO
# A unique identifier for the eclipse help plugin. When installing the plugin
# the directory name containing the HTML and XML files should also have
# this name.
ECLIPSE_DOC_ID = org.doxygen.Project
# The DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs)
# at top of each HTML page. The value NO (the default) enables the index and
# the value YES disables it. Since the tabs have the same information as the
# navigation tree you can set this option to NO if you already set
# GENERATE_TREEVIEW to YES.
DISABLE_INDEX = NO
# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
# structure should be generated to display hierarchical information.
# If the tag value is set to YES, a side panel will be generated
# containing a tree-like index structure (just like the one that
# is generated for HTML Help). For this to work a browser that supports
# JavaScript, DHTML, CSS and frames is required (i.e. any modern browser).
# Windows users are probably better off using the HTML help feature.
# Since the tree basically has the same information as the tab index you
# could consider to set DISABLE_INDEX to NO when enabling this option.
GENERATE_TREEVIEW = NO
# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values
# (range [0,1..20]) that doxygen will group on one line in the generated HTML
# documentation. Note that a value of 0 will completely suppress the enum
# values from appearing in the overview section.
ENUM_VALUES_PER_LINE = 4
# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
# used to set the initial width (in pixels) of the frame in which the tree
# is shown.
TREEVIEW_WIDTH = 250
# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open
# links to external symbols imported via tag files in a separate window.
EXT_LINKS_IN_WINDOW = NO
# Use this tag to change the font size of Latex formulas included
# as images in the HTML documentation. The default is 10. Note that
# when you change the font size after a successful doxygen run you need
# to manually remove any form_*.png images from the HTML output directory
# to force them to be regenerated.
FORMULA_FONTSIZE = 10
# Use the FORMULA_TRANPARENT tag to determine whether or not the images
# generated for formulas are transparent PNGs. Transparent PNGs are
# not supported properly for IE 6.0, but are supported on all modern browsers.
# Note that when changing this option you need to delete any form_*.png files
# in the HTML output before the changes have effect.
FORMULA_TRANSPARENT = YES
# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax
# (see http://www.mathjax.org) which uses client side Javascript for the
# rendering instead of using prerendered bitmaps. Use this if you do not
# have LaTeX installed or if you want to formulas look prettier in the HTML
# output. When enabled you may also need to install MathJax separately and
# configure the path to it using the MATHJAX_RELPATH option.
USE_MATHJAX = NO
# When MathJax is enabled you need to specify the location relative to the
# HTML output directory using the MATHJAX_RELPATH option. The destination
# directory should contain the MathJax.js script. For instance, if the mathjax
# directory is located at the same level as the HTML output directory, then
# MATHJAX_RELPATH should be ../mathjax. The default value points to
# the MathJax Content Delivery Network so you can quickly see the result without
# installing MathJax.
# However, it is strongly recommended to install a local
# copy of MathJax from http://www.mathjax.org before deployment.
MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
# The MATHJAX_EXTENSIONS tag can be used to specify one or MathJax extension
# names that should be enabled during MathJax rendering.
MATHJAX_EXTENSIONS =
# When the SEARCHENGINE tag is enabled doxygen will generate a search box
# for the HTML output. The underlying search engine uses javascript
# and DHTML and should work on any modern browser. Note that when using
# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets
# (GENERATE_DOCSET) there is already a search function so this one should
# typically be disabled. For large projects the javascript based search engine
# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution.
SEARCHENGINE = NO
# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
# implemented using a PHP enabled web server instead of at the web client
# using Javascript. Doxygen will generate the search PHP script and index
# file to put on the web server. The advantage of the server
# based approach is that it scales better to large projects and allows
# full text search. The disadvantages are that it is more difficult to setup
# and does not have live searching capabilities.
SERVER_BASED_SEARCH = NO
#---------------------------------------------------------------------------
# configuration options related to the LaTeX output
#---------------------------------------------------------------------------
# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
# generate Latex output.
GENERATE_LATEX = NO
# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `latex' will be used as the default path.
LATEX_OUTPUT = latex
# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
# invoked. If left blank `latex' will be used as the default command name.
# Note that when enabling USE_PDFLATEX this option is only used for
# generating bitmaps for formulas in the HTML output, but not in the
# Makefile that is written to the output directory.
LATEX_CMD_NAME = latex
# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
# generate index for LaTeX. If left blank `makeindex' will be used as the
# default command name.
MAKEINDEX_CMD_NAME = makeindex
# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
# LaTeX documents. This may be useful for small projects and may help to
# save some trees in general.
COMPACT_LATEX = NO
# The PAPER_TYPE tag can be used to set the paper type that is used
# by the printer. Possible values are: a4, letter, legal and
# executive. If left blank a4wide will be used.
PAPER_TYPE = a4wide
# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
# packages that should be included in the LaTeX output.
EXTRA_PACKAGES =
# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
# the generated latex document. The header should contain everything until
# the first chapter. If it is left blank doxygen will generate a
# standard header. Notice: only use this tag if you know what you are doing!
LATEX_HEADER =
# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for
# the generated latex document. The footer should contain everything after
# the last chapter. If it is left blank doxygen will generate a
# standard footer. Notice: only use this tag if you know what you are doing!
LATEX_FOOTER =
# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
# is prepared for conversion to pdf (using ps2pdf). The pdf file will
# contain links (just like the HTML output) instead of page references
# This makes the output suitable for online browsing using a pdf viewer.
PDF_HYPERLINKS = NO
# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
# plain latex in the generated Makefile. Set this option to YES to get a
# higher quality PDF documentation.
USE_PDFLATEX = NO
# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
# command to the generated LaTeX files. This will instruct LaTeX to keep
# running if errors occur, instead of asking the user for help.
# This option is also used when generating formulas in HTML.
LATEX_BATCHMODE = NO
# If LATEX_HIDE_INDICES is set to YES then doxygen will not
# include the index chapters (such as File Index, Compound Index, etc.)
# in the output.
LATEX_HIDE_INDICES = NO
# If LATEX_SOURCE_CODE is set to YES then doxygen will include
# source code with syntax highlighting in the LaTeX output.
# Note that which sources are shown also depends on other settings
# such as SOURCE_BROWSER.
LATEX_SOURCE_CODE = NO
# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
# bibliography, e.g. plainnat, or ieeetr. The default style is "plain". See
# http://en.wikipedia.org/wiki/BibTeX for more info.
LATEX_BIB_STYLE = plain
#---------------------------------------------------------------------------
# configuration options related to the RTF output
#---------------------------------------------------------------------------
# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
# The RTF output is optimized for Word 97 and may not look very pretty with
# other RTF readers or editors.
GENERATE_RTF = NO
# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `rtf' will be used as the default path.
RTF_OUTPUT = rtf
# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
# RTF documents. This may be useful for small projects and may help to
# save some trees in general.
COMPACT_RTF = NO
# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
# will contain hyperlink fields. The RTF file will
# contain links (just like the HTML output) instead of page references.
# This makes the output suitable for online browsing using WORD or other
# programs which support those fields.
# Note: wordpad (write) and others do not support links.
RTF_HYPERLINKS = NO
# Load style sheet definitions from file. Syntax is similar to doxygen's
# config file, i.e. a series of assignments. You only have to provide
# replacements, missing definitions are set to their default value.
RTF_STYLESHEET_FILE =
# Set optional variables used in the generation of an rtf document.
# Syntax is similar to doxygen's config file.
RTF_EXTENSIONS_FILE =
#---------------------------------------------------------------------------
# configuration options related to the man page output
#---------------------------------------------------------------------------
# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
# generate man pages
GENERATE_MAN = NO
# The MAN_OUTPUT tag is used to specify where the man pages will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `man' will be used as the default path.
MAN_OUTPUT = man
# The MAN_EXTENSION tag determines the extension that is added to
# the generated man pages (default is the subroutine's section .3)
MAN_EXTENSION = .3
# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
# then it will generate one additional man file for each entity
# documented in the real man page(s). These additional files
# only source the real man page, but without them the man command
# would be unable to find the correct page. The default is NO.
MAN_LINKS = NO
#---------------------------------------------------------------------------
# configuration options related to the XML output
#---------------------------------------------------------------------------
# If the GENERATE_XML tag is set to YES Doxygen will
# generate an XML file that captures the structure of
# the code including all documentation.
GENERATE_XML = NO
# The XML_OUTPUT tag is used to specify where the XML pages will be put.
# If a relative path is entered the value of OUTPUT_DIRECTORY will be
# put in front of it. If left blank `xml' will be used as the default path.
XML_OUTPUT = xml
# The XML_SCHEMA tag can be used to specify an XML schema,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_SCHEMA =
# The XML_DTD tag can be used to specify an XML DTD,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_DTD =
# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
# dump the program listings (including syntax highlighting
# and cross-referencing information) to the XML output. Note that
# enabling this will significantly increase the size of the XML output.
XML_PROGRAMLISTING = YES
#---------------------------------------------------------------------------
# configuration options for the AutoGen Definitions output
#---------------------------------------------------------------------------
# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
# generate an AutoGen Definitions (see autogen.sf.net) file
# that captures the structure of the code including all
# documentation. Note that this feature is still experimental
# and incomplete at the moment.
GENERATE_AUTOGEN_DEF = NO
#---------------------------------------------------------------------------
# configuration options related to the Perl module output
#---------------------------------------------------------------------------
# If the GENERATE_PERLMOD tag is set to YES Doxygen will
# generate a Perl module file that captures the structure of
# the code including all documentation. Note that this
# feature is still experimental and incomplete at the
# moment.
GENERATE_PERLMOD = NO
# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
# the necessary Makefile rules, Perl scripts and LaTeX code to be able
# to generate PDF and DVI output from the Perl module output.
PERLMOD_LATEX = NO
# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
# nicely formatted so it can be parsed by a human reader.
# This is useful
# if you want to understand what is going on.
# On the other hand, if this
# tag is set to NO the size of the Perl module output will be much smaller
# and Perl will parse it just the same.
PERLMOD_PRETTY = YES
# The names of the make variables in the generated doxyrules.make file
# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
# This is useful so different doxyrules.make files included by the same
# Makefile don't overwrite each other's variables.
PERLMOD_MAKEVAR_PREFIX =
#---------------------------------------------------------------------------
# Configuration options related to the preprocessor
#---------------------------------------------------------------------------
# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
# evaluate all C-preprocessor directives found in the sources and include
# files.
ENABLE_PREPROCESSING = YES
# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
# names in the source code. If set to NO (the default) only conditional
# compilation will be performed. Macro expansion can be done in a controlled
# way by setting EXPAND_ONLY_PREDEF to YES.
MACRO_EXPANSION = NO
# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
# then the macro expansion is limited to the macros specified with the
# PREDEFINED and EXPAND_AS_DEFINED tags.
EXPAND_ONLY_PREDEF = NO
# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
# pointed to by INCLUDE_PATH will be searched when a #include is found.
SEARCH_INCLUDES = YES
# The INCLUDE_PATH tag can be used to specify one or more directories that
# contain include files that are not input files but should be processed by
# the preprocessor.
INCLUDE_PATH =
# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
# patterns (like *.h and *.hpp) to filter out the header-files in the
# directories. If left blank, the patterns specified with FILE_PATTERNS will
# be used.
INCLUDE_FILE_PATTERNS =
# The PREDEFINED tag can be used to specify one or more macro names that
# are defined before the preprocessor is started (similar to the -D option of
# gcc). The argument of the tag is a list of macros of the form: name
# or name=definition (no spaces). If the definition and the = are
# omitted =1 is assumed. To prevent a macro definition from being
# undefined via #undef or recursively expanded use the := operator
# instead of the = operator.
PREDEFINED = gtk \
WITH_THEME_INSTALL
# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
# this tag can be used to specify a list of macro names that should be expanded.
# The macro definition that is found in the sources will be used.
# Use the PREDEFINED tag if you want to use a different macro definition that
# overrules the definition found in the source code.
EXPAND_AS_DEFINED =
# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
# doxygen's preprocessor will remove all references to function-like macros
# that are alone on a line, have an all uppercase name, and do not end with a
# semicolon, because these will confuse the parser if not removed.
SKIP_FUNCTION_MACROS = YES
#---------------------------------------------------------------------------
# Configuration::additions related to external references
#---------------------------------------------------------------------------
# The TAGFILES option can be used to specify one or more tagfiles. For each
# tag file the location of the external documentation should be added. The
# format of a tag file without this location is as follows:
#
# TAGFILES = file1 file2 ...
# Adding location for the tag files is done as follows:
#
# TAGFILES = file1=loc1 "file2 = loc2" ...
# where "loc1" and "loc2" can be relative or absolute paths
# or URLs. Note that each tag file must have a unique name (where the name does
# NOT include the path). If a tag file is not located in the directory in which
# doxygen is run, you must also specify the path to the tagfile here.
TAGFILES =
# When a file name is specified after GENERATE_TAGFILE, doxygen will create
# a tag file that is based on the input files it reads.
GENERATE_TAGFILE =
# If the ALLEXTERNALS tag is set to YES all external classes will be listed
# in the class index. If set to NO only the inherited external classes
# will be listed.
ALLEXTERNALS = NO
# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
# in the modules index. If set to NO, only the current project's groups will
# be listed.
EXTERNAL_GROUPS = YES
# The PERL_PATH should be the absolute path and name of the perl script
# interpreter (i.e. the result of `which perl').
PERL_PATH = /usr/bin/perl
#---------------------------------------------------------------------------
# Configuration options related to the dot tool
#---------------------------------------------------------------------------
# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
# or super classes. Setting the tag to NO turns the diagrams off. Note that
# this option also works with HAVE_DOT disabled, but it is recommended to
# install and use dot, since it yields more powerful graphs.
CLASS_DIAGRAMS = YES
# You can define message sequence charts within doxygen comments using the \msc
# command. Doxygen will then run the mscgen tool (see
# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the
# documentation. The MSCGEN_PATH tag allows you to specify the directory where
# the mscgen tool resides. If left empty the tool is assumed to be found in the
# default search path.
MSCGEN_PATH =
# If set to YES, the inheritance and collaboration graphs will hide
# inheritance and usage relations if the target is undocumented
# or is not a class.
HIDE_UNDOC_RELATIONS = YES
# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
# available from the path. This tool is part of Graphviz, a graph visualization
# toolkit from AT&T and Lucent Bell Labs. The other options in this section
# have no effect if this option is set to NO (the default)
HAVE_DOT = YES
# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is
# allowed to run in parallel. When set to 0 (the default) doxygen will
# base this on the number of processors available in the system. You can set it
# explicitly to a value larger than 0 to get control over the balance
# between CPU load and processing speed.
DOT_NUM_THREADS = 0
# By default doxygen will use the Helvetica font for all dot files that
# doxygen generates. When you want a differently looking font you can specify
# the font name using DOT_FONTNAME. You need to make sure dot is able to find
# the font, which can be done by putting it in a standard location or by setting
# the DOTFONTPATH environment variable or by setting DOT_FONTPATH to the
# directory containing the font.
DOT_FONTNAME = Helvetica
# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs.
# The default size is 10pt.
DOT_FONTSIZE = 10
# By default doxygen will tell dot to use the Helvetica font.
# If you specify a different font using DOT_FONTNAME you can use DOT_FONTPATH to
# set the path where dot can find it.
DOT_FONTPATH =
# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for each documented class showing the direct and
# indirect inheritance relations. Setting this tag to YES will force the
# CLASS_DIAGRAMS tag to NO.
CLASS_GRAPH = YES
# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for each documented class showing the direct and
# indirect implementation dependencies (inheritance, containment, and
# class references variables) of the class with other documented classes.
COLLABORATION_GRAPH = YES
# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for groups, showing the direct groups dependencies
GROUP_GRAPHS = YES
# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
# collaboration diagrams in a style similar to the OMG's Unified Modeling
# Language.
UML_LOOK = NO
# If the UML_LOOK tag is enabled, the fields and methods are shown inside
# the class node. If there are many fields or methods and many nodes the
# graph may become too big to be useful. The UML_LIMIT_NUM_FIELDS
# threshold limits the number of items for each type to make the size more
# managable. Set this to 0 for no limit. Note that the threshold may be
# exceeded by 50% before the limit is enforced.
UML_LIMIT_NUM_FIELDS = 10
# If set to YES, the inheritance and collaboration graphs will show the
# relations between templates and their instances.
TEMPLATE_RELATIONS = NO
# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
# tags are set to YES then doxygen will generate a graph for each documented
# file showing the direct and indirect include dependencies of the file with
# other documented files.
INCLUDE_GRAPH = YES
# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
# documented header file showing the documented files that directly or
# indirectly include this file.
INCLUDED_BY_GRAPH = YES
# If the CALL_GRAPH and HAVE_DOT options are set to YES then
# doxygen will generate a call dependency graph for every global function
# or class method. Note that enabling this option will significantly increase
# the time of a run. So in most cases it will be better to enable call graphs
# for selected functions only using the \callgraph command.
CALL_GRAPH = YES
# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
# doxygen will generate a caller dependency graph for every global function
# or class method. Note that enabling this option will significantly increase
# the time of a run. So in most cases it will be better to enable caller
# graphs for selected functions only using the \callergraph command.
CALLER_GRAPH = NO
# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
# will generate a graphical hierarchy of all classes instead of a textual one.
GRAPHICAL_HIERARCHY = YES
# If the DIRECTORY_GRAPH and HAVE_DOT tags are set to YES
# then doxygen will show the dependencies a directory has on other directories
# in a graphical way. The dependency relations are determined by the #include
# relations between the files in the directories.
DIRECTORY_GRAPH = YES
# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
# generated by dot. Possible values are svg, png, jpg, or gif.
# If left blank png will be used. If you choose svg you need to set
# HTML_FILE_EXTENSION to xhtml in order to make the SVG files
# visible in IE 9+ (other browsers do not have this requirement).
DOT_IMAGE_FORMAT = png
# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
# enable generation of interactive SVG images that allow zooming and panning.
# Note that this requires a modern browser other than Internet Explorer.
# Tested and working are Firefox, Chrome, Safari, and Opera. For IE 9+ you
# need to set HTML_FILE_EXTENSION to xhtml in order to make the SVG files
# visible. Older versions of IE do not have SVG support.
INTERACTIVE_SVG = NO
# The tag DOT_PATH can be used to specify the path where the dot tool can be
# found. If left blank, it is assumed the dot tool can be found in the path.
DOT_PATH =
# The DOTFILE_DIRS tag can be used to specify one or more directories that
# contain dot files that are included in the documentation (see the
# \dotfile command).
DOTFILE_DIRS =
# The MSCFILE_DIRS tag can be used to specify one or more directories that
# contain msc files that are included in the documentation (see the
# \mscfile command).
MSCFILE_DIRS =
# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
# nodes that will be shown in the graph. If the number of nodes in a graph
# becomes larger than this value, doxygen will truncate the graph, which is
# visualized by representing a node as a red box. Note that doxygen if the
# number of direct children of the root node in a graph is already larger than
# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
DOT_GRAPH_MAX_NODES = 50
# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
# graphs generated by dot. A depth value of 3 means that only nodes reachable
# from the root by following a path via at most 3 edges will be shown. Nodes
# that lay further from the root node will be omitted. Note that setting this
# option to 1 or 2 may greatly reduce the computation time needed for large
# code bases. Also note that the size of a graph can be further restricted by
# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
MAX_DOT_GRAPH_DEPTH = 0
# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
# background. This is disabled by default, because dot on Windows does not
# seem to support this out of the box. Warning: Depending on the platform used,
# enabling this option may lead to badly anti-aliased labels on the edges of
# a graph (i.e. they become hard to read).
DOT_TRANSPARENT = NO
# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
# files in one run (i.e. multiple -o and -T options on the command line). This
# makes dot run faster, but since only newer versions of dot (>1.8.10)
# support this, this feature is disabled by default.
DOT_MULTI_TARGETS = YES
# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
# generate a legend page explaining the meaning of the various boxes and
# arrows in the dot generated graphs.
GENERATE_LEGEND = YES
# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
# remove the intermediate dot files that are used to generate
# the various graphs.
DOT_CLEANUP = YES

/contrib/network/netsurf/netsurf/Docs/LIBRARIES
0,0 → 1,51
--------------------------------------------------------------------------------
NetSurf project libraries required 1 July 2012
--------------------------------------------------------------------------------
To build NetSurf, you need the libraries required by the core, and any extra
libraries required by the specific front end you are building.
NetSurf Core
==============
Required:
$ git clone git://git.netsurf-browser.org/buildsystem
$ git clone git://git.netsurf-browser.org/libwapcaplet
$ git clone git://git.netsurf-browser.org/libparserutils
$ git clone git://git.netsurf-browser.org/libhubbub
$ git clone git://git.netsurf-browser.org/libcss
$ git clone git://git.netsurf-browser.org/libdom
$ git clone git://git.netsurf-browser.org/libnsbmp
$ git clone git://git.netsurf-browser.org/libnsgif
Optional:
$ git clone git://git.netsurf-browser.org/libsvgtiny
RISC OS front end
===================
Required:
$ git clone git://git.netsurf-browser.org/libpencil
$ git clone git://git.netsurf-browser.org/rufl
Framebuffer front end
=======================
Required:
$ git clone git://git.netsurf-browser.org/libnsfb
Non RISC OS front ends
========================
Optional:
$ git clone git://git.netsurf-browser.org/librosprite

/contrib/network/netsurf/netsurf/Docs/PACKAGING-GTK
0,0 → 1,86
--------------------------------------------------------------------------------
Packaging suggestions for NetSurf 30 July 2008
--------------------------------------------------------------------------------
This document lays out some suggestions for people interested in packaging
NetSurf for UNIX-like OSes.
We consider the Debian (and thus Ubuntu) packages excellent examples to
crib from. They do everything right.
Building NetSurf
==================
You should change Makefile.config to be specific (rather than rely on AUTO)
for the libraries and functionality you want to include. This will help
your packages be consistent. Also remember that you can turn off
functionality such as PDF export, RISC OS Sprite support, SVG rendering etc.
from here should you require a smaller, lighter build.
Launching NetSurf
===================
The GTK port of NetSurf requires access to some resources at run time.
These are stored in gtk/res/ in the source tree. Some of these files are
symlinks into the !NetSurf directory, which is the application container
for the native RISC OS build. None of the other files from the !NetSurf
directory are required - the symlinks are used only as a way of making
checkouts smaller and making sure changes to one set of resources updates
the other.
The binary that the build system produces is called "nsgtk". There is also
a shell script called "netsurf" that will set up the environment and launch
the nsgtk binary. Do not ship this shell script with your package. It is
included only as a convience for launching NetSurf from the build tree.
Instead, you should move nsgtk to /usr/bin/netsurf (or wherever your
distribution's packaging policy suggests) and copy the contents of
gtk/res/ (dereferencing the symlinks, obviously) to /usr/share/netsurf (or
wherever your packaging policy suggests).
You will need to tell NetSurf where to find its resources. NetSurf searches
three locations by default when trying to load them, in this order:
1. ~/.netsurf/
2. $NETSURFRES/
3. /usr/share/netsurf/
The second one is how the netsurf launcher script controls it. The third
location is controlled by the NETSURF_GTK_RESOURCES option in
Makefile.config, and this is the recommended way for packagers to change
the location it searches, as this still allows the user some flexibility in
changing what NetSurf uses.
User agent string
===================
You may also want to change NetSurf's user agent string to include the
name of your distribution. The user agent string is build by a function
kept in utils/useragent.c - you'll want to change the macro called
NETSURF_UA_FORMAT_STRING. It's processed via sprintf, so keep that in
mind when changing it. The first two printf parameters are major and minor
version numbers, the second two are OS name (uname -s) and architecture
(uname -m). You might want change this to something like:
"NetSurf/%d.%d (%s; %s; Debian GNU/Linux)"
or similar. Please don't be tempted to mention Mozilla or similar - let's
let that lie die.
Home page URL
===============
If the user hasn't specified a home page URL in their Preferences, NetSurf
defaults to a "portal" welcome page at about:netsurf - if you wish to
change this, you can do so by overriding the NETSURF_HOMEPAGE URL in
Makefile.config.
If you make significant changes to NetSurf in your package, please ask your
users to report bugs to your bug tracker, not ours. We'd also be interested
in seeing the diffs for these changes - we may be able to integrate them
to make your job easier in future.

/contrib/network/netsurf/netsurf/Docs/USING-Framebuffer
0,0 → 1,201
--------------------------------------------------------------------------------
Usage Instructions for Framebuffer NetSurf 2nd October 2010
--------------------------------------------------------------------------------
This document provides usage instructions for the Framebuffer version of
NetSurf.
Framebuffer NetSurf has been tested on Ubuntu and Debian.
Overview
========
What it is
----------
The NetSurf framebuffer front end is primarily intended for kiosk
and embedded applications where there is insufficient Operating
System support for a full graphical windowing environment.
The framebuffer frontend features:
* A trivial occluded rectangle window management toolkit
* Font handling system using either:
- A trivial internal monochrome bitmap glyph set.
- An interface to fully anti-aliased glyphs using libfreetype 2
* Uses libnsfb to provide transparent support for:
- Numerous surface providers allowing usage on Linux, X, SDL, VNC
and any mapped linear memory region.
- Surface depths of 8, 16, 24 and 32bpp
- Optimised software plotters for lines, rectangles, polygons,
arbitrary ellipses (including circles), cubic and quadratic
splines, font glyphs and 32bpp RGBA bitmaps.
- Abstracted input handling.
What it is not
--------------
The framebuffer frontend is not a replacement for full native
ports. It lacks functionality and flexibility compared to such
implementations.
Limitations include:
- Single window interface.
- No tabbed interface.
- Expects to control the entire plotting surface.
- No ability to re-size a surface after initialisation.
- Inflexible input character mapping.
- Limited history view.
In addition it should be noted support for some libnsfb surfaces has
been implemented purely for debugging functionality (SDL
especially) and is not intended to replace native surface
handlers.
If a high level windowing system is available then a native NetSurf
frontend is almost certainly a better choice than attempting to use
the framebuffer frontend.
If there is a graphical environment which supports GTK then using
the GTK frontend is a vastly superior choice. The framebuffer
frontend will appear exceptionally limited on such capable systems.
Configuring
===========
Several resources are set at *compile* time and are not changeable at
run time such as the icon bitmaps, the font system to use and what
default surface to use. Refer to the BUILDING-Framebuffer document
for details.
Toolkit Options
---------------
The trivial toolkit has some configuration parameters allowing the
user to alter specific aspects of the UI. All the sizes are in
surface pixels however that is mapped.
fb_furniture_size
This is the size allowed for the scroll bar elements.
fb_toolbar_size
The height of the toolbar.
fb_toolbar_layout
The layout of the toolbar, layout uses a string to define buttons
type and position each character adds an element to the toolbar:
b - back
l - local history
f - forward
s - stop
r - refresh
u - url bar expands to fit remaining space
t - throbber/activity indicator
c - close the current window
The default layout is "blfsrut" there should be no more than a
single url bar entry. If the option is set to the empty string (no
spaces permitted) the toolbar is disabled altogether.
fb_osk
Whether the on screen keyboard should be enabled for input.
Framebuffer Surface
-------------------
There are four command line switches which override compiled in
defaults these are:
-f <handler>
Selects a surface handler to pass to libnsfb instead of the
default. (e.g. x, sdl, mem, linux)
-b <depth>
Selects the pixel depth to pass to libnsfb instead of the
compiled in default. (one of 8, 16, 24, 32)
-w <width>
Selects the surface width to pass to libnsfb instead of the
compiled in default.
-h <height>
Selects the surface height to pass to libnsfb instead of the
compiled in default.
As with any NetSurf frontend run-time configuration is read from a
"Choices-fb" file. This file is a simple key:value list. In addition
to the standard values supported by the NetSurf core there are a
number of values to control specific aspects of the framebuffer
version.
The libnsfb surface parameters are controlled with:
fb_refresh - The refresh rate (for physical displays)
fb_depth - The depth (in bits per pixel) of the surface
fb_device - The path to the device (for physical displays)
fb_input_devpath - The path to the input devices (for linux input layer)
fb_input_glob - The input device selection glob (for linux input layer)
window_width - The width of the framebuffer
window_height - The height of the framebuffer
The defaults are for 800 by 600 pixels at 16bpp and 70Hz refresh rate.
The documentation of libnsfb should be consulted for further
information about supported surfaces and their configuration.
Fonts
-----
If the compile time option is set to use the freetype font system
then several configuration options are available. If the simple
bitmap glyphs are used none of these options apply.
Font faces are provided for the css default styles of sans serif,
serif, monospace, cursive and fantasy. Only the sans serif
non-italic normal weight font is required to exist, If any of the
other faces are missing the sans serif font will be used instead.
The compiled in default font file paths are specified within the
build time Makefile.config. The default faces is the truetype DejaVu
font set in the directory /usr/share/fonts/truetype/ttf-dejavu/
The font glyphs are, by default, rendered as 256 level transparency
which gives excellent visual results even on small font sizes.
The font selection may be changed by placing truetype font files
in the resources path. The resource files will be the generic names
sans_serif.ttf, sans_serif_bold.ttf etc.
The font system is configured at run-time by several options:
fb_font_monochrome
This option causes the renderer to use monochrome glyph
rendering. This method of rendering is much less visually
appealing and while faster to plot it is slower to render.
fb_font_cachesize
This option sets the number of kilobytes of memory set aside for
caching the rendered glyphs. This caching significantly improves
the performance of using the freetype rendering system. It is set
to 2048 by default (2 Megabytes of memory) which impiracle testing
shows to be a suitable value for the seven default faces.
The remaining options control the files to be used for font faces. The
font file name options will override both the compiled in paths and
files found in the resource path.
fb_face_sans_serif - The sans serif face
fb_face_sans_serif_bold - The bold sans serif face
fb_face_sans_serif_italic - The italic sans serif face
fb_face_sans_serif_italic_bold - The bold italic sans serif face.
fb_face_serif - The serif font
fb_face_serif_bold - The bold serif font
fb_face_monospace - The monospaced font
fb_face_monospace_bold - The bold monospaced font
fb_face_cursive - The cursive font
fb_face_fantasy - The fantasy font

/contrib/network/netsurf/netsurf/Docs/USING-Monkey
0,0 → 1,318
--------------------------------------------------------------------------------
Usage Instructions for Monkey NetSurf 13 March 2011
--------------------------------------------------------------------------------
This document provides usage instructions for the Monkey version of
NetSurf.
Monkey NetSurf has been tested on Ubuntu.
Overview
========
What it is
----------
The NetSurf Monkey front end is a developer debug tool used to
test how the core interacts with the user interface. It allows
the developers to profile NetSurf and to interact with the core
directly as though the developer were a front end.
What it is not
--------------
Monkey is not a tool for building web-crawling robots or indeed
anything other than a debug tool for the NetSurf developers.
How to interact with nsmonkey
-----------------------------
In brief, monkey will produce tagged output on stdout and expect
commands on stdin. Windows are numbered and for the most part
tokens are space separated. In some cases (e.g. title or status)
the final element on the output line is a string which might have
spaces embedded within it. As such, output from nsmonkey should be
parsed a token at a time, so that when such a string is encountered,
the parser can stop splitting and return the rest.
Commands to Monkey are namespaced. For example commands related to
browser windows are prefixed by WINDOW.
Top level tags for nsmonkey
---------------------------
QUIT
WINDOW
Top level response tags for nsmonkey
------------------------------------
GENERIC
WARN, ERROR, DIE
WINDOW
DOWNLOAD_WINDOW
SSLCERT
401LOGIN
PLOT
In the below, %something% indicates a substitution made by Monkey.
%url% will be a URL
%id% will be an opaque ID
%n% will be a number
%bool% will be TRUE or FALSE
%str% is a string and will only ever be at the end of an output line.
Warnings, errors etc
--------------------
Warnings (tagged WARN) come from the NetSurf core.
Errors (tagged ERROR) tend to come from Monkey's parsers
Death (tagged DIE) comes from the core and kills Monkey dead.
Commands
========
Generic commands
----------------
QUIT
Cause monkey to quit cleanly.
This will cleanly destroy open windows etc.
Window commands
---------------
WINDOW NEW [%url%]
Create a new browser window, optionally giving the core
a URL to immediately navigate to.
Minimally you will receive a WINDOW NEW WIN %id% response.
WINDOW DESTROY %id%
Destroy the given browser window.
Minimally you will recieve a WINDOW DESTROY WIN %id% response.
WINDOW GO %id% %url% [%url%]
Cause the given browser window to visit the given URL.
Optionally you can give a referrer URL to also use (simulating
a click in the browser on a link).
Minimally you can expect throbber, url etc responses.
WINDOW REDRAW %id% [%num% %num% %num% %num%]
Cause a browser window to redraw. Optionally you can give a
set of coordinates to simulate a partial expose of the window.
Said coordinates are in traditional X0 Y0 X1 Y1 order.
The coordinates are in canvas, not window, coordinates. So you
should take into account the scroll offsets when issuing this
command.
Minimally you can expect redraw start/stop messages and you
can likely expect some number of PLOT results.
WINDOW RELOAD %id%
Cause a browser window to reload its current content.
Expect responses similar to a GO command.
Responses
=========
Generic messages
----------------
GENERIC STARTED
Monkey has started and is ready for commands
GENERIC CLOSING_DOWN
Monkey has been told to shut down and is doing so
GENERIC FINISHED
Monkey has finished and will now exit
GENERIC LAUNCH URL %url%
The core asked monkey to launch the given URL
GENERIC THUMBNAIL URL %url%
The core asked monkey to thumbnail a content without
a window.
GENERIC POLL BLOCKING
Monkey reached a point where it could sleep waiting for
commands or scheduled timeouts. No fetches nor redraws
were pending.
Window messages
---------------
WINDOW NEW WIN %id% FOR %id% CLONE %id% NEWTAB %bool%
The core asked Monkey to open a new window. The IDs for 'FOR' and
'CLONE' are core window IDs, the WIN id is a Monkey window ID.
WINDOW SIZE WIN %id% WIDTH %n% HEIGHT %n%
The window specified has been set to the shown width and height.
WINDOW DESTROY WIN %id%
The core has instructed Monkey to destroy the named window.
WINDOW TITLE WIN %id% STR %str%
The core supplied a titlebar title for the given window.
WINDOW REDRAW WIN %id%
The core asked that Monkey redraw the given window.
WINDOW GET_DIMENSIONS WIN %id% WIDTH %n% HEIGHT %n%
The core asked Monkey what the dimensions of the window are.
Monkey has to respond immediately and returned the supplied width
and height values to the core.
WINDOW NEW_CONTENT WIN %id%
The core has informed Monkey that the named window has a new
content object.
WINDOW NEW_ICON WIN %id%
The core has informed Monkey that the named window hsa a new
icon (favicon) available.
WINDOW START_THROBBER WIN %id%
The core asked Monkey to start the throbber for the named
window. This indicates to the user that the window is busy.
WINDOW STOP_THROBBER WIN %id%
The core asked Monkey to stop the throbber for the named
window. This indicates to the user that the window is finished.
WINDOW SET_SCROLL WIN %id% X %n% Y %n%
The core asked Monkey to set the named window's scroll offsets
to the given X and Y position.
WINDOW UPDATE_BOX WIN %id% X %n% Y %n% WIDTH %n% HEIGHT %n%
The core asked Monkey to redraw the given portion of the content
display. Note these coordinates refer to the content, not the
viewport which Monkey is simulating.
WINDOW UPDATE_EXTENT WIN %id% WIDTH %n% HEIGHT %n%
The core has told us that the content in the given window has a
total width and height as shown. This allows us (along with the
window's width and height) to know the scroll limits.
WINDOW SET_STATUS WIN %id% STR %str%
The core has told us that the given window needs its status bar
updating with the given message.
WINDOW SET_POINTER WIN %id% POINTER %id%
The core has told us to update the mouse pointer for the given
window to the given pointer ID.
WINDOW SET_SCALE WIN %id% SCALE %n%
The core has asked us to scale the given window by the given scale
factor.
WINDOW SET_URL WIN %id% URL %url%
The core has informed us that the given window's URL bar needs
updating to the given url.
WINDOW GET_SCROLL WIN %id% X %n% Y %n%
The core asked Monkey for the scroll offsets. Monkey returned the
numbers shown for the window named.
WINDOW SCROLL_START WIN %id%
The core asked Monkey to scroll the named window to the top/left.
WINDOW POSITION_FRAME WIN %id% X0 %n% Y0 %n% X1 %n% Y1 %n%
The core asked Monkey to position the named window as a frame at
the given coordinates of its parent.
WINDOW SCROLL_VISIBLE WIN %id% X0 %n% Y0 %n% X1 %n% Y1 %n%
The core asked Monkey to scroll the named window until the
indicated box is visible.
WINDOW PLACE_CARET WIN %id% X %n% Y %n% HEIGHT %n%
The core asked Monkey to render a caret in the named window at the
indicated position with the indicated height.
WINDOW REMOVE_CARET WIN %id%
The core asked Monkey to remove any caret in the named window.
WINDOW SCROLL_START WIN %id% X0 %n% Y0 %n% X1 %n% Y1 %n%
The core asked Monkey to scroll the named window to the start of
the given box.
WINDOW SELECT_MENU WIN %id%
The core asked Monkey to produce a selection menu for the named
window.
WINDOW SAVE_LINK WIN %id% URL %url% TITLE %str%
The core asked Monkey to save a link from the given window with
the given URL and anchor title.
WINDOW THUMBNAIL WIN %id% URL %url%
The core asked Monkey to render a thumbnail for the given window
which is currently at the given URL.
WINDOW REDRAW WIN %id% START
WINDOW REDRAW WIN %id% STOP
The core wraps redraws in these messages. Thus PLOT responses can
be allocated to the appropriate window.
Download window messages
------------------------
DOWNLOAD_WINDOW CREATE DWIN %id% WIN %id%
The core asked Monkey to create a download window owned by the
given browser window.
DOWNLOAD_WINDOW DATA DWIN %id% SIZE %n% DATA %str%
The core asked Monkey to update the named download window with
the given byte size and data string.
DOWNLOAD_WINDOW ERROR DWIN %id% ERROR %str%
The core asked Monkey to update the named download window with
the given error message.
DOWNLOAD_WINDOW DONE DWIN %id%
The core asked Monkey to destroy the named download window.
SSL Certificate messages
------------------------
SSLCERT VERIFY CERT %id% URL %url%
The core asked Monkey to say whether or not a given SSL
certificate is OK.
401 Login messages
------------------
401LOGIN OPEN M4 %id% URL %url% REALM %str%
The core asked Monkey to ask for identification for the named
realm at the given URL.
Plotter messages
----------------
Note, Monkey won't clip coordinates, but sometimes the core does.
PLOT CLIP X0 %n% Y0 %n% X1 %n% Y1 %n%
The core asked Monkey to clip plotting to the given clipping
rectangle (X0,Y0) (X1,Y1)
PLOT TEXT X %n% Y %n% STR %str%
The core asked Monkey to plot the given string at the
given coordinates.
PLOT LINE X0 %n% Y0 %n% X1 %n% Y1 %n%
The core asked Monkey to plot a line with the given start
and end coordinates.
PLOT RECT X0 %n% Y0 %n% X1 %n% Y1 %n%
The core asked Monkey to plot a rectangle with the given
coordinates as the corners.
PLOT BITMAP X %n% Y %n% WIDTH %n% HEIGHT %n%
The core asked Monkey to plot a bitmap at the given
coordinates, scaled to the given width/height.

/contrib/network/netsurf/netsurf/Docs/ideas/cache.txt
0,0 → 1,178
Content caching
===============
NetSurf's existing fetch/cache architecture has a number of problems:
1) Content dependencies are not modelled.
2) Content source data for non-shareable contents is duplicated.
3) Detection of content sharability is dependent on Content-Type, which
requires content cloning (which will fail for dependent contents).
4) Detection of cycles in content dependency graphs is not performed
(e.g. content1 includes content2, which includes content1).
5) All content caching is in-memory, there's no offline storage.
Proposal
--------
A split-level cache.
Low-level cache:
+ Responsible for source data (+header) management.
+ Interfaces with low-level fetch system to retrieve data from network.
+ Is responsible for offline storage (if any) of cache objects.
+ Returns opaque handles to low-level cache objects.
+ Handles HTTP redirects, recording URLs encountered when retrieving resource.
+ May perform content-type sniffing (requires usage context)
High-level cache:
+ Responsible for content objects.
+ Tracks content dependencies (and potential cycles).
+ Returns opaque handles to content objects.
+ Manages content sharability & reusability (see below).
+ Contents with unknown types are never shared and thus get unique handles.
+ Content handles <> content objects: they're an indirection mechanism.
Content sharability & reusability
--------------------------------
If a content is shareable, then it may have multiple concurrent users.
Otherwise, it may have at most one user.
If a content is reusable, then it may be retained in the cache for later use
when it has no users. Otherwise, it will be removed from the cache when
it has no users.
Example: retrieving a top-level resource
----------------------------------------
1) Client requests an URL, specifying no parent handle.
2) High-level cache asks low-level cache for low-level handle for URL.
3) Low-level cache looks for appropriate object in its index.
a) it finds one that's not stale and returns its handle
b) it finds only stale entries, or no appropiate entry,
so allocates a new entry, requests a fetch for it,
and returns the handle.
4) High-level cache looks for content objects that are using the low-level
handle.
a) it finds one that's shareable and selects its handle for use.
b) it finds only non-shareable entries, or no appropriate entry,
so allocates a new entry and selects its handle for use.
5) High-level cache registers the parent and client with the selected handle,
then returns the selected handle.
6) Client carries on, happy in the knowledge that a content is available.
Example: retrieving a child resource
------------------------------------
1) Client requests an URL, specifying parent handle.
2) High-level cache searches parent+ancestors for requested URL.
a) it finds the URL, so returns a non-fatal error.
b) it does not find the URL, so proceeds from step 2 of the
top-level resource algorithm.
NOTE: this approach means that shareable contents may have multiple parents.
Handling of contents of unknown type
------------------------------------
Contents of unknown type are, by definition, not shareable. Therefore, each
client will be issued with a different content handle.
Content types are only known once a resource's headers are fetched (or once
the type has been sniffed from the resource's data when the headers are
inconclusive).
As a resource is fetched, users of the resource are informed of the fetch
status. Therefore, the high-level cache is always informed of fetch progress.
Cache clients need not care about this: they are simply interested in
a content's readiness for use.
When the high-level cache is informed of a low-level cache object's type,
it is in a position to determine whether the corresponding content handles
can share a single content object or not.
If it detects that a single content object may be shared by multiple handles,
it simply creates the content object and registers each of the handles as
a user of the content.
If it detects that each handle requires a separate content object, then it
will create a content object for each handle and register the handle as a
user.
This approach requires that clients of the high-level cache get issued with
handles to content objects, rather than content objects (so that the decision
whether to create multiple content objects can be deferred until suitable
information is available).
Handles with no associated content object will act as if they had a content
object that was not ready for use.
A more concrete example
-----------------------
+ bw1 contains html1 which includes css1, css2, img1, img2
+ bw2 contains html2 which includes css1, img1, img2
+ bw3 contains img1
Neither HTML nor CSS contents are shareable.
All shareable contents are requested from the high-level cache
once their type is known.
Low-level cache contains source data for:
1 - html1
2 - html2
3 - css1
4 - css2
5 - img1
6 - img2
High-level cache contains:
Content objects (ll-handle in parentheses):
+ c1 (1 - html1)
+ c2 (2 - html2)
+ c3 (3 - css1)
+ c4 (4 - css2)
+ c5 (5 - img1)
+ c6 (6 - img2)
+ c7 (3 - css1)
Content handles (objects in parentheses):
+ h1 (c1, used by bw1)
+ h2 (c3, used by h1)
+ h3 (c4, used by h1)
+ h4 (c2, used by bw2)
+ h5 (c7, used by h4)
+ h6 (c5, used by h1,h4,bw3)
+ h7 (c6, used by h1,h4)
If img1 was not of known type when requested:
Content handles (objects in parentheses):
+ h1 (c1, used by bw1)
+ h2 (c3, used by h1)
+ h3 (c4, used by h1)
+ h4 (c2, used by bw2)
+ h5 (c7, used by h4)
+ h6 (c5, used by h1)
+ h7 (c6, used by h1,h4)
+ h8 (c5, used by h4)
+ h9 (c5, used by bw3)
This achieves the desired effect that:
+ source data is shared between contents
+ content objects are only created when absolutely necessary
+ content usage/dependency is tracked and cycles avoided
+ offline storage is possible
Achieving this requires the use of indirection objects, but these are expected
to be small in comparison to the content objects / ll-cache objects that they
are indirecting.

/contrib/network/netsurf/netsurf/Docs/ideas/css-engine.txt
0,0 → 1,381
CSS engine
==========
Requirements
------------
+ Parse stylesheets conforming to the forward compatible CSS grammar
(Note that in the short term, the semantic analysis stage only need
support CSS2.1)
+ Stylesheet management/merging (i.e. multiple stylesheets may be added
to a single engine context and thus affect style selection)
+ Be able to select a style for a DOM node based upon the current stylesheets
in the engine context.
+ Implemented as a standalone, reusable, library -- ideally MIT licensed.
Suggested API
-------------
struct css_context;
struct css_style;
struct css_stylesheet;
typedef struct css_context css_context;
typedef struct css_style css_style;
typedef struct css_stylesheet css_stylesheet;
typedef enum css_error {
CSS_OK,
CSS_NOMEM,
/* etc */
} css_error;
typedef enum css_origin {
CSS_ORIGIN_UA,
CSS_ORIGIN_USER,
CSS_ORIGIN_AUTHOR
} css_origin;
#define CSS_MEDIA_SCREEN (1<<0)
#define CSS_MEDIA_PRINT (1<<1)
/* etc */
#define CSS_MEDIA_ALL (0xffffffff)
#define CSS_PSEUDO_CLASS_NONE (0)
#define CSS_PSEUDO_CLASS_LINK (1<<0)
#define CSS_PSEUDO_CLASS_VISITED (1<<1)
#define CSS_PSEUDO_CLASS_HOVER (1<<2)
#define CSS_PSEUDO_CLASS_ACTIVE (1<<3)
#define CSS_PSEUDO_CLASS_FOCUS (1<<4)
typedef enum css_property {
CSS_BACKGROUND_ATTACHMENT,
/* etc */
} css_property;
typedef struct css_value {
css_property property;
union {
css_background_attachment background_attachment;
/* etc */
} value;
} css_value;
typedef css_error (*css_import_handler)(void *pw, const char *url,
css_stylesheet *sheet);
/* Initialise library */
css_error css_init(void);
/* Finalise library */
css_error css_fini(void);
/* Create a stylesheet associated with the given URL,
* specifying the sheet's origin, the media type(s) it applies to and
* a callback routine for fetching imported sheets */
css_stylesheet *css_stylesheet_create(const char *url,
css_origin origin, uint32_t media,
css_import_handler import_callback, void *pw);
/* Destroy a stylesheet */
void css_stylesheet_destroy(css_stylesheet *sheet);
/* Append data to a stylesheet, parsing progressively */
css_error css_stylesheet_append_data(css_stylesheet *sheet,
const uint8_t *data, size_t len);
/* Tell stylesheet parser that there's no more data (will complete parsing) */
css_error css_stylesheet_data_done(css_stylesheet *sheet);
/* Retrieve the URL associated with a stylesheet */
const char *css_stylesheet_get_url(css_stylesheet *sheet);
/* Retrieve the origin of a stylesheet */
css_origin css_stylesheet_get_origin(css_stylesheet *sheet);
/* Retrieve the media type(s) applicable to a stylesheet */
uint32_t css_stylesheet_get_media(css_stylesheet *sheet);
/* Create a selection context */
css_context *css_context_create(void);
/* Destroy a selection context */
void css_context_destroy(css_context *context);
/* Append a top-level stylesheet to a selection context */
css_error css_context_append_sheet(css_context *context,
css_stylesheet *sheet);
/* Insert a top-level stylesheet into a selection context, at the given index */
css_error css_context_insert_sheet(css_context *context,
css_stylesheet *sheet, uint32_t index);
/* Remove a top-level stylesheet from a selection context */
css_error css_context_remove_sheet(css_context *context,
css_stylesheet *sheet);
/* Retrieve the total number of top-level sheets in a selection context */
uint32_t css_context_count_sheets(css_context *context);
/* Get a stylesheet from a selection context given an index [0, count) */
const css_stylesheet *css_context_get_sheet(css_context *context,
uint32_t index);
/* Select a style for a given DOM node with the given pseudo classes active
* and media type.
*
* If the document language contains non-CSS presentational hints (e.g. HTML
* presentational attributes etc), then these are passed in through
* property_list and treated as if they were encountered at the start of the
* author stylesheet with a specificity of 0. */
css_style *css_style_select(css_context *context,
<dom_node_type> *node, uint32_t pseudo_classes, uint32_t media,
css_value **property_list, uint32_t property_list_length);
/* Destroy a selected style */
void css_style_destroy(css_style *style);
/* Retrieve a property value from a style */
css_value *css_value_get(css_style *style, css_property property);
/* Destroy a property value */
void css_value_destroy(css_value *value);
Memory management
-----------------
+ Stylesheets are owned by their creator. Selection contexts reference them.
+ Selection contexts are owned by the client.
+ Selected styles are owned by the client.
+ Property values are owned by the client.
Therefore, the only difficulty lies within the handling of stylesheets
inserted into a selection context. The client code must ensure that a
stylesheet is destroyed after it has been removed from any selection
contexts which are using it.
DOM node types & tree traversal
-------------------------------
This is currently undecided. Either the CSS engine is tied to a DOM
implementation (and makes API calls directly), or it's more generic and
performs API calls through a vtable provided by the client.
Imported stylesheets
--------------------
Imported stylesheets are handled by the CSS engine creating an appropriate
css_stylesheet object for the imported sheet and then asking the client
to fetch the data and append it to the sheet. The imported sheet is then
stored in the sheet that imported it. This effectively creates a tree of
stylesheets beneath the initial top-level sheet created by the client.
Style selection algorithm
-------------------------
css_style_select(context, node, pseudo_classes, media,
property_list, property_list_length):
result = blank_style;
done_props = false;
foreach sheet in context:
# Assumes that sheets are in the order UA, USER, AUTHOR
if !done_props && css_stylesheet_get_origin(sheet) == CSS_ORIGIN_AUTHOR:
fake_rule = fake_rule(node, property_list, property_list_length);
cascade(result, fake_rule, CSS_ORIGIN_AUTHOR);
done_props = true;
process_sheet(sheet, node, pseudo_classes, media, result);
return result;
fake_rule(node, property_list, property_list_length):
rule = (node.name, 0); # Specificity is 0
foreach (property, value, importance) in property_list:
rule[property] = (value, importance);
return rule;
process_sheet(sheet, node, pseudo_classes, media, result):
if (css_stylesheet_get_media(sheet) & media) == 0:
return;
foreach import in sheet:
process_sheet(import, node, pseudo_classes, media, result);
origin = css_stylesheet_get_origin(sheet);
foreach rule in sheet:
if matches_rule(rule, node, pseudo_classes):
cascade(result, rule, origin);
cascade(result, rule, origin):
foreach (property, value, importance) in rule:
insert = false;
if result[property]:
rOrigin = result[property].origin;
rImportance = result[property].importance;
rSpecificity = result[property].specificity;
if rOrigin < origin:
if rImportance == "important":
if rOrigin != CSS_ORIGIN_USER:
insert = true;
else:
insert = true;
else if rOrigin == origin:
if rImportance == "" && importance == "important":
if rOrigin == CSS_ORIGIN_UA:
if rSpecificity <= rule.specificity:
insert = true;
else:
insert = true;
else if rImportance == "important" && importance == "":
if rOrigin == CSS_ORIGIN_UA:
if rSpecificity <= rule.specificity:
insert = true;
else:
if rSpecificity <= rule.specificity:
insert = true;
else:
if origin == CSS_ORIGIN_USER && importance == "important":
insert = true;
else:
insert = true;
if insert:
result[property] = (value, origin, importance, rule.specificity);
Outstanding issues
------------------
+ Parsing/selection quirks.
Probably as an argument to css_stylesheet_create() and possibly
css_style_select(). This could either take the form of a blanket
full/almost/not quirks mode flag or be more granular and permit the
toggling of individual quirks.
References:
+ http://developer.mozilla.org/en/docs/Mozilla_Quirks_Mode_Behavior
+ http://www.opera.com/docs/specs/doctype/
+ http://www.quirksmode.org/css/quirksmode.html
+ http://www.cs.tut.fi/~jkorpela/quirks-mode.html
+ Grep WebKit sources for inCompatMode()
+ The :lang pseudo-class
Need to pass the current language string into css_style_select()
+ Pseudo-elements
Probably as an argument to css_style_select(). Most likely a bitfield
like the way in which pseudo-classes are handled.
The inheritance model of :first-line and :first-letter is such that:
+ css_style_select() must begin with a blank style and not the
parent node's style
+ an API for cascading one style onto another is needed
This is because pseudo-elements may be nested inside children of the
node to which they are logically connected. e.g.:
<div>
<p>
first paragraph
</p>
</div>
is logically equivalent to
<div>
<p>
<div:first-line>
<p:first-line>
first paragraph
</p:first-line>
</div:first-line>
</p>
</div>
so the actual cascade order is only known at the time the render tree is
built. Note that, courtesy of scripting, the location of pseudo-elements
can move around (e.g. if some text was inserted just before the <p> within
the div, above, then <div:first-line> would move). Additionally, the actual
content that pseudo-elements apply to can change due to reflow.
Pseudo-elements may also affect the processing of inline boxes. e.g.:
<p>
<span>foo bar baz bat</span>
</p>
becomes (logically):
<p>
<p:first-line>
<span>foo bar baz </span>
</p:first-line>
<span>bat</span>
</p>
In terms of interaction between pseudo-elements, :first-letter inherits
from :first-line e.g.:
<p>
first line
second line
</p>
becomes (logically):
<p>
<p:first-line>
<p:first-letter>
f
</p:first-letter>
irst line
</p:first-line>
second line
</p>
:first-line and :first-letter apply to the relevant content _including_ any
text inserted using :before and :after.
List of CSS 3 pseudo-elements:
+ :(:)?first-line
+ :(:)?first-letter
+ :(:)?before
+ :(:)?after
+ ::selection
+ ::footnote-call
+ ::footnote-marker
+ ::before-page-break
+ ::after-page-break
+ ::line-number-left
+ ::line-number-right
+ ::line-number-inside
+ ::line-number-outside
+ ::slot()
+ ::value
+ ::choices
+ ::repeat-item
+ ::repeat-index
+ ::marker
+ ::outside
+ ::alternate
+ ::line-marker
References:
+ CSS 2.1 $$5.12 and $$12.1
+ Stylesheet charset handling
An embedded stylesheet shares the charset of the containing document.
The charset of a stand-alone stylesheet can be specified by (in order of
priority, highest -> lowest):
+ the transport layer
+ a BOM and/or @charset at the immediate start of the sheet
+ <link charset=""> or other metadata from the linking mechanism
+ charset of referring stylesheet or document
+ assuming UTF-8
The API currently has no way of conveying the first, third, or fourth of
these to the engine. This can be realised through the addition of a
parameter to css_stylesheet_create()
CSS 2.1 $4.4 specifies that a stylesheet's transport encoding must be a
superset of US-ASCII.
The internal encoding will be UTF-8.
All strings passed in by the client are assumed to be UTF-8 encoded.
Strings retrieved from DOM nodes are assumed to be UTF-8 encoded.

/contrib/network/netsurf/netsurf/Docs/ideas/render-library.txt
0,0 → 1,121
Rendering library
=================
General notes
-------------
+ Potentially long-running routines probably want to exit early and
ask to be resumed (or similar)
+ There's loads of stuff missing from here (like a typesystem :)
Possible API
------------
/* Initialise library */
error html_init(void);
/* Finalise library */
error html_fini(void);
/* Create a context */
ctx html_create(void);
/* Destroy a context */
void html_destroy(ctx);
/* Configure a context
*
* Things that need configuring:
*
* Callbacks from library -> client:
*
* + Handler for embedded object fetch requests (how to handle frames?)
* + Event notification handler (e.g. form submission / link navigation,
* mouse pointer shape changing, redraw request, position caret, etc)
*
* Other stuff:
*
* + Scale? (should this be handled by the client?)
* + Whether to run scripts? (possibly, not needed yet)
*/
error html_setopt(ctx, opttype, optparams);
/* Feed HTML data to a context */
error html_process_data(ctx, data, len);
/* Flag end of data to context */
error html_data_done(ctx);
/* Reflow context, to given width/height */
error html_reflow(ctx, width, height);
/* Redraw context, using provided plotters */
error html_redraw(ctx, rect, plot_table);
/* Some kind of input event notification APIs.
* These are called by the client to notify the library
* that something's happened.
*
* e.g.:
*/
error html_mouse_move(ctx, x, y);
error html_mouse_press(ctx, x, y, buttons, modifiers);
error html_mouse_release(ctx, x, y, buttons, modifiers);
error html_key_press(ctx, key, modifiers);
error html_key_release(ctx, key, modifiers);
error html_scroll_x(ctx, offset);
error html_scroll_y(ctx, offset);
/* Retrieve properties of document in context
*
* e.g.:
*/
error html_get_title(ctx, title);
Example usage
-------------
/* Main routine */
main:
/* Initialise library */
html_init();
/* Create a context */
ctx = html_create();
/* Configure the context */
html_setopt(ctx, FETCH_HANDLER, my_fetcher);
html_setopt(ctx, EVENT_HANDLER, my_event_handler);
/* Get it to process data */
foreach (chunk, len) in data:
html_process_data(ctx, chunk, len);
html_data_done(ctx);
/* Reflow content to desired dimensions */
html_reflow(ctx, width, height);
/* Main client event loop -- processes UI-toolkit events */
do:
on mouse event:
html_mouse_{move,press,release}(ctx, event.x, event.y ...);
on key event:
html_key_{press,release}{ctx, event.key, event.modifiers);
on scroll event:
html_scroll_{x,y}(ctx, event.offset);
on redraw event:
html_redraw(ctx, event.rect, my_plotters);
until quit;
/* Destroy context */
html_destroy(ctx);
/* Finalise library */
html_fini();
/* Event handler for library-generated events */
my_event_handler:
on pointer shape change:
set_pointer_shape(shape);
on redraw request:
redraw_window(window);
on position caret:
position caret(x, y);