On 2014-09-19 13:32, Manlio Perillo wrote:
2014-09-19 14:08 GMT+02:00 Daniele Varrazzo <p...@develer.com>:

[...]

Proprio pochi minuti fa mi e' venuto in mente che sia chordlab che rst2pdf
usano reportlab come motore di rendering. Anziche' usare chordlab come
processo esterno potrei usarlo come libreria e scrivere nello stesso
documento che sto generando.


Potrebbe essere una alternativa, ma significa fare a meno di reST ed usare
reportlab per la gestione del documento finale.

Perdendo reST per la gestione del documento finale non mi perdo molto: docutils e' debole in questo e Sphinx in effetti e' nato proprio per coprire questa mancanza (ed e' stato quello il momento in cui si e' potuto usare reST per generare la documentazione di roba grossa come Python). Gia' usare rst2pdf mi consente di avere di piu', e questo non lo perderei: la struttura del documento rimane quella che avevo in mente:

    titolo
    ------

    Qualche parola di circostanza

    .. song:: the-man-who-sold-the-world.cho
    .. song:: karma-police.cho
    .. song:: personal-jesus.cho

    Ringraziamenti finali

solo che la direttiva song, invece di generare un pdf in un file temporaneo da unire al documento in una fase successiva al rendering, consiste nel richiamare chordlib (la libreria di chordlab), passargli il "canvas" o quello che sia di reportlab, e fargli fare la sua cosa li'.


Io proverei a scrivere il "renderer" del tuo formato chopro, che generi un
documento reST, usando delle direttive custom per la formattazione che ti
serve.


Scrivere quelle direttive potrebbe non essere proprio banale, in
particolare riguardo lo spostare il "cursore" per scrivere gli accordi
sopra al testo:


Si, non è banale perchè, come scrivevo, reST non è "formatting oriented".


chordlab lo fa parlando direttamente con reportlab; passare per docutils
comporta che comunque quei programmi dovranno bypassare un po' di
infrastruttura docutils e interagire col renderer. Quindi a questo punto il
mio formato e' fortemente legato al formato di input.


Perchè?
Usi un elemento dell'AST di reST e poi definisci come renderizzarlo in PDF. Al limite quindi il tuo formato diventa legato al formato di output, non di
input.

Tra l'altro in

https://github.com/hammeruke/hug-chords/blob/songbook/books/songbook.py

non stai già usando reportlab per definire come renderizzare il tuo
elemento SongSheet?

Si' ma e' roba facile: e' solo un segnaposto che consuma il numero di pagine giusto per ottenere l'indice corretto. E' molto piu' semplice che avere tutti i dettagli dell'AST.

Ti basta definire un elemento SongLine o SongFragment ed usare reportlab
per la formattazione, a meno che non mi stia perdendo qualche pezzo
importante...

Ci sono cose da fare tipo "se la linea della canzone non contiene accordi allora lascia un interlinea minore" e cosine del genere che sono (semi-)risolte in chordlab e sono esterne a quello che *normalmente* un renderer reST fa, quindi si tratta di scrivere tutte le direttive e patchare il renderer pesantemente. Avendo gia' chordlab (semi-)funzionante, se posso, provo a frustare quel cavallo anche poco dopo che e' morto. :)


Credo tu non abbia nemmeno bisogno di generare il documento reST
intermedio, ma puoi generare l'AST direttamente e renderizzarlo in PDF. Rispetto a reportlab almeno hai tutte le feature "document oriented" di
reST.

Tutto questo è solo ad intuito, non avendo mai utilizzato reST per fare cose più complicate di un rst2html di un documento standard, ma mi stupirei
se non fosse possibile.

Diciamo che il mio compito e' semplificato dal fatto che il songsheet e' sempre una pagina a se', mai completamente integrato nel documento. La strada di avere un unico AST globale, comprendente sia le parti di documento che quelle dei songsheet, e' di sicuro "elegante", ma se mi costringe a risolvere problemi "specializzati" tentando di usare una struttura e un renderer generico potrebbe non essere la piu' semplice. Su questo c'e' il fattore risparmio, per cui se ho gia' queste due toolchain funzionanti:

    [documento .rst] -> (rst2pdf+reportlab)  -> [file PDF]
    [documento .cho] -> (chordlab+reportlab) -> [file PDF]

uno dove prova ad integrarsi? Pigro 1: coi pdf. Pigro 2: con reportlab. L'alternativa:

[documento .cho] -> [documento .rst+cho] -> (chorst2pdf) -> [file PDF]

costringe a scriversi uno o due pezzi che non esistono ancora: conversione cho -> rst con direttive custom, rendering delle direttive custom in reportlab e probabilmente hackare il renderer stesso perche' e' facile che quelle direttive vadano "di traverso" a come il motore di rendering e' progettato.

-- Daniele

_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Rispondere a