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.
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 happened: 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 thumb 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.
Obvously, nearly everyone spitts on html-0.32, and you can not take this DTD serious. Even worse, there is no one else you can take serious for html. 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. I am really to lazy to keep track with all this shit..
Anyway, this shouldn't cause real problems for you, except maybe some wrong jerk-related warnings.
PROGDIR:, which is automatically
assigned to the same directory where the hsc binary resides
when hsc is invoked
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 and options 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 of this concept: 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 entities 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.