KeyNote uses plain text files which can be read on a line-by-line basis.RTF data is stored as-is, without any conversion.

The file consists of a header section and a data section.

The header identifies the file as a valid KeyNote file and stores some metainformation about the file, such as the date and time the file was created, which note was last active, user-defined description and comment, etc.

The data section consists of subsections for notes and tree nodes. Sections and subsections are separated by special markers, described below.

Almost all elements in the data section, where the properties of notes and tree nodes are stored, are optional. KeyNote fills in any missing data using default values. This applies even to names of notes. Default values are configured by user via Tools|Default settings. There is a bug, however, which prevents KeyNote from automatically assigning default names for tree nodes, so if a particular tree node has no name specified in the file its caption will be blank. Other than that, you can leave out all elements of a file. Only the markers are required, because they define the structure of the file.

For tree nodes, the level number must also be specified, because it is required to re-create the tree hierarchy: level value indicates nesting, where level value of zero means top-level (root) node.

Some elements or identifiers mentioned in this document may not appear in every KeyNote file. This is because some elements are only stored in the file if necessary. For instance, the file header carries information about the note which was used for clipboard capture. If clipboard capture was not enabled at the time the file was saved, this property is not stored in the header.

(The example elements and properties shown in this document are based on a sample file "fileformat.knt", included in the package. The file contains one simple note with two lines of text, and one tree-type note with two normal nodes and one virtual node.)

This document does not describe the structure of encrypted files, because this is closely tied to the encryption library used (DCPCrypt 1.0, by David Barton). Please see KeyNote source code to see how encrypted files are created and handled.

Each line begins with '#', followed by a single character that identifies a header field. All header fields except for the first line are optional and will be auto-created if missing (KeyNote will use default values). The first line identifies the file as a valid KeyNote file and MUST be present. Lines not understood are simply ignored, as long as each line begins with the '#' character.

Header ID - required; must not be changed. (1.0 was used for files that did not have tree-type notes.)#!GFKNT 2.0

Comment line, ignored# This is an automatically generated file. Do not edit.

Optional: if clipboard capture was active at the time the file was saved, this is the index of the note which was used for clipboard capture#L0

--------------------------------

SECTION (START AND END) MARKERS:

The start of each subsection is marked by a single line. The first character in such lines is always the percent sign. For example, '%' marks the start of a new simple note, while '%+' marks the start of a tree-type note. Markers are as follows:

%marks start of a new SIMPLE note

%+marks start of a TREE-TYPE note

%-marks start of NODE in a tree-type note

%:marks start of RTF data. Please see below for notes about the RTF data section.

%%marks end of file (KeyNote stops reading the file here, but it will also stop at end of file, so this marker is not required, though always present in files generated by KeyNote.)

No other markers are used. No end-of-section markers are used, except for end-of-file, above.

--------------------------------DATA SECTION:

Each line begins with a 2-character identifier, possibly followed by equal sign (=) and data. For example, NN=titleidentifies the note name.

Each line is guaranteed to be at least one character long. Each line with an identifier is guaranteed to be at least three characters long: the two characters of the identifier itself, plus the equal sign. (The file can be analyzed a little faster if we don't have to check for zero-length strings.)

Number of lines of text (not required, but allows KeyNote to pre-allocate memory, which somewhat improves the speed of loading data into the RTF editor)LC=2

RTF data marker, followed by RTF data until one of the following occurs: new note start, new tree node start, end of file.%:{\rtf1\ansi\ansicpg1250\deff0\deflang1045{\fonttbl{\f0\fnil\fcharset238{\*\fname Courier New;}Courier New CE;}{\f1\fnil\fcharset0 Courier New;}}{\*\generator Riched20 5.40.11.2210;}\viewkind4\uc1\pard\f0\fs24 This is the text of the simple note.\parThis is another line of text.\par\lang1033\f1\par}

Optional: full absolute path to file, if node is a virtual node (see also node flags)VF=c:\delphi\projects\keynote\doc\todo.txt

RTF data follows:%:{\rtf1\ansi\deff0{\fonttbl{\f0\fnil\fcharset238{\*\fname Courier New;}Courier New CE;}{\f1\fnil\fcharset0 Courier New;}}{\*\generator Riched20 5.40.11.2210;}\viewkind4\uc1\pard\lang1045\f0\fs24 This is the text of the node.\parThis is another line of text.\par\lang1033\f1\par}

End of fie marker follows:%%

-------------------------------------

NOTES:

1. About "flags" strings.

Flags strings hold a number of boolean (yes/no) values, and, rarely, other types of values. Each value is encoded as a single character in the flags string. Boolean values are encoded as 0 (false) and 1 (true); for meaning of other values see flag descriptions below.

Each flag string is exactly 24-characters long, and will be IGNORED if it is shorter. (That is, if the string is shorter than 24 characters, KeyNote will not read ANY values from the string.) Not all 24 values are used.

There are three versions of the flags string: one for file, one for each note (with additional meanings for tree-type notes), and another one for every node in the file.

The meanings of particular flags and values have changed with subsequent releases of KeyNote. Only the current values and meanings are described here - they are valid for KeyNote 1.6. If your file was created by an older version, the meaning of some flags may be different than described here.

a) FILE FLAGS

position type meaning1 boolean Open file as read-only2 boolean Show icons on tabs3 boolean TRUE if file was saved using version 3.0 of the richedit control; otherwise FALSE4 boolean TRUE if the multi-level backup setting (Tools|Options) should be IGNORED for this file; otherwise FALSE (i.e. perform multi-level backup if so configured)(other flags are unused)

b) NOTE FLAGS- flags for simple notes:

position type meaning---------- -------------- --------------1 boolean Note is visible (UNUSED; could be used for hiding notes, but this has never been implemented)2 boolean Note is read-only3 boolean Word-wrap ON/OFF4 boolean URL detection ON/OFF5 boolean if TRUE, use true TAB character in this note; if FALSE, insert spaces instead of TAB character when user presses the TAB key6 boolean if TRUE, note has the "Plain text only" setting enabled (Note properties|Advanced). IMPORTANT: This affects how RTF data is stored, see below.

1. The data section may be empty or missing entirely, which will not invalidate the file. This allows you to easily create file templates without having to worry about supplying valid RTF data: your template can simply define the structure (notes and nodes), while leaving out the data sections, which users will fill in as they create files based on the template.

2. If the flags string for a note contains '1' at sixth position (see above), the note has been marked as "Plain text only" (Note properties|Advanced). When storing plain text data in the RTF data section, we could encounter lines which would be interpreted by KeyNote as section markers (i.e. if the note has a line that consists only of a percent sign, it would be interpreted as a start of a new note). This cannot happen in RTF data, because there will at least be a trailing backslash or "\par" token, but for plain-text data we MUST avoid the possibility of such conflicts.

Therefore, if the note has been marked as plain-text, KeyNote prepends a semicolon (;) to each data line, like this: