Versions file for OvHTML
========================

0.00   2002/09/18

       Basically an empty shell.

       Found an oddity in Ovation Pro. Right, take the !RunImage in OvHTML
       and rename it so it won't be run. Then drag an HTML file to OvationPro
       and you'll see the error "File blahblahblah not found". Once you
       dismiss that, OvationPro will pop up an error saying "File could not
       be converted".
       Fair enough... but look at the title. It says "Message from ArcFax".
       Do WHAT?
       This is OvationPro 2.67, and I'm using the 204Mb harddisc so ArcFax is
       not even installed. The ArcFax printer driver is around but I do not
       load !Printers 99% of the time.
       So I looked in OP's !RunImage, libraries, resources, templates. I mean
       David Pilling also made ArcFax so if he borrowed a bit of code and
       forgot to take the message out it would make sense. But "arcfax" does
       not seem to appear anywhere. Confused? I sure as hell am!


       2002/09/28

       First working version. Pretty much did <pre> and text styles like <i>
       and <b>.



       2002/09/29

       Added lookups for entities. Done table for extended entities and
       matched a bunch of stuff in the Sidney font - though I'm not sure I've
       got the Greek letters right.


       2002/09/30

       Character entities now matched by a single call which deals with
       normal entities, extended, numerical, and handles errors. I would like
       to put in special handlers for common UniCode things - I used to keep
       seeing Fresco report something like "&8432;" which I think was a
       copyright symbol. If anybody can send me a list I'll do it.

       The parser now has a big table of supported HTML commands and their
       tokens. A lot easier to whizz the list than to do a stupid pile of
       strcmp() calls.

       Turned the configuration guff into a bit-field struct. Now it takes
       one word plus version byte. The whole lot in five bytes. Way cool. Of
       course I lose a gazillion bytes in the LFAU, but the intentions are
       good. :-)

       Got Avril Lavign's CD "Let Go". Way cool!



0.01   2002/10/07

       Font set/unset is now handled by special code. This allows OvHTML to
       keep track of up to 16 'changes'.

       Added code for <a href...>. Not complete, it will only underline
       and/or bluify. It won't greenify for non-ftp/http URIs. Not yet.

       Added <address>. Change to Homerton and italicise it.

       Added <b>.

       Added <blockquote>. This basically just indents. It's the basis for
       testing an indent method for <ul>/<ol>/<dl> stuff (in the future).

       Added <cite>. It just calls the handler for <i>.

       Added <dfn>. It calls <b>.

       Added <h1> to <h6>. You can tweak the styles if you don't like them,
       look in !OvHTML.data.definition, but please note the 'switch off'
       command is "" so don't get /too/ enthusiastic!

       Added <kbd>. Same code as for <code> and <tt>.

       Added <plaintext>. Also supported the apparently invalid </plaintext>.
       You see, after a <plaintext>, the entire rest of the document is
       supposed to be... well... plain text. But Fresco seems to support the
       </plaintext> command, so we shall too.

       Added <s> and <strike> (same thing).

       Added <samp>, it behaves like <code>.

       Added <sup> and <sub>.

       Altered <u> to set the underline colour to black (the a href might
       have set it to blue).

       Revised the whitespace system. You should now get a fairly faithful
       reproduction in <pre> and <plaintext> with leading spaces and double
       spaces; while it's all clipped sanely in normal mode. The problem of a
       blank space following a newline has been seen to.

       This has a new version number as this is the first version that I
       would consider releasing.



0.02   2002/10/08

       What an odd song "Pilots" by "Goldfrapp" is!

       Added an eggy. As you should have expected. It's quite an inventive
       eggy actually.

       In <pre> mode, tabs will advance to the next multiple of eight spaces.
       So tabbed stuff should now look correct ...
       ... like "Twin Peaks: Fire Walk With Me".

       The default colours (Black, White, Transparent, and VDU Red/Yellow/
       Green/Blue/Magenta/Cyan (recognise that order?)) are now built
       directly into the program.

       You can now call OvHTML with the (single) command line parameter
       "-version" to find out exactly when it was compiled. If you should
       ever feel so inclined... :-)

       PS:  I live in Europe, so "CET" is Central European Time - which is
            British time +1, or Washington, DC time +6.
       PPS: For the nerds:
              *Status [highlights]
              DST
              TimeZone +1:0
              *Territories
              13 RickFrance
              6 France
              1 UK
            13 is my France, with French dates but English number system.
            6 is France, downloaded I *think* from Jerme Matthevet's site.
            1 is UK, amended to have ISO 8601 dates (the ccyy/mm/dd form).

       Just so you know, calling it with "-configure" (alone) will enter the
       configuration mode. That's what the "CheckIfAlt" program does. You
       must do this from the desktop though - else it'll whinge when trying
       to start itself as a desktop application.

       The !Boot file now sets up &FAF (HTML) file descriptions and icon if
       it has not already been done.



0.03   2002/10/09

       Removed "wbr" and "nobr" as these did not have any relevence.
       
       Added suppression of output. This is set by default at the start, and
       unset when <body> is encountered - anything before <body> is simply
       dropped on the floor.
       
       Added <script> and </script>. These disable output when in script.
       
       Just tried it with pages cached from BT's site. Oh dear! It builds
       up the document in JavaScript (yuck!) and seeing "<body>" within the
       script re-enabled output. :-)
       So now if within script block, all HTML openers are ignored, and the
       only recognised closer is "</script>". Now BT's business services
       page is readable. :-)
       
       I will not be including support for <? ... ?> script blocks (such as
       php) because this stuff is handled by the web server - you are
       unlikely to encounter this from a real web site; you'll only get it
       from 'local' pages if you use php-alike scripting in them. :-)
       
       Now supports alignment types in <center>, <h1>-<h6>, <p> and <div>.
       Also sets alignment if specified in <img>.
       
       Upon image, will output "[ image "<name>" ]" in italics.  Also added
       special code to unset image alignments (there's no </img> you see!).
       The <name> is the leafname of the image, so it'll be something like
       "willow2.jpeg". I am not using "alt" text, as I've seen (and created)
       some rather long alt descriptions... but most of mine say the image
       format and size (in kilobytes), 'cos the pictures are usually
       described in the document.
       
       Will now greenify URIs for:
          cso:
          file:
          finger:
          gopher:
          mailto:
          news:         snews:
          newspost:     snewspost:
          newsreply:    snewsreply:
          nntp:
          telnet:
          wais:
       [this list yanked out of Lynx for RISC OS, v2.8.4rel.1].
          
       <hr> outputs a paragraph break, so things are better formatted. It
       doesn't output a line (yet?).



0.04   2002/10/10

       Had very little time to work on this today, but I got <ul>/<ol> & <dl>
       lists working, as follows:
         <ul>   Okay. First level prefixed '*', second level '+', then '#',
                then '%', then it wraps back to '*'. Sorta like in Lynx.
         <ol>   Always counts from 1 - I'll do start subparse later.
         <dl>   Does not do different indent levels for <dt> and <dd>, but
                it does do <dt> in bold.
       The indent holds for wrapping, but it will wrap back over the prefix.
       What I mean is:
         What would be perfect:
           1.  some boring text blah blah blah blah blah blah blah blah blah
               blah blah blah
           2.  more boring text blah blah blah blah blah blah blah blah blah
               blah blah blah
         What actually happens:
           1.  some boring text blah blah blah blah blah blah blah blah blah
           blah blah blah
           2.  more boring text blah blah blah blah blah blah blah blah blah
           blah blah blah
         This is because we're using a desktop publisher's script language,
         not a browser. You can fix it by inserting a bunch of tabs, so...

       The <dir> and <menu> is not working correctly yet, and there's too
       much whitespace inserted in the lists.
       Other than that, it looks pretty much like Webite's output, only
       without the cute circle graphic. I've run out of time today, so I'll
       see to this tomorrow, tomorrow, I'll love ya tomorrow... <gah!>



0.05   2002/10/11

       Added "debug" option to advanced section. Now all that debug rubbish
       can be switched seperately. Please note that debug output writes a
       lot of stuff to the DDL file.
       The best way to use it is to write an Obey file to call OvHTML, then
       run that. Including it as due course when using OvationPro will make
       things larger/slower to no effect - as Ovation removes the temporary
       files when done with them.
       
       The "Include processed HTML as comments" will now output the HTML
       interpreted, followed by either a token number or "(unrecognised)".

       Tightened up the spacing around <h#>...</h#> blocks, don't need so
       much whitespace!
       
       Implemented <dir> and <menu>, and tightened up the spacing in the
       list handler code. The lists are now very similar to Webite, even
       down to only outputting a trailing linespace when all lists closed,
       and not during nested lists. Cool, huh? :-)
       
       
       Now has option to omit unknown &blah; entities, instead of writing
       them out to the document in red.

       Option to reset styles upon a paragraph break, ie, a "<p>" command.
       Totally. Effective, but nasty. Oh yes!

       "Try-to-recover" mode implemented. Upon errors that would normally
       cause an abort, but are theoretically recoverable (like running out
       of font stack), the Try-to-recover will kick in.
       How it works is:
         If you run out of some sort of stack space, you will be given a
         warning. Then the font/style/whatever stack will be wiped and the
         pointers reset. Then the font/style/whatever will be reset in the
         document (as appropriate).
       Parsing will cause possibly incorrect output - ie, as the HTML
       unwinds, the styles will not be available. Having said that, the
       stacks are 16 deep - it takes effort to mess 'em up. Look in the
       "testdoc2" HTML source to see what I mean.
       
       Now parses <font face=xxx>, the complete and total mapping is as
       follows:
          Georgia                Trinity
          Serif                  Trinity
          Times New Roman        Trinity
          Times.New.Roman        Trinity
          TimesNewRoman          Trinity
          Times                  Trinity

          Arial                  Homerton
          Arial Narrow           Homerton
          Ariel                  Homerton (for those who can't spell "arial"!)
          Geneva                 Homerton
          Helvetica              Homerton
          Sans Serif             Homerton
          Sans-Serif             Homerton
          Trebuchet MS           Homerton
          Univers                Homerton
          Verdana                Homerton

          Courier                Corpus
          Courier New            Corpus
          Mono                   Corpus

          Comic.sans.MS          Sassoon
          Comic sans MS          Sassoon

        The matching is not case sensitve.
        If you have any other font face names, please let me know. I did
        search my entire Fresco cache and my BtVS archives, so hopefully
        I've included all of the "most popular" definitions.
        The only ones I've come across that I can't figure out are "algerian"
        and "alluressk".
        I've examined 7,359 <font> commands, so I should hope that I've got
        all the common ones! :-)

        Now also parses <font size>, both absolute values, and +/- base
        size. Each size is worth 2pt different, thus:
          Size 1 =  8pt
          Size 2 = 10pt
          Size 3 = 12pt [default]
          Size 4 = 14pt
          Size 5 = 16pt
          Size 6 = 18pt
          Size 7 = 20pt
       
        So cool... :-) I dropped the shooting script 6/01a for Buffy the
        Vampire Slayer (season six, episode 1, part one; "Bargaining") and
        it required only one adjustment to make it 'look' correct; that
        being the inner table was wrapped in a <center>, which threw off the
        alignment code as it didn't understand tables... Removing the extra
        <center> and it looked good.
        
        So then I tried http://www.heyrick.co.uk/assembler/debugger.html
        :-) Nice.       [okay, I lie, I've got it on disc, but that URL
                         is where you'll find it if you wish to try it!]



0.06   2002/10/12

       Didn't have much time to work on OvHTML today as I spent lots of time
       writing my songbook. Well, it is poetry right now. I'll do the music
       when my crap comes over from England and I have, like, actual musical
       instruments to work out a tune on. :-)

       Now detects if/not it is running in the desktop, and will report
       version and no-parameter error in error box if in desktop, or printed
       to VDU if not. You'll need to be in desktop for configuration or
       processing.

       Option to include unrecognised HTML in red. Parameters are stripped,
       you'll only get the tag itself.



0.07   2002/10/13

       Now properly supports extended entities (before it'd recognise them
       but not output anything.

       Tested the "testdoc" file on Fresco (v2.23 I think). It doesn't do
       badly but it does not attempt font face recognition. Shame. Nor does
       it understand much of the extension characters.
       Won't set up Oregano 1.10JS because I'm using the 200Mb disc as the
       bigger one is acting up, and Oregano is *way* too liberal with system
       resources ... it's like the RISC OS answer to Microsoft!
       Tested the "testdoc" file on Webbite 1.49. It makes a reasonable HTML
       2.0 output, but stops at <plaintext> ... hehe!

       Some internal tidying.

       Add <left> ... </left> and <right> ... </right>. Not valid HTML, but
       I've seen them used and they're easy enough to implement.

       Now supports an <ovhtml> command:
         <ovhtml fontsize=12>        8 to 20, to set base size, in points.
         <ovhtml leading=10>         5 to 200, to set leading, in percent.
         <ovhtml macro="xxxxx">    Output code from macro (into DDL).
         <ovhtml ddlscript "xxxx">   Output DDL script string into file.
         <ovhtml ddlcomment "xxxx">  Output string as a comment in the DDL.
         <ovhtml debug [on|off]>     Switch debug output on or off.
         <ovhtml debug parsevars>    Dump the parser status (into doc!).
         <ovhtml debug config>       Output OvHTML config (into doc!).
         <ovhtml debug [in|out]file> Output name of input/output file.
         <ovhtml appname>            Output application name "OvHTML".
         <ovhtml appvers>            Output software version, like "0.06".
         <ovhtml appdate>            Output vers date, "12th October 2002".
         <ovhtml appauth>            Output name of the geek responsible.
         <ovhtml copystr>            Output standard 'copyright string'.

       The description blocks now contain macros (must be uppercase):
         FGCOL      The current foreground (text) colour
         BGCOL      The current background (page) colour
         FSIZE      The current font size
         TLEAD      The current text leading (that's said like 'ledding')
         ALIGN      The current text alignment
       This output DDL *CODE*, not a value, so "FSIZE" will cause something
       like "{textsize 12000}" to be output.
       The '' key is Alt- on older 'Archimedes-era' machines, and
       Shift-Alt-3 on RiscPCs. On RISC OS 3.70 it gives the eggy symbol, the
       'o' with four 'handles'. It may, on RISC OS 4, display the Euro
       currency symbol. FontManager 3.54 has additional encodings, but no
       Euro symbol, so I'm not sure exactly when this was introduced.
       If you get stuck, either cut'n'paste from the above, or hold down the
       Alt key and tap out 164 on the numeric keypad.

       Finally, got around to doing the 'smart quotes'.



0.08   2002/10/16

       Fixed bugette with default alignment reverting to left aligned if was
       supposed to be justified.
       
       Now sets filetype of output file to DDL script.
       
       Added pre-process. Now if:
          <ovhtml fontsize ##>
       or
          <ovhtml leading ##>
       appear BEFORE the <body> tag, they will be used as defaults, but only
       if pre-processing is active. If "processing blind", you'll get the
       standard font size/leading (12pt, 20%).
       
       Began work on colour lookups and colour name/value recognition. I've
       summed lots of coding into a single sentence. Wow-ee!



0.09   2002/10/17

       Added <big> and <small>. Oops! Well, I never did claim my memory was
       any good.
       It bigs/smalls from the current font size (even if adjusted with
       <font size...>), is this correct or should it be relative to the base
       size?
       
       Now parses colours that are given by value (like "#ffffff" for white)
       in standard or extended colour range.
       
       Little 'fix' to get rid of that "initial space character" that always
       seemed to crop up.
       
       Now correctly sets URI colours according to (v)link colours, or uses
       default blue/green if no (v)link colours defined.
       
       I've decided... To hell with it. I've had *enough* of seeing all these
       frickin' web pages with "Verdana" and "Arial". So, you may if you wish
       refer to the fonts as "Corpus", "Homerton", "Sassoon", and "Trinity"
       and OvHTML will deal.
       [okay, I draw the line at font names, don't try "Trinity.Medium" as
        it won't be recognised... at least, not by this version. ;^) ]

       Pops up Hourglass after the standard 1/3rd second. Counts the percent
       processed (includes correction for blind processing or not), has the
       upper Hourglass LED on when preprocessing (well, < 50% too!).

       Way cool! Now supports looking up colours by name. Mmmm...



0.10   2002/10/19

       Isn't software considered "ready for release" when it hits two digits
       in the version number? <giggle>
       
       Now can be run within a TaskWindow and it'll behave as if it was run
       from the command line, instead of an error about "WindowManager is
       currently active"... :-)
       
       The Select command length can be longer than 256 characters (I wonder
       how much stuff /that/ broke?); I don't know exactly how long a filename
       can be - so I allocate memory for the filename buffers on the fly
       instead of a pre-defined buffer.
       
       Supports <embed> ... </embed>. Basically copied the <img...> bits!
       
       Now has an option to warn you upon encountering:
         <form ...>
         <frameset ...>
         <iframe ...>
         <multicol ...>
         <table>
         <style>
       all of which are unsupported, and are often used to do rather dramatic
       things to the 'look' of the document.
       You will ONLY be warned once; so if your document uses <table> and
       then <form>, you'll only get a warning for the <table>. This makes a
       lot more sense if you consider a document with twenty tables - you
       won't want twenty warnings!

       <hr> commands now write " [ horizontal rule ] " in size '2' (which is
       2pt smaller than the default size; usually 10pt), with optional
       alignment.
       
       Sanity checks for empty files and files with no <body>. It worked in
       the past, now it'll tell you about it and abort, instead of giving
       you a blank document.



0.11   2002/10/21

       Colour lookups all fixed and tested. Some pathological conditions
       caused incorrect output. Tracked 'em all down. [I hope!]
       Unknown defined colours, like, say, <font colour="rickmurray">... are
       defined as the default text colour.

       You know, there are very few CDs I can put in my player and engage the
       "Random" mode, as most CDs have a couple of good songs, and then a
       bunch of lame songs, and the rest? Filler. Somebody came up with the
       slogan "all killer no filler", but sadly I wouldn't play most of the
       CDs that advertise like that if you paid me.
       "Let Go" by Avril Lavign (spot a theme here?) is the one exception.
       I'm not 100% keen on "Skater Boi", but it's cool to have one of those
       rare CDs that you can random play without thinking "Oh God, I don't
       wanna listen to that", as it is ALL good.
       As for the copy protection system? It plays (analogue) on my RiscPC,
       and I've not enough free disc space to try to sample it. What doesn't
       work is CDFS. The disc lookup table does some weird s... which makes
       CDFS emulate Windows9x loading (you'll soon hear what I mean!). Oddly
       enough, !PC gets you a directory at least. Can't say if the software
       is any good as it doesn't want to run under Win3.11. Wonder why! :-)

       The entity scanner will now 'assume' a semicolon if it reads a space.
       In English, if it sees, say, "&copy 2002 [etc]", it will assume that
       you meant to say "&copy; 2002 [etc]". This fixes a fair few web pages.

       Damn! Reading "oakforpark" in the examples directory, I just tried to
       click on one of the 'links' for the (cached) picture. Hehe!

       Now there are two builds of !OvHTML. The normal, "!RunImage" no longer
       contains debug code or debug messages. If you require such output, you
       should use "!RunIDEBUG".
       Please note by debug, I mean the (numerous) running status messages
       within !OvHTML's DDL file. It saves some 5K in the executable, and a
       few billion K in the DDL output.
       To tell the difference, when the program is running or if you've
       moved the files around - the debug version has a 'D' after the version
       number in the Info window, and when you pass it "-version" as a command
       line parameter.



0.12   2002/10/27

       The _kernel_swi() calls have now been replaced by calls to custom
       assembler routines.

       Amended entity handler to treat "&;" as "&amp;".

       Fixed comment-walker so it will cope with:
         <!----the document content starts here---->

       Altered the parser so that it can cope with EvenMoreCrap. By this,
       I'm thinking mainly of people who don't understand the logic behind
       putting strings in quotes, and create code like:
         <img src=pathname/imagename width=100 height=100>
         <font color=black>
         <font face=verdana>

       Special OvHTML option "<ovhtml trashtt>". This is a 'fix' in this
       program for a little buglette in another. :-) Basically, if you are
       already in typewriter mode (<tt> or <code>), all further <tt> and
       <code> tags are ignored.

       Armalyser examined the 0.11 build of !OvHTML, and it said 3.5% is not
       32bit and 3.6% uses the PSR. My SharedCLib stubs are 26bit, so there
       seems little point in trying -APCS /32bit

       Just discovered OvationPro can import images in-line without defining
       the exact frame location, but an alignment - sorta like Word or
       EasiWriter. First thought - WAY COOL! Second thought - dammit, OvHTML
       will absolutely totally, like, SO have to do that.
       [I'm not an '80s valley girl, honest!]

       Why oh why oh why oh why does OS_Module 20 return the module version
       number in such a weird way? Like, OS 3.70 will be returned as &37000.
       Note - important - it's in hex. So to get the version number I looked
       in some RISC OS 2 code to see how RMEnsure does it (it didn't support
       OS_Module 20). It looked like a hell of a lot of work. So instead I
       got OS_ConvertHexSomethingorother to turn (&37000 >> 8) into a string
       which I then simply read the bytes. What I mean is basically
       ((Char1 - 48) * 100) + ((Char2 - 48) * 10)) + (Char3 - 48). Crude but
       effective.

       :-) The image ASCIIfied encoding wasn't anything near as difficult as
       I thought it would be. I sorta stared at a screenful for a few minutes
       (while humming to myself Pink's "Just like a pill" instead of doing
       any actual thought) and I thought "I wonder...". Not too long later
       I'd cobbled together some code that was 99% correct, and after
       dropping some random images into a test document, it became completely
       correct. So, the code's in BASIC, but now I know the procedure it
       should not be a problem to convert it to C.

       Downloaded the sources for DeskLib the other day - many thanks to John
       Williams ( http://www.picindex.info/ ) for that. Sadly, the version on
       the Argonet FTP site is *SERIOUSLY* old. I mean, like 1.01 IIRC. Mine
       is 2.30 and the source I used to have (pre-disc-crash) was 3.20. Still
       there should be enough there to aid me in removing DeskLib and writing
       my own custom WIMP code (some day!). No problem with DeskLib, it just
       seems to add a lot of code for a fairly rudimentary API. It's probably
       all that event handling stuff that is designed for more intense things
       than one window with a bunch'o'clickies...



0.14   2002/11/01 [hope y'all had a happy halloween!]

       Added parameter "-converthtml" and the Obey files "!SetupHTML" and
       "!RunHTML". The first of these will define what an HTML file is, and
       give it an icon - if it doesn't already have this done.
       Optionally, in conjunction with the "!RunHTML" file, you can get
       OvationPro to load HTML files when you double-click on them (the way
       this works is !OvHTML picks up the request, makes a DDL file, then
       just Filer_Runs it... :-)
       That last one is, obviously, browser-unfriendly. However if you wish
       to print a bunch of stuff off, and you're annoyed at Fresco's habit of
       putting page-breaks in the middle of lines, or Oregano's complete and
       total weirdness, then simply get your favourite DTP software to do it
       with few hassles (blame OvHTML!!!) and absolutely no bullshit.

       Seperated <img src ...> handler into 'image' source, and expanded it
       to pre-process as well.
       
       Now embeds simple-path (ie, things in the same 'directory' as the main
       document) images.
       
       A lot to do yet with the image handler, but we're getting ever closer!



0.15   2002/11/02

       Image handler now understands offset paths. It will handle all (most?)
       paths given relative to the current document, like:
         ../../images/buididipi/piccy.jpeg
       or
         /images/logo.gif
       What it cannot handle is absolute images, either "/images/logo.gif" or
       "http://blahblah/logo.gif". Note, you can't refer to <base href...> as
       that requires an absolute URL parameter, so we again run into the
       problem of what where?
       In reality, most of the sites I visit (including my own) use relative
       image paths most of the time.



0.16   2002/11/03

       Did you know MTV2:Pop (Germany) is censoring "Pink"? [*]
       In the song "Just like a pill", the correct start of the chorus is:
         Can't stay on your life support, there's a shortage in the switch.
         Can't stay on your morphine, 'cos it's making me itch
         I tried to call the nurse again, but she's being a little bitch!
       It is now:
         Can't stay on your life support, there's a shortage in the switch
         Can't stay on your life support, 'cos it's making me itch
         I tried to call the nurse again, but she's being a little switch
       This is, for God's sake, worse than the amazingly bad censorship that
       the ITV network used to dub 'nice' words over expletives. But, what
       gets me is that it seems (seemed?) apparently okay to play "Puddle of
       Mudd"'s song "She [f***ing] hates me!" without censorship.
       I dunno. It's pretty crazy really, isn't it. It seems to me that this
       is censorship for the purile sake of censorship. Oh no! We can't have
       a pop song containing a line about taking morphine - - - when that's
       kinda the point of the song? Huh? Eh?
       Weird.

       [*] Obviously, the follow-on question would be "do you give a ....?"
           :-)

       Fixed small bug where images got the wrong sized frames.

       Image data generator now no longer outputs an extra word of junk data
       (usually containing a '"' character) if EOF happens at a triplet
       boundary.

       Tested it with various documents from my website. One of the network
       setup documents is included in the examples.

       Well, for now, I guess that's it!
       Cool.
       Time to rewrite the !Help file.



0.17   2002/11/10

       Included new f***wit handler for entities, so stuff like:
         Testing memory from &8000 to &Stopped at breakpoint at &0000808C
       will work. :-)
       
       Underline code now sets the underline colour correctly.
       
       Made assembler code conditional for 26/32bit depending on {CONFIG}.



0.18   2002/11/17

       Couldn't resist adding stuff...

       Fonts are now read from a look-up file. This is not meant to be
       altered, but if you really must (ie, if you want it to look like the
       default setting in Fresco - body in Homerton, titles in Trinity).

       It seems the "testdoc" was causing Data Abort errors. Pretty severe
       ones, as DDT was, well, useless. So I've checked the buffering to
       ensure nothing gets overshot. Seems to have fixed the problem... I
       suspect it was the 500 character <img src> leafname...
       
       Tested all of the examples.

       Wrote a StrongHelp file...



0.19   2002/11/29

       Come across an "XHTML 1.0" file, one of the Buffy scripts. I quote:
          <p
           align="center"><font
           face="verdana"
           size="-1">WILLOW<br />
          Do I?</font></p>

          <p
           align="center"><font
           face="verdana"
           size="-1">DAWN<br />
          You're back on the Magicks.</font></p>

          <p
           align="center"><font
           face="verdana"
           size="-1">WILLOW<br />
          No, honey. I <i>am</i> the Magicks.</font></p>
       Looks to me like regular HTML with a whole loada linebreaks in it!

       There is now a "translate" file. This will, if invoked, translate
       one tag to be another tag, with a few small conditionals. For example:
         translate inpath(`shooting`)
         {
            when `font`
            {
              ifin `verdana` then replace `tt`, setflag A
              done
            }
            when `/font`
            {
              ifflag A then replace `/tt`, clearflag A
              done
            }
            done
         }
       This will apply the translation to any file with "shooting" in the
       path of the input file.
       If <font ...> is encountered, and it is setting the font to "Verdana",
       then the entire <font ...> command will be replaced with <tt>.
       If </font> is encountered, and the <tt> exchange was done, then the
       closing </font> will be replaced with </tt>.
       
       Look in the "<OvHTML$Dir>.data.translate" file for a much better and
       more refined version.
       If you would like to test this, then download a Buffy "shooting script"
       (not a transcript) from http://www.studiesinwords.de/ and try it with
       one copy in, say, RAMdisc's root directory, and the other in a
       directory called "shooting". I tested it with the various season 6
       scripts, but I'd imagine they're all pretty much formatted the same
       way. Yes, even the XHTML ones. :-)
       
       The commands are:
         translate inpath `<name>`
         translate ifpath `<name>`
         translate ifleaf `<name>`
           This invokes the translation if the path contains / if the path is
           or if the filename is...

         when `<command>`|M {|M <command>|M }|M
           Do something upon an HTML command. You should only specify the
           first part, ie, "a" for "a href", etc...

         unknown `<command>`|M {|M <command>|M }|M
           Matches (string, case insensitive) an unknown keyword.

         ifin `<string>`|M {|M <command>|M }|M
         ifis `<string>`|M {|M <command>|M }|M
           If the PARAMETER of the command contains/is. Case insensitive.

         ifflag <flag>|M {|M <command>|M }|M
         ifnotflag <flag>|M {|M <command>|M }|M
           Obvious, no?
           Oh, your flags are A - E, uppercase.

         ifopt <option>|M {|M <command>|M }|M
         ifnotopt <option>|M {|M <command>|M }|M
           Options upon various 'states':
             l   If left aligned, or justified
             c   If centred
             r   If right aligned
             h   If within <a href>...</a> block
             b   If bold
             i   If italic
             u   If underline
             t   If in typewriter font (<code>, <tt>, <pre>, etc)
             p   If in <pre> or <plaintext> block
             o   If <ol> or <ul> block

         setopt <option>
         unsetopt <option>
           Set/unset the option as defined above. USE WITH CARE as this can
           REALLY screw up the parser!
           You cannot 'setopt' 'h' or 'o' options.

         replace `<command>`
           Replace the current command with that given. The parameter data
           will be cleared.

         omit
           Simply omit the cureent command.

         setflag <flag>
         clearflag <flag>
           Sets and clears the flags, A - E.
           The version 'unsetflag' is also accepted for 'clearflag'.

         done
           To drop out of translate script and continue parsing the input.

         Example of the above, on:
           "<center><font size=1><font face="verdana"> blurb </font></font>
            </center>"

           Input           Translation             What OvHTML 'sees'

           <center>        No match.               <center>
           <font size=1>   Match font, not size.   <font size=1>
           <font face...>  Matched and changed.    <tt>
           blurb...        Ignored                 blurb...
           </font>         Matched, flag set.      </tt>
           </font>         Matched, no flag.       </font>
           </center>       No match.               </center>

       The 'translation' stuff has only been LIGHTLY tested, okay?
       Let me know...

       Wrote a StrongHelp file...



0.20*  2002/12/06

       Wimp now requires WindowManager 3.xx. Not a problem as this code, and
       quite likely OvationPro, won't work with RISC OS 2. This allows us to
       tell the Wimp what messages we are interested in. A small
       optimisation to make OvHTML more efficient at doing nothing (rather
       like me, actually!).

       The "Templates" file is now read from "<OvHTML$Dir>.Resources.UK".
       Well, actually it is looked for in "...Resources.[territory name]" and
       will fall back to "UK" if the required territory was not found.
       OvHTML does not, as yet, support "Messages".

       When importing from a selection, say a bit quoted in !Edit, hold down
       the shift key while dragging your selection to OvationPro. KEEP IT
       HELD until the import has finished.
       That way, OvHTML will detect the shift key and it will attempt to
       parse the snippet given. It has side effects, like it won't moan about
       not finding the <body> tag, etc.

       Now requires "href" in "<a href...>" blocks. "<a name>" stuff no
       longer underlined/coloured.

       Pre-scanning now skips <script>...</script> blocks, to cater for some
       amazingly badly written code with loads of <font...> and precious few
       </font>s.
       At one point, we were up to 34 font elements active (OvHTML will cope
       with 16), thanks to code like:
         <font size="2"><font size="2" color="black"><font size="2">
         <i>9/9/2001 9:41:03 PM</i></font>:
       I /think/ that code came from http://www.planet-source-code.com/ but
       don't hold me on it - I'm reading the FASTCLICK.COM pop-under comment
       (so, not only is the HTML crap, it uses FASTCLICK which in itself
       should be a crime punishable by slow and tedious death inflicted with
       a mini-stapler (I'll leave the visuals to your imagination!)).

       A bit of a masochist. me, I stripped all <script>...</script> out of
       the file (which tidied it up a LOT), and inserted newlines before each
       '<' so I could read it.
       I gave it an HTML 3.2 doctype header, then tossed it at sgmls:
         * In the <body>, it said 'TEXT = "#000000"' twice (!)
         * Comments appeared to be in the form "<!comment>" instead of the
           expected "<!--comment-->".
         * "<td valign=topwidth=1 [...]"? What the ....?!?!?
       I gave up after correcting some fifty errors and discovering I was
       only about a fifth of the way into the file. Gah!

       SPECIAL FEATURE not documented anywhere else (see, you get a special
       treat for taking the time to read this crap!):
       While dragging your HTML file to OvationPro, holding down a special
       key will do a special action. Namely...
         * Hold the 'C' key to toggle whether or not document colours are to
           be used.
         * Hold the 'I' key to toggle whether or not images are to be loaded.
         * Hold the 'P' key to toggle whether or not styles are reset upon a
           paragraph "<p>" break.
       The action performed is the OPPOSITE of the configured action, it'll
       work both ways.
       This is SO much easier for those little annoying badly-written files
       than all that rubbish with reconfiguring OvHTML...

       If, for some bizarre and twisted reason (usually related to <table>s)
       the text colour is set to the same as the background colour, the text
       colour will be inverted... Red becomes cyan, blue becomes yellow,
       black becomes white; pretty familiar stuff.

       ANOTHER SPECIAL FEATURE for you, Constant Reader: For most of the
       repetitive errors (usually the "TryTorecover: <blah>" ones), you can
       hold down the 'S' key to suppress further error messages. You may get
       really manky output, but at least you won't have to click through
       forty-odd messages to get there!



0.21   2003/02/12

       New type of configuration file. As always, OvHTML will automatically
       do a load-old-save-new for first-time use.

       Converted OvHTML to use a more !Configure-alike method of setting up
       the program.



0.22   2003/02/26


       Entities:
         Added: "Cedilla", "acute", "ordm", and "shy".
         Added: "degree" (had this already as "deg", which I've kept).
         Fixed: "brvbar".
         Fixed: "not", and added "macron" to be the entity that "not" was...
         Delet: Removed dpulicates of "reg" and "sup1".
         My "Para" (a paragraph symbol) and "para" (same as 'thorn') are
         different, is this correct? I can't find my DTP guide, but I'm sure
         that "uppercase" and "lowercase" paragraph symbols are different.
         Now 134 regular entities, and 65 extended entities.

       Added new text option - keep hyphens as non-breaking. So, "trench-
       coat" would not be split as shown, but would be kept as "trench-coat"
       and will wrap to the next line if necessary.



0.23   2003/03/28

       Changed the code for the non-breaking hyphens so it is part of the
       main 'switch' statement, not a check on each 'regular' byte passed. It
       is more efficient this way...

       When setting "Keep JPEG as JPEG" or "Convert ALL to JPEG", it will
       disallow it if the system is not able to natively display JPEGs.
       
       Things are, now, likely to get a bit odd if ChangeFSI cannot be found,
       so OvHTML will warn you at start-up if "<ChangeFSI$Dir>" has not been
       defined.
       The behaviour in this case is a little different. If ChangeFSI is not
       present:
         * Sprites will be kept as sprites, always.
         * GIFs will be converted to sprites with the internal code, always.
         * JPEGs will be examined with the OS routines (if present). If the
           JPEG is valid (ie, not 'progressive'), then it will be kept as a
           JPEG.
         * Anything that fails the above checks will be omitted and marked as
           if the image file was not present.
       This falls into the category of "making the best of a bad situation",
       as surely any RISC OS 3++ system WITHOUT ChangeFSI is!

       Implemented "Keep JPEGs as JPEGs", and "Convert all to JPEG". When
       converting all to JPEG, the internal GIF decoder will not be used; as
       it is (currently) quicker to use ChangeFSI, and JPEGs do not have a
       transparency colour, so...
       The full logic is:
         If not converting all to JPEG:
           * GIFs -> sprite (via ChangeFSI or internal, as configured)
           * Sprite left untouched IF system can handle them, or marked as
             invalid and ignored.
           * JPEGs -> sprite or JPEG depending on configuration. If left as
             JPEG, they're checked to ensure they are baseline. If not, they
             are given to ChangeFSI to output as a JPEG.
           * Anything else...passed to ChangeFSI, output sprite.
           Sprite output is 16bpp on newer hardware, or 8bpp on older...
         Else:
           * Everything passed to ChangeFSI, output JPEG.
       A later version of this software may make further checks on invalid
       sprites (a deep sprite on RISC OS 3.10 will be 'invalid'), but since
       sprites are not an official 'web' format, this has not been done now.

       The internal GIF decoder is not included at this time. It works, all
       except there is a small memory allocation problem which causes the
       memory allocation heap to become corrupted. Once this (obscure) bug is
       tracked down and nailed to the wall...
       


0.24   2003/03/29

       Special trap for "<!" to ignore up to the next '>'. This is because
       the HTML version of ARMinstrs had these dotted around for "BOXED" or
       somesuch.
       The logic, now, is:
         <!-  carry on until  ->
         <!   carry on until   >

       Created a simple GUI page size editor (though I prefer to do it in
       !Edit).
       For the page editor, note that the page size icons go in the order:
           Width
           Height
           Top
           Left
           Right
           Bottom
       All measurements are to be given in millimetres. You may use up to
       two decimal places if this is required.
       IMPORTANT: The page definition window does NOT auto-close after you
                  click "Accept". You must explicitly close it yourself.

       New DDL macros:
         PSIZE  - output page size code, like:
                      {paraersize "blah" 0 {w blah} {h blah} {sideways 0}}
         MRGNS  - output margin size code, like:
                      {fcurve {box {x blah}\nblahblah\n{h blah}\n}}\n

       Created paper sizes:
         A3,     margins 10,10,10,10.
         A4,     margins 10,10,10,20; default created if no page defs found.
         A4Rick, margins 10,10,11,21.
         A4Web,  margins  5, 5,11,21; exactly the same as my printer driver.
         A5,     margins 10,10,10,10.
         A5Rick, margins 20,20,10,10.
         DL,     margins 10,10,10,10; third size A4, like the envelopes.
         Legal,  margins 10,10,10,10.
         Letter, margins 10,10,10,10.
         SRA3,   margins 10,10,10,10; this is for A3 with bleed area.
         SVGA,   margins  1, 1, 1, 1; see below.
         VGA
         XGA,    margins  2, 1, 1, 1; see below.
         XXGA,   margins  2, 1, 1, 1; see below.
       The page sizes are given in millimetres, and may use decimal places.
       Upon saving, two decimal places are saved.
       
       The "*GA" sizes are designed for on-screen reading, not printing. They
       are good for web documents. Simply drag-size so the entire screen is
       covered, ensure Print Guidelines are switched off, and read!
       The pages are long (50cm, or 1m for XXGA) and the margins narrow, so
       page breaks and other guff shouldn't get in the way. After a while,
       you probably won't even notice the grey page break marker any more.
       The "VGA" size is 174.7 x 500, with 1mm margins. This size nicely fits
       a 640x480 screen.
       The "SVGA" size is 220 x 500, with 1mm margins. This size nicely fits
       an 800x600 screen, and may be used to read web documents.
       The "XGA" size is 283 x 500, with 1mm top/right/bottom margins and 2mm
       left margin. This is designed for a 1024x768 screen, though you'll
       need good eyes to work at this resolution!
       The "XXGA" size is 389 x 1000, with 2,1,1,1 margins (like XGA). This
       is designed for a 1400x960 screen, which, of course, you won't be
       using on a 14" monitor! :-)
       Again, don't forget to turn off print guidelines...

       Now constrains the image boxes within the page margins - useful for
       those HUGE images - so now they won't simply 'vanish'. Please note
       that the image is sized so it is always 5mm smaller (all round) than
       the page margins. Also, the image frame is sized roughly. There is no
       attempt made to correct, say, the height if the width is altered.
       Additionally, the image is not 'centred' in the frame. This is simply
       a method to prevent image frames spilling out of the allocated area.



0.25   2003/04/01

       April Fools!

       Wrote memtrace_* functions, and changed all memory claims to use it.
       It'll output a report when OvHTML exits, if there are outstanding
       memory claims. It won't tell you WHAT claimed, it'll tell you the base
       address of the block, the size, and the function in which the claim
       occurred. This should be enough. It'd have been a doddle to include
       the exact line number - but I wanted my code to be an identical
       replacement for the calloc() and free() [etc] functions. Thus, a few
       simple search and replaces will update the entire program. Adding
       things like line numbers involves more work!
       If you find you often get memtrace reports - TELL ME!!! - you should
       not get ANY. Then, you can redirect them to a file and stop them being
       printed by passing "{ 2 > <OvHTML$Dir>.memtrace }" at the end of the
       command line. You'll probably want to write an intermediate Obey file
       to do this, and get Ovation Pro to run the Obey file which runs OvHTML
       (or something).
       :-)

       Corrected various minor memory claims that were not freed. This would
       not have affected much, as it was "stuff not formally released for
       program termination", which the C library would have freed for us
       anyway. Now, all is freed prior to exit.
       IMPORTANT: As each module keeps a lot of it's own data to itself, this
       RELIES upon the fact that 'atexit()' handlers are called in REVERSE
       order. If it happens that this should change, you will probably get a
       lot of memory claim errors as the trace would be called before each
       module has had a chance to tidy up after itself. However, given that
       this reverse-call behaviour has been active for over a decade, across
       various releases of CLib, and also given that there isn't really much
       impotus to change it, and given that reverse-call is ideal for things
       like this ... I don't forsee it changing in a hurry.
       [famous last words]
       


0.25   2003/04/01

       Corrected memory release error in HTML href parameter parser. It'd
       claim memory, but not free it until the end. If aborted early (like an
       "a name" tag instead of "a href"), it'd not be freed at all.

       Extended the HTML test document with some evil things, like entire
       lines in entities, and a list of 'control codes' in entity form.

       Fixed entity lookup to report invalid entity as "&<entity>;" and not
       "&#<entity>;", because that meant unknown numerical entities would
       look like "&##27;".

       In the following parse differences, we ignore little things, like
       different ideas of what <h1> is, etc. The plus is for things we do
       better (or can do better), the - is for things we don't do better. An
       equals means it does it the same.

       Parse differences between OvHTML and Fresco 2.26/3.20:
         + Different URIs may be coloured
         ? Doesn't put new <ul>/<ol> as an <li> on a new line. For example,
           we do:
             1.
                 1. item
                 2. item
             2.
                 1. item
                 2. item
           Fresco does:
             1)  1) item
                 2) item
             2)  1) item
                 2) item
           Which is more preferable?
         ? Do we support <ol>'s start number tag? I can't remember!
         - Our <dl> handling is non-optimal.
         + We support <right>.
         + We support font face. Fresco appears to only support "Courier".
         - tables, forms, and frames - obviously.
         + Fresco doesn't understand any of the extended tags except &fnof.
         ? Mmm... Fresco isn't showing the 'valid' images. Interesting...
         + Fresco parses text (incl. markup) after </html>. Naughty!

       Parse differences between OvHTML and Lynx Version 2.8.4rel.1:
         = We do the lists in the same way, only with slightly different
           characters for the <ul> items (ie, Lynx is *+o for the first
           three).
         + <right> Okay, it's invalid HTML so it can't really be counted...
         + Our effects aren't all magenta. :-)
         ! Wow! It does a fair number of the extended entities.
         + It parses after </html>...



0.26   2003/04/04

       Began "Scripter".
       

       
0.27   2003/04/05

       If OvHTML is 'loaded' in configure mode, and you drag an HTML document
       to it, it will run a copy of itself in "converthtml" mode.

       More work on Scripter. Much of the basic parser is complete, and it
       recognises all commands, and performs correct style changes for ones
       like <chapter>, <defactor>, <dia>, <scene>... In fact, apart from the
       slash commands and <b>, <i>, & <u>, it does about all it can when it
       isn't able to parse parameters within commands. That'll be tomorrow's
       task!
       
       

0.28   2003/04/06

       A tiny bit more work on Scripter. Little things, like unsetting text
       effects in reverse order to that set (ie, <b><i> ... </i></b>). This
       isn't really necessary (especially as Ovation Pro itself seems to do
       <b><i>...</b></i>), but it makes me feel the output is tidier.

       The main part of today's work:
         Wrote the Scripter guide, and updated the !Help file.



0.29   2003/04/09

       FINALLY got the styles working correctly, especially the dialogue
       header. After applying a style, we output: "{bold}{italic}{underline}
       {font}{textsize}". This seems to set up the aspects of the style that
       are not set with the "{adduserstyle xxx}" command. Note that those
       five setup commands are output after any added style - we do not
       'tailor' them to each specific style - as otherwise you would find it
       difficult to edit the styles.

       Styles now have no 'scope', they are applied at the caret position,
       rather than "to a sentence" or what-have-you.

       New formats for the directives:
         Camera direction     - Homerton, 12pt, bold.
         Location             - Homerton, 12pt.
         Prop                 - Italic
         Special effect       - Homerton, 12pt, italic.
       These are now handled as styles, so they may be altered. Script
       behaviour is as before, they can't be combined and textual effects are
       unset by a directive...
       The homerton fonts are 12pt (script body is 13pt) as Homerton is a
       visually 'larger' font. Reducing Homerton's size by 1pt makes it look
       'correct' in the flow of text.

       New style for "actorname". This is currently unused.

       Made a start on parameter parsing. This works slightly differently
       than the HTML parser as we know that valid parameters only contain
       the letters A-Z and a-z, and the numbers 0-9. Parameter tags, if
       required, follow the same scheme. Tags and parameters are seperated
       by an '=', and string parameters are quoted.
       For example:
         <command "parameter" tag="parameter">
       But this will work:
         <command "parameter", tag = "parameter">
       This, also, will work:
         <command "paramter" tag parameter>
       But this will NOT work:
         <command parameter tag parameter>
       as we can't easily tell where the first parameter finishes. However
       this will work:
         <command parameter>
       In general, the first parameter is the only one that is often needed,
       usually a name or a title, and as such it has no tag. All following
       parameters should have tags.

       The exceptions to the above are:
         * Scene duration, in mm:ss.
         * Scene int/ext.
         * Dates.
         * Addactor/addactress 'quiet'.
       These are handled seperately by the relevant parsing code.

       Now correctly and completely parses <defact[or|ress]>, including
       building the actors array.
       
       Parses <scene>, with int/ext. Does not parse duration yet, nor does it
       do the scenes array stuff.
       
       Parses the title in <chapter>.
       
       Apart from the title page (none of the parameters are parsed for the
       setup commands ... yet), the generated output looks pretty much as it
       should. :-)



0.30   2003/04/13

       Scripter now parses <title> and parameters, <author>, <address>,
       <copyright>, <telephone>, <date>, <started>, and <finished>.
       
       There is a special 'tweak' in that if the specified date is given as
       "9999/99/99" (exactly as that, not in UK format), then the current
       date will be inserted instead.
       
       It mentions it in the Scripter guide, I'll say it again here - if you
       specify a UK format date with a two-digit year that could possibly be
       a day, it will be interpreted as an ISO date.
       For example:
         You specified: <date 23/03/03>
         You meant    : 23rd March 2003
         Scripter read: 3rd March 2023
       Try to ALWAYS give four-digit years.
       
       Scene array managed, including durations.

       Now creates a proper front cover page. Wheee!
       
       New commands <scenelist> and <actorlist>. Can be called in script mode
       though it is ADVISED you do it at the end!



0.31*  2003/04/19

       Tiny fix, Scripter date says "7th" rather than "07th"...



0.32   2003/04/25

       
       Added backtrace handler, so serious errors will cause a backtrace file
       to be generated ... "<Wimp$ScrapDir>.!ovhtmlerr". I really wish like
       hell I could figure out how to read R0-R3, but it doesn't really seem
       possible as they aren't pushed. Somehow, the 'critical C runtime
       backtrace' (the one you don't see until things get /really/ bad) can
       do it, but however it does so - it isn't made terribly clear in the
       various APCS descriptions. I'm leaning towards 'inside knowledge'
       coupled with 'deep magic'.

       The default stack size is now configurable by a command line variable,
       so if you get the errors:
         Too many nested font changes - resetting the font stack...
         Too many nested indentation changes - resetting the indentation...
         Too many nested colour changes - resetting the colour stack...
         Too many nested alignment changes - resetting the alignment stack...
         Too many nested font size changes - resetting the font size stack...
       then simply increase <OvHTML$StackSize> in the !Run file.
       The default stack size is 16, and this will be used if the command
       line variable is unset. The maximum stack size is 128. Invalid values
       will reset the stack size to the default of 16.
       Note: You can set to stack size to less than 16. This is for testing
             purposes, don't do it in normal use.
       Recommended values are 16 or 32. If you find you need something higher
       than 32, then either there's a pretty severe fault in OvHTML's parser,
       or you're looking at a particularly strange (bad?) web document!

       Just for the hell of it, I tried the !HTMLPro demonstration in the
       OvationPro CD-ROM. I quote from the output of HTMLPro Demo v1.6:
          <BODY TEXT="#000000" BGCOLOR="FFFFFF" LINK="#0000ff">
       Because there is no '#' before the background colour definition, my
       OvHTML treated it as a user defined colour and set it to black (the
       default).
       Because of this, two changes have been made to OvHTML:
         1. Will check that the foreground colour does not match the
            background colour. If it does, it will be inverted. [*] You will
            not be warned of this, as there could be numerous such colour
            changes in the document. It'll be obvious anyway...
         2. Does not assume a colour is 'named' if it has no '#' proceeding
            it. Now it will check to see if 'FFFFFF' could be a colour def.
       [*] Yes, I know this 'happened' in version 0.20. The previous code
           compared the colour index references. Now it compares the actual
           RGB values for each colour.

       Bugfix: colour_colourelement() now correctly returns colour elements
               for extended (ie, not built-in) colours.



0.33   2003/04/25

       Tweaks and additions to Scripter:
         a. <dia> text should be followed by two blank lines.  Special
            handler for <dia> following <dia>, so it doesn't insert more
            blank lines.
         b. Even-more-special handler for "</dia> some text <dia>" so it puts
            in the blank lines in that case.
         c. The blank space between actor definitions is now done by the
            closing tag, not the opening tag. Minor alteration.
         d. The first '<defact[or|ress]>' will output a "Cast" header.
         e. <scenelist> will now totalise the scene durations, if given.
         f. Tidied up some of the spacing between things, like slightly less
            space between actors/actresses, and a tad more space between
            scenes.
       As it happens, I'm in the process of writing a script, with Scripter.



0.34   2003/06/11

       There have been few actual changes to the code for this version. The
       Big News is that it is now linked with a 26/32bit version of DeskLib
       (that I converted myself, as I still use DeskLib v2.30); and a small
       number of functions were altered to take advantage of the 'new' stuff
       in "DeskLib v2.30 [RM/32]" (as I have called it...).
       Please be VERY aware that this is an entirely THEORETICAL thing, as I
       don't have any 32bit version of RISC OS <sob!>; however both !SID and
       !Armalyser have passed this software without so much as a whinge (well
       that's a lie - SID kept on saying "Warning: Conditional LDM/STM slow
       on StrongARM and XScale" - whatever...).

       You will experience the following changes:
         If you are using a different Territory, you'll need to copy the
         "Sprites" file into it.
         
         There is no DEBUG build for this version. If you try and run it, it
         may crash (Sprites not found). Copy the sprites back out to the main
         !OvHTML directory and it'll work.
         
         You'll need SharedCLibrary v5.34 or later. You'll notice that the
         OvHTML !Run file doesn't actually check for a CLib. That's because
         if you're running OvationPro then you've got the right stuff to run
         OVHTML...
         
         The first two changes have been brought about by the decision that
         "sprites are resources, so they belong in the resources". The latter
         change is due to using a munged form of APCS 3/32 (as far as I can
         work out, it's basically a version that doesn't expect processor
         flags to be in any specific state, and hence it'll work across all
         processors - only so long as SharedCLibrary is aware of this...).

       "CheckIfAlt" is now 26/32 neutral.
       
       The supplied "!Server" should be 26/32 neutral. I'm pretty sure I
       upgraded it, but I've not had time to unsqueeze it and toss it at
       Armalyser to make sure.
       
       Please can somebody with an Iyonix give this thing a good ol' thrash
       and report back to me if it is 32bit 'safe', as I'm afraid that while
       the compiler claims to be 32bit safe, and I've coded the assembler
       32bit safe, and both SID and Armalyser like it... there's simply NO
       substitute for "the real deal".
       
       If you click on the program name in the Info window with Shift, Ctrl,
       and Alt held down (yes, all three), then OvHTML will 'crash' with a
       type 5 error. This is quite deliberate, so that the backtrace stuff
       may easily be tested.
       If, after reading the error message that pops up, you click to close
       it with ADJUST and also while holding down ALT, you will trigger a
       fatal failure in the error handler, which will drop to a little bit
       of code designed to terminate-without-asking-questions.
       


0.35   2003/07/25

       Clicking on "New" in the page editor without altering the filename
       would cause a type 5 error. This was simply a side-effect of telling
       the "report this message to the user" function that there was a
       parameter, and forgetting to pass that parameter (duh!).

       Now 'understands' "<nobr>" and "</nobr>". This doesn't do much, as it
       does not really have context in OvationPro documents...so this is
       treated as an "unknown", like "<table>"...
       
       Now understands "<listing>" and "<xmp>", these are treated as "<pre>".

      Now supports "<basefont>" to poke in the 'default' font size for all
       sebsequent text. Please note that your font stack must be empty for
       this to work. The following would fail: 
         <font size=+1>
         <basefont size=7>
         <font size=+1>
       As the previous +1 is already on the size stack. This, like font size,
       takes the range 1 to 7, with 3 being 'normal'.
       If the <basefont> fails, you will NOT get a warning - it'll just be
       ignored (this is so crappy HTML doesn't generate lots of annoying
       errors).

       The "<kbd>" command now outputs in italic, to differentiate between
       <kbd> and <code>. However, <code> and <tt> still look alike. Should
       <code> maybe be output in bold? Let me know what you think...

       The "Arachne" web browser claims to support some 102 HTML commands,
       and it may seem as if OvHTML supports far fewer. This, it seems, is
       apparently because the programmers consider "<div ...>" and "</div>"
       as different tags. Using this logic, OvHTML v0.35 supports 108 HTML
       commands (counting <center>, <centre>, </center>, and </centre> as
       four different commands...). Oh, and it recognises an additional six
       commands that are not supported, to warn you that they aren't
       supported. :-)

       If the first parameter begins '-' is now assumed to be a command-line
       switch. Those that are not recognised are faulted.

       Began work on the (basic) HTML exporter. Yeah, you read that
       correctly, I said "exporter". :-)

       Exporter now loads in the colours defined in the OvationPro document,
       and maps them to HTML 'named' colours if possible.

       Amended colour_lookupbyrgb() to scan the HTML defined colours before
       the internal colours - to try to match against the NetSafe colour
       palette in preference. This is to allow the exporter to, insofar as
       possible, always get valid NetSafe colours for colours defined in the
       OvationPro document being exported.

       IMPORTANT: This *may* change your colours. If you create a document
                  with, say, "fuchsia", and pass it both ways through OvHTML,
                  then you'll find the "fuchsia" is now "magenta". Both are
                  255,0,255. Currently the lookup uses a last-match IIRC.
                  When I get around to optimising it to be a first-match
                  loop, your "fuchsia" may remain as "fuchsia", but your
                  "magenta" will be "fuchsia" too.
                  [actually, I have a horrible suspicion that it'll be
                   "foosha" or one of the other 'typical mis-spellings of
                   that word'...]

       Exporter now loads the fonts defined in your document, and aliases
       them, if desired. [by that I mean it'll understand "Homerton" should
       be called "Verdana", etc].
       Please be aware that the font lookup here is done on a "family" name,
       so "Homerton.Italic" and "Homerton.Medium" and "Homerton.Bold" are all
       treated equally. OvationPro, luckily, defines all the fonts it needs
       at the start - but the actual bold/italic differences are done by
       script commands.
       Note that "Homerton.Light" and "Homerton.Black" will, quite likely, be
       handled wrongly. This isn't a big problem, Ovation Pro doesn't get it
       right either. :-)



0.36a  2003/07/26

       As this is not a 'finished' version, the file version number is going
       to stay the same, with an incremented letter appended.

       Exporter now extracts story data to sequentially numbered files in the
       scrap directory.

       Added a status window to the export. Little slidy-bar-and-text-message
       kinda thing.

       If the story/image extraction fails three times in a row, OvHTML will
       automatically ignore all further images or stories. This might happen
       if, say, you try to export a complex document with lots of small
       images and logos, and lots of seperate text frames - such as might be
       found in my VideoList user guide - as the Scrap directory will fill up
       and reach it's 77 files limit (pre-RISC OS 4).
       I do not see this as a problem, however, as the chances of OvHTML
       outputting sensible HTML for such a complicated document are about the
       same as my winning a few million Euro on the lottery by the end of the
       year (tell you what - if I do win, I'll get a better coder than me [*]
       to make a /proper/ HTML exporter for Ovation Pro!).
       [*] i.e. anybody



0.36b  2003/07/27

       Now decodes the images, and converts:
         Unknown JPEG to Sprite
         JPEG to JPEG
         Sprite to Sprite
         Draw to Sprite
       It recognises ArtWorks, but there is currently no facility to convert
       ArtWorks images to sprites.

       The Draw-to-sprite routines use InterGIF.



0.36c  2003/07/28

       Now converts the RISC OS images to JPEG or GIF (as selected as
       appropriate) and copies them to the correct places.

       Exporter now writes an HTML 'shell'.

       Please note that OvHTML does NOT tidy up after itself (in Scrap) if
       an error occurs that causes the export to be abandoned. This may be
       useful to aid in finding out at what stage things went wrong.

       "_export" document added. OvHTML will (doesn't currently) open this
       on-screen after a successful HTML conversion.

       La "Templates" est disponable en franais aujour d'hui, mais le
       traduction ne parfait pas - regarde le texte pour un petit
       amusement. :-)
       Aussi, le OvHTML image dans l'iconbar, cette contient un lettre 'F'
       (trs petit) pour marqu le version franais, comme mme.
       Une problme, le reponse de le logiciel est toute en anglais, pas
       un fiche "Messages". Desol, mais je resolvez ca dans le futur.

       [and if you think that's crap, wait 'til I try to pronounce it!!!]



0.36d  2003/07/29

       New Scripter command:
          <continue "filename">
       When encountered, it will stop parsing the current input file, open
       "filename" and begin parsing it, as if it was 'current input'. This
       was added because my crappy WP software (on the PC) wets itself if I
       ask it to do something complicated, like edit files >=64K...
       There is, obviously, no cyclic checking. If you set two files to point
       to each other, then you deserve to be sat in the corner, facing the
       wall...
       IMPORTANT: The filename must be a complete pathname. There is not
                  currently any provision for 'local' filenames. That'll come
                  in a future version of OvHTML.

       Began HTML conversion code. :-)

       PLEASE NOTE - AN ASSUMPTION HAS BEEN MADE - the PICTURE_xxx data has
       a number ONE LESS than the corresponding PICT_xxx description. For
       example:
         PICT_11a={pictframe
         {...blah...}
         }

         PICTURE_119={picture
         {...blah...}
         }
         }
       So when OvHTML encounters an {embed PICT_11a}, it will insert the
       image referenced as PICTURE_119.
=====
-----> Currently, only embedded images are supported. Proper inserted images
=====  will be supported at a later date. The "big arrow" highlight is so you
       don't ask "Why don't my images appear?". This is why!

       Non-nerd: Here's your lexicon:
         Inserted images: You design a frame, and in that frame you put an
                          image. This frame can be positioned anywhere.
         Embedded images: You drag an image to OvationPro and it creates a
                          frame for it. These frames can be left/centre/right
                          to follow the 'flow' of the text. This is sort-of
                          how Microsoft WORD normally in-lines images.



0.36e  2003/08/13

       New extension to Scripter:

         In a Scene, the command:
           ##{name}
         is interpreted as:
           <dia "{name}">
         And:
           ##
         is interpreted as:
           </dia>
         These must be on a line on their own.

         Anything in ( brackets ) in the dialogue name is interpreted as a
         directive. Accordingly, this will be reproduced in non-bold. For
         example:
                             Sandrine (incredulous)
                             ======================
                             Blah blah, blah, blah...
         Name in BOLD, directive not in bold.

         Additional parameter "unlisted" to phone number.



0.36f  2003/08/15

       Well, given how America sees itself and how technologically advanced
       they claim to be - it is amazing that one single point of failure
       caused a cascading failure when brought down the entire eastern side
       of the US and parts of Canada.
       Do people NOT learn from the past? Didn't a large portion of the
       American telephone network fail because a single point of failure
       caused switches downstream to fail, which caused further switches to
       fail - until the whole system went down.

       Working on export system 'styles'.



0.36g  2003/08/18

       Exporter comes together, not perfect, but not bad...



0.36h  2003/08/25

       Bugfix: Exporter flaked when dealing with the 'third stacked style'.

       Exporter now copes (correctly!) with '{' within output text strings.

       Exporter now understands FONT_xxxx macros, but note that discrete
       {font ...}s are not recognised at this time. No big matter, Ovation
       Pro uses the macro method.



0.37   2003/09/25

       Newlines after <p> (HTML source looks better).

       OvationPro uses an 'unexpected' way to cancel superscript:
         [...]"un connexion I" {super 1}{sub 0} "2" {sub} "C dans le "[...]
       This should be:
         [...]un connexion I<sup>2</sup>C dans le[...]
       Note that it uses {sub} without a parameter to cancel {super}.
       So, now, if OvHTML encounters a no-parameter {sub}, it'll cancel
       {super}; and likewise {super} cancels {sub}.

       Fixed bug in colour mapping. Basically, the "Unknown object at xxxx"
       error occurred because:
         a. OvHTML scans your HTML to see what colours are defined
         b. Those colours, and ONLY those colours, are written to the OP file
         c. Upon finding 'foreground = background', it'll invert the fore...
              ...and write out the inverted colour if it's defined.
       That last bit is where the error occurred. So now it will check the
       colour is not only defined, but 'included'. If not, it will write out
       an absolute colour definition. This isn't the best way to do things,
       but then again ... neither is:
         <BODY BACKGROUND="GIFS/BACKHOME.GIF" LINK="#FF0000" TEXT="#000000"
          ALINK="#FFCE00" BGCOLOR="#000000">
         [...]
         <B><FONT SIZE="4" COLOR="#000000">Welcome to the Internet Magazine
         CD for February</FONT></B>
       That is ACTUAL code from the INDEX/HTM document on the CD-ROM that
       accompanied an issue of Internet Magazine! (the CD title is
       "INTERNET39" so I'd guess issue 39) I checked the HTML to ensure that
       an alternative background colour wasn't being set in a table... BUT
       NOOOO! And it looked pretty ick on Oregano (t'was mostly all black!),
       so now I've fixed the bug, score 'one' for OvHTML. :-)
       <fx: licks finger and holds it in the air>
       Okay, it isn't perfect and it /may/ miss sections of text in certain
       circumstances - however I reiterate, again, that this is a 'fix' for
       broken HTML.



0.38   2003/09/27

       More work on Scripter...

       Too many spaces were being inserted between <dia> blocks when using
       the '##' syntax. Fixed.

       Recognises, and ignores, the "<scripterdos>" command. This is in
       keeping with the necessity to _not_ fault a command that is valid in
       a different version of Scripter, as proscribed by the protocol spec.

       "<scenelist>" now writes out some (possibly useful) totals.

       The "th", "rd", "st" (etc) in the title page date is superscript.

       "<scene>" now accepts the "day" and "night" sub-tags. These are
       currently defined as "optional" Scripter extensions.

       Accordingly, the "<scenelist>" outputs "day" or "night" if given. The
       "I/E; D/N" heading of the scene list stands for "Int/Ext; Day/Night".
       I tried for quite a while to think of a one-word name for that, but
       all I could come up with was "Specifics", and that sucks, so it's
       "I/E; D/N" until somebody comes up with a better word!

       The slash processor now supports '\>'. This is unofficial and
       "undocumented", but recommended behaviour so we don't get weird stuff
       happening if the user is \<overcautious\>...

       Now supports the "<episode>" command. This, again, is an extension to
       the protocol. It takes a string parameter, and if it is specified,
       then underneath the title it'll say:
          Episode <string>
       The parameter is a string so it'll support various different episode
       numbering systems, like "5V22" and so on.

       "<defactor ... quiet>" and "<defactress ... quiet>" were outputting
       newlines when they shouldn't have been. Fixed.

       The title page now throws a newpage after itself. It is sentences like
       that, before, that make translators want to kill themselves. :-)

       There was a space 'lost' between two slash-effected blocks, for
       example:
          \dtrack after\\ \aChris\\
       came out like:
          [...]{HomertonBold}track after{Homerton.Medium}Chris[...]
       This has, hopefully, been fixed so it works with slash-effected blocks
       and commanded blocks, and a mixture, ie:
          we \sblow up the\\ \pprop\\ now!<br>
          we <sfx>blow up the</sfx> \pprop\\ now!<br>
          we \sblow up the\\ <prop>prop</prop> now!<br>
          we <sfx>blow up the</sfx> <prop>prop</prop> now!<br>
       will all cause identical output.

       Unexpected 'leading' spaces have now been fixed. Since this required
       a number of changes in the DDL generation module, I have examined all
       of the example documents for correct output - but let me know if there
       is anything I might have missed.
       Also, for those interested in doing a memory trace of Scripter: by
       default all multiple spaces are quashed. Additionally, any 'leading'
       spaces in the DDL output string are stripped. This is where one of the
       problems occured - between two 'effect' blocks, the DDL string simply
       consisted of a space character! To work around this, the 'effect'
       switch off function inserts a space of it's own. This is not 100%
       ideal as there are times when an extra space is inserted, such as:
         \dtrack after\\! !\aChris\\!
       comes out like:
          [...]{HomertonBold}track after! ! {Homerton.Medium}Chris[...]
       The extra space is here-------------^
       However this is artificial and, honestly, I don't recall seeing this
       side-effect in 56 pages of script. I guess another 'possible' solution
       would be to allow cases where the output is ONLY " ", however that too
       may have side effects. Let me know your thoughts on this.

       Now supports 'local to original' referencing for the "<continue ...>"
       command.
       For example, if the original file is:
         IDEFS::Anya.$.scripts.script_p1
       and the CSD is:
         ADFS::BootDrive.$
       and you do:
         <continue "script_p2">
       then Scripter will first look in the CSD, ie:
         ADFS::BootDrive.$.script_p2
       and if that fails, it will try to construct a valid pathname from the
       original filename, in this case:
         IDEFS::Anya.$.scripts.script_p2
       The latter works. The original is retained for compatibility and for
       those using the DDE *Prefix command (!).
       You may receive four possible errors, all of which are:
         Can't open file "{file}" for Scripter continuation, aborting... [#]
       The '#' number at the end tells you the true fault:
         1 - Filename is an absolute reference (ie, with a path) and the file
             cannot be opened.
         2 - The original filename is only a local reference, and we can't
             construct a pathname out of thin air, so...
         3 - This is the "impossible" error. It occurs if, when scanning for
             a '.' in the original path, to strip off the old filename, we
             scan the entire string and find no '.' character. This is
             "impossible" as just before this we look for a '.' to tell if it
             is a relative (filename only) or absolute (with path) reference,
             and hence this would mean "there /was/ a '.', but not now!". :-)
         4 - Worked out a path to a new file, but that file couldn't be
             opened...

       This, now, makes the Scripter extension generate /correct/ and nice
       looking output for a given script. :-)

       This, now, also, makes the RISC OS (OvHTML) version of Scripter FULLY
       compliant with the Scripter protocol document. Yay.



0.38  2003/10/02

       More stuff... :-)

       OvHTML now keeps a 'line count' as it reads data. This is mainly so
       Scripter can return a line number for markup errors, but a few HTML
       errors report a line number too.

       Removed "<scripterdos>" from the parser. It does NOT belong there. Now
       Scripter runs an 'ignore' system where commands to be ignored are
       loaded from a resource file, and that's how it should be ... you can
       'update' the parser to recognise and ignore (ie, not flag an error
       for) commands that have relevance to other versions of Scripter
       without the need for a rebuild and update. Simply add it to the
       'ignore' file!

       I wanted to define a string array, right? Now the problem is that the
       number of elements is unknown until runtime. Okay so far. The next
       problem is the size of the strings is ALSO unknown at runtime. I don't
       want to be cheesy and make a struct with a 32 character string only
       to load two six-letter words!
       Well, after lots of experimentation, and scouring all of my C books,
       I am no further forward. Have I really found something C can't do?
       The method I devised for now is:
         if ( strcmp( (ignores + (ignoremaxlen * offset)), scriptcmd) ...
       However I feel that such a thing is, well, to be quite frank I think
       it's a frigging ugly pile of fetid steaming rhino crud. It just
       /screams/ of memory-muckage, BASIC style. Anybody have a better way?

       Now supports <act> ... </act> as analogous to \a ... \\.


       If you're wondering why I'm not working on the exporter... that's
       because I want to have a serious think about the best way to include
       the nesting system. I don't fancy recoding the exporter, so this must
       be more compatible with existing code.
       My current thought is a 'stack' system. As effects and such are made,
       the effect tag is pushed onto a stack. When an effect, style, etc is
       turned off, we scan through the stack to determine the correct order
       to undo tags.



0.39   2003/10/09

       Oh... my... God!
       You wouldn't BELIEVE the cock-up in the URI colourisation code. I'm
       surprised it worked AT ALL. I won't go into boring details, suffice to
       say it has been fixed. This will also get rid of the "unknown object"
       errors that turn out to be COL_025 references...

       The colour-match (when parsing HTML) now favours the built-in colours,
       as we know we'll always have those. Also, it doesn't return a colour
       for unused matches - as we won't have them.

       Ever wondered why some documents just 'appeared' in black? Well, it is
       quite simple - the colour extraction code expected to find:
         <body text="#aabbcc" bgcolor="#ddeeff" vlink="#123456" [etc]>
       and if it instead received:
         <body text=#aabbcc bgcolor=#ddeeff vlink=#123456 [etc]>
       it would read 'em all as colour "#0" (i.e. black!).

       Rewrote simpler code that should cope with all variations. Youpidou!

       Holy s**t!
       The temporary buffer for "<basefont xx>" was a few bytes too small for
       it's "maximum" value. This, very sadly, did not really affect the
       basefont parsing. Instead, those extra bytes trod on the stack (or
       something like that), so I've been chasing ghosts for THREE hours!!!
       We'd crash with a type 5... then a type 2... sometimes we'd get screwy
       results, and it all seemed to go "pear shaped" at the statement:
         if (byte == 10)
            linenumber++;
       which was, well, okay... Gah!
       You cannot /imagine/ the joy I felt nailing this bug to the wall. It
       is a pity I've got an upset stomach, else I'd go and drink a glass of
       ros to celebrate. Oh, sod it... I've been at this one for three hours
       solid, so gut-rumble or no gut-rumble, I *deserve* my glass of wine.

       And here endeth the modifications to make v0.39.
       Possibly just as well. :-)



0.39  2003/10/13

       Export system modified to keep track of which style is set when, and
       so it will unwind styles in reverse order to that which set, ie:
         Previously:
           <i><b>this is a <u>test</b></i></u>     <-- incorrect
         Now:
           <i><b>this is a <u>test</u></b></i>     <-- correct
       Please note that this parser works slightly differently... this is
       mainly to cover myself for anything that used to work, but no doesn't.
       Not that there should be any such thing... :-)

       Now supports font sizes, colours, and faces.

       Tested with loading, then exporting, some of the example documents.
       Remember, again, that the export system is designed to AID you in
       making HTML documents...



0.40   2003/10/14

       Hotkey to restrict the output to a stricter form of HTML 3.2. To bring
       this into effect, simply hold down SHIFT while saving your document as
       HTML, and keep SHIFT held down until the OvHTML slidy-bar thing pops
       up. You'll notice the title during HTML generation says "(stricter)"
       at the end.
       Here's what is different:
         Sexed single and double quotes   are converted to ' and ".
         fi and fl ligatures   are converted to fi and fl.
         Ellipsis  is converted to ...
         The three dash types , , and  are converted to normal -.
         Font FACE is disabled.
       This should allow most simple documents not using non-ISO characters
       to pass sgmls to "-//W3C//DTD HTML 3.2//EN", as the output claims. :-)

       Fixed 'bug' with image extraction failing, side effect being to abort
       the HTML export (pooh!).

       Now the image looks for +1 from the PICT as the PICTURE offset. This
       will become an option as I could have sworn last time it was -1, but
       maybe that was the result of too much wine?

       Well I f***ed up and pretty much killed the effects setting in v0.39
       so it was like:
         <b></b>this text should be in bold
       So, obviously, I fixed that. Actually, it was only a test to look for
       ways to speed up the export. That one made it a bit faster, but had a
       few tiny side effects that rendered the entire process, well, useless.
       Hehe...

       The copyright year is now read from the system clock (it was, before,
       fixed at '2003').

       Added another 'expert' option. Simply hold down CTRL while saving to
       create a more 'terse' output - this time it outputs minimal META tags
       and commentary.
       You can do this at the same time as the 'stricter' expert option,
       described above - just hold down both keys...



0.41   2003/10/16

       New configuration file format. OvHTML will automatically convert it
       it you. Note that it is not backwardly compatible (well, you'd get
       some milage out of replacing the first byte '&03' with '&02', if you
       really MUST go back to an earlier version of OvHTML than v0.41.

       Added Exporter options, you'll find these where the URI options used
       to be, and the URI options in the General Options.

       You can choose to disable FONT FACE, FONT SIZE, and/or FONT COLOUR.
       The font face is automatically disabled in 'Stricter' mode.

       You can also configure sparse HTML, or strict HTML as previously
       described. If you don't want these options always on, you can set them
       using the aforementioned CTRL and/or SHIFT keypresses - but this is
       only "for now".

       You'll see some other options "coming soon". Don't bother with using
       an icon enabler patch, selecting the 'shaded' options will alter your
       configuration, but won't cause anything else to happen, at least not
       in this build.

       By accessing the Secret Power User Options window, you can also
       tailor if the PICT/PICTURE relationship is +1 or -1. As this is a
       Power User option, it is left for Power Users to figure out how the
       Power User window is opened... :-)

       Trapped bad font colour pulled from stack. This is a bug somewhere
       else, I'll look into it when I have some time free as I don't expect
       it to be a "here I am, come and get me!" type of bug.

       Added support (in a number of places) for CRLF style linefeeds. These
       are used in the DDL files created by Ovation Pro for Windows. In
       particular, the image extraction got messed up by it.
       Note that it expects either &0A or &0D,&0A as a line ending. Anything
       else (&0D or &0A,&0D) is not valid.



0.41  2003/10/19

       Added "<adbreak>" to Scripter.

       Added day/night to scene title display.

       Both Scripter (OvHTML) and Scripter (for DOS) follow the re-revised
       Scripter protocol. Various code modifications (in both versions) to
       rationalise how things were handled.

       If you plan to walk the source - note that adbreaks are a SCENE, with
       bit 4 set. In order to maintain sensible scene numbering, you must
       count the scenes manually - as adbreaks don't get counted.
       Adbreak has bit four of the flags set (AND with 16), no other flags
       and/or relevant array variables have any meaning, their contents
       should not be assumed.




0.412 2003/10/20

       Modifications to the HTML export, now it *does* get all the tags in
       the proper place. Yipee!

       The Scripter parser still suffers from the "missing space" problem,
       but only three such omissions in a 62 page script, not bad. :-)

       Changed the MakeFile so that the "main" module is rebuilt EVERY time
       anything is rebuilt (doesn't take long), so the time and date reported
       are always exactly up to date.



0.413 2003/11/06

       Should probably be v0.42 as technically v0.412 was uploaded, but
       since the stupid Windows telnet client kept dropping dead, I don't
       think it got as far as actually being uploaded...

       Scripter supports:
         <ind> ... </ind>
         <revised>
         <target>

       When outputting <scenelist>, no longer assumes there'll be a running
       time.



0.414 2003/11/18

       Initial work on BMP detection. Otherwise, nothing of importance
       happened.



0.415 2004/01/01

       It is New Years. Sorry, but I have the blues as I am pretty sure that
       a large number of people I know have headaches today. Me? Well, last
       night I had two glasses of Ros d'Aude (that's down the lower-right
       side of France, a more acidic and stronger wine than the Anjou; rather
       reminiscent of Bardolino Chiaretto). TWO glasses. And at 0h00 CET I
       watched a bunch of people in lederhosen sing Aude-lang-syne (sp?)
       badly (I have the old analogue Astra so my line-up is mostly a bunch
       of German channels - I taught myself the days of the week in German
       and a few other words so I can try to look up stuff on teletext; but
       most of it is gibberish to me). I got my old Betamax limping along, so
       I watched an episode of Sliders. At +1h00 CET, I flipped over to CNNi
       to watch the fireworks (all three minutes of them) in London. Then I
       went to bed. How lame is that?

       Anyway, I have added BMP support to the HTML export. This is mainly
       for coping with DDL files saved on a PC - where the user has imported
       BMPs - and now (under RISC OS) you wish to 'export' as HTML. I have no
       idea if this will work through OvationPro as v2.72 just doesn't
       support BMPs - however writing an Obey file and doing it directly...
          <OvHTML$Dir>.!RunImage -tohtml <input file> <output directory>
       ...does work.
       IT IS A COP-OUT. If you think, on New Year's Day (is that a possessive
       's'? I mean, the new day belongs to the year, but does a year have any
       concept of ownership?) that I'm going to deal with the horribleness
       that is BMP, then you've got another think coming! It actually fudges
       the BPP to be 24bit in ALL cases, so then OvHTML's image core will
       decide to JPEG it (and not GIF it), which is quite okay since
       ChangeFSI is quite 'appee (as the French might say) to import BMPs and
       save 'em as JPEG.
       NOTE that ChangeFSI uses a pathetically slow implementation of a BMP
       decoder, so it will take FOREVER on large pictures. Also, it is
       apparently broken but I've yet to see that for myself.

       I don't plan to write a BMP decoder (in C *) until such time as it is
       necessary - like when OvationPro for RISC OS supports BMPs itself...

       [*] I have a crap-heap cobbled together in BASIC. It's about as flimsy
           as the average dress worn to an Academy Awards Ceremony (!), but
           it is a few times faster (what I mean is it is a few times faster
           than CFSI, but it's probably faster (and sexier to look at) than
           the awards dresses - after all, I don't think I'd be caught dead
           wearing a dress that looks like /that/ (y'know, if I was a girl)
           and to think the sucker paid thousands for it! Yaaagh!).
           Anyway, if need be I'll probably tidy it up and port it to C...
           ...that oughta be a whole heap of fun.


       THERE HAS BEEN A BIG CHANGE THE THE "ENTITY" SUPPORT.

       *                                                                   *
       *  pleeze lizzen do may cayfoolee foh I zal zay zeez oh-nlee vonce  *
       *                                                                   *

       Firstly, the "Stricter" option now does only one thing - it switches
       off font "FACE" in HTML export.

       The entity handling is split across FOUR files, which may be used as
       follows:
         1. !OvHTML.data.entities
            This is the standard entities file, and now must ONLY contain
            actual /defined/ HTML entities.
            This is looked-up on import, to convert things like &quot; to "
            and &Eacute; to .
            This is reverse-looked-up on export, to convert things like " to
            &quot; and  to &Eacute;...

         2. !OvHTML.data.sidneyent
            This contains 'extended' entities that may be used if the Sidney
            font is present. These extensions are the Greek alphabet and
            various mathematical symbols. Some browsers (like Oregano) will
            sort-of support them. Others, like Fresco, won't.
            This is looked-up on import.
            Note that exporting the 'extended' entities WILL fail; for a
            Greek 'alpha', you'll get an 'A', and so on.

         3. !OvHTML.data.unierr
            This contains UniCode additional entities, unofficial entities,
            and commonly-misspelt entities.
            For example:
              &Scaron; cannot be supported, so we map it to a plain 'S'.
              &fllig; is supposed to make a '' character, but since it is
              not an official definition, most browsers don't support it.
              '' is properly &cedil; but it has been seen as &Cedil; as well
              as &Cedilla; - both of which are wrong.
            On import, this data is considered a part of the normal entities
            list, so should be considered equal to the "entities" file.
            On export, this data isn't even considered. AT ALL.
            That's the difference between this and the "entities".

         4. !OvHTML.data.revent
            Of course, we hit a problem when we encounter an entity ('' is a
            good example) that is mapped from "unierr" but which has no
            inverse method - it's a one-way conversion.
            The way around this is to decide that since &fllig; EXISTS, and
            since many browsers don't actually support it, and since OvHTML
            does ... the logical thing is to keep '' as '' right up until
            the export. At that time, we'll convert it to "fl". This is what
            the "revent" file is for. It contains a list of 'problematic'
            characters, and what they should be converted into.
            NOTE that this errs on the side of caution. While '' and '' are
            not actually defined; '', '', and '' (etc) are - though some
            of the older browsers won't support them.
            In order to have those actually-defined characters converted to
            entities, simply remove the definition from "revent", and OvHTML
            will revert to the proper entity.

       It is worth noting that upon export, the conversion rules are:

          a. If character is >31 and <127 and not a known entity (like '&'),
             it'll be output as a plain byte - which is correct.

          -. (otherwise, we come through to the next steps if a known entity
              or a control character, or high-bit-set character)

          b. The "revent" data is scanned. This allows ANYTHING in the
             "revent" data to override any other definition. This is how
             &hellip; is a valid definition (for '', yet the export will
             output "..." and not "&hellip;").

          c. If no match still, we'll whizz through "entities" to see if we
             can get a match.
             ** WE DO NOT CONSIDER "sidneyent" OR "errent" AT ALL **

          -. (by now, we should have something, but if not...)

          d. Our final approach, since we've defined the document to be ISO
             8859/1 (Latin1), is to output "&#<ASCII code>;".

       This system has been introduced as it gives us greater control over
       how the entities are handled - in both directions. This is especially
       true of "revent" which saves us having to hardwire stuff into the
       software.

       Be aware that the "Stricter" option DOES NOT enable or disable the
       "revent" conversions. They are, now, ALWAYS active. The only way to
       'undo' them is to edit the files.
       You may prefer to edit the "revent" file to get &hellip; and the
       various sexed quotes to be handled 'properly' as they ARE valid
       entities.
       If you choose to treat '' and '' as valid entities, not only will
       you need to remove the entries from the "revent" file; you'll need to
       MOVE the entry from "errent" to "entities" (else it'll be a one-way
       conversion).


       IMPORTANT NOTE:

             On the subject of the sexed quotes, they are actually in a part
             of ISO 8859/1 that was originally marked as undefined (128-159,
             IIRC). This is why RISC OS has various Welsh characters '' that
             are not part of the Windows character set, and also why the
             Windows character set has Scaron yet we don't.
             Likewise, the Windows sexed quotes are different to the RISC
             OS sexed quotes for the same reason.

             Currently OvHTML has NO provision for correcting the differences
             in the Windows version of the character set.

             The (Western) Windows character set is CP-1252 (CP = Code Page).
             This is also known as PC-ANSI because the bloody Americans can't
             /stand/ that some non-American standards agency is involved
             (this is the same reason why everybody talks about ANSI C
             programming; it is actually ISO C as the ISO outranks ANSI by...
             well, quite a lot, but the Americans have bigger egos). It is,
             essentially, a version of ISO 8859/1 (Western European). At
             least, it is when we're talking about the 8 bit character sets.

             By the way... The character set used on the older 'DOS' systems
             (with the line-drawing stuff) is ALSO known as PC-ANSI, as any
             person who has ever called an ANSI BBS will know. I would say
             "typical Americans", but people might start to think I don't
             like Americans, and that isn't true - they play the "comic
             relief" role... <smirk>



0.416 2004/03/16

       Added entity definition "&bull;" to make a '', since a French tax
       document uses it...

       Special handler - </span> directly followed by alphanumeric will be
       converted to a space (that French tax stuff again!).

       Special handler for '<' followed by a non-alphanumeric and not '!' or
       '-' or '?' will be treated as '&lt;' and the character read... This
       should fix several software sites that enbed sourcecode without
       converting potentionally problematic characters into entity form.

       Began a power user option to replace:
         <font face="{corpus mapped font}"> ... </font>
       with:
         <tt> ... </tt>
       This may be more desirable given the number of RISC OS web browsers
       that actually support <font face> PROPERLY (like, all half of them?).
       NOT FULLY IMPLEMENTED, SO DO NOT USE IT *YET*.



0.42   2004/06/11

       A fairly simple upgrade. (haha...)

       Entity import now recognises &#x..; as being a hex entity. Why people
       couldn't stick with the original (denary) form is beyond me, but some
       people are weird.

       Also, "&#9;" is automagically converted to {tab} as it is obvious the
       user wants more than a plain 'space'!

       Scripter now counts the bytes of dialogue that each character has.
       This is not of great use as a statistic in itself (i.e. if your lead
       character says 14,573 bytes then she'll not say "whoo-hoo!") but it
       can be used for balancing. If your support characters are saying more
       than your lead ... why? Is it intentional or would it be better to
       swap lead?

       Scripter can now auto-add unrecognised characters to the character
       list (based upon dialogue). This is most likely to occur for minor
       characters thus forgotten, and for typos.

       Holding 'D' during conversion init allows you to invoke dialogue
       debugging if your values are 'weird'. It should say:
         [d+ <num> name "<name>"]
       or:
         [d+ <num> alias "<alias>"]
       at the start of a block of dialogue, if it has correctly matched
       the name/alias of the speaker. The number is the array reference
       of the match.
       If it fails, you'll see:
         [d? failed "<name>" - CREATING <num>]
       which means <name> was not recognised, so is creating a new entry
       <num> in the character array.
       In all cases, the end of the dialogue will say:
         [d-]

       In the dialogue counting, the following SHOULD work okay, but
       because it is technically incorrect, I have not tested it, nor do
       I plan to...
         <dia "whoever">
         blah blah
         <dia "somebody else">
         blah blah
         </dia>

       No longer says "Target duration exceeded by 0 seconds.", it is now
       smart enough to call this a match. :-)

       Scripter now has the "<omit> ... </omit>" keyword. In normal use, this
       is treated as if it was "<!-- ... -->".
       Note that <omit> ... </omit> can ONLY be used within the same sort of
       blocks as <i> ... </i> would be allowed within. You cannot span entire
       scenes using this, however:

       Scene definitions can contain the "omitted" parameter. This instructs
       Scripter to 'ignore' the scene. It is VERY important to use this
       (and not <omit>...</omit> with the scene contents) as:
         a. The other method will result in blank scenes.
         b. Scripter is aware of omitted scenes, and will write an
            appropriate entry within the <scenelist>, such as:
              #147  Pigs might fly            Int/Day   04:23
                    ( omitted )
              #149  La aport dell'cuore     Ext/Day   02:00

       Dialogue is now ragged-right (as it should have been AGES ago) so it
       is (now) a little bit easier &&/|| quicker to read.

       Added "Typewriter style" definition to style data - for a future
       expansion.

       Scripter now traps files it thinks are encoded Scripter files, and
       displays a message saying "Sorry, but...".
       As OvHTML is a FILTER and not an on-screen viewer, it WILL NOT support
       the processing of encoded Scripter documents.
       [currently - only Scripter for DOS does this, but that's 50% of the
        available Scripter software!]



-.--   2004/06/17

       Threw together a C version of the Scripter encoder. The BASIC version
       suffered from two faults:
         a. Horrible slowness
         b. Didn't run (also) on my craptop
       Both are fixed with the C version. :-)

       The encoding algorithm is "secret". It is pretty simple (if you're a
       programmer), but it is being kept a secret so that the format offers
       some small measure of security against wannabe file pinchers.
       If you require the algorithm for your software, then:
         a. Your software MUST be an on-screen viewer. If your software
            offers any export options (or is a filter like OvHTML) then you
            won't be given the algorithm. It will be considered if you export
            (say, as text) but disable this for encoded files.
         b. You'll need to be willing to sign a document stating that:
               i. You won't release the algorithm to any third party
              ii. If you plan to release sources, the decoder will be placed
                  within its own module and supplied ONLY in object form, not
                  as source.
       In return, I'll provide you with C source code for the encoder and
       also the source I use within OvHTML for decoding (also in C). In
       addition, if the algorithm should change in the future to be something
       more secure, then this will be shared with you.



0.42W  2004/12/12

       Basic reworking of OvHTML (no export, no pictures...) for use within
       the Microsoft Windows (32bit) environment.
       Read the "README.TXT" file for specifics.



0.43W  2005/04/17

       Now reads from a "config" file. If you open this and compare it
       against the RISC OS configuration options, you should find it matches
       up. :-)

       No longer crashes if you give it just the one filename (CLI params).

       No longer crashes in "-converthtml" mode trying to open the
       "<Wimp$Scrap>" file (!). It will direct all output to the file
       "C:\Temp\OvHTML.ddl".

       Now asks you to press a key after reporting an error. This is not to
       annoy you, but rather to force the DOS window to remain on-screen
       long enough for you to read the error. If you were not running OvHTML
       from *WITHIN* DOS (i.e. as a shortcut, etc) then the window would
       flicker, barely visible, and you'd not know if that was good or bad...

       Reworking of the "alignment stack" logic. For documents with a lot of
       (re)alignment (you know, <div align="....."> etc), things COULD have
       come astray at various points. This should cure a number of instances
       of stuff being centrally aligned when it shouldn't, and vice versa.

       The font "face" parsing now copes with multiple font specifications
       in the form: <font face="Courier New,Courier,mono">
       It will look for each specified font in turn until it finds (or fails
       to find) a match.

       Blockquote now outputs a newline before the block, so it now indents
       correctly.

       IMAGE SUPPORT! :-)
       The caveat, the source images MUST be JPEG format - anything else
       (namely GIF and PNG) will be treated as 'image not found'.
       OvHTML does not make any distinction between baseline JPEG and the
       progressive JPEG variant as it appears that OvationPro for Windows is
       easily capable of handling both. The same may not be true with Ovation
       running under older versions of RISC OS (by 'older', I mean *MOST*
       versions!).

       The document I used for testing this version is an off-line copy of:
         http://www.heyrick.co.uk/ricksworld/digibox/thcreview.html
       (it comes to 28 pages, from a 954K DDL file - good grief!)



0.44W  2005/04/20

       As I type this, it is 02:48 CET and I've been up since 06:30 after
       going to bed at 04:30 the night before. It's a rough life, eh? And it
       has taken coffee and ros wine to get me thinking of coding... oh,
       and I appear to have eaten half a family-sized Dairy Milk. Well, there
       goes my complexion or my bowels. Something will suffer for this!

       All to bring you <fanfare please!> modifications to the image scanning
       routine so it should work with files located ANYWHERE on your filing
       system (which may not be the 'default' drive, i.e. CD-ROMs and stuff)
       but note that I have not tested this.

       The image processing will now examine the JPEGs themselves to retrieve
       image dimensions, if you do not pass them in the <img src...> tag. If
       you do, the tag dimensions will be used in preference to the actual
       image size (this matches browser behaviour).
       I tested this one, lots. :-)

       Meanwhile, fixed bizarre bug in image processor where it would find
       files okay if you walked the path backwards, i.e.:
         img src="../../images/ricksworld/thc/l_lvdeadgrl3.jpeg"
       but failed to find files if you walked the path forwards, i.e.:
         img src="images/ricksworld/thc/l_lvdeadgrl3.jpeg"

       OvHTML will tell you how long the processing takes. It is kinda
       cheesy I know, but on the plus side it is frightfully inaccurate. And
       I'm not using quaint anachronisms here, it really is frightful... The
       DOS timer works at clock ticks, which is something stupid like 18.2
       per second. To confound this, it is calculated intergerally. So '1'
       is added to work around it saying stupid things like "processed in 0
       seconds". Consider it about as accurate as most of the "Time
       remaining" calculations you see. :-)
       Having said all this, the ENTIRETY of the file "thcreview.html" with
       ALL of the pictures (except the GIF ones) converts to a file just
       short of a megabyte; in FOUR seconds. This is a 466MHz Celeron running
       Win98SE, WinAmp, and all the compiler stuff at the same time; so any
       half-decent modern machine will work heaps faster...

       By the way, if there is something 'wrong' with your JPEGs (it isn't
       my JPEG scanning code, that is PERFECT!), then you'll get a whole
       bunch of unhelpful messages whizzing by yacking about "SOF" and "EOI"
       and suchlike. In this case, the offending image(s) is/are the one(s)
       that have their size(s) fixed at 256 x 256. This is the size that all
       images will revert to if the dimensions cannot be read; but then if
       my code can't read the size, it is likely a number of things will also
       fail. I've tested the code on JPEGs from numerous sources...



0.45W  2005/06/11

       Modified setup/config file loaders to read relative to the base path
       in which OvHTML.exe lives.

       The image retrieval path canonicalisation is now smarter and doesn't
       make crap like:
         C:\Program Files\DavidPilling\[...]\Filters\OvHTMLC:\RickMisc\[...]

       Basic provision for insertion of GIFs into the DDL, but OvationPro
       just displays a blank image area - perhaps you can't call a filter
       within output from a filter? I could have sworn that David said this
       was possible, but then I could have sworn I was born "human" but our
       little kitten has other ideas (she's "in heat"), so who knows - I can
       be mistaken! Anyway, this part HAS been enabled, but the image
       dimensions are fixed at 256x256. I'll correct this once I get the
       GIF images working. As it stands, GIFs WILL be inserted into the DDL
       file...



0.46W  2005/06/12

       Modified image insertion routines to only insert ONE copy of an image
       used multiple times (an example could be the 'haspics.jpeg' image
       that is used about thirty times in my THC reviews page). In such an
       instance, one copy of the image will be inserted into the DLL and all
       further references will point back to this one copy.

       If no parameters specified when OvHTML is run, it will pop open a
       Windows style message box to inform you of this. The DOS style
       command window ALSO opens in the background because it IS a DOS
       program (and, thus, shouldn't really be calling Win's MsgBox!). This
       is done because otherwise the error message would flash by as the
       command window opens and closes again...

       An icon has been drawn, new for the Windows version, and embedded
       into the EXE along with version information and comments, etc.



0.47W  2005/06/13

       "Translations" now working. The default translation file will
       automatically translate:
         <tr> -> <p>
       & <td> -> <br>

       URI for non-URLs will try a mid-shade Green. If that colour is not
       available, it will revert to VduGreen (like "lime" in HTML parlance)
       which may be a bit bright.

       Scripter now sorts character listing, first alphabetically and then
       by dialogue count.



0.48W  2005/08/25

       Fixed small error that would cause exceptions in cirtain situations;
       the "extended entities" is hardwired to be inactive because the
       Sydney font is not available under Windows, only in two places it
       was reading the entity count (from an undefined array) before doing
       the "has this been disabled?" check! Like, duh!

       Now recompiled as a Windows executable. It can still be called from
       DOS. The differences are:
         1. No command window will flash on-screen and vanish.
         2. If you have warnings for unsupported stuff (i.e. tables) then
            the warning will appear as a regular "message", with the whole
            "OK" button and everything, not a some brief text in a command
            window...
       Oh, it is also slightly faster too, but seeing as it chunders
       through large HTML documents in under a second on my slow old
       machine... a few milliseconds here or there probably won't be
       noticed!

