| Back to Contents List |
|
This chapter details all the policy options supported by AscToHTM.
There is an Alphabetical list of policies available in AscToHTM available. The policies themselves are grouped together according to the area of functionality they support as follows :-
'What to look for' policies
General analysis policies
Bullet policies
Contents list policies
File structure policies
Headings policies
Pre-formatted text policies
Table analysis policies
Added HTML policies
Advanced HTML policies
Colour policies
CSS policies
Directory page policies
File generation policies
File splitting policies
Font policies
Frames policies
Hyperlink policies
Pre-processor policies
Style policies
Table generation policies
Configuration file policies
Settings policies
Policies set elsewhere in the user interface
Policies that need to be added manually
The following is a list of all the policies supported by this version of AscToHTM:-
Menu location: Configuration Options -> Analysis Policies
Analysis policies are usually calculated by AscToHTM by making a first pass through your document. The resulting policies are then used during the second, conversion pass to categorise all input lines so that they may be correctly converted to HTML.
You should only need to change these policies should the analysis fail.
Menu location: Configuration Options -> Analysis Policies -> What to look for
These policies act as "broad stroke" policies enabling or disabling areas of functionality within the software by telling it what to look for and to try to detect.
For example you can tell the program whether or not to bother looking for patterns of indentation, bullets, or numbered lists. In many cases if you enable a policy you can further fine tune the conversion details on other policy sheets.
Menu location: Configuration Options -> Analysis Policies -> What to look for
AscToHTM can attempt to detect the indentation pattern of your document and replicate it in the output file. If you chose to disable this policy, all your text will be output with no indentations at all.
If the program is wrongly indenting your files, you can try
adjusting the pattern of indentation on the
General Analysis tabbed policy sheet.
Menu location: Configuration Options -> Analysis Policies -> What to look for
By default AscToHTM will attempt to look for paragraphs in your source. Usually this is signaled by a blank line between paragraphs, a leading indent on the first line of each paragraph, or (in extreme cases) a short line at the end of a paragraph.
If you don't want AscToHTM to detect paragraphs, disable this policy.
If AscToHTM is wrongly detecting paragraphs, try adjusting the paragraph analysis policies on the General Analysis tabbed policy sheet.
(New in version 5.0)
Menu location: Configuration Options -> Analysis Policies -> What to look for
By default AscToHTM will attempt to look for paragraphs whose first line is offset relative to the rest of the paragraph. Where this happens, lines at different indentations will be treated as a single paragraph. Where this fails to happen a first line of a paragraph may be treated as a separate indented paragraph.
If you don't want AscToHTM to detect these offsets, disable this policy.
See the discussion in Hanging paragraph indent detection
See also hanging paragraph position(s)
Menu location: Configuration Options -> Analysis Policies -> What to look for
By default AscToHTM will attempt to detect short lines and preserve their structure by adding a line break. Disabling this will cause short lines to be merged into the surrounding paragraph's text.
If AscToHTM is wrongly handling your short lines, you can adjust the short line cutoff point or the page width (which is used in short line detection) in the Sizes section of the General Analysis tabbed policy sheet.
Menu location: Configuration Options -> Analysis Policies -> What to look for
By default AscToHTM will treat a series of hyphens, minus signs, equal signs on the same line as a horizontal rule. (On occasion it might be regarded as underlining a heading on the previous line).
You can disable this is you wish, or you can specify how many "line" characters it takes to make a horizontal rule.
Menu location: Configuration Options -> Analysis Policies -> What to look for
Specifies the minimum length of any line to be considered as a horizontal rule when the program is looking for such lines (see Look for horizontal rulers)
Lines in the source text that consist only of "rule-like" characters, and which exceed this minimum length will be marked up as Rules, rather than as the original character sequence.
Menu location: Configuration Options -> Analysis Policies -> What to look for
By default AscToHTM will try to detect bullet points and numbered lists. This can sometimes go wrong if you have lines that look to the program like bullet points.
You can disable this behaviour should you wish. Alternatively you can fine tune the detection of bullets on the bullet analysis tabbed policy sheet.
Menu location: Configuration Options -> Analysis Policies -> What to look for
By default AscToHTM will try to detect definitions and notes, usually in the form of a single word and a hanging paragraph.
This can often go wrong, so you can use this policy to disable this feature.
Menu location: Configuration Options -> Analysis Policies -> What to look for
By default AscToHTM will try to identify "quoted" lines. Quoted lines are lines that have had a single character (often ">" or "!") inserted at the start. This is common practice when quoting email in a reply. AscToHTM places such text in italics.
You can disable this behaviour should you wish.
Menu location: Configuration Options -> Analysis Policies -> What to look for
AscToHTM will try to look for text that has been marked up with underscores and asterisks to signify bold an italic text. For example
*This is bold* and _this is italic_
becomes
This is bold and this is italic
This appears on-screen as "Look for emphasis"
Menu location: Configuration Options -> Analysis Policies -> What to look for
AscToHTM will try to detect where a line of text has been "underlined" by following it by a same length row of dashes, hyphens, equal signs etc. This text will then be regarded as a candidate for being an underlined heading or - if those are not allowed - underlined text.
If you have tables and reports, you may want to switch this policy off since the line at the end of a table may appear to under- or over-line the last line of text in the table.
Menu location: Configuration Options -> Analysis Policies -> What to look for
AscToHTM will try to look for email and USENET headers. Where these are recognised they can be simplified so that only the To, Form and Subject lines are shown in the output.
You can disable this behaviour should you wish.
Menu location: Configuration Options -> Analysis Policies -> What to look for
Specifies whether or not the software should attempt to detect alternative character sets, such as those used for languages such as Greek, Turkish, Chinese etc.
The software does this by doing a statistical analysis on the characters used in the source file. This process isn't perfect, and when it fails you will need to manually set the correct character set using the Character encoding policy.
If you find the program is wrongly detecting the character set, disable this policy and/or manually set it using the Character encoding policy
Menu location: Configuration Options -> Analysis Policies -> What to look for
By default AscToHTM will try to identify regions of preformatted text. Once identified AscToHTM will try to decide if it's a diagram, table or some other form of preformatted text. If it thinks it's a table it will attempt to place the text in an appropriate table structure.
You can disable the search for preformatted text, or if you allow preformatted text, disable table generation. (This may be appropriate if you have a large number of ASCII diagrams in your text).
The search for preformatted text can be refined via the
Pre-formatted text and Table analysis
tabbed policy sheets.
The output of tables can be fine-tuned via the output policy Tables tabbed policy sheet.
Menu location: Configuration Options -> Analysis Policies -> What to look for
Specifies whether or not regions of preformatted text that are detected should be considered as candidate diagrams. Text that contains numbers of characters such as "|", "-", ">" and "<" may be considered to be an ASCII diagram.
If you find the program is wrongly treating tables as diagrams then disable this policy.
Menu location: Configuration options -> Analysis Policies -> General Layout
These policies aid AscToHTM's analysis by describing in detail what the contents of the document being converted are
Sizes
Paragraphs
Definitions
Layout
Menu location: Configuration options -> Analysis Policies -> General Layout
This indicates the width (in characters) of your nominal output page. This width is calculated from the observed line lengths in the original document.
This width is used in short line calculation, and determining whether a given line contains a definition term or not (definition character near the start of the line).
In documents that contain line feeds this should be automatically detected.
In other documents you may need to set this manually.
Menu location: Configuration options -> Analysis Policies -> General Layout
This indicates the size (in characters) of your tabs. AscToHTM converts all tabs to spaces on conversion before analysis. By default a tab size of 8 characters is assumed.
The tab size can influence the analysis of paragraph indentations and other layout. Provided they are used consistently there shouldn't be a problem. However where tabs and spaces are used in combination, mistakes can arise.
This is particularly true in tables of data. AscToHTM does not expect tab-separated table cells, instead converting the tabs to spaces and analysing the results.
If your source document has been created with an editor with a different tab size, you should change this value should you start to experience strange layout conversion problems.
Menu location: Configuration options -> Analysis Policies -> General Layout
This policy is used to determine what is a "short line". Short lines are treated specially by AscToHTM by adding a paragraph marker on the end. They can also be used to detect ends of paragraphs in those documents that don't have blank lines between paragraphs.
Normally AscToHTM will determine whether or not a line is short by comparing it to the page width, given the current context.
The default value is 0 characters (indicating a comparison to Page Width should be used). Set this to any value you like. A value of 80 is likely to make every line in your original document have a <BR> tag on the end.
Menu location: Configuration options -> Analysis Policies -> General Layout
This policy tells AscToHTM what the smallest chapter size may be. This is used when trying to determine if a numbered line is a chapter heading. AscToHTM tries to avoid treating numbered lists as a series of small chapters using this policy.
The default value is 8 lines. Change this only if you suspect small chapters are being ignored, or large list items are being treated as chapter headings.
Menu location: Configuration options -> Analysis Policies -> General Layout
AscToHTM can detect whether or not it should expect blank lines between paragraphs. Documents without blank lines between paragraphs will be harder to convert, and errors are more likely. Unfortunately text documents exported from Word for Windows often have this property.
Where there are no blank lines, AscToHTM relies of spotting the last line of a paragraph (usually shorter), and (in some documents) the presence of a hanging indent at the start of each new paragraph.
This should be automatically detected.
Menu location: Configuration options -> Analysis Policies -> General Layout
Some documents start the first line of a new paragraph with an offset of a number of characters. This is especially true in text files saved from Word for Windows documents.
AscToHTM can sometimes confuse such paragraphs as being two different levels of indentation. Use this policy to eliminate such confusion.
This should be automatically detected
Menu location: Configuration options -> Analysis Policies -> General Layout
This policy can be used to disable the search for definitions. Sometimes this leads to unexpected results with text that is not part of a definition being treated as such. In such cases you can adjust the definition policies, but if this still fails, use this to disable the search completely.
See also one-line definitions and definition paragraphs
Menu location: Configuration options -> Analysis Policies -> General Layout
This policy identifies the indentations used for the follow-on text in definition paragraphs. These indentation levels need not be the same as the indentation levels used for normal text, though of course often they are.
This should be detected automatically, but if your document has only a few examples it's possible AscToHTM will ignore them. In such cases you may need to set this policy manually.
This appears on-screen as "Definition paragraph indent levels"
Menu location: Configuration options -> Analysis Policies -> General Layout
This policy specifies whether or not hyphen (-) characters are used in one-line definitions.
If the hyphen character only occurs in definitions, then set the nearby always flag, otherwise AscToHTM will have to guess whether a particular character is part of a definition or not. This is sometimes a source of conversion errors.
If this policy is selected, it will result in a suitable Definition Char line being added to the policy file.
This should be detected automatically.
Menu location: Configuration options -> Analysis Policies -> General Layout
This policy specifies whether or not colon (:) characters are used in one-line definitions.
If the colon character only occurs in definitions, then set the nearby always flag, otherwise AscToHTM will have to guess whether a particular character is part of a definition or not. This is sometimes a source of conversion errors.
If this policy is selected, it will result in a suitable Definition Char line being added to the policy file.
This should be detected automatically.
Menu location: Configuration options -> Analysis Policies -> General Layout
This policy specifies a character that may be used in one-line definitions.
This may be detected automatically, but more likely you'll need to specify it yourself.
This specifies the characters used to detect "definitions". 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
Address : Somewhere over the rainbow.
The character can be marked as "Strong" or "weak". Strong means such characters always signal a definition. Weak means they only sometimes do this, depending on the position relative to the Page Width.
For example for the above example you'd expect policy lines in the form
Definition Char : '=' (strong)
Definition Char : ':' (strong)
This appears on-screen as "Other definition characters", and each character entered into that field will get it's own "Definition Char" policy line
The user interface presents this more cleanly than the text in the policy file does, and the latter may be changed in later versions.
Menu location: Configuration options -> Analysis Policies -> General Layout
AscToHTM recognises multiple levels of indentation. This policy shows the character levels at which indentation has been detected.
AscToHTM converts all tab characters into multiple spaces in input. These indentation positions are the positions that result after that conversion. Depending on your tab settings these might not be exactly the positions you would expect.
Normally these levels are correctly detected automatically, but should you wish to set them manually you may need to experiment slightly to see how AscToHTM has handled your tabs.
Menu location: Conversion Options -> Analysis Policies -> Bullets and lists
AscToHTM should be able to detect the use of bullets on a reasonably sized document. These policies describe the type of bullets expected.
Expected Bullet types
Bullet characters
See also the discussion on Bullets and list detection
Menu location: Conversion Options -> Analysis Policies -> Bullets and lists
This policy states whether or not the program should attempt to automatically detect bullets and numbered lists. This should normally be left on unless your document has no such features, but the program (wrongly) thinks it has.
This appears on the Bullets dialog as "Automatically detect bullets and numbered lists", but is identical to the "Look for bullets" policy on the 'What to look for' policies tabbed property sheet
Menu location: Conversion Options -> Analysis Policies -> Bullets and lists
This policy states whether or not numbered bullet points are expected. The numbered bullets can be followed by any punctuation, thus 1., 2) and (3) will all be recognised, but HTML will not necessarily support this in the markup produced.
This should be automatically detected.
Menu location: Conversion Options -> Analysis Policies -> Bullets and lists
This policy states whether or not alphabetic bullet points are expected. The numbered bullets can be followed by any punctuation, thus a., b) and (c) will all be recognised, but HTML will not necessarily support this in the markup produced.
Both upper and lower case bullets are recognised (and supported in the markup).
This should be automatically detected
Menu location: Conversion Options -> Analysis Policies -> Bullets and lists
This policy states whether or not roman numeral bullet points are expected. The numbered bullets can be followed by any punctuation, thus i., ii) and (iii) will all be recognised, but HTML will not necessarily support this in the markup produced.
Both upper and lower case bullets are recognised (and supported in the markup), although the range of roman numeral values supported is limited.
This should be automatically detected.
Menu location: Conversion Options -> Analysis Policies -> Bullets and lists
This policy states whether or not bullet points starting with the hyphen character '-' are expected.
This appears on-screen as "recognize hyphen character as a bullet point"
This should be automatically detected.
Menu location: Conversion Options -> Analysis Policies -> Bullets and lists
This policy states whether or not bullet points starting with the lower case 'o' are expected.
This appears on-screen as "recognize 'o' character as a bullet point"
This should be automatically detected.
Menu location: Conversion Options -> Analysis Policies -> Bullets and lists
This policy lists any other characters that are to be recognised as bullet characters.
This appears on-screen as "Other bullet point characters"
Each bullet character entered will appear in the policy file as it's own "Bullet Char" line as follows:-
Bullet Char : '<'
This should be automatically detected, but may sometimes need to be manually entered.
Menu location: Conversion options -> Analysis Policies -> Contents List
Menu location: Conversion options -> Output Policies -> Contents List
This dialog shows both analysis and output policies connected with contents list detection and generation.
Diagnostics
Output
Menu location: Conversion options -> Analysis Policies -> Contents List
This policy specifies whether or not the document already contains a contents list. If it does, AscToHTM will attempt to convert the existing list into a series of hyperlinks.
This should be detected automatically, but occasionally you will need to set this policy manually.
See the discussion on contents list generation
Menu location: Conversion options -> Output Policies -> Contents List
This policy specifies whether or not AscToHTM should generate a contents list. This lost will be generated from either an existing list in the source documents, or from the observed headings.
A link to "contents list" will be added to the main HTML file.
See the discussion on contents list generation
Menu location: Conversion options -> Output Policies -> Contents List
This policy specifies whether or not you wish to use any existing contents list found in the source document. If you disable this option, any contents found will be discarded. A contents list will only be added if you select the Add contents list policy
This option is not fully supported, as it depends on the software correctly detecting the contents list, and then matching the contents lines with headings in the document.
If this option is disabled (the default) any contents list will be created from the headings detected in the document (this is the recommended option)
On-screen this appears as a choice between calculating the contents from observed headings, or from the contents list in the document
See the discussion on contents list generation
Menu location: Conversion options -> Output Policies -> Contents List
This policy specifies that an external contents list file should be generated. This is not always possible.
See the discussion on contents list generation
Menu location: Conversion options -> Output Policies -> Contents List
When Generate external contents file is enabled, this specifies the name of the external contents list file.
The default will be "contents_<input_filename>.html"
Menu location: Conversion options -> Output Policies -> Contents List
This policy specifies whether the hyperlink in a contents list entry should be placed on the section number, or the section title.
This appears on-screen as a choice between placing the link on the number or the title, but in the policy file this is simply a "Yes/No" option on placing the link on the number.
This is only relevant for documents with numbered section headings.
Menu location: Conversion options -> Output Policies -> Contents List
This policy specifies whether the hyperlink in a contents list entry should be placed on the section number, or the section title.
This is only relevant for documents with numbered section headings.
(New in version 5.0)
Menu location: Conversion options -> Output Policies -> Contents List
This policy specifies whether or not mail headers should be included in any generated contents list. For a mail digest this should be yes, but for larger documents with only a couple of mail headers the answer may be no.
Menu location: Conversion Options -> Analysis Policies -> File Structure
These policies aid AscToHTM's analysis by describing some of the file structure that would affect the analysis.
Expected File contents
Text Attributes
Text to ignore
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM puts a lot of effort into detecting overall structure such as headings etc.
In documents that don't have any such structure, AscToHTM is liable to convert any line with a number at the start into a heading.
To prevent this, you can mark the document as simple, that is with no global structure. In a simple document AscToHTM will attempt far less analysis.
This appears on-screen as "Expect only a simple layout"
AscToHTM attempts to automatically identify simple documents, but you may still need to set this policy manually.
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM can markup C-like code fragments in <PRE>...</PRE> tags to preserve the layout and readability of the quoted code.
This may be automatically detected, but occasionally needs to be manually corrected.
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM can convert files that use the DOS (OEM) character set. By default the file is assumed to be in the ANSI character set, but some files may have originated under DOS.
This may be automatically detected, but usually needs to be manually set.
(New in version 5.0)
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM has some ability to detect files that contain Unicode characters or which are themselves encoded using Unicode. Where Unicode is detected on input, and UTF-8 file will be created as output, and extra care will be taken when processing file not to split any of the multi-byte character values.
This should be automatically detected, but may sometimes needs to be set manually.
(New in version 5.0)
Menu location: Conversion Options -> Analysis Policies -> File Structure
Indicates that the input file contains PCL printer codes. When set, the program will make whatever sensible use it can of these codes, otherwise they will be removed.
Please note that the PCL printer codes offer a rich command language that may be used to drive graphical printers. As such the emulation possibilities in a text converter are limited, and it is quite likely that files that make heavy use of such codes will fail dramatically to convert.
That said, those codes that are not recognised will be eliminated from the output.
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM is designed to convert ASCII files, and is biased to parsing the structure of files written in European languages.
However, this policy can tell the program that there are some non-ASCII characters (Japanese, Chinese, Korean etc) present. When this is the case certain conversions of exotic characters to HTML entities are disabled so that there is some prospect of the HTML still being readable in a browser.
There is a limited ability for this policy to be auto-detected.
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM can convert mime-encoded quotable characters. These will usually appear in files that were originally part of an email message. Such files use the "=" character to escape special characters. So for example "=20" should be interpreted as a space.
This appears on-screen as "Contains mime-encoded quotable characters"
This may be automatically detected in files where the "=" is used to break up long lines, but more usually you will need to manually set this.
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM can strip out change bars in documents that contain them. Change bars are usually a vertical bar '|' placed in the leftmost or rightmost column.
Currently this is not automatically detected, and so will need to be manually switched on.
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM has a limited ability to remove page markers. These are normally a few lines following a form feed (FF) character, containing page numbers etc. This will commonly occur with files generated from older software packages.
Menu location: Conversion Options -> Analysis Policies -> File Structure
The number of lines after each form feed (FF) that should be ignored. These lines will not be copied to the output.
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM recognises documents that are left justified (default), right justified, centred or both left and right justified (confusingly known as "justified").
The program cannot currently mark up the text in a matching style, but this policy is important in the analysis. For example "justified" documents are padded with extra white space which could be interpreted as pre-formatted text where the document not recognised as being justified.
Normally this policy is correctly detected automatically.
Menu location: Conversion Options -> Analysis Policies -> File Structure
AscToHTM will normally treat a blank line as a break between paragraphs. Some files have extra CR/LF characters (usually if they've come from a different computer, or from a printer package). In such cases AscToHTM will see every second line as blank, and this will affect the analysis, usually by turning each line of data into a separate paragraph.
If you have such a file, use this policy to mark the file as double spaced to get better results.
(New in version 5.0)
Menu location: Conversion Options -> Analysis Policies -> File Structure
This specifies how many lines from the input files should be ignored at the start of the file. These lines will be discarded from the output.
This can be useful when converting file copied from a news feed or whatever that adds a small data header to the file.
(New in version 5.0)
Menu location: Conversion Options -> Analysis Policies -> File Structure
This specifies how many lines from the input files should be ignored at the end of the file. Up to 40 lines may be ignored in this way. These lines will be discarded from the output.
This can be useful when converting file copied from a news feed or whatever that adds a small data footer to the file.
Menu location: Conversion options -> Analysis Policies -> Headings
These policies determine the headings structure that the document is expected to have. Normally these are calculated correctly by AscToHTM, but due to the complexity of heading detection, you may sometimes need to correct the analysis.
At the top of the dialog you can specify what type of headings you expect to see. Any combination is allowed, although usually documents use just one type of heading.
If numbered headings are expected, it may be possible to expect headings at multiple levels, and to also expect a contents list. Each level of heading will have it's own set of policies which are shown on this dialog. The policies are shown in text form, but are edited via the Advanced Headings Policies Dialog
Note: This area of functionality is continually under review.
See also the discussion in detecting headings and section titles.
Menu location: Conversion options -> Analysis Policies -> Headings
This policy specifies whether or not numbered headings are expected in the document.
Numbered headings may be found at multiple levels, and their details may be edited via the Advanced Headings Policies Dialog
This should be calculated correctly by AscToHTM. But is prone to error, getting confused by numbered bullets and the like. In such cases you may need to set this policy manually.
Menu location: Conversion options -> Analysis Policies -> Headings
This policy specifies whether or not underlined headings are expected. Note, where the headings themselves are numbered, the underlining will be taken into account, and you should set the expect numbered headings policy instead.
AscToHTM uses the character in the underlining to determine the heading level, thus text underlined with equals signs is given prominence over text with single underline characters such as minus signs, tildes or underscores.
Menu location: Conversion options -> Analysis Policies -> Headings
This policy specifies whether or not CAPITALISED headings are expected. Note, where the headings themselves are numbered, this policy need not be set, and instead you should set the expect numbered headings policy instead.
(New in version 5.0)
Menu location: Conversion options -> Analysis Policies -> Headings
This policy specifies whether or not "embedded" headings are expected, i.e.. the heading is "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.
This policy specifies whether or not embedded headings are expected. An embedded
heading is one where the heading is the first sentence in the first paragraph of the
section itself. The program can only detect this if the heading is in capitals.
An example might be :-
RULE 15.6 – TERMS AND CONDITIONS. The terms and conditions that apply
are described in this section. They will apply...
In this case the text "RULE 15.6 – TERMS AND CONDITIONS" will be treated as the embedded heading.
At present such headings are not auto-detected... you need to switch this policy.
(New in version 5.0)
Menu location: Conversion options -> Analysis Policies -> Headings
If specified, then any line that begins with one of the key phrases will be regarded as a heading. The syntax is
<details>, <details>...
where each set of details is
<details> = <phrases>, [<heading_level>]
and
<phrases> = <phrase_1> [|<phase_2>]
That is, each set of <details> can optionally specify a <heading_level>. If omitted this will default to 1,2,3 for the first, second, third set of details etc. Note, this is a logical heading level, and will be apparent in the contents list.
Each set of <details> must supply a set of <phrases>, and each set of phrases would must have at least one phrase with extra phrases added if wanted, separated by vertical bars.
So for example
Part, Chapter, Section
would treat lines beginning with the words "Part", "Chapter" and "Section" as level 1,2, and 3 headings.
The key phrases are case-sensitive in order to reduce the likelihood of false matches with lines that just happen to have these phrases at the start of the line. So
PART|Part, Chapter, Section
Would allow either "PART" or "Part" to be matched.
"PART|Part,1" , "Chapter,2" , "Section,2"
Would make lines beginning with "Part" level-1 headings, while both "Chapter" and "Section" would become level 2. This would be the same as
"PART|Part,1" , "Chapter|Section,2"
Note, spaces may form part of a match phrase, but because of their use in the tag syntax commands and vertical bars may not.
If false matches occur, (e.g. the word "Part" appears in the body of the text) edit the source text so that the offending word is no longer at the start of the line.
(New in version 5.0)
Menu location: Conversion options -> Analysis Policies -> Headings
When this option is selected, the first line in the document will be treated as a heading. This can be a useful option to select when the first line of your document is a document title line, but doesn't conform to the headings style used in the rest of the document.
See also use first line as title
(New in version 5.0)
Menu location: Conversion options -> Analysis Policies -> Headings
When this option is selected, the first heading in the document is centred. This may be an appropriate choice when the first heading is in fact to be treated as a document title.
See also use first line as heading
Menu location: Conversion options -> Analysis Policies -> Headings
The program performs a number of consistency checks when detecting headings. Amongst these is a check that all headings of the same type occur at the same indentation. This check can help distinguish between numbered headings and numbered lists.
However, if you have numbered headings that are different indentations - e.g. because they are centred on the page - then this check will cause them to be rejected as headings. In such cases you can manually disable this check.
This appears on-screen as "Check indentations of headings are consistent"
Menu location: Conversion options -> Analysis Policies -> Headings -> Advanced Options
This dialog is reached through one of the edit buttons on the main Headings Policies dialog. This allows you to edit details of a particular type or level of heading.
Position of section number on the line
Section number formatting
Bracketing
See also Heading policies in a policy file.
Menu location: Conversion options -> Analysis Policies -> Headings -> Advanced Options
AscToHTM uses checks on indentation levels to reject lines with numbers on that could be confused with headers.
This is the indentation level (in characters) that heading of this types are expected to be found at.
Menu location: Conversion options -> Analysis Policies -> Headings -> Advanced Options
Some documents put words like "chapter", "subject" and "section" in front of the section number. These are known as prefix words.
Menu location: Conversion options -> Analysis Policies -> Headings -> Advanced Options
This is the numbering scheme expected for headings at this level. At present AscToHTM can't cope with mixed types like "II-2.b".
This may be addressed in later versions.
Menu location: Conversion options -> Analysis Policies -> Headings -> Advanced Options
This shows the separator expected between parts of the heading number.
Not currently supported
Menu location: Conversion options -> Analysis Policies -> Headings -> Advanced Options
This shows whether we expect trailing letters after the section number, as in "1.1b".
Not currently supported
Menu location: Conversion options -> Analysis Policies -> Headings -> Advanced Options
This shows what bracket characters (if any) we expect before and after the section number as in "[2.2]" or "3.2.1)".
Not currently supported
Menu location: Conversion options -> Analysis Policies -> Pre-formatted text
These policies specify how AscToHTM detects pre-formatted text.
Detecting pre-formatted regions
See the section on pre-formatted text for more details.
These policies specify how AscToHTM detects pre-formatted text.
Menu location: Conversion options -> Analysis Policies -> Pre-formatted text
This policy specifies the minimum number of consecutive pre-formatted lines that must be detected before <PRE>...</PRE> markup is applied.
AscToHTM detects heavily formatted lines, and then looks at their neighbours to see if they too could be part of a pre-formatted text.
Once a group of lines is identifies, it will only be marked up as pre-formatted if the minimum is exceeded.
The default value is 0. Set this value larger if AscToHTM is marking text as pre-formatted when it shouldn't do.
Menu location: Conversion options -> Analysis policies -> Tables
These policies specify how AscToHTM detects possible tables and analyses the data in them into columns and rows.
Detection
Analysing rows
Analysing columns
See the section on pre-formatted text for more details.
Menu location: Conversion options -> Analysis policies -> Tables
This policy specifies whether or not you want HTML table generation attempted for regions of apparently pre-formatted text. AscToHTM will attempt to analyse such regions, preferring to fit them into a HTML table. However, if this is not possible, or if AscToHTM decides the pre-formatted region is something else (like a diagram or a piece of code) then a HTML table will not be generated.
Disabling this policy tells AscToHTM not to attempt this analysis, usually leading to pre-formatted text being placed in simple fixed width font markup instead.
Menu location: Conversion options -> Analysis policies -> Tables
When the program encounters a strongly formatted line, it examines the adjacent lines to see if they too could form part of the same preformatted region.
This policy specifies the extend to which strongly preformatted lines should be used to "extend" to include adjacent lines as part of the same preformatted regions. If set to 10, then all adjacent lines up to the next page break or section heading will be treated as part of the same region. When set to 1 only those lines that are clearly heavily formatted themselves will be included.
This appears on-screen as "Extend preformatted regions"
(New in version 5.0)
Menu location: Conversion options -> Analysis policies -> Tables
This specifies the maximum length of line that could be considered as a possible table line. Since some files output one paragraph per line, it is possible for some text to contain a lot of the "markers" used to detect table lines, and to be wrongly diagnosed as part of a table. This value is set to prevent that happening.
The value should be set as low as reasonable for your files, however the current default value of 256 has been set to cope with observed legacy reports which were often designed to be printed on line printer paper
(New in version 5.0)
Menu location: Conversion options -> Analysis policies -> Tables
This option specifies whether or not tables are expected to have blank lines between rows. If they are, the software will be more likely to merge the text for adjacent source lines into a single row in the output table.
(New in version 5.0)
Menu location: Conversion options -> Analysis policies -> Tables
This option allows you to specify the default table layout for all tables in the document. The layout specifies the number of columns and their end positions. If there are no gaps between columns in the data then you will need to enable the Column boundaries have zero width options.
This is the default layout and will normally be applied to all tables the document. If a document has multiple tables you are better off either using the pre-processor to mark up the source text and supplying TABLE_LAYOUT commands, or supplying a "Layout" component in a Table Definition File.
The format of the Table Layout policy is the same as that described in the discussion of the TABLE_LAYOUT pre-processor command.
See also TDF line: Layout
(New in version 5.0)
Menu location: Conversion options -> Analysis policies -> Tables
When a Default TABLE layout is set, this specifies whether or not the boundaries between columns have zero size. By default the software assumes there is a single-character boundary (either a space or a delimiter character) between columns.
Sometimes data comes from a source with no character between data columns. This policy should be set in such cases.
Menu location: Conversion options -> Analysis policies -> Tables
This policy is used to tell AscToHTM that you expect your tables to be quite sparse in places. This can affect AscToHTM's analysis, as the algorithms are liable to merge "empty" columns with their less empty neighbours.
Enabling this policy will usually result in your tables having more, emptier, columns.
See also the Pre-processor command: TABLE_MAY_BE_SPARSE.
Menu location: Conversion options -> Analysis policies -> Tables
This policy specifies that the table header should be ignored when analysing the column structure of the table.
In some tables (usually "reports") the header can be quite complex, with titles spanning multiple columns, whereas the body of the table is much more structured.
In such cases including the table header in the analysis can lead to errors, so enabling this policy can simplify the analysis giving better chances of success.
See also Expect multiple COLSPAN values
This appears on-screen as "Ignore table header when analysing columns"
(New in version 5.0)
Menu location: Conversion options -> Analysis policies -> Tables
When auto-detecting the column structure of tables, the software has to decide where the column boundaries are, and in doing this it looks for character positions that appear to contain mostly blank or non-text characters.
The analysis can have problems if the table has a lot of data that spans multiple columns (in HTML this would require a COLSPAN value to merge the cells together). Tables with complex headers (e.g. financial tables merging results from many sources) or witchy internal headers often have this feature.
If you have such tables and find that the analysis is failing to detect your columns (commonly merging columns together), try enabling this option which will relax the definition of what constitutes such a table.
In such cases you should also review your use of the Column merging factor and Ignore table header during analysis policies.
This appears on-screen as "Expect cells that span multiple columns"
Menu location: Conversion options -> Analysis policies -> Tables
This policy specifies the minimum number of spaces that should be interpreted as a gap between columns in a potential table. The default value is 1, but this value can sometimes lead to too many columns, especially in small tables. Larger values may lead to columns being merged together.
This appears on-screen as "Minimum number of spaces between table columns"
Menu location: Conversion options -> Analysis policies -> Tables
Once the program has detected the column layout of a table, it reviews how well the data can be fitted into these columns. If too many cells in a column are empty, or if too many cells "span" multiple columns, then the columns are deemed to be "poor", and may be merged together to form fewer, wider columns.
This factor determines the extent to which columns should be merged. A value of 10 means columns should be merged together whenever there is any doubt. Use this if you are getting too many columns. A value of 1 means columns should never be merged. Use this if you are getting too few columns.
This appears on-screen as "Merge together "poor" columns"
Note, this policy can't guarantee you will the correct column structure, but it does give you a chance to influence the logic.
Menu location: Conversion options -> Output policies
These policies are used to control the output to HTML. Generally these policies allow you to decide how the resulting HTML should look in a manner that cannot be inferred from the original document.
Menu location: Conversion options -> Output policies -> Title description etc.
These policies allow you to "add value" to the HTML produced. That is, to specify details that cannot be inferred from the original text.
Title
Meta tags
Other
A button will take you to the Advanced HTML options dialog
Menu location: Conversion options -> Output policies -> Title description etc.
When this option is selected, the first heading detected in the document will also be used as the document's title, i.e. as the text that goes into the <TITLE>...</TITLE> tags in the <HEAD>...</HEAD> section of the generated HTML pages.
Note, this relies on the program correctly detecting headings, and in particular the first heading. If the first heading is also the first line, you may want to instead just consider using the use first line as heading and/or use first heading as title policies.
If no heading is encountered the document title is used instead
Menu location: Conversion options -> Output policies -> Title description etc.
When this option is selected, the first line in the document will be treated as the document title, i.e. as the text that goes into the <TITLE>...</TITLE> tags in the <HEAD>...</HEAD> section of the generated HTML pages.
This can be a useful option to select when the first line of your document is a document title line.
If you also want the first line to appear in the output as a heading, select the use first line as heading option
This will only take effect if the first heading is not to be used, or no heading has been found.
Menu location: Conversion options -> Output policies -> Title description etc.
This specifies the text to be used by default in the <TITLE>...</TITLE> tags in the <HEAD>...</HEAD> section of the generated HTML pages. The default value is
Converted from [[filename]]
where [[filename]] gets replaced by the original filename (see Pre-processor command: filename).
This value will only be used if the first heading is not to be used (or is not found), and if the first line is not to be used.
If you want this to be the title, make sure the "Use first heading" and "use first line" options are disabled.
See also:
Menu location: Conversion options -> Output policies -> Title description etc.
This specifies text that will be inserted into a <META> tag in the <HEAD> portion of your HTML page. Search engines use this description when indexing your page, and may be shown as the summary of your page when people search for it.
This text is not normally visible in a browser.
Menu location: Conversion options -> Output policies -> Title description etc.
This specifies text that will be inserted into a <META> tag in the <HEAD> portion of your HTML page. Search engines will use these keywords when indexing your page. You should add here any keywords that summarise the contents of your page, and in particular include words not actually in the document, or alternative spellings (e.g. American versus UK English).
This text is not normally visible in a browser.
(New in version 5.0)
Menu location: Conversion options -> Output policies -> Title description etc.
Identifies the URL of the author of this document. A META tag will be added to the HTML so that those browsers that can display this information can use it.
(New in version 5.0)
Menu location: Conversion options -> Output policies -> Title description etc.
Identifies the URL to be used as the bookmark for this document. A META tag will be added to the HTML so that those browsers that understand this information can use it.
(New in version 5.0)
Menu location: Conversion options -> Output policies -> Title description etc.
Identifies a URL describing the copyright notice for this document. A META tag will be added to the HTML so that those browsers that can display this information can use it.
(New in version 5.0)
Menu location: Conversion options -> Output policies -> Title description etc.
Identifies the URL of any icon to be used as a shortcut for this page. A META tag will be added to the HTML so that those browsers that support shortcut icons can use it.
Menu location: Conversion options -> Output policies -> Title description etc.
This specifies the image file to be drawn as background on your HTML page. This is the text inserted into the <BODY BGIMAGE=value> tag in the generated HTML.
The value entered should be the absolute or relative URL of the file to be used. Usually this is simply the name of a .GIF or .JPG file that will be placed in the same directory as the created .HTML files.
Menu location: Conversion options -> Output policies -> Title description etc. (and then press the "Advanced options >>>" button
These policies allow you to control more advanced features that influence HTML generation.
HTML Options
Character Set
Include files
These policies allow you insert files into your output HTML at
particular locations. This can be useful to give your pages a
common "look and feel".
Menu location: Conversion options -> Output policies -> Title description etc. (and then press the "Advanced options >>>" button
This policy specifies that the <HTML>, <HEAD> and <BODY> tags should be omitted from the HTML generated. This will end up producing HTML that is not, technically, a correct standalone document, although many browsers will display it correctly.
You shoul