Den middels store LaTeX-tråden

[Torbjørn T.]

Det hadde nok stått i manualen til mhchem, om det var mogeleg. Longwinded nemner òg berre kjemiske likningar, ikkje strukturformlar.

[....]

For kjemiske ligninger anbefales mhchem, som har en veldig vennlig syntaks.

Jeg kjenner til mhchem. Har skrevet endel likevektsreaksjoner underhverandre i regnestykkegrupperingsmiljøet align i rapporter. Men er det virkelig mulig å skrive strukturformler av ulikt slag i mhchem?

Strukurformler begrenser seg til enkle ting som «O=C=O».

 

Ref. Torbjørn T., bør du bruke et grafisk program for kompliserte diagrammer. Wikipedias metadiskusjon angående dette anbefaler ChemDraw. Se også Wikipedia: Molecule editor.

Endret 3. januar 2012 av ....

[Euklid]

Hvordan pleier dere å legge inn bøker som er oversatt i BibTeX? Skal sitere Lattimore-oversettelsen av Odysseen i et paper jeg skriver, og bruker agsm-stilen i BibTeX. Nå har jeg bare gjort det manuelt med note, og har i bibliografien:

Homer (1991), The Odyssey of Homer, HarperCollins, New York. Translated into English by Richard Lattimore.

 

Dette duger for så vidt for mine formål, bare interessant å vite hva som er best practice.

[....]

Dette duger for så vidt for mine formål, bare interessant å vite hva som er best practice.

Finnes ikke. «note» er helt OK å bruke, selv om det ikke lar seg automatisere. Selv har jeg dette i leselistedatabasen min:

 

@Book{dawkins02,
 author =     {Richard Dawkins},
 title =      {Det egoistiske genet},
 publisher =  {Humanist Forlag},
 year =       2002,
 isbn =       8290425562,
 translator = {Arne Hem},
 pages =      396,
 language =   {norsk}
}

I teorien kan man få BibTeX-stilen til å plukke opp feltene «translator» og «language» og autogenerere teksten «Oversatt til norsk av Arne Hem». Forsøksvis:

 

• Bruk custom-bib-pakken til å produsere en skreddersydd .bst-fil. Tips: baser stilen på natbib, det gir deg flere tilpasningsmuligheter.
  
• Du må antagelig hacke .bst-filen for å få ting slik du vil. Dette er noe involvert fordi den baserer seg på et obskurt stack-basert språk (à la Forth), og det er lite dokumentasjon å oppdrive.
  

Så det er neppe verdt innsatsen, med mindre du har en veldig lang referanseliste og veldig gjerne vil automatisere.

Endret 3. januar 2012 av ....

[Euklid]

Takk for godt svar! Riktignok har jeg ofte rimelig lange referanselister, men dette er ikke verdt innsatsen siden det aller meste går på originalspråk.

[Imaginary]

Holder på å lage meg en dokumentmal, men har støtt borti en del problemer. For eksempel sliter jeg med å få en korrekt linje under avsnittoverskrifter, dvs. per nå oppfører den seg ulikt avhengig om jeg har bokstaver som går "ned i kjelleren" (p, j, g, etc.) eller ikke. Tenker at det har noe med hvordan LaTeX håndterer tekstboksene, men hvordan kan dette overstyres?

 

Et annet problem er tabeller i dobbelkolonne-struktur. tabular går greit, men table har jeg ikke greid å plassere i én kolonne. Hvordan?

 

Lenke til foreløpig dokument: rapport.pdf

Endret 17. april 2010 av Imaginary

[Torbjørn T.]

Angåande tabellane:

Veit ikkje kva du har gjort, men det fungerer no fint med ein table-float i tokolonneoppsett i dei vanlege dokumentklassane iallfall. T.d

\documentclass[a4paper,twocolumn]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[nynorsk]{babel}
\usepackage{
 microtype,    % for betre typografi
 lipsum        % for lorem ipsum
}

\begin{document}
\lipsum[1-2]
\begin{table}[h]
\centering
\caption{Tabelltull}
 \begin{tabular}{ccccc}
   1 & 2  & 3 & 4 & 5\\
  6 & 7 & 8 & 9 & 10 \\
 \end{tabular}
\end{table}
\lipsum[3-7]

\end{document}

Endret 17. april 2010 av Torbjørn T.

[Imaginary]

Jeg har brukt multicol-pakken, og da fungerer tydeligvis ikke tabeller/figurer helt.

 

Har fått lagt til følgende i preamble:

% Figures within a column...
\makeatletter
\newenvironment{tablehere}
{\def\@captype{table}}
{}
\newenvironment{figurehere}
{\def\@captype{figure}}
{}
\makeatother

 

Da får jeg inn tabeller greit, men det ser ut som om tabellen "henger" sammen med neste avsnitt. Tabelldataene er slengt til venstre, og avsnittet har innrykk.

 

 

Takk for tipse om microtype-pakken!

[Torbjørn T.]

Med forbehold om at eg aldri har gjort slikt, so det kan vere høve eg ikkje kjenner til:

 

Legg til ein \par\noindent\ignorespacesafterend i det siste argumentet for den nye omgivnaden, so ser det ut til å verte rett:

\makeatletter
\newenvironment{tablehere}
{\def\@captype{table}}
{\par\noindent\ignorespacesafterend}
\newenvironment{figurehere}
{\def\@captype{figure}}
{\par\noindent\ignorespacesafterend}
\makeatother

(Fann det her: http://en.wikibooks.org/wiki/LaTeX/Customizing_LaTeX#Extra_space )

 

No er det dog eit problem at tabellen ikkje vert lista i listoffigures. Det veit ikkje eg korleis ein fikser. Red.: Kortslutning. Naturlegvis vert ikkje tabellar lista i ei liste over figurar ...

 

Eg sender takken for microtype vidare til longwinded, som har nemnt den ved eit par tidlegare anledningar i tråden.

 

 

Og forresten, om du ikkje kjenner til den frå før kan eg nemne booktabs for betre tabellar.

Endret 17. april 2010 av Torbjørn T.

[Imaginary]

Supert! Ja, var innom booktabs under feilsøkingen.

[....]

Dette er ikke rent TeX-relatert og er egentlig noe alle bør kunne enten de bruker TeX eller ei, men det illustrerer hvilke særskilte fordeler tekstbaserte filformater har. Så, folkens, listen up.

 

Bruk versjonskontroll.

 

Vi skriver 2010, og skikkelige lagringssystemer er ikke lenger forbeholdt dem som driver med teknisk utvikling. De kan og bør brukes av alle. Versjonskontroll gir deg:

 

• Lagring: en svært trygg og oversiktlig måte å lagre arbeidet på.
  
• Sikkerhet: systemet beregner sjekksummen av filene dine, og verifiserer at de er intakte.
  
• Endringslogg: oversikt over hvordan prosjektet skrider fremover.
  
• Filhistorikk: alle tidligere utgaver kan hentes frem igjen.
  
• Diffing: de konkrete endringene gjort fra en versjon til den neste.
  
• Merging: ulike personer kan arbeide samtidig på den samme filen, og endringene kan integreres.
  
• Branching: du kan jobbe på «eksperimentelle» utgaver av prosjektet i parallell, og integrere dem med hovedutgaven når de er gode nok.
  
• Distribuering: du kan dele arbeidet ditt via sosiale utviklingsportaler som GitHub og BitBucket.
  

La oss se på dette i praksis.

 

 

Her er endringsloggen til et TeX-dokument. Kommentarene gir oss en oppsummering av endringene fra versjon til versjon, og forfatterkolonnen forteller oss hvem som har gjort hva. Jeg kan klikke på en hvilken som helst versjon i listen og gjenopprette denne: Ingenting som slettes, går tapt.

 

Det minner litt om Wikipedia, ikke sant? Siden TeX er tekst, kan vi også sammenligne to versjoner med en diff:

 

 

Her ser vi at en mengde nye linjer er blitt lagt til siden forrige gang. Denne funksjonaliteten er kjempenyttig når man jobber sammen med andre, men også når man er usikker på hva man selv har gjort siden sist.

 

Hvor blir all historikken lagret? Dersom du bruker Git, opprettes det en skjult undermappe med navnet .git i arbeidskatalogen din. Med et grafisk grensesnitt som TortoiseGit får også filikonene et nytt utseende, der grønt betyr «sjekket inn» og rødt at det er gjort endringer siden sist.

 

 

For å plassere et nytt prosjekt under versjonskontroll, høyreklikker man bare på mappen med prosjektet, velger «Create repository here», og legger til filene. (Alt kan også gjøres via kommandolinjen, naturligvis, men Tortoise-klientene fungerer som en forlengelse av det grafiske grensesnittet.)

 

Du kan i prinsippet plassere hva som helst under versjonskontroll, f.eks. musikk, bilder og video. Men TeX-dokumenter er særlig godt egnet fordi de er ren tekst, og kan dermed «diffes», dvs. betraktes som linjer fjernet og lagt til. Diffen kan lagres og utveksles med andre som sitter med den samme filen (men Git har også egne og automatiske verktøy for synkronisering). Når du har blitt vant til dette, vil du aldri mer gå tilbake til Word, og du vil se med skjevt blikk på alle som «lagrer» arbeidet sitt i binære og proprietære formater.

 

Sett i gang! Installer Git (Windows: msysGit) eller Mercurial – samt en grafisk klient som TortoiseGit eller TortoiseHg, om du vil – og les innføringen:

 

• Pro Git
  
• Hg Init: A Mercurial tutorial
  

Det spiller ingen stor rolle om du velger Git eller Mercurial, bare du styrer langt, langt unna utdaterte og sentraliserte systemer som Subversion. (Mercurial er imidlertid bedre for dem som er vant med Subversion.) Git og Mercurial er distribuerte, som vil si at all revisjonshistorikk ligger lokalt i arbeidsmappen din (i underkatalogen .git eller .hg), og du er ikke avhengig av en server.

 

Bruk versjonskontroll. Begynn i dag.

Endret 3. januar 2012 av ....

[kyrsjo]

Vil absolutt anbefale å bruke versjonskontroll!

 

Men jeg vet ikke om jeg er enig i "ikke bruk SVN etc. fordi det er gammeldags og sentralisert" - for min del er sentralisert flott. Jobber på to maskiner (en arbeidsstasjon på UiO og en laptop), bruker UiO sin SVN-tjener. Jobber på prosjektene alene. SVN gjør at jeg sjekker inn arbeidet til serveren, slik at jeg lett kan holde de synkronisert, og at jeg alltid har backup.

 

Forøvrig: Eclipse har SVN-støtte integrert. LaTeX-edit-moduset TeXclipse fungerer og meget bra (brukt emacs med AucTex før - det er meget flott, men liker TeXclipse bedre

Endret 28. april 2010 av cyclo
Fjernet unødvendig sitat

[....]

Vil absolutt anbefale å bruke versjonskontroll!

 

Men jeg vet ikke om jeg er enig i "ikke bruk SVN etc. fordi det er gammeldags og sentralisert" - for min del er sentralisert flott. Jobber på to maskiner (en arbeidsstasjon på UiO og en laptop), bruker UiO sin SVN-tjener. Jobber på prosjektene alene. SVN gjør at jeg sjekker inn arbeidet til serveren, slik at jeg lett kan holde de synkronisert, og at jeg alltid har backup.

For all del, jeg er helt for backup! Og det er akkurat på dette området at distribuerte systemer er Subversion overlegent, fordi serveren er ikke den eneste backupen du har. Med Subversion kan du ikke sjekke inn arbeidet ditt uten nettilgang (eller når UiOs servere er nede for vedlikehold), for det er bare den siste versjonen som ligger lokalt. All versjonshistorikk er på serveren, og backup er en tungvint og manuell affære.

 

Når du bruker en Git-server, derimot, har du minst to backuper av hele versjonshistorikken: din egen mappe (som du kan kopiere over på en minnepenn, brenne ut, etc.), og serverutgaven, som du synkroniserer mot. Hver gang du kloner Git-repo’et ditt, har du laget en backup, og du kan jobbe lokalt med den kopien inntil du er klar for å laste opp arbeidet ditt. Å sjekke inn og publisere er hva de bør være: to separate steg!

 

Oppsummering: kontakt UiO pronto om å sette opp et distribuert alternativ til SVN.

 

(Jeg vil til og med hevde at et distribuert system som Git er lettere for en nybegynner enn Subversion, i hvert fall lokalt. Å sette opp et lokalt Git-repo er bare å høyreklikke på en mappe og velge «Create repository here», mens med Subversion må man bale med Apache.)

 

LaTeX-edit-moduset TeXclipse fungerer og meget bra (brukt emacs med AucTex før - det er meget flott, men liker TeXclipse bedre

Gammel AUCTeX-bruker her. Utdypning?

Endret 3. januar 2012 av ....

[kyrsjo]

Så,så, ingen grunn til å gå i forvarsmodus!

 

SVN funker fint. Dersom serveren skulle være nede, kan jeg alltids bruke "gamlemåten" med sftp mellom maskinene. Ikke at det noensinne har skjedd...

 

Lettere for nybegynner? Kanskje om du må sette opp server og greier - men om noen allerede har satt opp serveren, og sørger for backups av den etc., så er det veldig lett å sette opp (husker ikke kommandoene akkurat, men noe slikt):

cd mappe
svn ci svn+ssh://bruker@server/mappe
*skriv kommentar*

 

Har venner/kollegaer som bruker Git med Github også - det funker for dem. Whatever works...

 

AucTex:

Rett og slett fordi jeg egentlig liker Eclipse bedre enn Emacs, i alle fall når jeg har prosjekter med mange filer (slik store skrivejobber med mange kapitler type "bok" bør organiseres). For litt mindre ting er emacs genialt

 

Hurtigfullføringer f.eks. av referanser, mini-templates for figurer, tabeller etc., kompilering av store prosjekter (her tuller emacs det til for meg ved å insistere på å kompilere fila jeg står i, ikke hovedfila - men det er sikkert en meta-X kommando som fikser det), valg av alternativ latex-distro +++ - funker kjempeflott!

[kyrsjo]

En helt annen ting:

Hvor mange her har sett [it]todonotes[/it]-pakken?

Genialt system:

Du skriver f.eks. ting alá

"... as discussed in reference\todo{Reference to blæh}",

og pakken gir deg en gul dings i margen med pil tilbake til punktet i teksten.

 

Kan også bruke ting som

"""

\todo[inline]{In this chapter: foo, bar, baz}

"""

eller

\missingfigure{Description}

(for \insertgraphics)

 

http://www.tex.ac.uk/tex-archive/macros/latex/contrib/todonotes/todonotes.pdf

[Torbjørn T.]

Har sett todonotes, men ikkje brukt. Bror min har dog brukt den i det siste, under arbeid med masteroppgåva. Snedig sak, kan jo gje deg ei \listoftodos òg.

 

Kva versjonskontroll angår, har eg aldri brukt det, men eg ser at det kan vere fornuftig, so eg må tenkje på det. Ser ut som UiB som UiO tilbyr SVN-tener, men ikkje tilsvarande for Git. (Var iallfall ingen treff for Git på sida til IT-avdelingen.)

 

Red.: Bruker forøvrig Dropbox for tida, som gjev automatisk backup (so lenge ein er kopla til nett) og tilgang til alle versjoner frå siste månad. Veldig enkelt og greit, men ikkje like mange fordelar som Git e.l.

Endret 19. april 2010 av Torbjørn T.

[Euklid]

Versjonskontroll høres interessant ut, men er ikke noe jeg har ressurser til å sette meg inn i i øyeblikket. Inntil videre takker jeg for tipset om todonotes og slenger meg på anbefalingen av Dropbox. På ingen måte like kraftig som skikkelig versjonkontroll, men ufattelig mye bedre enn den ikke-eksisterende lagringen av tidligere versjoner mange sitter med.

[....]

Så,så, ingen grunn til å gå i forvarsmodus!

Jeg er bare entusiastisk Jeg har brukt både Subversion og Git, og jeg kan kategorisk si at alt Subversion gjør, gjør Git bedre. (Men Mercurial er kanskje lettere hvis man er vant til Subversion.)

 

Hurtigfullføringer f.eks. av referanser,

Bruk RefTeX, som er inkludert med Emacs:

 

(add-hook 'LaTeX-mode-hook 'turn-on-reftex)

Dette gjør det ikke bare lettere å arbeide med referanser, men gir deg også verktøy for å lage indeks, dersom du har tid til det.

 

mini-templates for figurer, tabeller etc.,

Dette får du jo med AUCTeX? For øvrig har Org-mode noen veldig nyttige funksjoner for å konvertere fra lettredigert «ASCII-art» til den grusomme tabellsyntaksen til LaTeX.

 

kompilering av store prosjekter (her tuller emacs det til for meg ved å insistere på å kompilere fila jeg står i, ikke hovedfila - men det er sikkert en meta-X kommando som fikser det),

Hvis du legger til

 

(setq-default TeX-master nil)

i .emacs, vil AUCTeX spørre deg om navnet på hovedfilen, og oppdatere den inkluderte filen med en kommentert referanse til denne. Se også kapittelet «Multifile Documents» i Info-manualen.

 

valg av alternativ latex-distro

AUCTeX har (require 'tex-mik) og (require 'tex-fptex) for skreddersydde oppsett for MiKTeX and fpTeX. Men det var kanskje ikke det du siktet til?

Endret 3. januar 2012 av ....

[Rusma]

Hei!

 

Jeg fikk noe tips om Inkscape og BKchem her tidligere i tråden. Nå har jeg skrevet inn formlene i rapporten min vha. pdf-dokument jeg eksporterte fra inkscape og \includegraphics. Ikke helt ideelt.

 

Her er hvordan jeg strukturerte alt til slutt:

 

Hvordan kunne jeg gjort dette i TikZ?

[Torbjørn T.]

Til dømes slik. Kan vere det finst meir elegante måtar å gjere det på.

\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{positioning}
\begin{document}
\begin{tikzpicture}[node distance=.5cm]
\node (C)               {C};
\node (O)  [right=of C] {O};
\node (H1) [right=of O] {H};
\node (H2) [above=of C] {H};
\node (H3) [left=of C]  {H};
\node (H4) [below=of C] {H};
\draw (C) -- (O);
\draw (O) -- (H1);
\draw (C) -- (H2);
\draw (C) -- (H3);
\draw (C) -- (H4);
\end{tikzpicture}
\end{document}

 

Red.: Har ikkje tid til å ta meir enn det enklaste dømet, men du skjøner sikkert opplegget. Spør om det er noko du lurer på, eller sjekk dokumentasjonen.

 

Redigert 2:

pgfmanual.pdf er forøvrig eit veldig nyttig dokument å ha om ein skal bruke PGF/Tikz. Veldig mykje informasjon, og mange døme.

 

Nokon feil er det dessverre. I starten er det fire guider som tek for seg konstruksjonen av fire ulike figurar frå starten av. I den andre av desse («A Petri-Net for Hagen», kapittel 3) er det eit avsnitt (avsnitt 3.8) som omhandlar relativ plassering av noder, slik eg har gjort over. Feilen her er at det står ein må bruke placements-biblioteket, medan det eigentleg er positioning-biblioteket som er aktuelt, jfr. dømet mitt over.

 

Og berre for ordens skuld legg eg inn link til Texample.com ein gong til:

http://www.texample.net/tikz/examples/

 

Når eg laga dømet brukte eg fyrst pgfmanual.pdf, men då fekk eg det naturleg nok ikkje til å fungere, sidan placements-biblioteket ikkje eksisterer ein gong. So då såg eg på eit døme under «node positioning» på Texample, og fann raskt at det var positioning-biblioteket eg måtte ha.

 

Det kan vere placements er gamalt, frå ein eldre versjon av Tikz, og so har ikkje manualen vorte oppdatert heilt, men det veit eg ikkje.

Endret 20. april 2010 av Torbjørn T.