Braille output strategy

[Han-Wen Nienhuys]

address@hidden writes:
> My scheme isn't really up to much and the kind of code required to add
> Braille output will be more comfortable in C++ in my view.
> Modifying the grammar is trivial to add a \braille block. Where I take it
> from this is a bit of a mystery...

There are two options:

        * To write a third translator type (we now have Engravers for
        normal typesetting, and Performers), by making a derived class
        from Translator. This new type (let's call it "Embosser"), can
        setup data structures to print braille dots in any way that
        you see fit. A lot of work, advantage: but you will not be
        burdened by any constraints of the printed
        output backend.

        Disadvantage: you have to redo all formatting.  If you go this
        route, it might be easier to make a generic (musicxml)
        outputter in lily, and write a separate application to convert
        from the generic output to dots

        * Write alternative engravers, that produces graphical objects
        printing dots. This allows you to reuse spacing, line breaking
        etc, and makes it easier to test if the dots are printed
        correctly.

        Once all the dots are printed correctly, make a separate
        "printing backend" (next to the PostScript, TeX, and SVG one)
        to drive a braille printer.

> I'm not entirely sure of the linkage between here (the bison parser) and
> midi output itself.
> In the meantime, I will keep on hacking.
> 
> I feel that I need a crash course in basic Lilypond architecture to get me
> going..... :(
> Any takers?

There is a section in the user manual discussing internal
design. Other than that, the best guide is studying the source code
itself.  If you take the second route, you can start out small by
making a single engraver and grob-type, eg. one that prints dots
corresponding to note heads only.

Good luck.


-- 

Han-Wen Nienhuys   |   address@hidden   |   http://www.cs.uu.nl/~hanwen