Ringlord Technologies Products
$VER: Product-Info_Specification 8.0 (23.3.96)

			Product-Info Specification
				Version 8
			      March 23, 1996

	A 'Product-Info' should accompany every released product: software,
	images,  animation, sound, etc. The  purpose of a 'Product-Info' is
	to describe a product in a way that  is reasonably complete so that
	a  customer can perform searches  on a collection of 'Product-Info'
	files (records) with a reasonable  expectation  of locating desired
	products or excluding undesired ones.  The structure of the data is
	designed so that a search can be defined with some certainty of its

	By providing a well-written 'Product-Info'  with  your product, you
	assure yourself of maximum  potential exposure to customers who are
	looking to fill a need that your product might fill.

	This document is aimed both at the developer of a product who needs
	to write an effective and  complete Product-Info, as well as at the
	customer  who  stands  a better  chance   of locating  satisfactory
	products  without having to  wade  through an inordinate  amount of
	irrelevant products, if she understands what a Product-Info offers.

	If  you are not a developer,  you   may  want to  skip  down to the

	The   'Product-Info' specification is  free of   copyrights and  is
	freely distributable and available for  use by  any  individual  or
	organization that  honors  the basic ideas   of this  document:  to
	provide a fairly concise and relatively burden-free description for
	a product.

	The  'Product-Info' specification  was  designed by Udo  Schuermann
	<walrus@RingLord.com> with initial design criteria and much feedback
	offered   by   Fred   Fish  <fnf@ninemoons.com>  and   Richard Fish
	<rjf@ninemoons.com> Support for  'Product-Info' files   was   first
	offered in the form of my product "KingFisher  Release 2", which is
	available on Aminet, nearly all of the Fish  CD-ROMs for the Amiga,
	and  from   the  KingFisher  home  page  on  the  World  Wide  Web:
	KingFisher 2

	A 'Product-Info' is a set of information stored in a file with your
	project.  There are three standard filenames which you can use (the
	quotes are not part of the name):

	     1.	"Product-Info"

	     2. ".Product-Info" (note the leading period)

	     3.	"project.pi" ("project" would be replaced by your project's
		name; example: "KingFisher.pi" or "DiskSalv.pi" or "VT.pi"

	The file must conform to the following rules:

	     1.	The file may begin with comment line, but  is  not required
		to do so. A comment is either a blank line (one that has no
		text, no blank spaces, no tabs) or a line  beginning with a
		`'#'  (hash) symbol.  Any  combination  of these  will   be
		ignored at the BEGINNING of the file.

	     2.  The first  field (following the  optional comments) in the
		'Product-Info' must be "name";  Fields are identified by  a
		Field Identifier  and followed by   their  contents.  Field
		contents are ended when another field  is encountered or by
		the end of file.

	     3.	A Field Identifier begins with a "."  (dot, period)  as the
		first character on a line, immediately followed by the name
		of the field. The  "name" field  is identified by  ".name";
		The name of the field is separated  from the field contents
		by a white space.  White space is a blank, a tab, or a new-
		line. It is recommended to use a newline, rather than space
		or tab. A field name cannot contain white space, obviously.

	     4.	The contents of the field   may span  one or more  physical
		lines  in the file.  Some fields   ignore anything past the
		first newline; others  will ignore newlines and  treat them
		as if they were a  normal blank space; other fields require
		newlines to separate sub-components from each other.  It is
		the  purpose of the file  you are currently reading to tell
		you the meaning of each of the defined fields.

	     5. A collection of  fields (beginning  with the  "name" field)
		represents a Product-Info record. A record is terminated by
		the end of file, by the presence of a blank line containing
		a  ^N  (control-N) symbol,  or by the  presence  of another
		"name" field.  Thus, a 'Product-Info' may store information
		for  more than a  single project, although this practice is
		in general not  encouraged. This feature is  used, however,
		for the  construction of variant-record-size databases such
		as used by  KingFisher,  but these are  not  a distribution
		format that go along with a project. That's the difference.

	     6.	Field names and field  contents should use  the ISO Latin 1
		character set which  is the default  of the World Wide  Web
		and also the standard of the Amiga computer.  The character
		^N (ctrl-n) is reserved as a  separator  between disks in a
		database of collected  records, should this  be a desirable

	     7.	If,  in  the contents of  a field, a  physical line of text
		begins   with a period     (such  as  ".guide    files  are
		provided...")  then the  period  should have a  "\"  symbol
		added before  the   period,  as  in   "\.guide  files   are
		provided..."  to prevent the  line  to be interpreted  as a
		new field ("GUIDE")  with the  contents starting as  "files
		are provided..."  In general, it is permitted to "escape" a
		period in this manner anywhere in a field's contents.

	     8.  A backslash  ("\")  is represented  by  placing \\  in the
		contents  of a field. This  permits  special layout control
		sequences to be introduced through the \ key, much like the
		"\."   suppresses  the interpretation   of  a  line-leading
		period as the introducer for a field name.

	     9.	Field name identifiers are not case sensitive.

	The 'Product-Info' format was designed with future extensibility in
	mind. Being a text-only format,  it lends itself to alteration with
	any   editor of your preference.    Its method  of  defining fields
	permits it to be adjusted and expanded to meet future requirements,
	and it is not  tied to any particular  implementation to facilitate

	The following fields have been added since the widely  spread v6 of
	the   'Product-Info'  specification:  "aminet-dir",  "aminet-file",
	"url", "keywords",  and "execute"; some other fields  have suffered
	some slight modifications: "author", "reference", and "installsize"
	with the aim to bring the fields in line with original intent. Also
	added or changed:  \>  \<  \N  \#  sequences in field contents.

	I believe it  useful  to provide the following information specific
	to KingFisher's implementation of  'Product-Info'  support, as  the
	databases and software are widely available on CD-ROM:

	     1.	A  KingFisher database is described by  a .kfdb file, whose
		(textual) contents  describes  the filenames containing the
		actual database records, the files  used for indexing these
		database  files,  as  well  as   some   other,  less  vital

	     2.	A database consists of zero or more records spread over one
		or more files  and is  indexed by a single  (primary) index
		file.  Although KingFisher  supports the format of (and  is
		shipped with) the original KingFisher  1 database, it  does
		not  support adding such  records to an  existing database:
		The new format has a header to identify and distinguish the
		new format.  The header is 8  characters (KF20DATA)  plus a
		newline character.  Index files are similarly identified by
		a KF20INDX header plus other information.

	     3.	Records collected from 'Product-Info' files and stored into
		a database are  stripped  of  their  comments to   preserve

	     4.	As index files  may  become  corrupted  or  lost, a special
		marker   symbol is inserted  on   a line by itself  between
		disks. This permits KingFisher to keep track of the disk on
		which a given item  is stored and recover this  information
		effortlessly if the index needs  to be rebuilt.  KingFisher
		1 used a  blank line  between 2-line records;  KingFisher 2
		uses a line with a single ^N (ctrl-n) symbol on it.

	     5.	A record  begins with  a "name"  field  and continues until
		another "name" field is encountered.

	     6.	The efficient  storage of variable-size records brings with
		it the  problem    of  very  costly    insert  and  removal
		algorithms.  KingFisher  offers  only truncation and append
		methods for this reason.

	     7.	If a text file being imported (appended) to a database does
		not begin with a "name" field (nor  comments) but the first
		line is less  than  30 characters long, KingFisher will try
		to parse the  file looking for a "name"  field anyway, even
		though DATA TRANSPORT MARKERS (see next section, "Exporting
		and Importing Data") should have been used.  This is a non-
		standard  extension on  this  specification  to  facilitate
		support for the old KingFisher 1 database format.

	This   ends the  section  on  KingFisher's  implementation  of  the
	'Product-Info' standard.

	To enable effortless  and error-free methods for  export and import
	of 'Product-Info' records, it  is required  to enclose records with
	'PRODUCT-INFO' FILES; they are  used only when  unrelated text (and
	comments) surrounds a 'Product-Info' file!

	Multiple DATA  TRANSPORT  MARKERS may be used in  a single text, so
	that each  'Product-Info' record is  enclosed; or one pair of these
	markers may enclose multiple, consecutive 'Product-Info' records:

	EXAMPLE: The following examples are  to be  read as complete  files
	         between the lines that look like this: ---------------

	Example 1:  A file  containing   text  in addition  to the database

	Hello, Joe.  Here is the description of that weird game
	I was telling you about.  See if you can figure out how
	to win this.  Good luck!

	KingKong Industries
	Lure the love struck monster ape back to his island.
	Tools include Fay Wray's torn nightgown, a Fokker
	airplane (you get to pilot it), a compass and a map.
	\.png image support lets you paint your own airplane

	Example 2:  A  file containing  nothing but two   database records.
	            Notice that  the  DATA TRANSPORT MARKERS are omitted in
	            this case, as they are unnecessary.   It would not hurt
	            to place them there, however!

	KingKong Industries
	Lure the love struck monster ape back to his island.
	Tools include Fay Wray's torn nightgown, a Fokker
	airplane (you get to pilot it), a compass and a map.
	\.png image support lets you paint your own airplane
	MonkeyCommand II
	KingKong Industries
	Keep the captured ape from assaulting the defenses
	of the prison that was erected at the conclusion of
	MonkeyCommand I.  The game consists of coordinating
	the actions of four native tribal leaders and their
	vassals in repairing the damage done by the enraged
	monster ape as it tries to escape and revenge itself
	on whoever won the original MonkeyCommand.

	Example 3: A file containing two database records interspersed with
	           extraneous text.   The records   are  protected by  DATA
	Hi Tom,

	Remember that monkey game you told my about?

	KingKong Industries
	Lure the love struck monster ape back to his island.
	Tools include Fay Wray's torn nightgown, a Fokker
	airplane (you get to pilot it), a compass and a map.
	\.png image support lets you paint your own airplane

	Well, seems that one wasn't enough and they released
	another one.  We'll have to figure out how to finally
	beat the first one, it seems, before they let us play
	the next.  Maybe we can look through the binary to find
	that code phrase.  Here's the text:

	MonkeyCommand II
	KingKong Industries
	Keep the captured ape from assaulting the defenses
	of the prison that was erected at the conclusion of
	MonkeyCommand I.  The game consists of coordinating
	the actions of four native tribal leaders and their
	vassals in repairing the damage done by the enraged
	monster ape as it tries to escape and revenge itself
	on whoever won the original MonkeyCommand.
	You need the secret code from the first MonkeyCommand
	which you can only get if you won that game.


	The following are standard fields. Their meaning is fixed, although
	sometimes open to interpretation. Nothing forces you to  obey these
	rules,  but  the closer you  adhere to them,  the more successful a
	search will be that relies on these rules.

	     1.	If a field does  not apply, or  you have no data to supply,
		leave it out. You may provide a blank  field, but this will
		have the same effect.

	     2.	Pay attention to the FORMAT, which  describes if a field is
		a single  line field (ignores 2nd and  further lines) or if
		it will flow its contents (ignoring YOUR newlines) or if it
		has any other constraints.

	     3.	The only absolutely required field  must also be  the first
		field in any 'Product-Info': "name"

.name (absolutely required; must also be the first field)
	Purpose:	The program's popular name. This is sometimes an
			abbreviated version of the "fullname"
	Format:		1 line only
	Example:	KingFisher
	Example:	HomeBase VI
	Example:	AIBB
	Example:	gcc

.fullname (optional)
	Purpose:	The full (or complete) name of the program if it
			differs from the "name"; omit this field if you
			would merely duplicate "name"
	Format:		1 line only
	Example:	Amiga Intuition Based Benchmarks
	Example:	GNU C Compiler

.short (optional, but recommended)
	Purpose:	A one-line description, preferably not exceeding
			40 characters in length, à la Aminet. A single-
			glance to the program's purpose.
	Format:		1 line, best not to exceed 40 characters
	Example:	Software catalog/search/maintenance tool
	Example:	Full featured C/C++ package; CLI only
	Example:	230db sound, mind-reading, killer game

	Purpose:	Categorize the package; multiple keywords permitted,
			but adhere as closely as possible to the list given
			at the end of this document. Wild variations will
			reduce the value of this field.
	Format:		One or more lines, but best not to exceed a single
			word or two.
	Example:	database
	Example:	animation player
	Example:	animation tool
	Example:	spreadsheet
	Example:	communications
	Example:	display commodity
	Example:	mouse commodity
	Purpose:	A full-text description of your package, containing
			anything that is NOT ALREADY available through the
			other fields (above and below.) The reader should
			gain a good understanding what your program can and
			cannot do. If you mention other (similar) software,
			please add these also to the "reference" field.
				Please note that this field FLOWS text and
			is not designed for fixed-pitch ASCII graphics or
			other flash. If you need to insert a newline, do so
			with the "\n" sequence (backslash followed by a
			lowercase "n"); newline characters are treated as
			blanks. See the section on FORMATTING below!
	Format:		Free form: Any number of lines, treated as a single
			stream of text and formatted according to embedded
			formatting symbols (see FORMATTING below.)
	Notes:		The text should be readable regardless of the font
			that is used in its display, and regardless of the
			line width available (resizable window vs. printer)

	Purpose:	The program's version number; please note that this
			should follow the standard guidelines for versions,
			as obeyed by most (but sadly not all, not even all
			system software):
				37.1 < 37.17 < 37.39 < 37.100 < 37.170
			The following are all vastly different versions:
				37.1  37.10  37.100  37.1000
	Format:		One line only: MAJOR.MINOR
	Example:	37.100
	Notes:		Nothing requires you to maintain your versions this
			way, but you should be aware that some software may
			make use of this field by searching for a release
			that has reached, for example, at least version 2
			(perhaps as a requirement that said software has
			been maintained by its author beyond some initial
			release 1); if your program's version is "v940205"
			then this would simply count as version 0 and could
			be missed.

	Purpose:	The program's official release date. NOT the date
			when it made it into the database.
	Format:		year.month.day
	Example:	1993.09.27
	Example:	1996.01.01
	Notes:		The format was chosen to make it easily sortable.
			Note the use of leading zeros in month and day, and
			the complete year (with century.)

	Purpose:	Any and all authors who have a part in the program.
	Format:		Any number of lines, each name should be placed on
			its own line.
	Example:	Joe R. User
			Tea Rexx
	Example:	J. Jones
			Random Hacker
			Bone Head
	Notes:		Addresses matching these authors should be placed
			into the .address field, one after the other, and
			in the correct order to produce a 1-to-1 relation.

.address (optional)
	Purpose:	Describe a full postal address of the author(s),
			to be used when it becomes necessary or desirable
			to contact the author by snailmail. Do not specify
			the author's name, as this already appears in the
			"author" field.
	Format:		Multiple lines. Formatting symbols are not used, as
			physical newlines are respected.
	Example:	7022 Hanover Parkway, Apt. C2
			Greenbelt, MD 20770-2049

.email (optional)
	Purpose:	Full electronic mail address
	Format:		Multiple lines, each having a 1-to-1 relation with
			the "author" field; more than one email address may
			appear on a line, separated by blank space (the
			preferred way) or by commas.
	Example:	walrus@wam.umd.edu
	Example:	walrus@wam.umd.edu walrus@uga.umd.edu

.url (optional)
	Purpose:	Universal Resource Locator, usually for ftp sites
			or World Wide Web support/home pages.
	Format:		One or more lines, each on a 1-to-1 relation with
			the "author" field. More than one URL (Universal
			Resource Locator) may appear on a single line.
	Example:	http://www.wam.umd.edu/~walrus/KingFisher.html
	Example:	ftp://nowhere.com/Bogus.png

.keywords (optional)
	Purpose:	List as few or as many keywords as necessary to sum
			up the major features of this package. It is
			recommended to keep this entry to 10 keywords or
			less, but no definitive limit will be enforced. The
			idea with this field is to help construct a memory-
			resident quick index for systems that can afford to
			maintain a large amount of data in RAM.
	Format:		One or more lines; keywords or keyphrases separated
			by white space (space, tab, or newline.)
	Example:	fish disks
			library maintenance			
			search expressions

.restrictions (optional)
	Purpose:	If your software has any restrictions placed upon
			it, list them here, in detail. You should indicate
			if your package has been made dysfunctional (such
			as would be the case with a demo package.) If the
			program will not run on anything less than a 68020
			CPU, you should list this here, to.
	Format:		Free form (see "description")
	Example:	Demo version has SAVE and PRINT disabled.
	Example:	Documentation available only in German.
	Example:	Disables video DMA while playing samples.
	Notes:		List actual restrictions here, not minimum system

.requirements (optional)
	Purpose:	List minimum requirements for your program. These
			should give the reader enough information to
			determine if the software is likely to run on his/
			her system. Be sure to specify operating system,
			(hard)disk requirements, non-standard libraries
			(such as MUI) and whether or not some or all of
			these required libraries are included in the
	Format:		Free form (see "description")
	Example:	68020, 68030, or 68040 CPU; 3M free RAM; 18M disk
			space; at least 640�480 display capabilities and
			16 colors or better.
	Example:	Requires WB2.1 (V38)
	Example:	Requires 1024�768 (or larger) displays.
	Example:	Works only with 4096-channel, 230db BLAZETHUNDER
			audio board.
	Example:	Requires MUI (Magic User Interface) version 10.

.reference (optional)
	Purpose:	List the full path to software in some way related
			to this package. This may include previous versions
			of your package or similar packages. The path is a
			volume:path/ or volume:path/archive
	Format:		2 lines per reference: the first is the path with
			trailing slash (if you do not give the slash then
			the name of an archive is assumed); the second line
			is the version number.
	Example:	FishROM-0002:Productivity/Databases/HomeBase VI/
			FishROM-0001:Productivity/Databases/HomeBase VI/

.distribution (optional)
	Purpose:	Describe the distribution and ownership status of
			this software. Please see below for a list of the
			most common (and recommended) terms.
	Format:		1 line
	Example:	shareware
	Example:	commercial demo

.price (optional)
	Purpose:	If your package is available for a fee, describe
			this price here. it is strongly recommended that
			the first currency is expressed in US dollars to
			provide a common base unit for prices. If your
			package is freely available and has no price
			attached, then omit this field.
	Format:		Free form but best adhere to examples.
	Example:	$50(US), DM75

.installsize (optional)
	Purpose:	The minimum and maximum sizes of the package as it
			is installed. The minimum size should give an
			indication of how much disk space is required for
			an absolute minimal installation. If the reader has
			less diskspace than that, the program is likely not
			to be able to function at all. The maximum is the
			absolute highest amount of diskspace that the
			package is likely to consume when all portions are
			installed (including optional tutorials, demo files,
	Format:		One or more lines; only the first line has a fixed
			format, the rest are free-form.
	Example:	220K - 2400K
			Most of the database files can be kept on floppy
			disks, so valuable hard disk space is not wasted.
	Example:	18K
	Example:	38K - 500K
			Lots of documentation and example scripts make up
			the bulk of this installation.
	Notes:		It is recommended that sizes are scaled to kilo-
			bytes to maintain a uniform scale, rather than
			expressing them in bytes or megabytes. Always add
			a size quantifier (K=kilobyte=1024bytes, M=megabyte,
			T=terabyte, etc.)

.exectype (optional)
	Purpose:	Describe the type of executable(s) that make up
			your program. Most packages are probably compiled
			C, but some may be shell or ARexx scripts, BASIC,
			AMOS, or otherwise interpreted. The reason for this
			is that some packages are known to cause problems
			on some systems, or the customer is looking for
			something "better" than interpreted BASIC and would
			like to know this before "wasting" time locating,
			downloading, and installing the package.
	Format:		Free form (see "description")
	Example:	Compiled C
	Example:	AmigaBASIC

.source (optional)
	Purpose:	Describe what source code is available as part of
			your package. If source is not available, then omit
			this field. How large is the source? What compiler,
			translator, or interpreter is required? It might be
			good to give an idea of the version of the compiler
			that is required.
	Format:		Free form (see "description")
	Example:	SAS/C 6.56, Manx, DICE source (750K) available for
			$15(US); some old SAS/C 5.10b sources (30K) included
	Example:	Limited C source examples (15K) included
	Example:	All source plus custom libraries: 12M

	Purpose:	Describe the types of languages used to create this
			program and the methods used to build the final
			executable. If possible, include the compiler
			versions and possibly important options, such as
			optimization for various CPUs (it is possible to
			optimize somewhat for a 68040 without sacrificing
			68000 compatibility.)
	Format:		Free form (see "description")
	Example:	SAS/C++ 6.56 with speed optimizations weighed for
			the 68040 CPU (68040 not required, however.)
	Example:	AdaEd
	Example:	Handcrafted assembly
	Example:	Fortran with self-made compiler.
	Example:	AMOS

.tested (optional)
	Purpose:	Give an indication of which configurations have
			served as test environments. If the software
			operates without problems with non-standard system
			enhancements, this would be a good place to mention
	Format:		Free form (see "description")
	Example:	A500(512K Chip, 0K Fast, 1 Floppy), A2000(1M Chip,
			2M Fast, 40M HD, 1 Floppy); not tested on 68020+
	Example:	A1000, A500, A600, A2000, A2000/30, A3000, A1200,
			A4000/30, A4000/40 with various amounts of Chip
			and Fast RAM, with and without MMU or FPU.  Found
			to be free of Enforcer hits and able to work with
			virtual memory products; compatible with Retina,
			EGS/Spectrum, and Picasso software.  Also tested
			under V33 through V40 system software.
	Example:	CPU: 68000, 68020, 68030, 68040 (68060 unknown);
			Kickstart V37, V38, V39, V40; Video/Graphics: PAL,
			NTSC, Picasso II (Village Tronic and CyberGraphX),
			GVP EGS Spectrum (others unknown); Tested with
			system enhancements such as GigaMem 3.12, VMM 3.2,
			Enforcer 37.62, Executive 1.30, IPrefs2Fast 0.9b,
			OpaqueMove 1.0, KingCON 1.3.

.run (optional)
	Purpose:	Specifies how to start the program.
	Format:		visible=type,command
			where 'visible' would be what the user would see
			and select; 'type' is either 'CLI' or 'WB' (the
			system interface) and 'command' is the program to
			execute. The 'CLI' version may include parameters,
			including I/O redirection, as this string is passed
			directly to the System() call.
	Example:	HomeBase VI=WB,HomeBase VI
			HomeBase VI=CLI,ExecuteMe.HB6
			HomeBase VI Fixer=CLI,ExecuteMe.HB6Fixer
	Example:	FishTub=WB,ExecuteMe
	Notes:		As this item may be dangerous to the unsuspecting
			user, it has not been implemented by KingFisher and
			is not likely to be implemented.

.execute (optional)
	Purpose:	An 'execute' script. This entry has been added by
			Fred Fish; the script views the documentation,
			installs the software, or merely runs the program.
	Format:		A shell script, line by line.
	Notes:		It is not recommended that this entry be supplied
			by you, as Fred Fish may simply replace it with a
			version of his own.

.docs (optional)
	Purpose:	List all documentation files associated with your
			package. Do not specify the files if they are not
			available as-is; if they are only located within an
			archive, omit them.
	Format:         1 line per file, do not include the path as this
			is provided by the "stored-in" field.
	Example:	HomeBase.guide

.described-by (optional)
	Purpose:	Who created the description ('Product-Info' file)
			for this project.
	Format:		Free form (should include an electronic mail
			address too, if available.)
	Example:	Fred Fish <fnf@amigalib.com>
	Example:	Udo Schuermann <walrus@wam.umd.edu>

.submittal (optional)
	Purpose:	Who submitted to package to Fred (or else how the
			package came to be on the reference disk.)
	Format:		Free form (usually one line)
	Example:	Submitted on disk directly by the author.
	Example:	Downloaded from wuarchive.wustl.edu in pub/aminet/util/misc

	Purpose:	Specifies where and especially HOW the package is
			stored. This field should specify EITHER the name
			of a directory (ending with a ':' or a '/') OR the
			name of a file. In the case of an archive, the name
			should reflect that with the appropriate extension
			(.lha .zip .gz .Z etc.)
	Format:		One or more lines
	Example:	FF1000:d501-1000/Disk950/Enforcer/
	Notes:		This field is usually generated by the disk creator
			software, not by the submitter of the package, as
			the final location on the disk may not be controlled
			by the submitter of the Product-Info.

.path (obsolete)

.aminet-dir (optional)
	Purpose:	The path (WITHOUT trailing '/') where this package
			is available on the global Aminet.
	Format:		One line; must NOT end with a '/'
	Example:	biz/dbase
	Example:	gfx/edit
	Notes:		Together with aminet-file, this entry can be used
			to construct the complete path to this package on
			Aminet or Aminet CD-ROMs.

.aminet-file (optional)
	Purpose:	The name of the package (archive) as stored on
	Example:	KingFisher220.lha
	Example:	VanGogh.lha
	Notes:		Together with aminet-dir, this entry can be used
			to construct the complete path to this package on

	Fields denoted as "free form"  disregard  the physical line breaks,
	performing word-wrapping of the text within the  current margins of
	the display window or the printer's  paper. To affect the layout to
	some degree, the  following  symbols may be inserted  at  strategic
	places in the text:

	\\	A single \ (backslash) symbol.

	\.	A single . (dot) especially useful  if/when  such  a dot is
		found (against normal practice)  at the very beginning of a
		line of text and would then be misunderstood to represent a

	\n	End of paragraph.  Text following this symbol is  forced to
		the beginning of the next visible  line.  Fixes all  \= tab
		definitions into place.  The next \= will cause all tabs to
		be cleared and  a  new one to be set.  Some fields, notably
		the  "description" field,  may  insert an  extra blank line
		between paragraphs.  If this is not desired, \N may be used

	\N	End of paragraph. Acts much like \n but will have no effect
		if two  newlines (\n or  \N) preceed it. Will also override
		the paragraph spacing of some fields (see \n above.)  \N is
		useful in controlling excessive inter-field spacing.

	\>	Indent (move left margin one  tab stop  to the right) until
		the next newline ("\n").

	\<	Un-indent (move an indented margin leftward again after the
		use of a \> indent symbol and before a \n is encountered.)

	\t	Tabs  to  the next tab.  Do  not   use  tabs  for paragraph
		indentation  after a  "\n".   The  implementation  of  tabs
		should, ideally, move the cursor  to the next  tab stop (to
		the right OR  the  left) so   that the 3rd  tab  on  a line
		actually moves to the 3rd defined tab stop.  If this is not
		possible, it is  recommended   to suppress tab   motion (or
		limit it to  a single  space)  if  leftward  motion  of the
		cursor is not possible.

	\=	Sets a tab at the current horizontal position.  The next \n
		will fix   these   tabs into place  and   prevent   further
		additions until the tabs are cleared  by the next "\=" (not
		yet implemented in KingFisher.)

	\#	Toggle between verbatim and flow mode. Most fields are flow
		fields, meaning  that  newlines  and  multiple  spaces  are
		treated as  a single space,  and the end of paragraphs must
		be specified by an explicit \n sequence. The effect  of  \#
		is,  therefore, dependent on  the type of field in which it
		is used:  in  a  flow  field,  the  first  \#  toggles into
		verbatim mode where multiple blanks and newlines are passed
		on to the display. The creation of tabular displays is made
		easier in verbatim mode.

	Action Game		Animation		Animation Player
	Animation Tool		Archiver		CLI Tool
	Communications		Compiler		Compression
	Database		Disk Tool		Display Commodity
	Drawing			Image Conversion	Image Processing
	Library			Mouse Commodity		Music Composition
	OS Utility		Painting		Picture
	Printing		Sound Analysis		Sound Editing
	Sound Playing		Spreadsheet		Strategy Game
	Text			Text Editing		Text Viewer
	Thinking Game		Word Processing		Workbench Tool


	Commercial	Commercial   software    is  owned and  distributed
			through  licenses.   It costs  money  to individual
			end-users  and is not  freely  distributable.  SUCH

	Commercial Demo
			Represents a demonstration of a commercial package.
			As such, commercial  demos are freely distributable
			and  may  have  limitations  as   described in  the
			.restrictions field.

	Giftware	Like shareware, usually.
	Shareware	Such software is owned  and  copyrights are held by
			the author(s).  The  software   may be  distributed
			freely,  but  not  sold   for   profit, of  course.
			Shareware  often  specifies   a limit of  some time
			after  which  you  are requested    or required  to
			register   the  software (i.e.  pay  for it.)  This
			provides   you  with the  means   to evaluate   the
			software thoroughly before paying for it.

	Freeware	Such software is owned and  copyrights  are held by
			the author(s).   The  software  may be  distributed
			freely, but  not sold for  profit, which would mean
			the software  is no longer  FREEware.  No  payments
			are required for such software.

	Public Domain	Software labeled  PD (Public Domain) belongs to the
			public,  i.e.  ANYONE.    Some people release their
			software into  the public domain with the  mistaken
			idea that they can continue to  own and control the
			program.  Not so.   Software that is labeled Public
			Domain (or said  by the author to  be released into
			the public  domain)  truly   belongs to anyone  and
			everyone.   It is quite legal   for someone to take
			such   a program  and  sell  it  for profit as  is.
			Likewise, it perfectly acceptable to  modify public
			domain  software to  build  a better    product (or
			whatever) out of it and then sell it for profit.

	GNU Public License
			The  terms and conditions of this  license are long
			and   not easily reproduced here.   Suffice  to say
			that software released under the GNU Public License
			must be distributed with source code.  They are not
			public domain, however.

	GNU Library Public License
			The terms and  conditions of this  license are long
			and not   easily reproduced here.    Suffice to say
			that software released under the GNU Library Public
			License must be distributed with source code.  They
			are not public domain, however.
	Copyright but Freely Redistributable
			The  author  holds all  copyrights  but  allows the
			material  to  be freely distributed under specified


All content is copyright © Ringlord Technologies unless otherwise stated. We do encourage deep linking to our site's pages but forbid direct reference to images, software or other non-page resources stored here; likewise, do not embed our content in frames or other constructs that may mislead the reader about the content ownership. Play nice, yes?

Find something useful here? Maybe donate some Bitcoin!