[RISOLTO] Iniziamo a programmare

Complimenti per il risultato davvero molto bello.
Premesso che non sarei nemmeno lontanamente capace di creare un file così, mi chiedo se il pacchetto bookmark caricato in quel posto va bene.
Essendo una implementazione di hyperref forse va caricato anch’esso per ultimo, magari dopo hyperreff che quindi diventerebbe il penultimo.

[attachment=819]dispensa.zip[/attachment]
Ti ho corretto alcune cose, e vi ho messo dentro un paio di astuzie epr usare una data sola per i tre file (.dtx, .cls, .sty).
L’errore più grosso è quello di mettere due volete \CheckSum come se volessi controllare la check sum di ciascun file sepratamente, e, grave, \Finale, che impediva di estrarre il file .sty.
[attachment]dispensa.zip[/attachment]

Non ho capito perché chiami i due file prodotti dispensacls.cls e dispensapkg.sty mentre si possono chiamare tranquillamente e senza confusioni dispensa.cls e dispensa.sty.

Devi imparare a usare il comando \meta (controlla il file .dtx e il corrispondente dile .pdf)

Avrei dei dubbi da esprimenre in merito alla compatibilità della classe con il pacchetto di estensione; per esempio non so se carichi certi pacchetti due volte e con opzioni diverse; Non ho avuto voglia di andare a vedere dentro i rispettivi file che cosa caricano rispettivamante ClassiThesis e arsclassica, ma ho il sospetto che ci siano dei doppioni, e come sai le due cose non vanno bene assieme, a mneo che le opzioni specificate non siano le stesse e nello stesso ordine.

Avrei dei comenti da fare sul fatto che il pacchetto .sty carichi di tutto, non solo per la composizione della matematica.

Ti ricordo che amssymb carica a sua volta amsfonts, ma ne rende accessibili i glifi e qualche altra cosa; caricare amsfonts senza amssymb non ha molto senso, caricarli entrambi ancora di meno, basta amssymb.

Calligra non definisce il corsivo, ma il calligrafico, per giunta in stile Edwardiano.

Le lettere greche minuscole corsive non hanno bisogno di amsmath per essere rese in “stile italiano secondo la tradizione”; puoi fare quel giochetto anche senza caricare amsmath & company.

\makeatletter e \makeatother non sono necessari né nei file di classe né nei file di estensione. l’esecuzione dello statement \begin{document} finisce il preambolo ma contemporaneamente ristabilisce tutti i codici di categoria, in particolare riassegna al segno @ il codice 12, quando durante l’esecuzione del file di classe ha codice 11.

Sono d’accordo con @Otacon sul fatto che il pacchetto bookmarks andrebbe più pulitamente caricato dopo hyperref, ma anche che può essere sostituito bellamente con l’opzione bookmarksopen fra le opzioni di hyperref. Controlla sulla documentazione di hyperref scrivendo texdoc –showall hyperref e poi digitando il numero corrispondente al “manual”.

Detto questo hai cominciato bene; usa più spesso le due barre verticali che delimitano le cose da comporre verbatim e/o in carattere teletype; puoi rendere più scorrevole la lettura del file .dtx se lo usi sistematicamente al posto di \texttt{…}, scrivendo |…| anche se i puntino non necessitano dela composione verbatim.

Ciao
Claudio

Dork” post=89834L’errore più grosso è stato pensare che il .dtx producesse due cose separate…avevo messo anche tutta la parte di preamble e postamble e chiamato i file diversamente per paura facesse confusione. Inizialmente infatti avevo fatto, di fatto, due codici interi nello stesso file, con gli stessi nomi e, ovviamente non andava nulla… poi ho tolto qualcosa ma credevo che i checksum li facesse comunque separatamente (e infatti lo faceva…e mi diceva i vari errori se sbagliavo di contare)

Beh, infatti un file .dtx può produrre cose separate. Dipende tutto da come si utilizza. 🙂 Infatti autori diversi hanno prodotto .dtx con stili completamente diversi.

Mi spiego con un esempio semplice semplice. Prendiamo ad esempio i nostri guru, Enrico e Claudio (OldClaudio) e i rispettivi pacchetti steinmetz e codicefiscaleitaliano. Se vai a leggere steinmetz.dtx troverai la charcter table mentre in codicefiscaleitaliano.dtx non è presente.

Ora, venendo al punto, se devi produrre file diversi, come una classe, uno o più pacchetti e magari un esempio di utilizzo (che ora nel tuo caso manca, ma potresti integrare), usare i .dtx è sicuramente la scelta vincente. Per fare un esempio, il mio smartdiagram.dtx produce: un file .sty, 4 librerie in cui è effettivamente suddiviso il codice, il file di installazione .ins e il readme.

Quello che ti consiglio quindi è di non prendere ad esempio solo un autore, ma confrontare diversi stili per capire meglio tutte le possibilità che ti offrono i .dtx. Non è assolutamente tempo perso.

OldClaudio” post=89833
Avrei dei comenti da fare sul fatto che il pacchetto .sty carichi di tutto, non solo per la composizione della matematica.

Anche io esprimo lo stesso dubbio. In primo luogo per quanto riguarda la codifica di ingresso (che poi ci sono cascato anche io come Enrico mi ha fatto giustamente notare).

Ciao
Claudio

Certo che un file .dtx pu`ø produrre cose separate; produce quello che l’autore dice di produrre; l’esempio di @cfiandra realtivo ai due .dtx composti da Enrico e da me non dice niente; Enrico ed io abbiamo abitudini diverse e produciamo file .dtx che contengono coes diverse; io per esempio non metto mai la tabella dei condici ASCII; è una abitudine che risale a tempi “antichi” quando le trasmissioni sulla rete potevano essere bacate; la presenza dei codici ASCII corretti poteva essere utile per rendersi conto se la trasmissione era avvenuta correttamente. Anch’io inserivo quella tabella anni fa; non lo faccio più, perché la trovo “oggi” un ingombro inutile; sicuramente non è dannoso ed Enrico fa benissimo a conservarla. Io invece, che ho gmail.com come provider di posta elettronico non uso più i file .ins: gmail.com li rigetta anche se sono annegati dentro un file .zip. Se invece rendo il file .dtx autoestraente come faccio di solito, come ho scritto nella guida che ha seguito @dork, come vedi in tutti i miei .dtx presenti in rete, inserisco il codice di estrazione nella prima parte; dovrebbe essere uguale (a parte i nomi diversi per i file da elaborare) a quello di Enrico, e diverso da quello che è raccontato nel tutorial dtxtut leggibile con texdoc dtxtut.

@dork, ora guardo il tuo file modificato e vedo con i file d’esempio perché i margini sono diversi, ma non sono convinto che sia utile fare un file .dtx distinto per caricare ciascun pacchetto che vorresti introdurre nei tuoi preamboli: non avrebbe senso usare \input invece di \usepackage nei tuoi preamboli, anche perché \input carica indiscriminatamente il pacchetto indicato, mentre \usepackage controlla e non ricaricare i pacchetti già caricati e in particolare segnala un eventuale “option clsh” se volessi ricaricare un pacchetto con opzioni diverse.

@cfiandra, come fai a generare il file .ins da dentro il file .dtx? Forse ti sei espresso male, ma non puoi estrarre un file .ins da un .dtx, se non è autoestraente; e se è autoestraente il file .ins non serve a niente. Invece potrebbe essere buona l’idea di mettere anche i file README e manifiest.txt dentro il file .dttx; senonché ho la sensazione che i gestori di CTAN rifiuterebbero un file .dtx fatto in questo modo, perché li costringerebbe ed eseguire l’estrazione, casa che non vogliono che sia fatta; i gestori di CTAN vogliono solo l’eventuale file .ins, il .dtx e la sua compilazione .pdf, il README e il manifest.txt; per questi ultimi due accettano anche un solo file, purché contenga tutte le informazioni che andrebbero poste nell’altro; le informazioni sulla costituzione di pacchetti di cui eseguire l’upload su CTAN sono cambiate da circa un anno.

OldClaudio” post=89840Certo che un file .dtx pu`ø produrre cose separate; produce quello che l’autore dice di produrre; l’esempio di @cfiandra realtivo ai due .dtx composti da Enrico e da me non dice niente; Enrico ed io abbiamo abitudini diverse e produciamo file .dtx che contengono coes diverse; io per esempio non metto mai la tabella dei condici ASCII; è una abitudine che risale a tempi “antichi” quando le trasmissioni sulla rete potevano essere bacate; la presenza dei codici ASCII corretti poteva essere utile per rendersi conto se la trasmissione era avvenuta correttamente.

Il mio intento era far capire a Dork che la sua frase:

Dork” post=89834L’errore più grosso è stato pensare che il .dtx producesse due cose separate

è sbagliata in quanto un file .dtx può produrre cose separate. L’esempio era più per suggerire di dare uno sguardo a diversi .dtx prima di iniziare con il proprio.

OldClaudio” post=89840

@cfiandra, come fai a generare il file .ins da dentro il file .dtx? Forse ti sei espresso male, ma non puoi estrarre un file .ins da un .dtx, se non è autoestraente; e se è autoestraente il file .ins non serve a niente. Invece potrebbe essere buona l’idea di mettere anche i file README e manifiest.txt dentro il file .dttx; senonché ho la sensazione che i gestori di CTAN rifiuterebbero un file .dtx fatto in questo modo, perché li costringerebbe ed eseguire l’estrazione, casa che non vogliono che sia fatta; i gestori di CTAN vogliono solo l’eventuale file .ins, il .dtx e la sua compilazione .pdf, il README e il manifest.txt; per questi ultimi due accettano anche un solo file, purché contenga tutte le informazioni che andrebbero poste nell’altro; le informazioni sulla costituzione di pacchetti di cui eseguire l’upload su CTAN sono cambiate da circa un anno.

Si, in effetti mi riferivo a .dtx autoestraenti. Quando ci ho messo mano la prima volta avevo letto la guida How to Package Your LaTeX Package, ma non mi era sembrata chiarissima così ho preso ad esempio alcuni autori per capirci un po’ di più.

Per quanto riguarda CTAN non concordo. In effetti da circa un anno è attivo il nuovo sito e il nuovo form di upload http://www.ctan.org/upload/ con le regole scritte molto chiaramente. Ai gestori non interessa tanto come sia strutturato il file .dtx perché, rispettando le regole, un autore invia un file zip con 1) pkg.dtx, 2) pkg.ins, 3) pkg.pdf, 4) readme. Che sono poi i file importanti.

La struttura del file .dtx ha influenza invece quando l’upload viene mandato al TeXLive Team o Christian Schenk, ed è una cosa che ho proprio imparato a mie spese con smartdiagram. Il pacchetto nasce più o meno lo scorso anno: il dtx originale non aveva le librerie, ma conteneva già il readme e non ci sono stati problemi neppure dai gestori di CTAN. I problemi sono nati a fine marzo/inizio aprile quando ho inviato la versione 0.3 con un cambiamento radicale: la divisione in librerie dell’originale file .sty (anche perché il file cominciava ad essere davvero troppo lungo). Sempre seguendo le regole ho inviato l’upload come descritto prima: anche qui nessuna segnalazione dai gestori di CTAN, ma facendo l’aggiornamento con il TeXLive manager il pacchetto non funzionava più. Motivo? Il TeXLive Team per installare il pacchetto aveva compilato il file .dtx e credendo le librerie dei file ausiliari non le aveva installate. Quindi dopo averne discusso con Rainer Schöpf e Karl Berry ho inviato una nuova versione spiegando meglio nel readme come è effettivamente composto il pacchetto.

Ciao
Claudio

@Dork, ho trovato il busillis della forma sbagliata della gabbai; questo ha richiesto alcune modifiche sostanziale del file .dtx che ti accludo;
[attachment=821]dispensa-CB2.zip[/attachment]

Ho trovato ancora un errore in BCOR5mm che va scritto BCOR=5mm.

Guarda il fondo del file .dtx ci sono delle righe commentate in modo strano… vale la pena di conoscere anche quel modo, validsdo solo per i file .dtx.

Commento:
Se ti fai un file opzioni.tex, non farlo: fatti un file opzioni.sty (magari commentando il codice in un opzioni.dtx, perché al pacchetto puoi passare delle opzioni, mentre al file immesso con \input non puoi farlo; questa infatti è la via da seguire, più che costruire una nuova classe per ogni documento; poi per imparare tutto va bene.