|
|
Documentation for the AscToHTM conversion utility |
This documentation can be downloaded as part of the documentation set in .zip format (370k)
AscToHTM performs statistical analysis on the document to determine at what character positions indentations occur. This information is used on the output pass to determine the indentation level for each source line.
AscToHTM attempts to indent the HTML code to match the output indentation level, to make it easier to read.
The indentations themselves are marked up using <BLOCKQUOTE> ... </BLOCKQUOTE> tags.
Future versions of AscToHTM may offer you the option of using <DIV> tags.
Some documents, especially ones dumped from Word, have hanging paragraph indents. That is, each paragraph starts at an offset to the rest of the paragraph.
AscToHTM struggles heroically with this, and tries not to treat this as text at two indent levels, but it does occasionally get confused.
If writing a text file from scratch with AscToHTM in mind, then it is best to avoid this practice.
AscToHTM detects and supports several types of bullets.
Bullet chars are lines of the type
- this is a bullet line
- this is a bullet paragraph
because it carries over onto
more lines
That is, a single character followed by the bullet line. AscToHTM can determine via statistical analysis which character, if any, is being used in this way. Special attention is paid to the '-' and 'o' characters.
Bullets of this type are given a <UL> ... <LI> ... </UL> markup.
AscToHTM can spot numbered bullets. These can sometimes be confused with section headings in some documents. This is one area where the use of a document policy really pays dividends in sorting the sheep from the goats.
Numbered bullets are given a <OL TYPE=1 START=N> ... <LI> ... </OL> markup.
- Note:
- Not all browsers support this type of markup. In such cases, it's possible that the numbering of bullets will get reset to 1 every so often. However, this isn't a problem with either Netscape or Internet Explorer.
AscToHTM detects upper and lower case alphabetic bullets. These are marked up like numbered bullets, with TYPE=a.
AscToHTM detects upper and lower case roman numeral bullets. These are marked up like numbered bullets, with TYPE=i.
AscToHTM can attempt to spot sections of centred text. However, because this can easily go wrong this option is normally switched off.
Centering is only switched on for single isolated lines, or any group of at least two lines. <CENTER> ... </CENTER> markup is used.
See the policy "Allow automatic centring"
A definition line is a single line that appears to be defining something. Usually this is a line with either a colon (:) or an equals sign (=) in it. For example
IMHO = In my humble opinion
or
Address : Somewhere over the rainbow.
AscToHTM attempts to determine what definition characters are used and whether they are strong (only ever used in a definition) or weak (only sometimes used in a definition).
AscToHTM marks up definition lines by placing a <BR> on the end of the line to preserve the original line structure. Where this decision is made incorrectly unexpected breaks can appear in text.
AscToHTM offers the option of marking up the definition term in bold. This is not the default behaviour however.
AscToHTM also recognises the use of definition paragraphs such as :-
Note: This is a "definition" paragraph, i.e. the whole
paragraph defines the term shown on the first line.
Unfortunately AscToHTM currently only copes with single
paragraphs (i.e. not with continuation paragraphs), and
only with single word definitions.
This gets marked up in a <DL> <DT>...</DT> <DD>...</DD> </DL> sequence
- Note:
- This is a "definition" paragraph, i.e. the whole paragraph defines the term shown on the first line. Unfortunately AscToHTM currently only copes with single paragraphs (i.e. not with continuation paragraphs), and only with single word definitions.
AscToHTM recognises that, especially in Internet files, it is increasingly common to quote from other text sources such as e-mail. The convention used in such cases is to insert a quote character such as > at the start of each line.
Consequently, AscToHTM adds a <BR> tag at the end of such lines to preserve the line structure of the original, and marks it up in <EM>..</EM> tags to differentiate the quoted text
AscToHTM can look for text emphasised by placing asterisks (*) either side of it, or underscores (_). AscToHTM will convert the enclosed text to bold and italic respectively using <STRONG> and <EM> tags respectively.
AscToHTM will also look for combinations of asterisks and underscores which is placed in bold italic. The asterisks and underscores should be properly nested.
The emphasised word or phrase should span no more than a few lines, and in particular should not span a blank line. If the phrase is longer, or if AsctoHTM fails to match opening and closing emphasis marks, the characters are left unconverted.
To a limited extent the software can detect and handle nested emphasis of different types. For example a phrase that is mostly in italics may contain a few bold words within it. Nested emphasis of the same type is not supported.
Tests are made to
- ignore double asterisks and underscores
- ignore phrases with underscores in the middle (these may become underlined)
- (new in version 4) to allow hyphenated words to be part-emphasised.
The program allows you to select the default font for your files. Fonts are implemented Cascading Style Sheets (CSS) by default, although this can be change to the <FONT> tag should you wish.
The <FONT> tag is allowed in "HTML 3.2", but is "deprecated" in favour of CSS in "HTML 4.0 Transitional". It is completely disallowed under "HTML 4.0 Strict".
Some older features of the software still use <FONT> tags. These will be changed to also use CSS in later releases as support for "HTML 4.0 Strict" is added.
See Font Policies for more details.
The program will detect special characters and symbols such as á and © and will replace these by the correct HTML entity codes á and ©. By using the correct HTML codes, the HTML produced is guaranteed to display correctly on all computers.
Some symbols use different character codes on different machines (e.g. Mac and PC).
Contents list lines are marked up in bold, and turned into a hyperlink pointing at the section referenced. The text is sized according to heading type in the range +/- 1 font size from normal (3).
AscToHTM can convert cross-references to other sections into hyperlinks to those sections. Unfortunately this is currently only possible for second, third, fourth... level numeric headings (n.n, n.n.n, n.n.n.n etc)
This is because the error rate becomes too high on single numbers/letters or roman numerals. This may be refined in future releases, although it's hard to see how that would work.
AscToHTM can convert any URLs in the document to hyperlinks. This includes http and ftp URLs and any web addresses beginning with www.
The domain name part of the URL will be checked against the known domain name structures and country codes to check it falls within an allowed group. So www.somewhere.thing won't be allowed as ".thing" isn't a proper top level domain.
URLs that use IP addresses or some more obscure methods of specifying domain names will also be recognised, but the link will be changed wherever to either a domain name or an IP address. This will de-obfuscate any obscure references so beloved by spammers.
AscToHTM can convert any newsgroup names it spots into hyperlinks to those newsgroups. Because this is prone to error, AscToHTM currently only converts newsgroups in known USENET hierarchies such as rec.gardens by default.
This can be overcome either by
- placing "news:" in front of the newsgroup name (e.g. news:this.is.a.newsgroup.honest)
- relaxing this condition via a document policy (see the policy "Only use known groups")
- specifying the newsgroup hierarchy as recognised via a policy "Recognised USENET groups".
AscToHTM can convert any email addresses into hypertext mailto: links. As with URLs (see 5.3.3), the domain name is checked to see it falls into a recognised group.
AscToHTM can convert use-specified keywords into hyperlinks. The words or phrase to be converted must lie on a single line in the source document. Care should be taken to ensure keywords are unambiguous. Normally I mark my keywords in [] brackets if authoring for conversion by AscToHTM
See the discussions on "link dictionaries" in 4.3.2.2 and 4.4.2.
AscToHTM offers a number of pre-processor commands and in-line tags that allow you to add hyperlinks commands to your source text.
For example the "GOTO" tag allows hyperlinks to be created to named sections in the same document. So that
[[GOTO Other sections and URLs]]
becomes
In the same way the "HYPERLINK" tag allows hyperlinks to be inserted
AscToHTM recognises various types of headings. Where headings are found, and deemed to be consistent with the prevailing document policy (correct indentation, right type, in numerical sequence etc), AscToHTM will use the standard <Hn> ... </Hn> markup.
In addition to this, AscToHTM will insert a named Anchor tag (<A> ... </A>) to allow hyperlink jumps to this point. These anchors are used for example in the contents list and cross-reference hyperlinks that AscToHTM generates.
This is the preferred heading type and the type that AscToHTM has most success with. Sections of type N.N.N can be checked for consistency, and references to them can be spotted and converted into hyperlinks.
At present more exotic numbering schemes using roman numerals and letters of the alphabet are not fully supported. This is planned to be implemented soon, possibly via user policy files.
AscToHTM can treat wholly capitalised lines as headings. It also allows for such headings to be spread over more than one line.
AscToHTM can recognise underlined text, and optionally promote the preceding line to be a section header. The "underlining" line should have no gaps in it.
New in version 4
The program can look for headings "embedded" in the first paragraph. Such headings are expected to be a complete sentence or phrase in UPPER CASE at the start of a paragraph. Where detected the heading will be marked up in bold, rather than <Hn> markup, although it will still be added to, and accessible from any hyperlinked contents list you generate for the document.
At present such headings are not auto-detected... you need to switch on the "Expect embedded headings" policy.
New in version 4
The program can now look for lines that start with particular words or phrases (such as "Chapter", "Part", Title") of your choice and treat these lines as headings. Previously this only worked in a limited way if the heading line was also numbered ("Chapter 1") etc.
To use this feature, set the policy "Heading key phrases"
Some types of documents use what look like section numbers to number paragraphs (e.g. legal documents, or sets of rules).
AscToHTM can recognise this, and mark up such lines by placing the number in bold, and not using <Hn> ... </Hn> markup on the whole line.
Some documents, especially those that were originally email or USENET posts, come with header lines, usually in the form of a number of lines with a keyword followed by a colon and then some value.
AscToHTM can recognise these (to a limited extent). Where these are detected the program will parse the header lines to extract the Subject, Author and Date of the article concerned. A 2-line heading containing this information will then be generated to replace all the unsightly header lines.
Lines are interpreted in context. If they appear to be underlining text, or part of some pre-formatted structure such as a table, then they are treated as such. Otherwise they become horizontal rules (<HR>).
An attempt is made to interpret half-lines etc as such, although the effect is only approximate.
Form feeds or page breaks also become <HR> markups.
New in version 4
You can use the HTML fragment HORIZONTAL_RULE to customize how lines are displayed, e.g. you can substitute your own image file.
AscToHTM normally ignores any HTML markup in the original text. The sole exceptions are any preprocessor tags which a user may insert into their text document (see Using the preprocessor).
For example :-
The use of BEGIN_PRE and END_PRE preprocessor
commands (see 7.1) in
the text documents
tells AscToHTM that
this portion of the
document
has been formatted
by the user and
should be left unchanged.
AscToHTM attempts to spot sections of preformatted text. This can vary from a single line (e.g. a line with a page number on the right-hand margin) to a complete table of data.
Where such text is detected AscToHTM analyses the section to determine what type of pre-formatted text it is. Options include
- Tables
- Code samples
- Ascii Art and diagrams
- some other formatted text
A number of policies allow you to control
- whether or not the program looks for such text
- how sensitivity it is to "pre-formatted" text
- how inclined the program is to "extend" the region to adjacent lines
- whether or not table generation should be attempted
- various aspects of any table analysis that is carried out.
See Pre-formatted text policies for full details.
Tables are marked out by their use of white space, and a regular pattern of gaps or vertical bars being spotted on each lines. AscToHTM will attempt to spot the table, its columns, its headings, its cell alignment and entries that span multiple columns or rows.
Should AscToHTM wrongly detect the extent of a table, you can mark up a section of text by using the "BEGIN/END_TABLE" pre-processor commands. Alternatively you can try adding blank lines before and after, as the analysis uses white space to delimit tables.
You can alter the characteristics of all tables via the table policies (see Table generation policies).
You can alter the characteristics of all or individual tables via the table pre-processor commands (see 7.1.4).
Or you can suppress the whole thing altogether via the "Attempt TABLE generation" policy
AscToHTM attempts to recognise code fragments in technical documents. The code is assumed to be "C++" or "Java"-like, and key indicators are, for example, the presence of ";" characters on the end of lines.
Should AscToHTM wrongly detect the extent of a code fragment, you can mark up a section of text by using the "BEGIN/END_CODE" pre-processor commands.
You can choose what type of markup is used for the code fragment (see the policy "Use <CODE>..</CODE> markup").
Of you can suppress the whole thing altogether via the policy "Expect code samples".
AscToHTM attempts to recognise Ascii art and diagrams in documents. Key indicators include large numbers of non-alphanumeric characters and the use of white space.
However, some diagrams use the same mix of line and alphabetic characters as tables, so the two sometimes get confused.
Should AscToHTM wrongly detect the extent or type of a diagram, you can mark up a section of text by using the "BEGIN/END_DIAGRAM" pre-processor commands.
New in version 4
If AscToHTM detects a block of text at a large indent, it will now place that text in a table in such a way as to preserve as faithfully as possible the original indent.
Of course, sometimes this text is, in fact, centred on the page. In that case you could consider switching on the policy "Allow automatic centring" See 5.1.4
If AscToHTM detects formatted text, but decides that is is neither table, code or art (and it knows what it likes), then the text may be put out "as normal", but with <BR> added to each line. In such regions other markup (such as bullets) may not be processed such as it would be elsewhere.
AscToHTM can calculate - or be told - the title of a document. This is placed in <TITLE>...</TITLE> markup in the <HEAD> section of each HTML page produced.
The Title is calculated as in the order shown below. If the first algorithm returns a value, the subsequent ones are ignored.
- If a $_$_TITLE pre-processor command (see 7.1.2) is placed in the source text, that value is used
- If the "Use first header as title" policy is set then the first heading (if any) encountered is used as the title.
- Note:
- Depending on your document structure, this is prone to give bland tiles like "Introduction" , "Overview" and "Summary"
- If the "Use first line as title" policy is set then the first line in the file is used as the title.
- If the "Document title" policy is set then this value is used.
- Note:
- If this is the value you want, ensure the other policies outlined above are disabled.
- Finally, if none of the above result in a title the text "Converted from <filename>" is used.
AscToHTM can detect the presence of a contents list in the original document, or it can generate a contents list for you from the headings that it observes. There are a number of policies that give you control over how and where a contents list is generated (see Contents generation policies).
There are four different situations in which contents lists may, or may not be generated. These are :-
By default AscToHTM will not generate a contents list for a file unless it already has one.
If it should detect a contents list in the document, then that list is changed into hyperlinks to the named sections. This only works currently for files with numbered headings.
Where an existing list is detected, headings shown in the contents list are converted into links, and the link text is that in the original contents list, and not the text in the actual heading (often they are different).
- Note:
- AsctoHTM currently only detected numbered contents lists, and is occasionally prone to error when they are present. If you experience problems, either delete the contents list and get AscToHTM to generate one for you, or mark up the existing list using the contents pre-processor commands (see 7.1.1)
As described in 5.6.2.1, AscToHTM will not generate a contents list by default unless it already has one.
Requesting a contents list
You can request that a contents list is always generated, by using the "Add contents list" policy. In this case a contents list is either
- made from the existing contents list, or
- generated from the observed headings. in this case the contents list will only be as good as the detection of headings in the rest of the document permits.
Forcing a generated contents list
You can force a generated list to be used by disabling the "Use any existing contents list" policy.If an existing contents list is present, it is deleted from the output. Normally it's best to either use the existing contents list, or to delete it from the source text and request a generated list.
Contents lists placement
By default the contents list is placed at the top of the output file. In earlier versions of AscToHTM the contents list was always placed in a separate file.You can cause contents lists to be placed wherever you want by using the "CONTENTS_LIST" preprocessor command. If you do this, then contents lists is placed only where you place CONTENTS_LIST markers.
Generating a contents list in a separate file
If you select the "Generate external contents list" policy the contents list is placed in a separate file, and a hyperlink to that file called "Contents List" is placed at the top of the HTML page generated from the document.You can choose the name of the external file using the "External contents list filename" policy. If omitted, the file is called "Contents_<filename>", where <filename> is the name of the document being converted.
AscToHTM can be made to split the output into many files. At present this is only possible at detected section headings. Each generated page usually has a navigation bar, which includes a hyperlink back to the following section in any contents list.
The behaviour is identical to that in 5.6.2.2 expect that
- the output is now split into several files.
- the options to generate an external contents list in a separate file are no longer available.
- if the contents list is being generated, it is now placed at the foot of the first document, rather than at the top (unless the CONTENTS_LIST preprocessor command is used)
This is usually before the first heading (which now starts the second document), and after any document preamble.
- Note:
- Where the original contents list is used when splitting files it is possible that not every file is directly accessible from the contents list, and that the back links to the contents list may not function as expected. In such cases you can go from the contents list to a major section, and then use the navigation bars to page through to the minor section.
New in version 4
Contents list generation for the main document will proceed as described in the previous sections.
When making a set of frames, you can elect to have a contents frame generated (the default behaviour), and this will have a generated list placed in a frame on the left. This can mean you have a contents list in the contents frame on the left, and also at the top of the first page in the main document. For this reason the main frame often starts by displaying the second page.
The number of levels shown in the contents frame list can be controlled by policy. Alternatively you can replace the whole contents of the contents frame by defining a CONTENTS_FRAME HTML fragment.
When converting several files at once, AscToHTM can be made to generate a "Directory Page". This is an HTML index of all the files converted and their contents.
The policies available for controlling generation of a directory page are explained in "Directory Page policies".
The directory page will consist of an entry for each file converted, in the order that files are converted (usually alphabetic). Each entry will (optionally) contain :-
- A link to the file being converted. The link will either be the converted file's HTML title, or failing that, the filename itself.
- Links to each of the sections of the converted file as detected by AscToHTM.
AscToHTM can be made to add standard header, footers and JavaScript to each page generated. It does this by allowing you to specify include files to be copied into the generated HTML. These include files can contain any valid HTML commands.
The program supports three types of such files :-
- Header files. These contain any HTML you want placing immediately after the output's <BODY> tag.
A good example might be a standard header, with a logo and links back to the home page.
- Footer files. These contain any HTML you want placing immediately before the closing </BODY> tag.
- Script files, These contain any HTML you want placing inside the <HEAD> ... </HEAD> portion of the generated file. Such tags are not usually visible.
You should place in here any JavaScript you want, although it is difficult to make this apply to the converted text.
You can specify include files for the converted files, as well as for any directory page (see 5.6.3) that you create. If you don't specify values for the directory page, then it will use the same files as the generated files.
HTML headers and footers can also be defined as HTML fragments (see 5.6.5).
New in version 4
The "HTML fragments" feature allows you to define a block of HTML that you can elect to have used in place of the default HTML that the program would generate.
Some reserved names are recognised by the software and used to override the default HTML that is generated. For example the fragment HORIZONTAL_RULE can be used to define a <IMG> tag that displays an image and which will be used in a number of situations where a simple <HR> tag would have been used otherwise.
They are described fully in the Tag Manual (see HTML fragments).
 |
Converted from
a single text file by
AscToHTM © 1997-2001 John A Fotheringham |  |