JpGraph makes it easy to draw both "quick and dirty" graphs with a minimum of code and complex professional graphs which requires a very fine grain control.
The library assigns context sensitive default values for most of the parameters which minimizes the learning curve. The features are there when you need it - they dont get in your way. The JpGraph library also comes wih very extensive documentation.
Main features:
- Web-friendly, average image size for a 300*200 image is around 2K and images are seldomly bigger than 4-5K
- Support for both GD1 and GD2 The library will autodetect which library is installed.
- Automatic generation of client side image maps to make it possible to generate drill-down graphs.
- Advanced interpolation with cubic splines to get smooth curves from just a few data points.
- Advanced support to add text to images with multi-line paragraphs and formatting support in several TTF fonts.
- Support for alpha blending
- has over 200+ built in Country flags
- Support automatic timing of images.
- Supports adding arbitrary lines and filled areas (with patterns) to plots
- Supports several plot types,spider-plots, pie-charts (both 2d and 3d) , scatter-plots, line-plots, filled line-plots, accumulated line-plots, bar plots, accumulated bar plots, grouped bar plots, error plots, line error plots, box plots, stock plots
- Supports advanced Gantt-charts (ex1, ex2)
- Flexible scales, supports text-lin, text-log, lin-lin, lin-log, log-lin and log-log
- Supports integer scale (labels are restricted to integers).
- Supports both PNG, GIF and JPG graphic formats. and can automatically choose the best available graphic format. Note that the available formats are dependent on the specific PHP installation where the library is used.
- Support various layout with a background image behind the plot
- Supports horizontal bar graphs
- Supports scientific plots
- More than 400 named colors
- Several possible axis positions
- Supports caching (with timeout) of generated graphs to lessen burden of a HTTP server.
- Intelligent autoscaling which gravitates towards aesthetical values.
- Fully supports manual scaling, with fine grain control of position of ticks
- Several different fill styles for line plots
- Supports up to two different y-scales, it is possible to have different left and right y-scale and add plots to both
- Supports unlimited number of plots in each graph, makes it easy to compose complex graph which consists of several plot types
- Designed as a flexible OO framework which makes it easy to add new types of plots
- Supports anti-aliasing of lines, more ...
- Supports color-gradient fill for bar graphs
- Supports automatic legend generation with user supplied format.
- Supports both vertical and horizontal grids (with image depth specification)
- Supports both on-the fly image generation and batch processing.
- Includes graph module to make it very easy to draw arbitrary shapes using custom scale on a canvas including Bezier-curves with full support for all the features of JpGraph (including caching and timeout).x
- Barcode generation The professional version includes a Barcode module that makes it easy to generate barcodes in all commonly used symbologies.
- Designed modularly - you dont have to include code which isnt used. JpGraph Architecture Block diagram
- extensive documentation with both a 150 pages tutorial and an extensive class reference.
- ... and many, many more features
Enhancements:
- This release follows the PHP4 version with functionality and defect fixes.
- 7x4 LED-like displays have been added.
- A long-standing issue with user-defined pie colors and legends has been fixed.
- There are various bugfixes.

Magpy is a Python wrapper for the mg search engine.
magpy module features fast full text sarch, indexing and boolean queries.
Both mg and magpy are released under the GPL (General Public License).
Installation:
To install magpy from source, extract the archive magpy-*.tar.gz, and run the following commands:
./configure
python setup.py build
python setup.py install
Usage:
The following script demonstrates a simple search frontend:
#!/usr/bin/python
import mgindexer
import mgquery
import sys
store = mgquery.MGSearchStore("/tmp/data","alice")
while 1:
query = sys.stdin.readline()
q = store.newQuery(query)
print "Searching for",query,"(words",q.words(),")"
for docnum,ranking in q.execute():
print "Document",docnum,"matches (Ranking",ranking,")"
Before this works, you first have to create search store at (here) the location
"/tmp/data", with the name "alice".
The following script creates such a store from a raw text file, which it splits into individual documents by splitting it into paragraphs.
#!/usr/bin/python
import mgindexer
fi = open("alice13a.txt", "rb")
fo = open("alice13a.splitted.txt", "wb")
for line in fi.readlines():
# split the file on the paragraph boundaries
if line.strip() == "":
fo.write(mgindexer.SEPARATOR)
else:
fo.write(line)
fo.close()
fi.close()
mgindexer.makeindex("alice13a.splitted.txt", "/tmp/data/", "alice")
If you have many individual documents you would like to run a search on, the following script is probably closer to what you need (notice it creates a new collection of the name "files", so you have to substitute "alice" by "files" in the example query script above):
#!/usr/bin/python
import mgindexer
import os
PATH = "files/"
fo = open("searchdata.txt", "wb")
for file in os.listdir(PATH):
if os.path.isfile(PATH + file):
# copy file
fi = open(PATH + file, "rb")
for line in fi.readlines():
fo.write(line)
# write document boundary
fo.write(mgindexer.SEPARATOR)
fo.close()
mgindexer.makeindex("searchdata.txt", "/tmp/data", "files")
Enhancements:
- This release adds support for wildcard search (truncation).
- Document types that have delimiters different from whitespace are now supported.

HTMLpage is a text-based HTML editor. It can use dragndrop to generate hyperlinks and image tags with relative links and image sizes. It allows you to create a table by highlighting and copying a table from a document, pasting it into HTMLpage, and then clicking TABLE-ify.
It will turn the comma-delimited data into a nice neat HTML table. Plain text can be converted to HTML. It also features spell-checking, color tag generation from a color picker, and keyboard shortcuts for several common HTML tags.
Main features:
- It can generate image tags and hyperlinks via Drag N Drop
- Convert simple text passages to HTML, basically giving you proper line breaks and paragraph indentation, along with generating Link tags from any URLs you may have included. HTML-ify works on selected text, as does the TABLE-ify, listed below.
- Convert tab-delimited info into an HTML table (meaning you can copy a table from a document or Web page, paste it into HTMLpage, the TABLE-ify it to generate a simple, neat HTML table.) Will also turn URLs into links.
- Can accommodate multi-line table-cell info.
- Spell checking on text selections/passages
- Insert HTML color codes via a color dialog
- Has search, go to line and page-wide replace functions.
- Date insertion. For example: Saturday, 08/20/2005
Enhancements:
- A tag generation issue with images where when implementing MIME types, images made HREFs instead of image tags was fixed.
- pyGTK 2.6 is now used.
- Deprecation warnings were removed.

Text::MetaMarkup::HTML is a MM-to-HTML converter.

SYNOPSIS

use Text::MetaMarkup::HTML;
print Text::MetaMarkup::HTML->new->parse(file => $filename);

This module extends Text::MetaMarkup and converts the parsed document to HTML.

Text::MetaMarkup::HTML adds special support for the following tags:

Paragraph tag style

Its contents are not subject to escaping and inline tag interpolation.

EXAMPLE

Input

h1: Example

This is just {i:an {b:example}}.

* foo
* bar
* baz

Output

< h1 >Example< /h1 >

< p >This is just < i >an < b >example< /b >< /i >.

< ol >< li >foo< /i >
< li >bar< /li >
< li >baz< /li >< /ol >

Nasal is a language that I wrote for use in a personal project. Ostensibly it was because I was frustrated with the dearth of small-but-complete embeddable scripting languages, but of course I really wrote it because it was fun.
It is still young and incomplete in a few places, but is under active development and has been integrated as the extension language for the FlightGear simulator.
Documentation is still sparse. There is a design document available, which talks at length about the "whys" behind the design of Nasal and includes documentation for the built-in library functions.
More useful to the experienced programmer is the tutorial-style sample code, which explains and demonstrates all the syntax features of the language.
Like perl, python and javascript, nasal uses vectors (expandable arrays) and hash tables as its native data format. This is a well-understood idiom, and it works very well. I felt no need to rock the boat here.
Like perl, and unlike everything else, nasal combines numbers and strings into a single "scalar" datatype. No conversion needs to happen in user code, which simplifies common string handling tasks.
Like perl, but unlike python, hash keys must by scalars in nasal. Python supports a "tuple" constant type that can be used as well, but there is no equivalent in nasal (you cant use vectors as keys because they might change after the insertion).
Like perl and python, nasal uses a # character to indicate and end-of-line comment. There is no multiline begin/end comment syntax as in Javascript.
Like perl, nasal functions do not have named parameters. They get their arguments in a vector named "arg", and can extract them however they like. Unlike perl, Nasal takes advantage of this feature to do away with function "declaration" entirly; see below.
Like python, there is no hidden local object scope in a function call. The object on which a method was called is available to a function as a local variable named "me" (python calls this "self" by convention, but because nasal has no declared function arguments, there is no opportunity to change it).
Like perl, "objects" in nasal are simply hash tables. Looking an item up by name in a hash table and extracting a symbol for an object are just different syntax for the same operation (but read on for an important exception):
a["b"] = 1 means the same thing as: a.b = 1
The above paragraph is a minor lie. The "dot" syntax is also the clue to the interpreter to "save" the left hand side as the "me" reference if the expression is used as a function/method call. That is, these expressions are not equivalent (one is a plain function call, the other a method invocation on the object "a"):
a["b"](arg1, arg2) isnt the same as: a.b(arg1, arg2)
Like javascript, nasal lacks a specific "class" syntax for OOP programming. Instead, classes are simply objects. Each object supports a "parents" member array; symbol lookup on the object at runtime bounces to the parents (and the parents parents) if the symbol is not found in the hash. The parents field is just like any other object field, you can set it however you like and even change it at runtime if you are feeling especially perverse.
Like lisp, javascript and perl, nasal supports lexical closures. This means that the local symbol namespace available to your function when it is assigned remain constant over time. If you dont know what this means, you dont need to care. It is this feature that allows functions to use variables declared in the outer scope when it is defined (e.g. seeing "module" variables).
Like all other scripting languages, functions are just symbols in a namespace, but unlike all other scripting languages, there is no function "declaration" syntax. A function is always an anonymous object (a "lambda," in the parlance), which you assign to a variable in order to use. Like so:
myfunction = func { arg[0] + 1 }
myfunction(1); # returns 2
One annoyance of this feature is that Nasal functions dont have unique internal "names". So a debugging or exception stack trace can only give you a source line number, and not a function name as reference.
Nasal has a straightforward, readable syntax which is closest to javascript among other scripting languages. Like later versions of javascript, it includes has a hash lookup syntax as well as an object field accessor syntax (that is, you can do both a.b and a["b"]).
Unlike python, nasal has a grammar which is not whitespace-sensitive. This doesnt make python hard to write, and it arguably makes it easier to read. But it is different from the way the rest of the world works, and makes python distinctly unsuitable for "inline" environments (consider PHP, Javascript, ASP or in-configuration-file scripts) where it needs to live as a plain old string inside of another programs code or data file.
Nasal garbage collects runtime storage, so the programmer need not worry about manual allocation, or even circular references. The current implementation is a simple mark/sweep collector, which should be acceptable for most applications. Future enhancements will include a "return early" capability for latency-critical applications. The collector can be instructred to return after a certain maximum delay, and be restarted later. Fancy items like generational collectors fail the "small and simple" criteria and are not likely to be included.
Like python, nasal supports exception handling as a first-class language feature, with built-in runtime-inspectable stack trace. Rather like perl, however, there is no special "try" syntax for exception handling, nor inheritance-based catching semantics. Instead, you call a "try" function on another function, and inspect the return value on your own. Code simply calls die with an argument list, which is returned from the closest enclosing try() invocation. Elaborate exception handling isnt really appropriate for embedded scripting languages. [NOTE: this isnt finished yet]
Nasal tries to be stricter than perl. Operations like converting a non-numeric string value to a number, reading or writing past the end of an array or operating on a nil reference, which are generally legal in perl, throw exceptions in nasal. Perl sometimes bends over backwards to do something "reasonable" with your instructions (e.g. whats the boolean truth value of a hash reference?); nasal doesnt try ("error: non-scalar used in boolean context at line 92")
Nasal is very small, very simple, written in ANSI C, and generally an excellent choice for embedded applications. It uses a simple and transparent syntax interpretable by a simple "bracket matching and operator precedence" parser. It does not depend on any third party libraries other than the standard C library. It does not depend on third party tools like (f)lex and yacc/bison. It builds simply and easily, supports a reasonably simple extension API and cohabitates well with other code.
Nasal makes no use of the processor stack when running recursive code. This is important for embedded languages as it provides the ability to "exit early" from a Nasal context. An outside application may have realtime constraints, and Nasal can be instructed to run for only a certain number of "cycles" before returning. Later calls will automatically pick up the interpreter state where it left off.
Nasal provides "minimal threadsafety". Multithreaded operations on Nasal objects are safe in the sense that they cannot crash or corrupt the interpreter. They are not guaranteed to be atomic. In particular, poorly synchronized insertions into containers can "drop" objects into oblivion (which is OK from an interpreter stability standpoint, since the GC will clean them up normally). Race conditions have to be the programmers problem anyway, this is just another symptom. Garbage collection will block all threads before running. [NOTE: this part is still unimplemented.]
Enhancements:
- This release contains the updates that have been available in SimGear for some time now.
- Important new functionality includes bugfixes, many performance enhancements, a declared function argument syntax, a ternary (?:) operator, indexable and mutable string objects, interpreter thread safety features, and much work to the "standard" library (including stdio, bitfields, Unix system calls, and PCRE regular expressions).

dotBook reader is a reader for HTML books in .jar and .zip files.

The dotBook application will be a book reader that can download, display and cache books in a special JAR file format.

The format will allow digital signatures with PGP and allow books to have chapters and paragraphs that can be found conveniently from within the application but will link sources outside books by opening the default web browser. Book pages will be HTML pages with some restrictions.

Design Goals

The goal is to have an XML descriptor format to be stored outside the book (JAR file) and an XML content format to be stored inside the JAR file. A compound format that allows to combine descriptor, JAR file and signatures in a single file is being considered. Reading the descriptor should be very easy and not require to read the JAR file, so the JAR file will possibly be compressed and appended to the uncompressed descriptor.

The book layout will honor CSS PrintLayouts.

The XML content will allow for imprints following an independent specification for XML imprints, factored out from the esp.nongnu.org project.

The dotBook editor will allow to edit a limited subset of the MediaWiki syntax and a subset of HTML.

The format is intended to be useful on e-Paper devices that can hibernate between turning pages. A sequential page order will be encouraged, while still allowing to set anchors and links inside pages. Animated content will be discouraged: It will probably only be animated on user request. That means all animated images will be replaced by empty boxes with the text "Animation : [play]" inside, if no still image is provided to take the place.

Grisbi is a personnal accounting application running under GNU/Linux.

Our aim is to provide you with the most simple and intuitive software for basic use, and still very powerful if you spend a little time on the setup.

Grisbi can manage multiple accounts, currencies and users. It manages third party, expenditure and receipt categories, as well as budgetary lines, financial years, and other informations that makes it quite adapted for associations (except those that require double entry accounting). The exhaustive list of Grisbis functionalities can be found in the Users guide, paragraph 1.2.

The complete manual under FDL license is avaliable on line (Documentation in the main menu). The version coming with the software is not illustrated, but can be replaced by the illustrated version any time, being availiable for download on this site. The manual will be soon completed with a Guide concerning accounting for associations.

If you want to keep updated with Grisbi releases, you may subscribe to the information mailing list (see Contacts) and if you like to live dangerously you even can download the unstable sources from CVS and compile them. Information about this is in the Manual paragraph 2.1.11.

Last but not least, Grisbi will be soon internationalised. All contributors are welcome.

Annotate project is a tool which makes DocBook documents annotatable.

It enables visitors to an online version of a DocBook document to add comments to any paragraph or chapter of the document.

It extends the DocBook XSL stylesheets, leading to modified HTML output which contains anchors at those places where annotations can be made.

Comments and notes are stored in a DBMS.

A CGI program then merges the HTML document and the comments to produce the output for the visitor.