Elrond

Intanto grazie per aver condiviso la tua esperienza!

OldClaudio” post=91279Cominciamo da questo secondo punto: il formato forse più diffuso è il formato epub. Scrivere direttamente un file epub è una cosa che non ho nemmeno osato tentare, ma ho provato a trasformare quanto si può ottenere con i programmai del sistema TeX; l’esperienza con tex4ht permette di ottenere i file in codice xhtml ma poi quando uno va a vedere che cosa contiene si può mettere le mani nei capelli se il file latex da cui si è partiti contiene matematica, figure, tabelle, liste e compagnia. Visto il genere di documenti che scriviamo noi tutti frequentatori di questo forum, direi che questa strada è preclusa visti i risultati improponibili.

Purtroppo credo sia un problema intrinseco agli ePub (come penso qualsiasi formato di ebook). Gli ebook non sono un granché per qualsiasi cosa diversa da testo + qualche piccola immagine. Il modo più semplice di inserire delle formule è quello di renderle in PNG o SVG e includerle come immagini. L’ultima versione delle specifiche degli EPUB, la numero 3, prevede la possibilità di inserire formule matematiche come MathML, ma (1) non so quanti nuovi dispositivi supportino questa versione dell’EPUB, sicuramente tutti i più diffusi ereader finora usciti non la supportano, (2) nel caso di formule particolarmente complesse i risultati non credo siano paragonabili a una formula prodotta da LaTeX su un PDF (3) non ho idea di come vengano rese le formule lunghe sugli schermi piccoli (strabordano? vanno a capo automaticamente? con quali criteri?).

OldClaudio” post=912791) tempi di compilazione: pdfLaTeX il più veloce; XeLaTeX appena un poco più lento; LuaLaTeX lentissimo, in rapporto almeno 10 a 1 rispetto ai temi di pdfLaTeX. Mi domando perché.

Può essere il caricamento dei font? http://tex.stackexchange.com/questions/75118/why-does-it-take-lualatex-so-long-to-load-fonts-and-can-i-speed-it-up

OldClaudio” post=912793) ingombro in memoria: le dimensioni dei file non differiscono molto conla composizione a schermo grande o con quella a schemro piccolo; quelle del file di prove con lo schermo piccolo sono: pdfLaTeX 1,317,339 byte; LuaLaTeX 828,220 byte; XeLaTeX 68,081 byte. Queste enormi differenze di contenuto informativo dentro i rispettivi file mi hanno stupito moltissimo e non ho spiegazioni convincenti; probabilmente XeLaTeX è il più snello perché non ricorre all’espansione dei font richesta da microtype; perché i file PDF prodotti da LuaLaTeX e da pdfLaTeX differiscano di circa mezzo megabyte mi stupisce e non trovo spiegazione; è vero che la qualità della compressione del contenuto è migliore con LaaLaTeX, ma continua=o a essere stupito dell’ammontare.

La risposta è di nuovo nei font: [tt]xelatex[/tt] e [tt]lualatex[/tt] comprimono i font, in maniera diversa, [tt]pdflatex[/tt] no:
http://tex.stackexchange.com/questions/54435/pdf-file-size-with-lualatex-vs-xelatex
http://tex.stackexchange.com/questions/14102/file-size-difference-between-xelatex-and-pdflatex
http://tex.stackexchange.com/questions/137451/why-does-lualatex-produce-smaller-files-than-pdflatex-in-this-example

Risultati di un test su un uguale documento compilato con i tre diversi motori:
`% pdffonts lualatex.pdf
name type emb sub uni object ID
———————————— —————– — — — ———
NBMKCE+LMRoman10-Regular CID Type 0C yes yes yes 4 0
% pdffonts xelatex.pdf
name type emb sub uni object ID
———————————— —————– — — — ———
OOYSRC+CMR10 Type 1C yes yes no 4 0
% pdffonts pdflatex.pdf
name type emb sub uni object ID
———————————— —————– — — — ———
WPOZJD+CMR10 Type 1 yes yes no 4 0`

OldClaudio” post=91279Spero che questi risultati possano esseere interessanti; se qualcuno, però, ha suggerimenti diversi per produrre risultati migliori, crdo che il nostro gruppo possa apprezzare e quindi speroc he questo lungo messaggio possa vere qualche intervento da parte di altri frequentatori.

Qui https://github.com/GuITeX/guidaebooklatex c’è la bozza di una guida di Pietro Giuffrida sulla produzione di ebook con LaTeX. Anche se sono interessato agli ebook, non l’ho mai letta perché non ho ancora avuto modo di cimentarmi nell’avventura di generare un ebook a partire da un sorgente LaTeX, però potrebbe esserci del materiale interessante (anche se mi sembra ancora in uno stato molto embrionale).

robitex” post=91274La GuidaGuIT è il principale documento di divulgazione del sistema LaTeX del GuIT.
Pertanto bisogna chiarire esplicitamente per prima cosa se i sorgenti possano o meno essere a licenza aperta. Infatti, a quel che ne so, una versione dei sorgenti è disponibile nell’area riservata ai soci del sito sul server del Sant’Anna (sito conosciuto con il nome di “vecchio sito”).

Il codice di alcune versioni è accessibile a chiunque, non solo i soci, in passato gli ho dato un’occhiata (anche per vedere come organizzare un documento molto complesso) e ho trovato alcune soluzioni che mi sembrano tutto meno che impresentabili.

OldClaudio” post=91275Nota che ho caricato la classe per creare le guide tematiche con la sua documentazione; l’esperienza è piuttosto deludente, ma forse il github non è ancora abbastanza conosciuto. Non so; sembra che il lavoro cooperativo non sia granché di moda.

Questi dati non mi sembrano confermare la tua idea “esperienza piuttosto deludente”: https://github.com/GuITeX/guidatematica/graphs/contributors Orlando è il maggior contributore per quanto riguarda il numero di modifiche, ha anche aggiunto un Makefile per sistemi Unix e uno per Windows, e in un suo repository personale mantiene un file di stile per AUCTeX per facilitare l’uso della classe. Più che altro non molti sono gli utenti della classe (non è che tutti gli utenti di questo forum scrivano guide per il GuIT) ed essendo fondamentalmente ben scritta non richiede grandi rivisitazioni, nonostante ciò c’è stato chi è riuscito a dare un buon contributo. Io avevo forkato il progetto per fare delle piccole modifiche, poi non ho più avuto il tempo di occuparmene e ho dovuto lasciar stare, ma c’era stata l’intenzione di dare una mano (chissà che io non completi il lavoro prossimamente). Inoltre, smanettando con il codice sorgente della documentazione della classe Orlando ha trovato un bug (poi corretto) in [tt]polyglossia[/tt], non sarebbe stato possibile senza avere il sorgente di quel file. Per me rendere la classe libera e accessibile per chiunque è stata un’ottima idea 😉

samiel” post=91265L’ebraico, come tutte le lingue semitiche, non scrive le vocali;
esse vanno pronunciate al momento, il che rende difficile l’apprendimento
per chi, come noi, è abituato alle lingue vocaliche. In più l’ebraico
è una lingua agglutinante, In ogni caso, per evitare possibili ambiguità
nel testo fondamentale, quello biblico, dal VII secolo i cosiddetti “puntatori”
(naqdanîm) introdussero un sistema di diacritici per specificare
la corretta vocalizzazione. Si tratta di segni (puntini, trattini)
posti sopra o sotto il testo. In ogni caso ho risolto per tentativi
ed errori. Io uso Debian con KDE come DE. Installando anche
la tastiera ebraica si hanno una serie di combinazioni
per inserire appunto tali vocali (chiamate nel loro insieme nikud):
ad esempio AltGr + e altre ancora più improbabili combinazioni
da scoprire appunto andando quasi a caso (AltGr + è ecc…)

m

Se usi Emacs puoi sfruttare i metodi di inserimento integrati descritti qui per il greco. Ci sono un paio di metodi il cui nome inizia con [tt]hebrew-biblical[/tt], vale a dire [tt]hebrew-biblical-sil[/tt] e [tt]hebrew-biblical-tiro[/tt].

Manuale di [tt]memoir[/tt], pagina 332, § 18.13 MOVING TO ANOTHER PAGE:

Peter WilsonA likely example for the optional [tt][/tt] argument is
`\cleartooddpage[\vspace*{\fill}THIS PAGE LEFT BLANK\vspace*{\fill}]`

Puoi definirti un alias per questo comando da inserire prima di ogni [tt]\chapter[/tt].

skevin93″ post=91100

Su TeX.SE avevo trovato questa soluzione
[quote=egreg]Use the calc package:
`\parbox{\widthof{my text}}{…}`

ma in realtà io nel PDF vedo [tt]my text[/tt] al posto di [tt]\widthof{my text}[/tt], non la larghezza della stringa 😕

Hai caricato il pacchetto [tt]calc[/tt] nel preambolo? [tt]\widthof[/tt] viene definito da quel pacchetto ed è equivalente a
`
\setbox0=\hbox{my text} \wd0
`[/quote]
Se non l’avessi fatto avrei ricevuto un errore di comando inesistente, non credi? A te funziona?

Edit: in compenso mi funzionano le soluzioni suggerite da Martin Scharrer:

Martin Scharrer
`\settowidth{\somelength}{}
\settodepth{\somelength}{}
\settoheight{\somelength}{}`

e funziona anche per stringhe multiriga

Doc” post=91082Ciao a tutti, ho appena scoperto come fare ad usare Emacs con Jabref. Sicuramente, rispetto a voi, ho scoperto l’acqua calda[/quote
Non ho mai usato JabRef, quindi mi stai dicendo una cosa nuova 🙂

comunque che ne dite di aggiungere un capitoletto alla guida? Mi pare una cosa comoda!

In ogni caso, io ho operato così: nelle impostazioni di Jabref, nella scheda “Programmi esterni”, ho impostato Emacs con “emacsclient” come eseguibile, SOLO “-eval” come parametro, spunta sulla voce per emacs23 e \cite come comando.
Quindi, ho aggiungo al config di emacs le seguenti stringhe:
`;; start emacsclient server to use with Jabref
(server-start)`

Può essere una buona idea. Potresti abbozzare tu questo capitoletto? 🙂 Io non conosco proprio JabRef, non avrei molto da dire

marchetto” post=91042io ho la versione 2.6.4

Qui 2.6.6, premere ESC almeno due secondi dopo l’inizio della compilazione la interrompe

La domanda era stata già posta qui: http://www.guitex.org/home/it/forum/5-tex-e-latex/84242-elenco-font-accessibili-a-fontspec ma da allora un paio di cose sono cambiate:
– il file del database non è più [tt]$(kpsewhich -var-value TEXMFVAR)/luatex-cache/generic/names/otfl-names.lua[/tt] ma [tt]$(kpsewhich -var-value TEXMFVAR)/luatex-cache/generic/names/luaotfload-names.lua[/tt]
– il comando [tt]luaotfload-tool[/tt] ora permette di elencare direttamente i font con l’opzione [tt]–list[/tt] che hai segnalato anche tu, senza dover leggere il file del database.
Altre soluzioni oltre a [tt]luaotfload-tool[/tt] non ne ho trovate (e sarei sempre interessato a conoscerle)