On Mon, Jul 28, 2003 at 08:55:54PM +0200, I. Oppenheim wrote: > > Please help me with identifying the errors and the > mistakes in the draft.
1) It starts by saying "The ABC standard itself deals only with structured, high-level information; how this information should be actually rendered by e.g. a typesetter or a player program, is dealt with in a separate standard". It then goes on to state where each field "will" be printed. This is at least inconsistent, and I don't think this is the right place for this level of detail. Better (IMO) would be if the proposed style-sheet mechanism allowed a way to control where, and which, fields the typesetting programs print, so that people can decide for themselves how they'd like things printed (I want different layouts for different purposes, for example) and still get consistent behaviour across different programs. <One possibility> My "abc_rip", for instance, uses a "%%RR-TextFormat:" magic header line, which is a "format string" sort of thing in which any instances of T:, C:, etc are treated as fields and replaced by their values. "Any" including any "%%" specials. Including a %TUNE variable which is replaced by a picture of the tune (with no text), so that I can put things below as well as above. That's how I manage to print a copyright string under the dots. It's probably less than perfect, but for me it works better than anything else I've seen. 2) I'd like more discussion of the redefining of A: as Author (of lyrics), and consequent redefining of O: to hold the "area" information that A: has been used for in the past. Jack suggested this, and it may may well be a good idea, but I haven't heard much comment from anyone else here, and I'd like to be sure we've thought it through. I have an interest here, since I use A:==area heavily; and since, as Jack noted, I use this with multiple O:'s, relying on human intelligence to make sense of possible confusion, it wouldn't be a simple editing job; so I'd like to be sure we all agree it's The Right Thing To Do before I do it. One thing I notice about the proposal for O: is that it introduces (for the first time, I _think_) a hierarchical structuring of information within a field (A: as area did that across different fields, of course, and I agree with Jack that it's not altogether nice). I wonder if there are maybe any catches to this ? One minor point, for example - the recommendations for which fields to print where (see 1 above) would lead to the whole lot getting printed, without any associated syntax for picking out sub-fields (I might want to print just the country, as I can at the moment, for example). Does any other software do anything with these "information" fields ? There are possibilities with external programs, of course, like the $ grep O: | cut -d ',' -f 1 example I gave earlier, which is why I argued (and repeated offlist to Irwin) the case for most-significant-first ordering rather than Jack's little-endian example. Special-case treatment of the O: field. That's what bothers me. It's the need for a delimiter character. My scripts, for example, which generate the listings for my web collection - since I list (and allow searching) these by country, and definitely don't want separate entries for, eg, "England" and "England, NW" I'll have to pick out all info up to the first comma. If I do that to any other field things'll go wrong, since comma doesn't mean "delimiter" anywhere else (and I can't think of any other character to which this wouldn't apply). Which is not the end of the world, of course. I can do that if I have to. But it's the sort of complication that makes me wonder if it's really the right way to go. -- Richard Robinson "The whole plan hinged upon the natural curiosity of potatoes" - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
