Posizione di un oggetto nella pagina PDF

Grazie della risposta, innanzitutto. Non vorrei andare off-topic nel risponderti, ma provo a farlo.

Ciao,
scrivere un editor per LaTeX che non sia grossomodo un ‘esercitazione’ è assai difficile perché esistono editor già molto evoluti come TeXWorks e Kile.
Il progetto potrebbe essere interessante solo nel caso che si implementino idee veramente nuove che facilitino la stesura del sorgente

Lo so che non è facile sviluppare un editor serio, ma tutto è partito come curiosità e la curiosità è poi dilagata, facendo, col tempo, venire in mente nuove idee. Non dico che siano tutte idee eccezionali o rivoluzionarie. A volte accade di rendersi conto che qualcosa che ti fai tu risponde meglio alle tue esigenze rispetto a ciò che ti viene offerto. È anche una questione di gusti. Esistono editor abbastanza diversi tra loro, è vero, ognuno con una sua anima. Ma proprio per questo non è detto che io (ma userei un pronome indefinito) ne riesca a trovare uno che più si confà alle mie richieste.

Sempre che tu non voglia esclusivamente divertirti, ti consiglierei di pensare a contribuire allo sviluppo di TeXWorks per esempio, piuttosto che correre da solo.

Almeno, questa è la mia opinione: tentare di scrivere un nuovo editor solo se si hanno idee innovative da proporre altrimenti conviene dare una mano con TeXWorks.

TeXworks in effetti è l’editor che preferisco, semplice, essenziale, con anteprima. Al contrario di Kile, che trovo barocco. Capisco che puoi pensare che sia una perdita di energie, ma è anche questo che muove il software libero (mi è capitato di dare una letta qualche volta al tuo blog e mi è parso di capire che ne sei un sostenitore): prendere ciò che c’è già e modificarlo per riadattarlo alle proprie esigenze.

…come per esempio un sistema di tips che suggerisca la sintassi corretta di un comando che si inizia a digitare appartenente ad un pacchetto caricato nel preambolo od alla classe alla maniera di un IDE per sviluppatori di un dato linguaggio.

Mi interesserebbe parecchio un argomento legato, ovvero (spererei proprio che esista già, ma non ne ho conoscenza) uno standard (un formato) per commentare i comandi alla loro definizione che ne precisino la sintassi (numero di argomenti, cosa rappresentano, eccetera). È una cosa usuale per i linguaggi di programmazione tradizionali, mi piacerebbe molto vederla in TeX/LaTeX. Approfitto per chiedere: qualcuno conosce uno formato di questo tipo? Un editor se ne potrebbe avvantaggiare moltissimo.

La lista di simboli è già presente per esempio in Kile: si clicca un simbolo e compare ne viene inserito il codice nel sorgente, il quale verrà poi processato in compilazione.
Per il resto ti confesso di non aver capito a cosa ti possa servire il pdf contenente il simbolo nella posizione fissa che desideri. Non riesco ad immaginarne un uso nel caso di un editor.

Dovresti spiegare meglio le basi della tua strategia.

Se riesco a individuare la posizione del glifo di un simbolo, la estraggo assieme al nome del comando che viene usato per inserirlo e scrivo tutto nel file exports.txt. In seguito, converto ogni pagina PDF in immagine e, usando la posizione trovata prima, ne ritaglio tutti i simboli salvandoli (come immagine) da qualche parte. A questo punto, per ogni simbolo ho l’immagine e il nome del comando: rielaboro tutti i simboli, li catalogo e li inserisco in un database. L’editor dovrebbe contenere una sorta di tabella con questi simboli (riordinabile secondo alcuni criteri: per pacchetto, per tipologia…): tu ci clicchi e vengono inseriti.

L’idea è che mi piacerebbe estrarre automaticamente questi simboli dalla Comprehensive LaTeX Symbol List, proprio perché la consulto molto spesso e vorrei che l’editor che uso ne riproducesse in qualche modo l’organizzazione. Ciò consentirebbe, tra l’altro, di inserire (eventualmente) in modo automatico una \usepackage con il nome del pacchetto che contiene il simbolo (informazione presente nella CLSL).

In definitiva, lo sviluppo di nuove idee rappresenta un processo entusiasmante, ma reinvetare la ruota ogni volta è certamente poco produttivo.

Tieni conto che possono essere sviluppati delle nuove feature per TeXWorks per mezzo di un linguaggio di scriting interno dunque iniziare a contribuire al progetto non è affatto lungo.
Per esempio, io avrei bisogno di un comando che in automatico riorganizzi con le giuste spaziature il contenuto del sorgente LaTeX di un ambiente tabular, allineando il testo delle celle ai caratteri &, per migliorarne l’editing manuale.
Oppure mi servirebbe un comodo comando per inserire ad inizio sorgente i tag per TeXWorks di definizione della codifica ecc.
Ecco dunque la conclusione: inventare potenti tool per editor LaTeX è fantastico, ma con plug-in per TeXWorks diventa anche utile con poco sforzo.
Anzi, rendere possibile la tecnologia a plug-in per TeXWorks è già di per se una buona avventura.
R.

Tra le idee c’è anche questa che dici tu sulle tabelle (ho già buttato giù del codice che pare funzionare): è una cosa semplice da fare ma che pure non ho visto in nessun editor (magari mi è sfuggita). Apro una parentesi: TeXworks non supporta i progetti con più file. Anche qui trovo che la scelta che l’utente deve fare del file TeX principale sia una cosa evitabile: (al di là di possibili sofisticazioni) basterebbe che l’editor si crei un albero dei file aperti (chi include chi): il file principale non può che essere la radice.

Voglio essere più chiaro, ragionando su due filoni. Da un lato, tutte le scelte progettuali che si fanno nello sviluppo di un’applicazione sono basate su compromessi e temo che ciò che io voglio non sia ciò che altri desiderano. Detto questo, c’è un altro aspetto da considerare: le idee sono appunto idee e possono essere ovviamente applicate su editor diversi. Voglio ancora studiare le diverse possibili strade: la fattibilità di cui parlavo all’inizio deve tenere certamente conto di tutto ciò ed evitare un eccesso di spreco di energie. Considero la possibilità di intervenire su TeXworks (che, ripetto, è quello che mi ispira di più) ma lascio assolutamente spalancata la possibilità di fare qualcosa di mio.

Apprezzo molto il tuo intervento (anzi ti chiedo se puoi suggerirmi link significativi su TeXworks, a parte quelli che si trovano sulla homepage).

Torno quindi a chiedere se esiste un modo per estrarre la posizione del riquadro disegnato da \framebox.

Uhm,
se ho capito bene ti serve ritagliare i glifi: avresti un pdf che contiene un glifo giusto, e ne vorresti ricavare l’immagine come icona.
Ma non puoi usare pdfcrop sul pdf? L’utility ti restituisce un pdf ritagliato secondo il bounding box, e fa parte della dotazione delle distro TeX (meglio usare TeX Live).

Non è un problema ritagliare il PDF in sé (posso farlo anche con ImageMagick o scrivendomi io il codice, così velocizzo l’esecuzione). Ci sono diversi glifi in ogni pagina. Il problema è che le coordinate verticali che riesco a estrarre non sono corrette (risultano spostate). Per “ritagliato secondo il bounding box” intendi che vengono eliminati i margini biachi? Mi pare che questo faccia pdfcrop.

Le coordinate dei glifi devo estrarle per forza lavorando in TeX (tutto il resto lo faccio con altri strumenti, e non è un problema). Il codice che avevo postato prima cerca di estrarre proprio la posizione dei glifi, ma non è preciso. In particolare, non riesco a ottenere le coordinate verticali della linea superiore e della linea inferiore del framebox.

Ti segnalo che premettendo al sorgente il tag opportuno, TeXWorks è in grado di individuare il file master. Per esempio compilando il sorgente con la seguente dicitura iniziale:
`% !TEX encoding = UTF-8
% !TEX program = pdflatex
% !TeX root = ../master.tex`
si da istruzione all’editor di compilare in realtà il file master.tex che si trova nella cartella superiore.
Questo è molto comodo perché così posso lavorare su file secondari e compilare il master.tex contemporaneamente, lasciando secondaria la necessità della gestione dei progetti come fa Kile per esempio, sempre piuttosto macchinosa, tanto che non lavoro mai utilizzando la gestione a progetto defli editor: troppo poco efficiente.
Invece con il sistema dei tag si va che è una meraviglia.

Sì, conoscevo già questo sistema, anche se non l’ho mai usato. Quello era solo un esempio: certo, specificare a mano qual è il file principale non mi abbatte la produttività, ma questa è una delle tante piccole cose che potrebbero essere automatizzate.

Per un formato di literate programming nei sorgenti dei pacchetti, credo non sia difficile costriure una standard in grado di informare l’editor sulla sintassi dei comandi, il quale potrebbe informare l’utente in tempo reale.

Non so se sia mai stato messo a punto qualcosa del genere, ma basterrebbe ispirarsi a Python od a javadoc o, per restare in casa, al formato di documentazione.docstrip…
Ciao

Intendevo proprio qualcosa tipo javadoc, ma che fosse già standardizzato (anche nel senso di “ampiamente diffuso”), una cosa a cui tutti possono uniformarsi e sfruttare.

Grazie
Antonio

Credo di aver finalmente risolto:
`\newlength{\heightoframebox}
\newlength{\depthoframebox}

% print and save position: visualizza (a PDF) il suo argomento e ne salva la posizione su file
\newcommand\psp[1] {%
\immediate\write\SymbolExport{page = \number\thepage}%
\settodepth{\depthoframebox}{\framebox{#1}}\settoheight{\heightoframebox}{\framebox{#1}}%
\zsavepos{b\thepage\detokenize{\string#1}}\framebox{#1}\zsavepos{e\thepage\detokenize{\string#1}}%
\immediate\write\SymbolExport{left = \zposx{b\thepage\string#1}}%
\immediate\write\SymbolExport{right = \zposx{e\thepage\string#1}}%
\immediate\write\SymbolExport{middle = \zposy{b\thepage\string#1}}%
\immediate\write\SymbolExport{height = \the\heightoframebox}%
\immediate\write\SymbolExport{depth = \the\depthoframebox}%
}`
che produce per ogni simbolo:
`page = 1
left = 10962208
right = 11735533
middle = 46493363
height = 10.34444pt
depth = 3.4pt
command = \textasciicircum
`

left e right sono le coordinate orizzontali del bordo sinistro e destro del framebox. Le coordinate verticali del bordo inferiore e superiore (che TeX misura dal basso verso l’alto) sono invece rispettivamente middle-(depth*65536) e middle+(height*65536).

Forse il codice è un po’ ridondante (dovre provare a smanettare direttamente con \ht e \dp), ma almeno funziona. Mi rimane da capire bene cosa rappresenta middle. Approfondirò…

Ciao