I. Oppenheim wrote: >> As for the 1.6 and 1.7.6 specifications, regardless of what program X, Y, or >> Z does, the written spec is awfully vague. I have several possible >> approaches to different elements of this, but the basic concept appears to >> be that "\" at the end of a line isn't so much a continuation, but a "don't >> break the staff here if you would normally". > > No. In 1.* it basically meant: continue on the next > line of the same type. (Whereas in 2.0 it means: > continue on the next physical line, regardless of the > context)
I don't think I can accept that definition, even though looking at the archives, I've seen that definition before. It implies far too many things which are problematic and not at all true for the programs I have here. Of course, I've only been testing with Barfly 1.52 and abcm2ps 3.7.18 right now. Doubtless other programs behave differently. Problem 1: It implies that you could break a line arbitrarily. For the ABC 2.0 style continuations, that is indeed the case, but we're talking about a 1.* specific parser here, where you can have other lines in-between. So if you allow breaking a line arbitrarily, you could end up with something like this: X:1 T:some made up tune M:4/4 K:Dminor abcd|efga|[K:\ M:3/4 G]def|gab| ...which would need to cache part of the first line (the "[K:" part) until the next tune data line arrived and it had the remaining info it needed to finish parsing stuff. Even without the meter change in the middle, both Barfly and abcm2ps give parse errors on that. And it doesn't need a field -- try something like: abcd|efga|c'\ ''def|| ...and you still get errors with both programs, even with nothing inbetween the lines. Likewise a lyric line would need to cache partial syllables. Take: X:2 T:another made up tune M:4/4 K:Dminor abcd|efga|bcde|| w:a1 b2 c3 d4 e5 f6 g\ w:7 a8 b9 c10 d11 e12 Now here, Barfly apparently only uses the abc 2.0 style continuations (for lyric lines - odd that it doesn't do the same for tune data lines...), so it always ends up with "gw:7" as a syllable, but ends up with the syllables in the right place. abcm2ps renders this with the g and the 7 as separate syllables, so all the following syllables are off by one note. All of which leads me to conclude that under 1.*, you cannot continue a tune line or a lyric line at any arbitrary character point -- you need to continue it at a point where a staff or lyric line break would be valid. Problem 2: It doesn't have any inherent limitation on what "line of the same type" could be. Which means you could continue just about any sort of line. Such as: X:3 T:yet another made up tune M:4/4 K:Dminor abcd|efga|[K:G]\ M:3\ bcde|\ M:/4 def|gab| ...complains about the split Meter line in both Barfly and abcm2ps. (With or without the intervening bcde line...) So it appears to me that it can't work with just any arbitrary field -- IMHO, the only fields it even makes sense to use it on (under 1.*) are tune body lines and lyric lines. So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: "A backslash ("\") at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending." It becomes pretty straightforward (actually fairly easy) to parse if you define it that way, and seems fairly consistent with the 1.* usage. Anyone see any gaping holes in that logic? -->Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html