Image Markup Tool blog

Created new SVG icons for Annotation, Add Annotation, Remove Annotation, Delete Annotation, Clone Annotation and Annotation List. These will be rendered to bitmaps and added into the 12 icon libraries at home (the GIMP on OSX works better than the Windows version, so it's better to do this on my laptop, and the icon library development is mostly done at home anyway).

The TIMTDocument object now uses processing instructions (as discussed in earlier posts) rather than the xsi:schemaLocation attribute to link to its schema.

The app version info (major and minor) is crucial because it's used all over the place to identify files such as XSLT files for conversions and rendering. Made changes to the actual embedded version info, the schema filenames, the XSLT filenames, and the imtSchemaFileName global variable. Actually, this should be derived automatically by the app on startup, since it's just imt_ + Major version + _ + Minor version. Look at making this the case. It'll help prevent changes being missed in future versions.

Change the docbook conversion XSLT files -- filenames have been changed to reflect the IMT version number, and contents have been updated, but round-tripping is broken, so some change in the app has not been accounted for.

...as detailed in this task.

Did some further research into this, and came to these conclusions:

• Syd's proposal is not significantly different from Makato Murata's proposal; they differ only in minor syntax, and the latter is an Oasis working draft, while the former is explicitly not a working draft; furthermore, Syd's position is that the TEI would happily use an Oasis recommendation if there were one. Therefore I believe it makes sense to use the Oasis standard rather than Syd's proposal.
• oXygen, which is our own favourite editor, used on all our projects, does not understand the Oasis processing instruction; therefore, for our own convenience, it makes sense to include the oXygen processing instruction as well, even though it is not a standard. oXygen is widely used in the TEI community, so IMT users will be familiar with it.
• I downloaded and installed a trial version of Stylus Studio, another common XML editor. It seems unable to handle RelaxNG at all. For XSD files, it uses the xsi:noNamespaceSchemaLocation attribute on the root element, and imports the xsi namespace. This is no use for RelaxNG, so we can ignore StylusStudio.
• I downloaded and installed a trial version of XMLSpy. Same thing: it only seems to handle DTD and XSD. Therefore we can also ignore that.

The upshot is that I believe the IMT should automatically include two processing instructions to link to the RNG schema, like this:

<?oasis-schema href="imt_1_5.rng" type="application/xml"?>
<?oxygen RNGSchema="imt_1_5.rng" type="xml"?>

I also think it might be a good idea to put these schemas on the IMT Website, and link to them there, like this:

<?oasis-schema href="http://www.tapor.uvic.ca/~mholmes/image_markup/schemas/imt_1_5.rng" type="application/xml"?>
<?oxygen RNGSchema="http://www.tapor.uvic.ca/~mholmes/image_markup/schemas/imt_1_5.rng" type="xml"?>

That would make it possible to validate a document from anywhere. The application itself should only add these processing instructions if they're not there; otherwise, it should retain any existing instruction, so that any user who wants to point to a local schema can do so. I'll implement this according to the task schedule.

The bug with IMT file saving under VISTA, which we discovered when testing the OS, turns out to be limited to the IMT. In fact I was trapping errors while a file save was happening, and then doing nothing in the except clause, which amounts to suppressing the error. Added this to the except clause:

This is not very sophisticated, because it simply recycles the error message from the OS, but in all cases I can think of it's clear enough.

Check whether any updates are required to the installer in order to exclude the old xsd schema files and include the new rng ones.

Then build the app, build the installer, update the Website, and release 1.5.

This is a reasonable decision -- if the zip output is to be a portable package, it should include the schemas. It's arguable this should be a choice, but that's a complicating factor for the GUI; we'll add it if people ask.

The schema changes will have to be documented on the Website and in the Help and Tutorial.

Once I've decided on the best way(s) to link schemas to documents, I need to implement this in code, in the TIMTDocument object, so the correct schema links are added to the files when they're saved, and preserved when they're opened. The latter might be much harder than the former, because if they're PIs they're not so accessible through the DOM...

Once this is done, we need to test the automatic conversion code (XSLT) which runs when opening a 1.4 file.

Simple task (as long as you don't forget one): check for all locations where version numbers are used in code, and make sure they know about the 1.5 version.

We need to automatically convert any old IMT doc to the new format before loading it. This is the list of XSLT files needed, and what should be included in each:

• imt_1_4_to_imt_1_5.xsl. This should include the two changes for this release, which are:
  1. Remove the xsi:schemaLocation attribute from the root element.
  2. Add any processing instructions for linking RNG files which we have decided to adopt (see previous post).
• imt_1_0_to_imt_1_5.xsl. This should be based on the existing imt_1_0_to_imt_1_4.xsl, but with the addition of the changes above.
• imt_1_3_to_imt_1_5.xsl. This should be based on the existing imt_1_3_to_imt_1_4.xsl, but with the addition of the changes above.

Other files can be dropped from the conversions folder and archived.

The IMT has always used XML Schemas for its documents, but as documented elsewhere on the blog, there are substantial problems with using this format. These problems have now afflicted the Mariage project; changes in the TEI P5 schema since the project started have resulted in our files being invalid against the current P5 schema, and our old schema also denies us the use of some attributes we now need (notBefore and notAfter on <date>. Regenerating XSD schemas from ROMA is problematic because Roma's native format is RNG.

So the Mariage schema, along with any other schemas based on TEI P5, needs to be rebuilt on a regular basis as P5 continues to change; and that means that it makes more sense to move to RNG for the project. To do that, we need to move the IMT to RNG, and that's what I've started to do.

The first stage is complete: I've generated an SVG 1.1 RNG file from the SVG DTD using Trang (in oXygen), and I've re-generated the IMT schema as RNG by uploading my ODD file into ROMA. Using only these two schemas (an explicit XLink schema doesn't seem to be needed), I've been able to validate an existing IMT file. The only change that needs to happen in the IMT files is to remove the xsi:schemaLocation attribute pointing at the old XSD file.

I'll now create a task list for the remainder of this process.

New release is announced here. Download it and put it in all the right places. Zip has increased in size significantly; check with the list why this might be. It looks a bit odd.

Greg and I began testing VISTA with non-privileged logons, and discovered a bug either in VISTA or in IMT, which presumably affects other apps too. When you try to save a file to a location where you don't have write permissions, the save operation fails silently; no error message comes back. The Modified setting remains true, so you can't close the document without being prompted; nevertheless, this is a serious issue. Look into this and make sure the apps show an appropriate error message when a save fails due to lack of privilege on VISTA.

Integrated the Nuvola image dll to provide GUI images for the application in a way which is more compliant with the LGPL under which Nuvola is released, and also allows us (or anyone else) to use the same code and images in non-open-source projects if we wish. Built a new version (1.4.0.6), updated the documentation in the source file archives, built an installer, tested, and released the version.

...and updated the Website info, feature list, roadmap etc.

...as specified in the task created yesterday.

Created a routine for building the Web view output, then packaging it in a zip file. This involved abstracting some of the existing aCreateWebViewExecute routine, which is tied to a TTntAction; that routine should now be rewritten as a wrapper which calls the new function (after some setup). Added that as a task; need to do that while the code is still fresh in my head.

I've been having increasing trouble getting the 16x16 images to display correctly in menus; it seems that the images are too small for the transparency blending functions to work properly, and images end up with fuschia backgrounds, or grey ones. Finally, I switched the menu image list over to the 24x24 images, which solved the problem once and for all. For the record, these are the settings that should work for the Images subproperties in TTntMainMenu:

• BkColor: clNone
• BlendColor: clNone
• DrawingStyle: dsNormal
• ImageType: itImage
• Masked: True

Completed the function requested by Claire for importing categories from an existing file. I ended up taking a slightly different approach from the one I'd predicted: I now create a TIMTDoc object to read the file, which is simpler than creating a standalong TAnnCatList. Since this TIMTDoc is not linked to any TImgView32 component (it's only used for manipulating data), I created it passing nil for the image component; this necessitated adding a check when freeing it, because it attempts to clear the layers of the image component during its Empty method. That was the only change necessary, though.

Fixed this bug by adding an if clause to web_view.xsl which prevents output of a category header in the menu if there are no associated annotations.

While creating the handout for John Lutz's class, it occurred to me that the Web View output now consists of seven files, and it would probably be a good idea to allow users to archive them into a zip file automatically (just as they can already archive the image and the markup file). This should be fairly straightforward to add (maybe six hours of work). Added as a task.

• Created a new TTntAction for Import categories from file.
• Created a vector icon for it.
• Built the 12 bitmap icons from the vector, and inserted them into the image lists.
• Roughed out the function itself in pseudo-code.

This shouldn't take more than a couple of hours to finish.

Done Jan 30.

Claire and France have begun marking up several documents without starting with the categories from previous documents. You can start a new document using categories from a previous doc, but once you've started marking up a document, you can't then go back and import categories from another. This makes sense as a feature, and it has a real use-case right now, so I'll add it for the next version. In the case of collisions (imported category has same id as existing category), the import of that category should be skipped.

The decision is made (forced on us, really, due to problems with the Mariage schema), and the updates have been planned in detail.

The problems we've encountered with getting working XSD versions of the SVG DTD have convinced me, finally, that I need to move the IMT over to using RNG schemas rather than XSD. This will be done in the next version, and I've added it as a task.

The bug report from Paolo Cutini a few days ago relates to tooltip hints on some spin-edit components in the Preferences screen. The issue is this:

These spin-edit controls (where you either type a number into the box, or click up/down buttons to make the numbers change) are not Unicode-enabled; that means that their Hint (tooltip) properties are not Unicode. Therefore they don't show up in the translation screen and can't be translated. The problem is that the TSpinEdit control is itself not a standard Delphi control; it's a combination of a TUpDown and a TEdit. The TntUnicodeControls component set which we use for Unicode-enabled GUI controls does not contain a Unicode version of TSpinEdit. Therefore, we're faced with these choices:

1. Create our own TUnicodeSpinEdit by combining the TTntUpDown with TTntEdit. This would not be trivial, but it's not that hard. However, it means we've added one more layer of complexity and dependency to the app.
2. Construct the same functionality in place in the app by faking the component, using TTntUpDown and TTntEdit. This would take some time.
3. Disable the hints on these components completely, so that Paolo and other translators don't get confused and frustrated by not being able to translate it.
4. Leave it as-is, so there is a partly helpful hint for anyone who understands English. This takes no effort, except explaining to Paolo what the problem is.

I'm going to do the last until there's time to do (1) or (2).

I've made this a separate post because it's likely to be quite long. First a general point: both of these feature requests involve significant work, and we'd need to get project approval for them. Right now, for both IMT and Transformer, I'm in maintenance mode, just doing bugfixes that are prompted by reports from users. To justify the extra work proposed here, we'd need to know who needs these features; if they're mainly for the Scraps project, what's the nature of HCMC's commitment to the Scraps project, who's using it, etc.

The request to make IDs visible and editable by the user makes sense; the only objection to it is that it's likely to be confusing to users who don't know what they're for, and also it'll involve a lot of error checking and user-informing to get around the inevitable id collisions when users forget that they've already used an id. Linking between documents is already straightforward for anyone who understands how xml:id attributes work; Claire Carlin's documents do this, by using TEI note tags like this:

<note type="link"><ref xml:id="wifes_lover" target="a_une_femme_mariee.xml sur_un_jaloux.xml la_crainte_du_cocuage.xml#vers_trente-sept remede_pour_le_cocuage.xml#deuxieme_strophe fantastique_repentir.xml#strophe_dix-huit Bosse.xml#wifes_lover">Les "Stances. A une Femme mariée", les vers "Sur un jaloux" et "Fantastique repentir" suggèrent que l'amant est un ami de l'époux, ce qui n'est pas impossible, ni dans cette image, ni dans "La femme battant son mari" de Bosse. Cette gravure représente aussi la réalisation de la peur de l'époux dans "Sur la crainte du cocuage". Le message du "Remède pour le cocuage" est qu'il faut accepter l'inévitable.</ref></note>

In other words, a note inside an annotation can link to another note inside another annotation in another document. This is much more flexible in that it allows linking to multiple targets from one link, and it allows multiple links inside one annotation. Given that this is not complicated to do, I don't know that the work to add extra code to the IMT is justified.

The template idea is a good one, and we've already discussed it at length; I'd like to do it, but it would involve a serious amount of time and work, and at the moment I don't have evidence that enough people are using IMT in ways that require this to justify it.

There's another option in both these cases, though: if these features are crucial to the Scraps project, then David could add them himself. IMT is open-source, the code is all on the Website, and the cost of one copy of Delphi at academic pricing isn't really significant. The Scraps version of IMT could either be forked completely, allowing David to create a very specialized app without the need to maintain general features for users in other contexts, or the new features could be added into the main trunk. If David and the Scraps project don't have the resources to do this, then perhaps that's an indication that they're not that vital.

Paolo Cutini wrote to point out that the latest distro didn't include the latest Italian interface file. My fault -- I must have lost track among the several that he's sent as the app has been updated recently. I did a quick rebuild of 1.4.0.2 and posted it on the site to include the latest Italian gui file. The rapid installer builder is really paying dividends!

Fixed the bug reported by Paolo Cutini, and also tidied up some of the conversion XSLT (for loading/converting old files), then did a new release package. Abandoned the use of Winzip to bundle the installer; Inno can provide an icon for the executable of the installer, and all of the prefatory messages are pretty much unnecessary for a free program. This will make future releases even quicker.

Paolo Cutini reported a bug with the Create Zip Package function of IMT; if the file already exists, it adds files to the archive, instead of overwriting the archive as it should.

Checked this out, and it's a clear bug. Logged the bug on the bugs page of the site, and investigated in the code. This is the problem function, in the ZipMasterFunc.pas library:

function TufrmZipMasterFunc.ZipFiles(TheFiles: TWideStringList;

We need to amend these lines:

Archiver.ZipFileName := ZipFileName;
Archiver.AddOptions := [];

to add a file deletion:

Archiver.ZipFileName := ZipFileName;
if WidefileExists(ZipFileName) then Archiver.EraseFile(ZipFileName, htdAllowUndo);
Archiver.AddOptions := [];

I'll get this done on Monday, and release a new version.

Working on the Mariage files, I discovered an oddity in the validation of SVG code. Chris Lilley of the W3C had written to me before Christmas, pointing out that I was using svg:id attributes on rect elements, when I should be using an unqualified id attribute. He was correct; however, I've now discovered that using plain id results in a failure to validate against the SVG 1.1 schema I'm using. This schema is an XSD file generated by Trang from the W3C's official DTD; they don't provide an SVG version at all. However, our code does validate against the DTD for SVG 1.1, so it seems that it's the schema, not the XML, that's wrong; and the error seems to have been introduced by the Trang conversion. This is not a major issue, but it's annoying. I've written to Chris Lilley to ask him if there's a standard XSD release of the SVG 1.1 standard, but I'm not hopeful; we may have to try to debug the XSD file we have, and fix the problem that way.

In the process of working on the Mariage site, I discovered that changes to the executable InternalName for the installer had caused the app to stop detecting when it was opening a version 1.3 file, so it was not doing conversions from 1.3 to 1.4. Did a quick bugfix, and (thanks to the new installer setup) built a new installer without having to change anything. Updated the site, and tested the installer while updating IMT on Endive and Chicory.

Updated all the source code libraries, and added new ones for the zip functionality; updated all the Web pages; and released version 1.4.

After many years of intending to do it, I finally downloaded the ISTool set of add-ons for Inno Setup. The objective is to take advantage of the ISPP (Inno Setup Preprocessor) to automate the assignment of version info and numbering to setup files and setup GUI messages. The docs are a bit sparse for ISPP, but I eventually figured it all out, and I'm now able to do this:

• Extract complete version info from the program executable.
• Use that info to create all relevant GUI messages and numbering for the installer.
• Specify file paths once, in the header of the file, and have the rest of the script automatically populated with the right paths.
• Also get company name, publisher, app URL etc. directly from the executable.

The main value of learning how to do this is that it will make updating the installer much quicker and simpler in future; once the executable has been rebuilt with a new version number, and as long as the version info in the file is complete, the installer will use it automatically and we'll be able to build a new installer for a new release without changing the Inno Setup script at all.

A further possible benefit for the future is that there is a download dll available for ISTool, which can be called from an installer to get files directly from the Internet. This provides the promise of releasing installers which only download files which are required or have changed, reducing server load. How practical this might be for the type and scale of applications we release remains to be seen.

Started the process of adding documentation for the Zip output to the Help file. Created the topic file, and a new "What's New" file, and XIncluded them in the main file. Still have to flesh out the details and add appropriate index and glossary entries.

Initially I had written the zip package functionality into the product using the TZipForge component, which is commercial (Half-Baked Software has a licence for it). However, that's incompatible with an open-source application, so it's now been replaced by TZipMaster, which is an open-source (Lesser GNU) Delphi component based on an adapted version of the InfoZip freeware code. Changes:

• Added the required dll to the app folder, and to the installer.
• Added unit zipmasterfunc to replace the other unit based on TZipForge.
• Managed to retain the existing progress dialog; it can be used with both zip components.
• Tested and debugged.
• Added licensing info and updated documentation on the site to include the component.

Remaining related work is covered by the "Update documentation for 1.4" task.

The "Set the viewing scale of the image" tooltip for the Zoom combo box in the main screen cannot be translated. My fault: I was using a TComboBox instead of a TTntComboBox, so the Hint property wasn't Unicode. Changed the component, tested the results, updated the English GUI file, and added the bug to the Website bug list.

It's long been part of the plan for IMT to include the ability to create a zip archive which includes the XML markup file, the image, and the schemas and odd files associated with the project. This is now working:

1. Installed ZipForge into Delphi 2005. This took a few tries; in the end I had to get the latest version, run the installer, then manually install the packages in D2005 using the BPL files which end up being built in zipforge/Lib/Delphi 2005.
2. Created a hidden form to house the component, including a zip file save dialog and a couple of umsg labels for user messages.
3. Created a progress dialog box with two progress bars to show the file progress and the overall progress.
4. Created a function in the hidden form which accepts a zip file name and a TWideStringList containing file masks to add to the zip file.
5. Created event handlers to update the progress window (this is largely based on the ZipForge basic demo for Delphi).
6. In the main application form, created an action aCreateZipPackage, along with an associated menu item on the File menu.
7. Built the function which saves a temp version of the file, populates the TWideStringList, and calls the zip file building function.
8. Tested and tweaked.

The next stage is documentation.

Made the following changes as part of the migration to 1.4:

1. Renamed the IMT schema and odd files to imt_1_4_p5.
2. Changed the app variable imtSchemaFileName to reflect this.
3. Created XSLT files to convert 1.0 and 1.3 files to 1.4 (I've decided to cut of 0.9 files at this point; it was an early beta and anyone using the app seriously will have upgraded in the interim).
4. Tested the update system, and discovered a bug: when a temp file is created by the update XSLT, it's created in the temp folder, which means relative links to images are lost and the image can't be loaded. Changed the update function which calls the XSLT, so that it actually saves the temp file in the same folder as the original file. Tested this, and it works well.
5. Updated the docbook i/o files to 1.4. This revealed a couple of oddities in those conversions, introduced when I was using the app to create help documentation. Figured those out and fixed them. IMT 1.4 can now export to docbook, and import from docbook to IMT 1.4. Old docbook files are not imported; there's little evidence that anyone except for me is using this functionality, which is only just approaching maturity, so I think we're safe with this for the moment.
6. Tweaked and tested the Web View output. The changes are minor, but will affect the Mariage project code, so once IMT 1.4 is released I'll need to move it to the working machines for Mariage and make small changes to the XSLT on the Mariage site. Added a task for this at the end of January.
7. Began planning the zip functionality which will be the main new feature. I'll get into that in more detail tomorrow.

I've begun work on the 1.4 update, and did the following bugfixes (based on bug reports by Paolo Cutini):

1. Fixed a missing tooltip hint in the Delete Annotations(s) toolbuttons.
2. Addressed the problem of translating column captions in TTntListView components. The way our translation engine works, there's no simple method to delve into the component's properties and extract/change the Columns[i].Caption values, so I took a different approach and did away with the regular column captions, replacing them with overlaid panel components. It seems to have been easier than I expected; I just needed to update the column widths whenever the panel splitter is dragged. If this proves a workable approach (especially when there are more than two columns), then it will save a lot of work in future applications.
3. The main Title label on the main window was set to ParentFont = False, which meant that it didn't change when font settings were changed in the preferences window.

• Tracked down the source of the Chinese interface bug; it's a Delphi bug in TypInfo.pas:
  
  Borland bug report.
• Figured out a workaround using an overloaded function.
  Tested this -- seems to work well.
• Did a release (1.3.0.4).
• Worked on the menu background colour issue, and found a workaround there too (unassigning them reassigning the Images list when changing captions).
• Got another release together (1.3.0.5).
• Posted the package.
• Updated the source files on the server.
• Updated the Website.

-Began looking at bugs reported since the release:
-The menu background colour issue appears to be a known Windows bug, documented here:
http://www.tsilang.com/delphiglobalizationtool_faq.html#20
There may be a workaround we can use, also explained on the page.
-The Chinese interface issue appears to be something much more general, afflicting all TntUnicodeControls; they no longer seem to support widestring captions! Created a sample project demonstrating the problem, posted it, and then explained the issue on the Tnt Webboard and on the relevant Borland newsgroup. Hope this gets fixed soon, assuming it's not something stupid I'm forgetting about. But it does look as though the code worked fine until I installed the October release of Tnt components, and then it broke.
-Looked at the display of disabled images in menu items, and found there's no good way to avoid Delphi's auto-creation of a crappy disabled image (often just a grey box).

• Built and tested a fresh installer.
• Discovered a bug with interface file loading -- menus ended up with a yellow background.
• Tried to fix this by various strategies to trigger a repaint of the component (being a TComponent descendant, it lacks actual Refresh, Invalidate, and Repaint methods). Seemed to work on most machines, but on a test install on Arugula it failed. This may be some kind of conflict with a graphics driver.
• Logged this as a bug on the Website.
• Posted a request for help to the Borland internationalization list (newsgroup home for Tnt components).
• Rebuilt, tested, tweaked and rebuilt the app and installer several times. Final test was in Lab B, where the screen settings were problematic (Large Fonts?), so I had to go back to the app and set Scaled = False and AutoScroll = False on every form. This should probably also be done for Transformer.
• Final release 1.3.0.3 seems OK tested on a variety of machines.
• Updated the Website.
• Added a Projects page showing three projects using the tool.
• Tweaked the site menu settings to make it a bit smaller.
• Created a project summary inc file and linked it into the future HCMC site projects page.
• Added a link to the blog from the site menu.
• Posted an announcement to the TEI list.
• Tried to post to TAPoR news feed, but no sign of the capability on the site! The My News tab has disappeared. I find that site hopelessly confusing; every time I click on something it opens a new tab in my browser with a small, unhelpful bit of info.

• Created a DocLauncher application with no GUI, which wraps the mdhHelp functions and can be used to launch tutorials and help files from shortcuts.
• Documented the above.
• Tested and tweaked it.
• Incorporated it into the Transformer installer, and tested the results works well.
• Posted it on the Source Website.
• Rewrote the IMT installer to include the DocLauncher and related functionality/icon creation.
• Updated all the licence docs etc. for the installer.
• Created an icon for the installer archive.
• Built the installer.
• Did a test install on a couple of machines. Contextual Help (F1) wasn't working in dlgAnnCat.
• Went back to Delphi and discovered the HelpContext had been deleted. Added it back in, and checked it for other windows.
• Rebuilt and tested the app.
• Figured out that the Tutorial launching code from within the app wasn't using mdhHelp functions. Rewrote it, rebuilt the app, rebuilt the installer, and tested on my VM where IE is the default browser. Opens in FF, but strangely: nothing is displayed. This needs more investigation. Only seems to show up on the VM, though; other XP machines were OK.
• Added a bit of code to make an example file available on the Recent Files menu if it's the first run of the app.
• Rebuilt installer and distro again.
• Found a Nuvola icon suitable for "Close File".
• Built the BMPs from it.
• Added a Close File action and menu item.
• Tested the app again.

WAS: The tutorial has lots of outdated info (especially about file formats). Proof it and fix it before you do anything else.

Completed November 8.

WAS: Post all updates to the Website, write to the TEI list, and also post on TAPoR.

Done Nov 11, except for TAPoR post; I can't find the page which allows me to post to the newsfeed!

WAS: All the site pages, including version info, release dates, and roadmap need to be updated ready for release.

All done Nov 9.

WAS: Source code libraries need to be updated, and their desc files checked for accuracy.

Completed Nov 10.

Do thorough testing of non-application-related aspects of the distro:

• Help files launch to correct topic.
• Tutorial launches and works.
• All ancillary files are installed.
• App will uninstall correctly.
• DocBook I/O works.

Test the installer on two or three machines, including Win2000.

WAS: Build a new installer for the IMT, including schemas, docbook and other XSLT, help files, tutorials etc.

Done November 10.

Worked all day to finish the Help docs:

• Added libxml and related Delphi code creators to acknowledgements.
• Wrote the rest of the Categories topic.
• Added lots of XML and TEI-related items to the glossary.

• Wrote these topics:

  • What can I do with my marked-up images?
  • XML file formats
  • The Web view output format
• Added new XSLT handlers for ordered lists and non-clickable images.

• Built and tested the file.

• Tweaked the CSS quite a bit.

• Fixed validation issues raised by the W3C validator.

This is basically ready for prime time now.

Spent all day working on the IMT Help:

• Did screenshots of all the windows and dialogs.
• Marked up the image window screenshot.
• Marked up the annotation dialog screenshot.
• Wrote the introduction.
• Updated the acknowledgements.
• Added some glossary entries for P5 etc.
• Began figuring out how to manage small inline images through Docbook.
• Built placeholder files for all the required topics, and added them into the root file.

• Integrated the Help calling system into the application, added a Help menu item, and assigned Help keywords to forms.