Andrea

Ciao a tutti,

lungi da me l’intento di accendere una polemica sterile, se mi sono deciso a inviare questo messaggio è solo per fornire un possibile spunto di approfondimento in merito alla gestione dei font in TeX.

Sono stato io, in una mail privata, a dire ad Emiliano che le fonti (o i font, ovvero gli stili dei caratteri della famiglia) Computer Modern sono scalabili: ho usato il termine pensando alla generazione del .dvi e in maniera elastica, dato che in effetti la descrizione di partenza dei font cm è più che scalabile (nel senso dato al termine dai font TrueType): è vettoriale e parametrica. I .pk usati per la presentazione a video o in stampa sono in effetti bitmap, ma la descrizione dalla quale hanno origine è data in metafont, ed è in formato vettoriale con molteplici possibilità di intervento sull’aspetto finale (per effetto dell’assegnazione di particolari valori ai suddetti parametri), tant’è che buona parte delle varianti della famiglia cm (roman, slant, bold, typewriter text, sans serif, small caps, e qualcun’altra) sono ottenute a partire dal medesimo insieme di descrizioni.

La peculiarità della famiglia cm, già riportata sia da Emiliano sia da fabusdra, è che Knuth, da appassionato tipografo, ha corretto l’aspetto del font in funzione del del numero di punti utilizzati, per cui un corpo 10 si presenta ai tipi diverso da un corpo 5 scalato 2x, come evidenziato a pagina 16 del TeXBook.

L’intervento di metafont è quasi del tutto trasparente: in una installazione di TeX ben fatta metafont viene chiamato in causa, per ciascun font, solo la prima volta in assoluto che si utilizza quel font; dalla descrizione .mf, vettoriale, vengono generate, in cascata, una descrizione gf, già bitmap, e da questa la descrizione .pk che è poi quella utilizzata a video e in stampa (sempre che si usi un driver che accetti direttamente il .dvi: ne esistono ancora?). E’ durante il passaggio mf->pk che vengono riportate a video le sfilze di codici di carattere tra parentesi quadre.

L’integrazione fra i diversi componenti di una installazione del TeX fa sì che l’utente possa evitare di farsi carico dei dettagli, per fortuna; ai tempi in cui giochicchiavamo con PasTeX su Amiga, l’impostazione di default per la chiamata a Metafont faceva sì che la generazione dei font partisse in modalità ProofReading ovvero con letteroni singoli a tutta pagina, ovviamente non utilizzabili per la visualizzazione del testo che si era redatto. Dopo un po’ di trial and error e di letture di documentazione non sempre chiarissima, gli script di colla andavano a posto e tutto prendeva a funzionare a meraviglia, quasi sempre. Altri tempi.

Per concludere, in teTeX le descrizioni della famiglia Computer Modern, nell’installazione Mandrake 9.0 di default, si trovano in /usr/share/texmf/fonts/source/public/cm. Senza un minimo di conoscenza di metafont la lettura può risultare alquanto ostica, ma ci si può comunque fare un’idea del meccanismo di fondo e delle relazioni tra le diverse varianti del font.

Ciao a tutti.

Ciao Rodolfo,

con qualche giorno di ritardo, eccoti i risultati delle ulteriori prove effettuate sull’abbinata emacs-xdvi. A patto di rispettare un certo ordine nelle operazioni, l’interazione tra emacs e xdvi sembra funzionare anche meglio di quella tra lo stesso emacs e kdvi!

Caro Andrea,

Bene, mi sembra che, a meno della modifica del file .el per attivare la ricerca in avanti direttamente da dentro emacs (ammesso che sia questo l’editor di tua preferenza), per il resto dovremmo esserci.

❓ vuoi dire che è possibile attivare la ricerca in avanti anche direttamente da dentro emacs?

Sì.

Si tratta di modificare leggermente il file kdvi-search.el (io l’ho rinominato xdvi-search per evitare confusioni, aggiornando poi il .emacs nella mia home così che carichi xdvi-search anziché kdvi-search e associ la sequenza di ricerca in avanti alla funzione giusta). Più nel dettaglio, si può procedere come segue:

0) copiare kdvi-search.el in xdvi-search.el; aprire xdvi-search.el con emacs
1) sostituire tutte le occorrenze di “kdvi” con “xdvi”
2) intervenire sulla funzione xdvi-jump-to-line sostituendo le linee 53-56

(start-process “xdvi”
“xdvi-output” “xdvi” ;;; src-arg
;;; args for -sourceposition:
“–unique” (concat “file:” dvi-file “#src:” current-line filename)
“-sourceposition” (concat current-line filename ” ” dvi-file)
)))))

(Nelle quali xdvi ha già preso il posto di kdvi 😉 )

con

(shell-command
(concat
“xdvi -sourceposition ”
current-line filename ” ”
dvi-file ” -editor ‘emacsclient +%l %f’”)
nil “xdvi-errors”)))))

[Nota 0: Il linguaggio di controllo di (Xe|E)macs è il LisP, pertanto tutte le parentesi sono importanti.
Nota 1: dopo svariati tentativi di avviare un processo per il controllo di xdvi, tutti andati male, ho deciso di optare per una shell. Questo comporta delle restrizioni d’uso, riportate più avanti (4.3).
Nota 2: Gli spazi sono importanti (determinano la giusta separazione tra gli argomenti della chiamata a shell).]

3) Salvare e uscire

4) IMPORTANTE: nell’uso dell’accoppiata emacs-xdvi così impostata occorre

4.1) Avere già un’istanza di emacs in esecuzione (o aprirla ad hoc, senza argomenti).
4.2) Lanciare xdvi sul file da editare, con le opzioni di ricerca inversa stabilite o tramite linea di comando (“-editor +%l %f”) o tramite l’assegnazione della medesima stringa a una variabile d’ambiente tra XEDITOR, o ViSUAL, o EDITOR (in quest’ordine di priorità) [consultare la pagina di man di xdvi per ulteriori informazioni].
4.3) (Questo è il punto veramente IMPORTANTE.) Lanciare PRIMA una ricerca inversa da xdvi, così che emacs abbia un canale aperto col visualizzatore, e poi da emacs le eventuali ricerche in avanti. In questo modo si mantiene un controllo asincrono sia su xdvi, sia su emacs.

X.0) Nella “malaugurata” ipotesi che si sia lanciata prima una ricerca in avanti, che dovrebbe aver aperto una propria istanza di xdvi, finché non si termina quell’istanza non sarà possibile riprendere il controllo di emacs.

X.1) Nell’ancor più malaugurata ipotesi che fosse stata lanciata una ricerca inversa dall’istanza di xdvi lanciata da emacs al passo X.0) chiudere l’istanza di xdvi e digitare C-g (cioè Control g) nella finestra di emacs. Ripartire dal passo 4.3.

😀 Il programma xdvi sarà anche vetusto,
ma è proprio vero che a volte le cose antiche funzionano meglio di quelle nuove.
Infatti ho l’impressione
(anche se, per esprimere un giudizio definitivo, devo continuare a testare)
che, eseguendo alla lettera tutti i comandi da te specificati nell’ultimo messaggio,
la ricerca avanzata e quella inversa funzionino, almeno per quanto riguarda plain TeX,
decisamente meglio con l’xdvi che non col kdvi.

Confermo.

Non ho ancora sperimentato la funzionalità della cosa quando ci sono i file \input,
poiché come ti dissi avevo rinunziato a \input-tare file.

Per quel poco che ho provato, sembra funzionare egregiamente. L’importante, lo ricordo ancora una volta, è usare \Input anziché \input se si sta usando TeX.

8) Comunque adesso, tra ricerca inversa e avanzata e hyperlinks,
ho la possibilità di spaziare in tutto il documento
con giochi di sponda e triangolazioni mai viste.
Se una importuna ustioncella all’avambraccio non mi avesse funestato le ultime settimane,
mi verrebbe voglia di brindare!

Riassumo qui di seguito tutte le operazioni
nel caso che possano tornare utili a qualcuno.

😯 Ricerca inversa e avanzata per TeX e LaTeX,
con xdvi ed Emacs,
in Mandrake Linux 9.0.

1)Hai controllato l’effettiva presenza di emacs? Riesci a lanciarlo?
In quanto segue assumo di sì.
2)Usa emacs per modificare il file .emacs: digita
emacs ~/.emacs
dalla Shell di Linux.
3)Vai in fondo al file (potrebbe verosimilmente essere vuoto: nessun problema)
e aggiungi la riga
(server-start);
salva il file e esci da emacs.
4)Impartisci i comandi
mkdir -p ~/lib/emacs (invio)
ln -s /usr/share/doc/HTML/en/kdvi/kdvi-search ~/lib/emacs (invio).
5)Apri il tuo file sorgente impartendo il comando
emacs ~/…/filename.tex (invio)
e aggiungi all’inizio del file il comando
\input /usr/share/texmf/tex/latex/srcltx/srctex.sty
se stai usando plain TeX, ovvero il comando
\usepackage[active]{srcltx}
se stai usando LaTeX, poi salva il file.
6)Apri una nuova Console di Shell, col comando cd accedi alla directory che contiene i due file, quello sorgente e quello .dvi, e impartisci il comando
xdvi -editor “emacsclient +%l %f” filename.dvi (invio).
7)In un punto qualsiasi del file .dvi clicca Ctrl-mouse-1 e voilà: la ricerca inversa.
8)Apri una nuova Console di Shell, col comando cd accedi alla directory che contiene i due file, quello sorgente e quello .dvi, e impartisci il comando
xdvi -sourceposition “linenumber filename.tex” filename.dvi (invio)
e voilà: la ricerca avanzata.

A te, Andrea, eventuali correzioni e aggiunte.

Ciao,
Rodolfo

Ora devo scappare, aggiornerò la lista di passi in un messaggio successivo.

Ciao,

Andrea.

Ci riprovo: ieri Linux m’è andato in stallo (!!!) mentre scrivevo e poi sono stato preso da altre incombenze meno divertenti

😳 il motivo per cui la ricerca inversa non mi funzionava
era che il mio mouse disponeva del tasto centrale
ma io non me n’ero accorto!

Bene! Un problema risolto. E’ un mouse con rotellina?

E tuttavia permangono i problemi.
Sì, perché io faccio molto uso di file che includono altri file
mediante il comando \input,
e le due ricerche applicate a un file che sia incluso appunto in un master file
non mi funzionano per niente bene.
Quella avanzata non riesce a beccare il punto giusto
e si ferma sempre solo all’inizio del .dvi;
e quella inversa, addirittura, non si attiva neppure.
Anche a te risultano queste difficoltà?

Quasi. Ho dato un’occhiata al .dvi e ai file di supporto: kdvi-search.el e src(tex|ltx).sty e ritengo che l’origine del problema risieda nell’uso dei .sty. In pratica: l’inserimento dei tag usati da kdvi per la ricerca avanzata o inversa (“src: “) nel .dvi per i file inclusi sembra non funzionare adeguatamente quando si usa il comando \input. Usando LaTeX, invece, e il comando \include{}, le cose vanno a posto. Devo analizzare srctex.sty e capire da dove nasce il problema. Le stringhe di tag ci sono, ma i comandi che le usano fanno parte di una gerarchia di macro che devo studiare.

E come fare (se possibile) per superarle?
In caso contrario, dovrei concludere che, così com’è,
la ricerca avanzata e inversa purtroppo mi è poco utile.

Se puoi usare il LaTeX la soluzione è sul piatto, ma il titolo del thread farebbe pensare diversamente 😉

Spero di avere presto buone notizie.

Ciao,

Ciao Fabiano,

Ciao a tutti,
facendo un uso piuttosto ingente di LaTeX e essendo un webmaster piuttosto attivo (ahaha) vorrei discuere un po’ la questione dei convertitori LaTeX HTML.
in passato ho provato a dare un occhiata ad un paio di questi, ho cercato un po’ sulle vecchie pagine del forum e su quelle di guit, i programmi sono parecchi e le informazioni che ho ricavato sono o frammentarie o terribilemnte complicate.
in particolare avevo dato un occhio a TeX4ht e LaTeX2html. nel ricordo entrambi i programmi erano complicati da installare (almeno con windoz) per esempio latex2html richiedeva se non sbaglio un compilatore perl che non ho intenzione di installare solo per convertire i file di LaTeX.

Io ho provato, sebbene in rare occasioni, latex2html, e ha sempre funzionato piuttosto bene.
Non so dirti per Windows: sotto Linux, perl puoi installarlo (o trovarlo già installato) senza fatica.

infine la domanda che da il titolo al tread: visto che tutte le mie pagine sono XHTML validate strict, sapete se esite un convertitore LaTeX a XHTML? convertire uan pagina da un HTML sporchetto al rigore dell’XHTML mi porterebbe via altrettanto tempo e fatica che partire direttamente dal file tex. quindi logicamente punterei su questo convertitore, ma io non ne ho mai sentito parlare.

Da una rapida occhiata a una ricerca su google (chiave “html xhtml”) risulta che esiste almeno una soluzione free:

http://www.w3.org/People/Raggett/tidy

Non so dirti come sia, non l’ho provato.

temo che questo messaggio sia un po’ troppo specifico per interessare agli utenti del forum, ma lancio un sasso nello stagno e aspetto che arrivi qualche onda fino a riva.
ciao a tutti e buon forum

From the Undertow…

Ciao.

Ciao Rodolfo,

(…)Ho fatto tutto come hai detto
tranne che, rispetto a quanto hai scritto al punto 4),
al posto del comando
“ln -s /usr/share/doc/HTML/en/kdvi/kdvi-search ~/lib/emacs”
ho dovuto impartire il comando
“ln -s /usr/share/doc/HTML/en/kdvi/kdvi-search.el ~/lib/emacs”
(cioè, in pratica, ho dovuto aggiungere l’estensione .el al nome del file kdvi-search),
altrimenti ottenevo un messaggio di errore all’apertura di Emacs.

Giusto! Mio refuso.

All’inizio la ricerca avanzata faceva un po’ la ritrosa, si faceva pregare,
mi mostrava delle finestre in cui diceva che non era in grado di arrivare, nel file .dvi,
proprio a quella riga precisata nel file di testo!
e arrivava sempre soltanto al principio del file .dvi;
ma poi dopo qualche mia insistenza ha ceduto (credo)
e ora mi porta non sulla riga ma bensì alla fine del capoverso.
E’ normale o dovrebbe andare precisamente sulla riga?
(O addirittura sulla parola esatta?)

Se il .dvi è già aperto quando eseguo la prima ricerca avanzata molto spesso la ricerca fallisce, proprio nel modo che hai descritto. Se invece lancio prima emacs e da emacs causo, per mezzo di una ricerca avanzata, l’esecuzione di kdvi tutto funziona bene.

In tutte le prove che ho effettuato la ricerca avanzata ha sempre portato a centrare la visualizzazione intorno all’inizio del paragrafo. Non ho provato a eseguire la ricerca partendo da una parola che appartenesse a un paragrafo spezzato (parte su una pagina, parte sulla pagina successiva) in formattazione; dando un’occhiata al file kdvi-search.el si vede che la chiamata a kdvi (shell wrapper per kviewshell) passa il numero della linea nella quale si trova il cursore emacs nel buffer corrente; escluderei, pertanto, una precisione superiore alla linea. Per una risposta più precisa occorre guardare il .sty.

🙁 Chi invece non vuol proprio saperne è la ricerca inversa.
Ho fatto esattamente così come tu hai detto nel tuo ultimo messaggio,
e infatti, all’apertura del file .dvi,
compare una promettente finestra che assicura che la ricerca inversa funzionerà;
ma invece, come ti avevo detto a proposito del file KDVI-features.dvi,
cliccando contemporaneamente col destro e sinistro
(il mio mouse non dispone del tasto centrale)
nulla accade!
Come può essere?

Mh, ricontrolliamo.
1) Se, dopo aver lanciato emacs, da un terminale provi a eseguire il comando emacsclient nomefile, emacs esegue la visualizzazione del file indicato? (Ctrl-x # per uscire)
2) Hai selezionato emacs nel campo editor del tab speciali-dvi del pannello Preferenze-KViewShell della voce OpzioniDVI del menu Impostazioni di KViewShell?
3) Hai compilato il tuo .tex dopo aver incluso il file srctex.sty?
4) Riesci a sfruttare l’emulazione del terzo tasto in altri contesti (tipo “selezione stringa” in xterm per mezzo della pressione del tasto sinistro e trascinamento del mouse, e copia, nello stesso xterm, della stringa per mezzo della pressione dei due tasti in contemporanea)?

Se hai risposto 4 sì la situazione si fa interessante…
Fammi sapere se anche una sola delle mie domande non ti è chiara. E’ importante.

[Next]

Ciao Rodolfo:

innanzitutto grazie per avermi fatto scoprire un’alternativa al tradizionale e vetusto xdvi.

Ora:

0) Hai ancora necessità di risolvere il problema in oggetto, o nel frattempo sei riuscito a impostare il tuo ambiente?

Io ho provato a configurare il .emacs come suggerito nell’help di kdvi, con un lieve adattamento per il search path (non tengo le estensioni personali in ~/emacs-scripts) di emacs, e sia la ricerca avanzata sia la ricerca inversa funzionano egregiamente.

Fammi sapere.

Ciao.