[Python] Taglia e cuci di PDF

Daniele Varrazzo piro a develer.com
Ven 19 Set 2014 15:01:18 CEST


On 2014-09-19 13:32, Manlio Perillo wrote:
> 2014-09-19 14:08 GMT+02:00 Daniele Varrazzo <piro a 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



Maggiori informazioni sulla lista Python