imtSchemaFileName
global variable is now derived automatically by the app on startup, since it's just imt_
+ Major version + _
+ Minor version. This makes updating simpler and avoids version-related errors in future.Contact Us on 0800 123 4567 or info@example.com
imtSchemaFileName
global variable is now derived automatically by the app on startup, since it's just imt_
+ Major version + _
+ Minor version. This makes updating simpler and avoids version-related errors in future.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:
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:
on E: Exception do MessageDlg(E.Message, mtWarning, [mbOK], E.HelpContext);
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:
xsi:schemaLocation
attribute from the root element.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:
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.
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:
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:
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:
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:
The next stage is documentation.
Made the following changes as part of the migration to 1.4:
I've begun work on the 1.4 update, and did the following bugfixes (based on bug reports by Paolo Cutini):
-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).
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:
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:
Wrote these topics:
Built and tested the file.
Fixed validation issues raised by the W3C validator.
This is basically ready for prime time now.
Spent all day working on the IMT Help:
Integrated the Help calling system into the application, added a Help menu item, and assigned Help keywords to forms.