Re: Text spanners that word wrap.

[Ralph Little]

Hi Han-Wen,
Thanks for your response.

The second option is what I think is best.
The Braille reads like unbroken text and is not structured positionally in 
music like usual notation, since this kind of visual structure has no meaning 
to a blind person. 

If you care to look at the examples on http://www.brl.org/music/index.html 
(you need the SimBraille truetype font to see the effect properly), they show 
that where Braille notation is shown, even with conventional notation, it is 
shown as normal sequential text. However, even Braille music has the concept 
of a bar measure, which is used as the delimeter of structures such as 
multi-voice phrases etc.

So far, I have generated Braille equivalents of notes, with accidentals, codes 
for specifying octavation and length and the same for rests, attached to note 
events as you suggested. This makes the music spacing extremely distorted and 
I have a lot more to add to the Braille. It has to be separate, if 
accompanied by normal notation, floating above as sequential text, not 
aligned with the normal notation.

I know it sounds a bit bizarre, and would seem to be both missing the 
notational point, and bucking the trend of everything else, but having seen a 
few examples, I think that it really has to be that way. It is also partially 
the reasoning for my considering a separate font. A small amount of 
conventional notation often generates a substantially larger amount of 
Braille to represent it. Therefore, it would make sense to leave the 
conventional notation to format and space itself out and present the Braille 
above (or below!) doing it's own thing. 

For example, a single note can require up to 6 Braille characters to fully 
describe it, including 3 characters to specify from which set of lengths it 
comes from, 1 character to specify the octave, 1 character for sharp/flat 
etc, and the single character which defines the length and name of note 
combined. If the note is a 256th, then there is an extra 2 characters. It can 
get very long winded, although this is more the exception.


On a related note (sorry to go on!) since I am tackling time/key signatures, I 
have been studying the related engravers to get the details on how they are 
generated, and although it all seems to make sense to me, I am becoming aware 
that a lot of the new Braille code is effectively copied from the other 
engravers to do largely the same thing. This instinctively seems wrong to me 
and I wonder if I am barking up the wrong tree.
I'm quite open to a little peer review and suggestions from other quarters. 
Therefore, I suggest that I wrap up neatly what I have done so far and send 
it up as a possible experiemental addition for scrutiny, especially since 
this is my first major piece of work for the cause!

What do you think?

Regards,
Ralph

Han-Wen wrote:
>> Since Braille is read as "prose" and is not formatted as per the
>> characteristics of printed "conventional" music, I am looking at
>> generating the text for a staff and planting it as a prose section above
>> as discussed previously. However, it *might* be long and I would prefer
>> it to word wrap rather than tramming off the end of the staff and/or
>> continuing with the next system as a break aligned object.
>> 
>> Can anybody tell me if there is an easy way to do this as things stand,
>> or will I have to program in a special item formatting object to achieve
>> this? I'm happy to have a go at this if there is no alternative already
>> available.
>
>I don't really understand: you want to put braille code next to
>staves. Should the braille texts be synchronized with musical events
>or not? Or are they to be synchronized only at line breaks (ie. at the
>left end of a system), and then follow their own formatting?
>
>What happened with the incremental path of starting with a \markup
>command that prints braille dots?