Everything hsc knows about html, it retrieves from a file named hsc.prefs at startup. This file contains information about all tags, entities and icon-entites. Additionally, some special attributes are set up there also.
The main advantage of this concept is that it's rather
easy to add new syntax elements. For this task, the hsc-tags
<$deftag>, <$defent> and <$deficon> can be used. See below
for more details.
The hsc.prefs coming with this distribution should support most elements needed for everyday use. This includes full html-2.0-support, tables, figures, client-side image-maps and several elements only used by special browsers.
But several weeks ago, something terrible has happended: html-0.32 has been released. From my point of view, this nothing more than the proof that those browser-developers, who clutter their software with loads of jerk-tags are too tumb to write a DTD (Document Type Definition) themselves and that the only reason that w3c still exists is that someone has to write those DTDs to pretend that there is a concept behind html.
Altough the DTD is out since 7-May-1996, there are less other documents available about html-0.32. Therefor, the current hsc.prefs is in a bit chaotic state and a mixture of html-2.0, html-3.0-draft and html-0.32. Anyway, this shouldn't cause real problems for you, expept some maybe wrong jerk-related warnings.
hsc looks at several places when trying to open hsc.prefs. At first,
it will examine the current directory. It it doesn't succeed, it tries
to read the environment-variable HSCPREFS and interprets it
contents as directory to look for hsc.prefs. If it still is unable to
find the syntax-definition, further directories scanned depend on the
operating system hsc runs on:
"env:" and "s:"
"/usr/local/lib/"
If it is unable to find hsc.prefs anywhere, it will abort with an error-message.
If you want to find out where hsc has read hsc.prefs from, you can use STATUS=VERBOSE when invoking hsc. This will display the preferences used.
This tag defines
a new entity. The (required) attribute NAME declares the
name of the entity, RPLC the character that should be
replaced by this entity if found in the hsc-source and NUM
is the numeric representation of this entity.
<$defent NAME="uuml" RPLC="ΓΌ" NUM="252">
This tag defines
a new icon-entity. The only (required) attribute is NAME
which declares the name of the icon.
<$deficon NAME="mail">
This tag defines
a new tag, and is used quite similar to <$macro>, exept that a
tag-definition requires no macro-text and end-tag to be followed.
<$deftag IMG SRC:uri/x/z/r ALT:string ALIGN:enum("top|bottom|middle") ISMAP:bool WIDTH:string HEIGHT:string>
To fully understand the above line, you might also want to read the sections about attributes for tags and macros and flags for tags and macros.
For those, who are not smart enough or simply to lazy, here are some simple examples, which should also work somehow, though some features of hsc might not work:
<$deftag BODY /CLOSE BGCOLOR:string> <$deftag IMG SRC:uri ALT:string ALIGN:string ISMAP:bool>
There are also some disadvantages: reading hsc.prefs every time on startup uses an awful lot of time. Usually, processing your main data takes shorter than reading the preferences. You can reduce this time, if you create your own hsc.prefs with all tags and entites you don't need removed. But I recommend to avoid this because you might have to edit your preferences again with the next update of hsc, if any new features have been added.
You also can't use the DTDs. This is because DTDs don't contain several information needed by hsc, for example entities are not defined within he DTD. Also several features of hsc like evaluation of image-sizes or stripping of external URIs can only be controlled with hsc.prefs.