* I think it would be wise to explicitely reserve the use of nonmentioned letters E, Y lowercase letters. Move ''exended information fields'' paragraph to front, just after the normal ones
* irregular compound meter: two ways of display 1) 3+2+2/8 displayed as is 2) (3+2+2)/8 displayed as 7/8 *G: group; clarify (I still don't get its definition) or explicit allow any useage... *H:is (the only?) field that can contimue on the next line without repeat of the H: ? *K: field move all the mode stuff, pipers stuff etc. to an appendix. allow mode=.... signature=.... and depricate previous use of keysigs mode fields etc. *w: to appendix * Tune-fields: rename to "Use of fields within body", explicit note which fields may be used in-tune. * ~ I always thought that ~ is used for a prall-trill by default. Hardly anybody will know what an Irish-roll is (is it eatable?) *chordsymbols (rather than accompaniment chords). Note that programs will regard anything written between double quotes, notn starting with one of the special characters as a chord. (there quite a few chord notations out there... being not compatible at all; so leave it to the interpreteing program to do whatever it sees fit best.) That done, just discard any not agreed on examples of chords ( C C# G7 Bbm Ebm7) would do IMO, But as this will reraise previous discussions make a statement like 'programs should treat chord symbols quite liberately' * clefs: Is "K: Am transpose=-2 " illegal where "K: Am treble transpose=-2 " is not? since "clefname" starts the specication (I'd rather like to see clef=clefname than clef alone there are not many abc tunes in the wild using other clefs than treble yet so... The K: syntax is complicated enough already) Allow for more than ''the 7'' keys (clef=clefname will do so) will ensure forward compatibility & easy parsing *voices state that all voices to be mentioned in the abc-body have to be declared in the header when using the [V:ID] syntax, where each ID will be referenced over and over. *special characters Reserve some unicode encoding scheme for future enhancements (forward compatibility) So characters like copyright signs, trademark or whatever may be used in the (near) future: proposal: \$<UnicodeSymbolName>; Current (ABC2) implementations should just ignore it, replace with some other sign or simply ignore it (but should parse the syntax) for the time being and implement it in version 3 or so. (please deprecate the archaic and insufficient octal seqences!!!) *reserved characters Try to make clear where/why which characters is reserved. Even better: reserve characters in a specialized context. - global - within body - within header - within textstrings - within w: and/or W: lines reserved syntax would be a nice thing to have. Knowing which generic syntax might be used in the future will render software useable for a longer time. *stylesheets The draft suggests that %%staves is likely to be moved to a stylesheet. So a stylesheet gets firmly boud to a specific abc-tune. I think that's a *bad* idea. The way CSS-sheets are usually used is that multiple HTML files reference the CSS for layout purposes. The %%staves example does not fit in that way at all. Fonts, papersizes, spacing do. %%text, %%vskip, %%newpage etc certainly do not. Programs should provide a list of stylesheet defaults (so the need arises for a complete current list of ABC2-directives) *special characters: why use = for a macron and/or stroke through - or _ is more logical The oe ligature is missing (fine to me as there is a readable workaround for it). It would violate the rules to allow \oe but on the other hand e-ring is not used anywhere (is it?) z-circumflex is not available in latin-extended-A (especially not as it typesetted here ;-) My 2 (or 3) cents Arent To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
