Open danse opened 6 years ago
la soluzione di questa issue non è così rapida come pensavo. includere il filtro com'è funzionerebbe ma non verrebbe mai accettato upstream, quindi è più comprensibile per tutti che rimanga un filtro finchè non c'è un'alternativa accettabile.
un'immagine ed un paragrafo sono due diversi run in DOCX. tutta la logica di processing in Pandoc.Text.Readers.Docx
è basata sul singolo run (vedi per esempio runToInlines
). L'estensione +styles
è probabilmente utilizzata in Pandoc.Text.Readers.Docx.Parse
, quindi la logica di riconoscimento degli stili e trasformazione del paragrafo andrebbe lì. anche in quel caso si tratterebbe di esaminare le possibili sequenze di due elementi. È decisamente qualcosa di desiderabile nel parsing DOCX prima o poi ma non qualcosa che possa fare in un giorno o due. In questa fase del progetto preferisco sviluppare in ampiezza chiudendo diverse piccole issues piuttosto che dedicare una o due milestones ad un argomento specifico
volevo lasciare le issues irrisolte nella propria milestones per avere un'idea degli errori di pianificazione, ma complica il filtraggio quindi la rimuovo
l'applicazione di -f docx+styles
causa anche #93, penso di risolvere reintroducendo il filtro che unisce blocchi di codice, ma è tutta logica che vorremmo rimuovere integrando la logica per le didascalie in pandoc
Attualmente convertiamo le didascalie applicando il
filtro-didascalia
, che però rende l'uso di pandoc complesso per i nostri utenti in quanto richiede l'opzione-f docx+styles
che a sua volta porta ad applicare ilfiltro-rimuovi-divs
(vedi #19). Una volta inclusa la logica di conversione della didascalia nel parser.docx
di pandoc potremo rimuovere due filtri ed un'opzione daconverti
e dalle buone pratiche, semplificandole