DELTA Editor issues reported by Mike Dallwitz via DELTA-L

DELTA Editor

(1) The 'empty' characters were Unordered Multistate characters with 0
states. This situation should never arise, either when data are imported
or when a character is added in the Editor. In fact, I don't know /how/ it
arose: I couldn't reproduce it. If you add or edit a character, you can't
exit from the 'Character edit' dialog unless you define at least one
state. Yet the characters are certainly there in the .dlt file that
Nicolas sent. Nicolas, perhaps you can tell us how you did it, so that the
'loophole' can be closed. If DELTA text files are exported, the 'number of
states' of the affected characters is shown as 0 (which isn't allowed by
CSIRO DELTA); but if they are re-imported, the 'number of states' becomes 2.

(2) The action sets included a file 'uncoded', based on similar files
supplied with CSIRO DELTA, but including the directive '*EXCLUDE
CHARACTERS 0', which is invalid. Again, I don't know how it managed to get
into the .dlt file in that condition. I couldn't import it, or enter that
value via 'View > Action sets > Edit'.

(3) When attempting to save an action set containing an error, the error
message is displayed over the toolbar, and stays in the same position /on
the screen/ until another window is activated, which makes it disappear.
Thus, after you correct an error, in order to access the 'Save' button you
need to either activate another window and then return to the editing
window, or move the editing window. If you use the latter method, and
there is another error, a second message is displayed without deleting the
old one; and so on. The error message should close when the user clicks in
the editing window. Alternatively (and better), it should be a normal
error window, which can be moved on the screen and has an 'OK' button to
close it.

(4) In the 'Action Sets' window, the actions are described by the contents
of the first SHOW or COMMENT directive, and should be sorted
alphabetically on this field. Currently, the order seems to be the order
in which the files are imported.

(5) When files containing a TYPESETTING MARKS directive ('markrtf' or
'markhtm') are imported (or created as part of a new dataset), or the
action sets are edited, the following changes occur.

(a) An extra set of angle brackets is added around each comment in the
TYPESETTING MARKS directive. The number of brackets continues to grow each
time the process is repeated. (However, the extra brackets cause no
problems when the files are used by Confor.)

(b) Each set of typesetting marks (between the special delimiters) is
rewrapped. During this process, 'end-of-line' may be changed to 'space'.
Spaces are significant in RTF, but line endings are not. Thus, the process
significantly changes the RTF marks, and typically the RTF header becomes
invalid. Depending on the changes, this may be diagnosed when the
generated RTF files are opened with Word, or the formatting information in
the header may be ignored.

Importing or editing should not alter the typesetting marks. As well as
avoiding the above errors, preserving the layout makes it easier to
understand and edit the typesetting marks (provided, of course, that the
layout has been designed with this in mind).

(6) In 'markhtm', the definition '#14. <NATURAL LANGUAGE: before item name
if at start of a file> …' initially contains 2 occurrences of @NAME, which
should be replaced by the current taxon name when each HTML description is
generated. Instead, they are replaced by the name of the last taxon when
'markhtm' is exported.

As a workaround until (5) and (6) are fixed, users should not import or
export 'markrtf' and 'markhtm'. The external DELTA files can be obtained
from the sample data, and any required editing can be done on these files
via a text editor. To guard against accidental overwriting of the files,
they should be backed up, and the corresponding internal action sets that
are created as part of a new dataset should be immediately deleted.

(7) The special delimiter in the 'markhtm' action-set template should
preferably be changed from '!' to '|', to allow the use of '<!DOCTYPE …'.

(8) In the action-set templates in a new dataset, the standard HTML
character entities such as '&bull;' should be used instead of the
Windows-1252 numeric versions such as '&#149;'. Also, references to the
obsolete DELTA Web site 'http://biodiversity.uno.edu/delta/' should be
changed to 'http://delta-intkey.com/' or an ALA URL as appropriate.

(9) In exported DELTA files, non-ASCII characters are represented by RTF
Unicode escapes and special control words, for example '\u233?' for
e-acute, and '\lquote{}'. (This is the same mechanism used by the CSIRO
Editor.) This potentially allows the use of any language (but see Confor
problems below). The mechanism can give rise to 'words' longer than the
120-character line-length limit in CSIRO Confor, but this limit isn't
present in the ALA Confor. In future versions, it would be worth
considering the optional use of UTF-8 in the exported DELTA files, as
discussed previously on DELTA-L.
Original issue reported on code.google.com by chris.go...@gmail.com on 22 Oct 2013 at 5:31
AtlasOfLivingAustralia / open-delta

DELTA Editor issues reported by Mike Dallwitz via DELTA-L #244
