luigi.scarso

Risposte nei forum create

Stai visualizzando 15 risposte – dal 211 al 225 (di 264 totali)
  • Autore
    Risposte
  • in risposta a: Imparare ConTeXt in classe (virtuale) #39846
    Up
    0
    Down
    ::

    So che hai in testa qualcosa..fammi un esempio coi nomi che vuoi tu

    PS
    Non vorrei che diventasse una classe virtuale inversa
    (gli alunni 😈 interrogano i professori 😥 ).
    Meglio allora
    chiedi all’oracolo 🙄 — ma fai la domanda giusta 😀

    in risposta a: Imparare ConTeXt in classe (virtuale) #39845
    Up
    0
    Down
    ::

    Sono entrato nella classe virtuale, stimolato dalla discussione apparlsa in ml,
    ma già non ci sto capendo niente

    Se hai una texlive 2009
    oppure una texlive 2008 funzionante e che comprende context
    salva in test.tex
    `
    \starttext
    \input tufte
    \stoptext
    `
    ed esegui
    `texexec test.tex`
    Se tutto funziona hai un pdf
    test.pdf
    con alcune righe di testo.
    Ecco, hai appena fatto un tipico esempio di testo context.

    … sono tentato ad andarmene subito. Ma siccome sono abbastanza vecchio da aver imparato che non si nasce imparati, non mi vergogno a dichiarare la mia totale ignoranza per questo argomento che pure mi incuriosisce, e dico:
    Mi potete spiegare in poche parole che cosa è conTeX? rispetto a LaTeX?
    grazie

    E’ analogo a LaTeX , AMSLaTeX, AMSTeX etc.
    Ovvero un insieme di macro coerenti che vengono compilate in un formato fmt.

    Per essere concreti: il nucleo di LaTeX è in
    texlive/2008/texmf-dist/tex/latex/base ,
    mentre quello di context è in
    texlive/2008/texmf-dist/tex/context/base

    La differenza è che in
    texlive/2008/texmf-dist/tex/latex
    ci sono circa 1098 packages ausiliari che si caricano con \usepackages a seconda dell’esigenza e sperando che non vi siano conflitti, mentre in context… 0.
    Beh, non è proprio così:ci sono poco meno di 20 packages in
    texlive/2008/texmf-dist/tex/context
    ma
    foxet — non usato
    pgf — poco usato
    bib — si
    /third/* — poco usati

    In sostanza ConTeXt è il duale di LaTeX: un formato onnicomprensivo che ha come obiettivo la pubblicazione nel suo insieme.. Mentre il kernel di LaTeX nasce con alcuni tipologie di documenti (eg article, report ,book) ed alcuni ambienti predefiniti, e delega altri packages per le altre cose (cfr memoir ad esempio), ConTeXt fornisce tutti gli elementi per costruire il proprio documento e delega alll’utente la personalizzazione di tali elementi.
    In proporzione a LaTeX non esistono praticamente utenti che scrivono stili o packages di ConTeXt: semplicemente è già tutto incluso, basta personalizzare.
    In questo modo si è risolta anche la gestione dei conflitti tra pi packages:
    semplicemte si eliminano i packages.

    Un’altro punto di differenza rispetto a LaTeX è il rapporto con MetaPost. La scelta di ConTeXt è una strettissima integrazione con Metapost, perchè si ritiene che questo sia in grado di rispondere a praticamente tutte le esigenze di grafica: è infatti con ConTeXt che è nato il formato Metafun di Metapost.

    Ancora, ConTeXt è sviluppato in modo esclusivo da una persona;
    tutti gli eventuali miglioramenti devono essere motivati, approvati
    ed in ogni caso vengono introdotti solo dallo sviluppatore.

    Infine ConTeXt è sempre stato orientato più verso il pdf che verso il dvi: il motore di impaginazione preferito è pdftex (quello che una volta era pdfetex)

    Prima conclusione: dal punto di vista delle funzionalità,
    context = latex + {alcuni altri packages, 4 o 5 in tutto} + metapost

    Ora, è importante capire il momento attuale.
    Esistono due rami di ConTeXt: mkii e mkiv (mark II e mark IV, ma io li chiamo Mark two e Mark four).

    mkii è congelato: nessuna nuova feature, solo bug fix.
    Si basa su pdftex e sul programma MetaPost con il formato Metafun, ma è caldamente consigliato pstoedit 3.45 (non credo che sia incluso nella TeXLive). Le due guide di riferimento sono
    http://www.pragma-ade.com/general/manuals/cont-eni.pdf
    http://www.pragma-ade.com/general/manuals/metafun-p.pdf
    Per uitlizzare il formato mkii si usa texexec, ie
    `#texexec test.tex`

    mkiv è l ramo attuale, in “furioso” sviluppo.
    Si basa su luatex, il nuovo motore di impaginazione che un giorno (2012?) diverrà pdftex2.0, ma nessuno ne fa una questione di principo: per ora è utile pensare a luatex come una riscrittura amichevole di pdftex, nel senso che alcuni sviluppatori del core di pdftex sono anche sviluppatori di luatex e che si cerca di mantenere una stretta relazione di output.
    Per una serie di motivi qui siamo veramente in una situazione opposta al mondo TeX:

      *) luatex ha (quasi tutto) un interprete del linguaggio Lua, oltre che un interprete del TeX ovviamente, ed anche un interprete Metapost al suo interno.
      Lua è un linguaggio di programmazione simile al pascal, python, basic. E’ minimale e sembra poca cosa, ma in realtà è estremamente utile, anzi è la scelta ottima. Il fatto di avere Metapost al suo interno elimina l’esigenza di chiamare il programma esterno Metapost, con impressionanti conseguenze sulle performance.
      Inoltre il formato del file di ingresso è utf-8, mentre è prevista una completa gestione dei font opentype, type1 e truetype grazie all’inclusione di parte del codice di fontforge.
      Luatex infine è scritto in C con target CWEB e dalla versione 0.46 di pochi giorni fa è iniziata la gestione di librerie esterne scritte C tramite loadlib .
      Questo è un enorme cambiamento rispetto a pdftex scritto in pascal web e tradotto in C tramite web2c che rendeva molto complicato gestire il codice e la sua integrazione con librerie esterne.

      *) luatex cambia spesso, e il nuovo invalida il vecchio. Cosi nella tl2009, il luatex presente è già vecchio ed inutile

      *) context mkiv è il formato di context che usa luatex, e dato che
      luatex cambia spesso, e il nuovo invalida il vecchio, lo stesso vale per mkiv. Per questo è stata creata una distribuzione ad hoc, la “minimals beta”
      http://wiki.contextgarden.net/ConTeXt_Minimals
      (completamente instabile secondo il punto di vista del mondo TeX)
      che, inutile dirlo, serve solo per testare le cose ed è completamente
      indipendente dalla TexLive.
      A volte accade che la minmals sia sballata per Windows a volte accade che la versione 64bit x Mac sia errata. La ml di context cerca di risolvere questi problemi.
      Esiste anche una “minimals current ” che è più stabile .
      Non bisogna essere però eccessivi: io ho un progetto che usa una current del novembre 2008, e fino ad oggi funziona bene.
      Indicativamente ci sono circa 3~4 current in un anno e 3~4 beta in un mese. Non è inusuale avere più minimals, magari perchè si hanno più progetti, ma in generale si hanno una current, una beta ed una extra

    Metapost infine è curato dallo stesso sviluppatore di luatex,che si preoccupa di non creare distorsioni tra la il metapost di luatex e Metapost programma ed il tutto è in stretta relazione con lo sviluppatore di context mkiv, che indica volta per volta quale parte di TeX rendere accessibile tramite Lua.

    Infine per usare mkiv (supposto una minimals funzionante)

    `#context test.tex`

    Brevissima “domande frequenti”:

      *) LaTeX è meglio di ConTeXt?
      Si. nel senso: la base di utenti è ampia, è un formato testato a lungo,
      esiste una ricca documentazione, è accettato per i documenti scientifici,
      è usato da altri programmi per generare i pdf.

      *) ConTeXt assomiglia a LaTeX minimale ?
      No.
      E’ progettato meglio e diversamente ed è completamente gestito.
      LaTeX è nato per poche cose, ed è cresciuto in modo non gestito.

      *) LaTeX “fa/è” di più di ConTeXt ?
      No

      *) E’ più facile risolvere un problema con LaTeX o con ConTeXt?
      Con ConTeXt

    Ora faccio un esempio, che c’è anche sulla ml pari pari.
    Il problema è mettere un nr di pagina “pataccone”

    Questa è una prima versione context mkii

    `
    %%test-ctx-mkii-no-ok.tex
    \setuppapersize[A4][A3]
    \setuplayout[location=middle,marking=on]
    %% colors
    \setupcolors[state=start]
    \definecolor[titleseccolor][r=0.65,b=0.0,g=0.0]
    %% pagenumber
    \setuppagenumbering[alternative=doublesided,location=]
    \startuseMPgraphic{PageNr}
    picture ppag ;
    ppag := textext(“\ssbf\pagenumber”) ;
    ppag := ppag scaled 4;
    path p ;
    p := unitsquare
    xscaled OverlayWidth yscaled OverlayHeight
    superellipsed .85 ;
    fill p withcolor \MPcolor{titleseccolor} ;
    draw p withcolor 1.5\MPcolor{titleseccolor}
    withpen pencircle scaled 2pt;
    draw ppag
    shifted (0.5*OverlayWidth-xpart center ppag ,
    0.5*OverlayHeight-ypart center ppag)
    withcolor white;
    \stopuseMPgraphic
    \defineoverlay[PageNr][\useMPgraphic{PageNr}]
    \setupbackgrounds[state=repeat]
    \setupbackgrounds[footer][rightmargin][background=PageNr]
    %%
    %%
    %%
    \showlayout
    \starttext
    \dorecurse{4}{%
    \chapter{Tufte}
    \section{A text}
    \input tufte}
    \stoptext

    # texutil –purgeall ; export shell_escape=t; texexec test-ctx-mkii-no-ok.tex
    `

    Non è una particolamente efficiente:
    per ogni pagina context ricalcola il background MetaPost
    PageNr, perchè è legato al numero di pagina.
    Per 100 pagine ho chiaramente 100 background differenti.
    l’elaborazione diventa notevole.

    Molto meglio fissare il background una volta per tutte,
    e scriverci sopra il numero.

    `
    %%test-ctx-mkii-ok.tex
    \setuppapersize[A4][A3]
    \setuplayout[location=middle,marking=on]
    \showframe
    %% colors
    \setupcolors[state=start]
    \definecolor[titleseccolor][r=0.65,b=0.0,g=0.0]
    %% pagenumber
    \setuppagenumbering[alternative=doublesided,location=]
    \startuniqueMPgraphic{PageNr}
    picture ppag ;
    path p ;
    p := unitsquare
    xscaled OverlayWidth yscaled OverlayHeight
    superellipsed 0.85 ;
    fill p withcolor \MPcolor{titleseccolor} ;
    draw p withcolor 1.5\MPcolor{titleseccolor}
    withpen pencircle scaled 2pt;
    \stopuniqueMPgraphic
    \defineoverlay[PageNr][\uniqueMPgraphic{PageNr}]
    \setupbackgrounds[footer][rightmargin][background=PageNr]
    %%
    \setupfooter[before=\vfill,after=\vfill]
    \setupfootertexts[margin][]%
    [\hsize=\rightmarginwidth
    \centerline{\scale[sx=4,sy=4]{\color[white]{\ssbf\pagenumber}}}]
    %%
    \showlayout
    \starttext
    \dorecurse{4}{%
    \chapter{Tufte}
    \section{A text}
    \input tufte}
    \stoptext

    # texutil –purgeall ; export shell_escape=t; texexec test-ctx-mkii-ok.tex
    `

    Se consideriamo context mkiv,
    la situazione cambia completamente.
    il primo file che era lentissimo
    diventa normale, proprio come il secondo.
    Queasto è dovuto al fatto che metapost ora è una estensione
    di luatex, quindi la gestione del ricalcolo è molto più veloce:
    è questo uno dei principali vantaggi di luatex
    (l’altra faccia della medaglia: maggiore occupazione di memoria).

    `
    %%test-ctx-mkiv.tex
    \setuppapersize[A4][A3]
    \setuplayout[location=middle,marking=on]
    %% colors
    \setupcolors[state=start]
    \definecolor[titleseccolor][r=0.65,b=0.0,g=0.0]
    %% pagenumber
    \setuppagenumbering[alternative=doublesided,location=]
    \startuseMPgraphic{PageNr}
    picture ppag ;
    ppag := textext(“\color[white]{\ssbf\pagenumber}”) ;
    ppag := ppag scaled 4;
    path p ;
    p := unitsquare
    xscaled OverlayWidth yscaled OverlayHeight
    superellipsed .85 ;
    fill p withcolor \MPcolor{titleseccolor} ;
    draw p withcolor 1.5\MPcolor{titleseccolor}
    withpen pencircle scaled 2pt;
    draw ppag
    shifted (0.5*OverlayWidth-xpart center ppag ,
    0.5*OverlayHeight-ypart center ppag)
    \stopuseMPgraphic
    \defineoverlay[PageNr][\useMPgraphic{PageNr}]
    \setupbackgrounds[state=repeat]
    \setupbackgrounds[footer][rightmargin][background=PageNr]
    %%
    \showlayout
    \starttext
    \dorecurse{4}{%
    \chapter{Tufte}
    \section{A text}
    \input tufte}
    \stoptext
    `

    in risposta a: Imparare ConTeXt in classe (virtuale) #39843
    Up
    0
    Down
    ::

    Hey parti giù duro..
    Direi di iniziare con
    l’hello world di ConTeX,
    ed anche un tipo esempio per riempire una mezza pagina

    \starttext
    \input tufte
    \stoptext

    #texexec test.tex

    Mo mi preparo un esempio x la tua domanda

    Intanto
    http://wiki.contextgarden.net/Project_structure
    ed un serio esempio
    http://context.aanhet.net/svn/contextman/context-reference/en

    in risposta a: Imparare ConTeXt in classe (virtuale) #39842
    Up
    0
    Down
    ::


    Hey parti giù duro..
    Direi di iniziare con
    l’hello world di ConTeX,
    ed anche un tipo esempio per riempire una mezza pagina

    \starttext
    \input tufte
    \stoptext

    #texexec test.tex

    Mo mi preparo un esempio x la tua domanda

    in risposta a: bibman #38689
    Up
    0
    Down
    ::

    D’accordo. Un gestionale in luatex è uno sproposito ed anche una provocazione.

    puff …
    non proprio, se pensi ad un db x la bibliografia
    che ha come struttura dati una tabella lua
    che è gestito con luatex .
    Solo che non è generale,ma molto focalizzato al mondo TeX

    Ps. Ok come numero di etichette vinci tu

    Ah no, era per dire che *TeX è ottimo per fare queste cose
    — avro’ fatto poco meno 10milioni di etichette fino adesso
    Solo che normalmente non lo si vede da questo punto di vista…
    ma tant’è, siamo ingegneri no ?

    in risposta a: bibman #38687
    Up
    0
    Down
    ::

    Tre progetti:
    1 – un linguaggio per comporre tabelle numeriche (attualmente il pacchetto LaTeX che lo implementa è fermo alla versione 0.6.1 perché la 1.0 è molto più complessa da scrivere sulla base del progetto linguistico che non ho ancora completamente definito, puoi cercarlo su CTAN con il nome di calctab);

    hmm ho qualche idea e qualche critica — già dall’anno scorso — ma preferisco farla in privato — hai il mio indirizzo email ?

    2 – creare un linguaggio per sfornare etichette in LaTeX (problema pratico per me che stampo per certi fini circa 3600 etichette all’anno utilizzando un software gestionale). Pensa che il primo abbozzo risale ad agosto 2008;

    io circa qualche milione in un anno — per un solo cliente, ed ho più clienti.
    Non so se esiste uno qualche standard xml per etichette , mi piacerebbe saperlo però, sono quasi 5 anni che sforno etichette e
    la cosa è collaudata e quindi .. si può cambiarla con qualcosa di nuovo 🙂
    In genere le stickers sono così personalizzate che il miglior linguaggio
    è.. TeX .

    3 – un progetto allucinante: creare un linguaggio per lavorare con database relazionali dall’interno di luatex a scopi di reporting o data processing od anche come sistema di input dati (che potrebbe assorbire il progetto 2).

    Le idee sono queste:
    Supponiamo un tuo dbms già esistente, dopo vedremo il problema
    di costruirne uno in luatex.
    Ti serve uno adapter per il tuo dbms, ie uno strato sw che permette a luatex (scrito in C) di comunicare con il dbms .In generale gli adapter sono sotto forma di libreria C,C++ , Java C#.
    Spesso trovi uno strato sw con un linguaggio dinamico (ie python ruby php vbasic lua ma anche java C# IronPython etc) sopra la libreria che ti facilita la programmazione.
    Ora puoi gestire la cosa con \write18:
    cioè per il job crei un processo luatex
    che a sua volta crea un processo con \write18 ogni volta che deve interagire con il dbms, utilizzando il linguaggio dinamico.Esempio (che spero *non* funzioni)
    \def\DoWork#1#2#3{%
    \immediate\write18{python myscript.py “#1” “#2” “#3”}}

    myscript.py fa qualcosa in base all’ingresso che specifichi con #1 #2 #3
    tipo
    python myscript.py in01 cmd01 out01
    (di solito bastano 2 switch , 3 perchè non siamo avari)

    elabora il file in01 (magari precedentemente creato proprio da luatex)
    in base alle direttive contenute in cmd01 scritte secondo un linguaggio preciso (python ha già una serie di linguaggi per questo come configParser e json),
    direttive magari scritte al volo da luatex in relazione all’input *tex
    e butta fuori il risultato in out01
    che successivamente elaborerai/presenterai con \Typeset#1, ie

    \DoWork{in01}{cmd01}{out01}
    :
    :
    \Typeset{out01}

    Ora con lua di luatex hai un sacco di facilità nello scrivere e leggere i dati
    rispetto a pdftex,
    ma la parte di comunicazione rimane la stessa e la puoi vedere cosi
    t = t_start_process + t_comm_dbms + t_shudown_process

    Ora se t_comm_dbms ~ t_start_process + t_comm_dbms + t_shudown_process

    (ie t_start_process + t_shudown_process << t_comm_dbms ) devi attuare dei meccanismi di caching dei risultati , altrimenti, data che in genere in *TeX hai 2~3 lanci per lo stesso job (sistemare gli indici e così via) aumenti il tempo del 200% ~ 300% Dato che normalmente il job si svolge su una sua directory separata, la cache può essere proprio una serie di files dei risultati delle query scritti da luatex dopo il primo lancio: allora devi scrivere del codice luatex che ti distingua i lanci e che dal secondo in poi usi i dati scritti nella cache piuttosto che interrogare il dbms Una soluzione più raffinata è questa http://en.wikipedia.org/wiki/Memcached
    in cui la cache è trasferita ad un server
    Quindi un job (sempre nella sua dir. separata) ad ogni lancio interroga
    il server memcache senza necessità di memorizzare i risultati come prima
    per cui ti semplifica il codice luatex
    I risultati intermedi poi sono disponibili a tutti i jobs, aumentando la
    l’efficienza della concorrenza. Ovvio che la cache deve essere dimensionata,
    altrimenti ricadi al collo di bottiglia del dbms

    I definitiva questo approccio non è male: se un processo \write18
    fallisce (/bug di libreria, errore di programmazione etc) al 99% riesci a gestirlo bene
    L’inefficienza nasce quando
    t_start_process ~ t_comm_dbms ~ t_shudown_process
    per cui sei efficiente al 33% e questo può accadere con la cache
    (normalmente non è mai t_comm_dbms < t_*_process) Con luatex+lunatic si estende luatex con python in modo tale che \write18{python myscript.py "#1" "#2" "#3"}} non è più necessaria, ed è sostituita in definitiva da una chiamata ad una funzione luatex ovvero da una macro In questo modo guadagni di colpo tutti gli adapter esistenti, ed in t_start_process + t_comm_dbms + t_shudown_process ha t_start_process = t_shudown_process = 0 Ma esiste un lato negativo: se comm_dbms abortisce per quache bug, puoi avere un seg. fault e *tutto* il job abortisce, lasciando il sistema eventualmente in stato inconsistente. In luatex lunatic ho trattato questa cose con dbxml e sqlite. Come vedi, non esattamente una passeggiata.

    creare un gestionale in luatex.

    hmm..creare un gestionale in luatex non ha senso (dal punto di vista ingegneristico) — non ti basta il casino di cui sopra ? 🙂
    Meglio usare quelli che già ci sono ed usare luatex com linguaggio di presentazione dei dati.
    Per sistemi piccoli ed agili ad esempio sqlite è molto in voga
    (ma come tutte le cose binarie, se corrompi un byte
    perdi *tutto* il db, per cui…)

    in risposta a: bibman #38685
    Up
    0
    Down
    ::

    Anche nel mio micro (nel “mio piccolo” ridotto), sto portando il linguaggio del pacchetto calctab verso gli stessi concetti per rilasciarne una nuova versione. Tuttavia sono fermo perché il codice TeX è spesso difficile e complesso da scrivere (come ti accennavo al GuITmeeting 2009).
    Non è escluso in futuro che la mkiv possa offrirmi un ambiente di programmazione più efficace e semplice per metter in pratica le mie idee (leggi sogni nel cassetto).
    Ciao a presto.

    hmm dimmi di più….

    in risposta a: Prima prova con ConTeXt #38183
    Up
    0
    Down
    ::

    Condividete anche voi quest’opinione, che cioè avremo due strumenti molto più potenti di quelli attuali, ma con la stessa impostazione di sviluppo di oggi?

    Per ConTeXt direi di si.
    Dove vedo un problema è nel passaggio LaTeX2e => LaTeX3
    e pdflatex => pdflualatex, due cambiamenti attualmente non correlati per quanto ne so (nel senso che LaTeX3 può benissimo essere pensato solo per pdftex non per luatex) .
    Tieni presente che si testa luatex/context almeno dal 2005, mentre di lualatex e
    latex3 se ne parla ogni tanto, ma codice ancora poco.
    Vedremo con la prossima texlive,ma non credo che la situazioni cambi.

    in risposta a: Prima prova con ConTeXt #38181
    Up
    0
    Down
    ::


    Solo un po’ d’ordine nella terminologia.

    – tex, etex, pdftex, xetex, luatex: motori (engine) di impaginazione. Hanno un set minimale di macro, sia macro primitive che macro costruite dalle macro primitive. Sono molto “veloci” , ma “fanno” poco.
    Ci sono (stati) altri motori (aleph, omega, nts, vtex) ma non molto popolari. Infatti la filosofia è backward compatibility: il nuovo engine dovrebbe dare gli stessi risulti del vecchio sugli stessi ingressi e deve essere stabile. Questi altri formati, per un motivo od un altro non hanno
    soddisfatto questi requisiti.

    -plain , eplain, latex, amstex, context ..(ce ne sono altri).. sono formati (format, *.fmt), ovvero un insieme coerente di macro che servono ad uno scopo. Ad esempio plain è usato nel TeXbook (con il notevole contributo però di manmac.tex), eplain è una estensione di plain, latex nasce per il typesetting di article, report e book, amstex per gli articoli della America Math. Soc., context per la pubblicazione in generale da parte di Praga-ade, una firm olandese.
    In generale più un formato è specifico meno “fai” e più sei “veloce” nel farlo; ad esempio con context “fai” più cose ma sei meno veloce.
    E’ ovvio che “fai” è relativo:
    “si può in context” se è solo se ” si può in latex” se e solo se “si può in pdftex” , solo che in context può essere più “facile” farlo.
    E quindi il problema diventa la scelta di un formato rispetto al problema
    che si ha sottomano.

    La relazione tra format ed engine è circa la seguente
    – plain con tex(?forse), etex, pdftex, xetex, luatex
    – eplain come sopra
    – latex con tex (?forse), etex, xetex, pdftex, e si sta cominciando con luatex
    – context con etex, pdftex, xtex,luatex

    La situazione pratica è la seguente
    – tex è ancora mantenuto da Knuth, ma praticamente non usato.
    – etex ingloba tex,
    – pdftex ingloba etex .
    – luatex (alla fine~2012) ingloba pdftex,etex,tex

    Alcune volta si parla di luatex come pdftex2.0, a significare che l’attuale pdftex confluirà naturalmente in luatex. Quando avverrà questa cosa ?
    Boh.

    Comunque la parte rilevente dello scenario è questa
    – latex2e, latex3 con pdftex, etex,luatex.
    attualmente abbiamo (mia stima)
    100%latex2e, 0%latex3;
    (90%latex,pdftex),
    (9%latex,etex),
    (~1%latex,xetex),
    la rimanenza (latex, luatex.)
    In futuro sempre meno pdftex ed etex, sempre più luatex,
    ma senza fretta; nel frattempo xetex può crescere bene.
    Onestamente non so dire molto su latex3.

    -context mkii usa pdftex, xetex . Ufficialmente è frozen: nessuna modifica in questo formato. Tutte le modifiche avvengono in mkiv

    -context mkiv usa luatex. E’ il formato del futuro, ma già oggi usato in ambiente di produzione controllato.

    Quello che mi aspetto è una proporzione (80%latex,20%context)
    Ovvero latex sarà sempre usato per gli articoli e book scientifici,
    Context per book in generale, anche scientifici, ma particolari.
    Il futuro è veramente denso: pensate ad esempio a pstricks.
    Attualmente segue la chain etex ->dvips -> pstopdf e
    non si può usare nativamente in pdftex. Ma con luatex (come ho mostrato con lunatic) si può estendere luatex stesso per inglobare un interprete
    postscript, e quindi potenzialmente in pdflualatex sarà possibile usare pstricks — beh qualcuno deve scrivere e mantenere il codice di interfaccia necessario, e tenete presente che pgf è bellissimo e che metapost è nativo in luatex e che quindi già ci sono concorrenti non da poco.

    in risposta a: Prima prova con ConTeXt #38177
    Up
    0
    Down
    ::


    Giusto x non perdere niente,
    esiste anche questo x windows
    http://www.w32tex.org/

    in risposta a: Prima prova con ConTeXt #38175
    Up
    0
    Down
    ::

    Infine, do
    `texexec`
    e vengo avvisato del fatto che
    `”texlua” non è riconosciuto come comando interno o esterno,
    un programma eseguibile o un file batch. `
    Ho controllato su Google se altri hanno avuto lo stesso problema, ma pare di no.

    Uh!? Forse non è settato come eseguibile e nen è nel tuo path ?

    Temporaneamente ho “risolto” così: creo un file prova.tex:
    `\starttext
    Hello World
    \stoptext`
    ( 😉 ) e do da prompt:
    `texmfstart texexec.rb prova.tex`
    in seguito al quale ottengo 7 file:

    1. mpgraph.mp;

    2. prova-mpgraph.mp;

    3. prova.log;

    4. prova.tui;

    5. prova.tuo;

    6. prova.tmp;

    7. prova.pdf.

    Anche un codice un po’ più corposo (preso dalle pagine 3 e 4 della guida mp-cb-en.pdf) viene trasformato in .pdf senza problemi (almeno così pare):
    `\starttext
    \startstandardmakeup
    \midaligned{How to make a document.}
    \midaligned{by}
    \midaligned{The Author}
    \stopstandardmakeup
    \completecontent
    \chapter{Introduction}
    … your text\index{indexentry} …
    \chapter{One Chapter}
    \section[firstsection]{The first section}
    … your text …
    \section{The second section}
    \subsection{the first sub section}
    … your text\index{another indexentry} …
    \subsection{the second sub section}
    … your text …
    \section{The third section}
    … your text …
    \chapter{Another Chapter}
    … your text …
    \chapter[lastchapter]{The Last Chapter}
    … your text …
    \completeindex
    \stoptext`

    Mi pare che te la cavi lo stesso, “paranoie” di Windows a parte.
    Cmq sul log c’e’ scritto che formato usa (e dove va a pescarlo)
    Se ci sono errori, questi iniziano con “!”

    (Mentre cercavo soluzioni, mi sono imbattuto in questo sito: http://minimals.contextgarden.net/. Vedo se trovo qualcosa di utile.)

    E’ la minimals cfr anche
    http://wiki.contextgarden.net/Main_Page

    La distribuzione ufficiale di context si chiama “minimals”
    ed io consiglio vivamente di usarla.
    Ad esempio, nel mio caso ho un paio di texlive completamente installate con latex context etc. che uso solo per Latex e non modifico nessun files .

    Per ogni cosa che riguarda context uso la minimals, che installo in una directory a mia scelta. Ho più minimals, non è un problema e non vanno in conflitto (ovvio che ci sono un sacco di files duplicati)
    “minimals” è pensata per un progetto, quindi più progetti + minimals,
    con minimals avete mpost,pdftex,luatex e xetex , e context. Niente Latex

    $>texexec test.tex
    usa context+pdftex aka context mkii

    $>context test.tex
    usa context+luatex aka context mkiv

    Tengo i miei files in una directory a parte, in modo che gli update del minimals
    non me li cancellino.

    Ora, sotto windows ci potrebbero essere proprio problemi con ruby 1.8 / ruby 1.9, ed in questi posts mi pare che si sia capace di risolverli.

    in risposta a: Prima prova con ConTeXt #38173
    Up
    0
    Down
    ::

    Scusate, vi ho fatto perdere tempo per una cosa così banale.
    Quindi ho risolto installando Ruby con il download del file dal sito ufficiale (è stato necessario riavviare il sistema operativo). Ecco cosa compare se lancio ruby dalla console di XP:
    `ruby -v
    ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
    `

    Non è banale. Gli sviluppatori di ruby non hanno fatto un rilascio
    ben fatto, La versione 1.9 dà subdoli problemi .

    L’unica cosa che noto è che la compilazione con ConTeXt è molto molto più lenta rispetto alla macchina Linux.

    Hm, strano.
    Forse sul log c’e’ scritto il tempo impiegato.

    Per altri esempi prova qui:

    Creating a style file in ConTeXt


    in risposta a: modules.pdf #6080
    Up
    0
    Down
    ::


    Con l’ultima release di modules,
    credo si sia scoperto un bug.
    Cfr
    http://sarovar.org/tracker/index.php?func=detail&aid=799&group_id=106&atid=493

    in risposta a: modules.pdf #6079
    Up
    0
    Down
    ::


    Aggiornato all’ultima release 2007-04-17

    http://www.logosrl.it/context/modules/2007-04-17/

    in risposta a: EDMAC e ledmac #11267
    Up
    0
    Down
    ::

    Ho un po’ di esperienza con i pacchetti EDMAC e ledmac per gestire la stampa delle proprie edizioni critiche, quindi mi rendo disponibili per risolvere dubbi.

    Un cordiale saluto a tutti,

    Jerónimo

    Vorrei segnalare l’intervento del prof. Idris Samawi Hamid
    al primo CONTEXT user meeting (Epen 24/25 marzo 2007 )
    http://context.aanhet.net/epen2007/programme.htm
    http://context.aanhet.net/epen2007/share/idris/

    luigi

Stai visualizzando 15 risposte – dal 211 al 225 (di 264 totali)

Go to top