Latex verpacken wie InDesign?

[hipokamp]

Bin vor einigen Monaten von Indesign auf Latex umgestiegen. Das war ein prima Entscheid, aber ich vermisse ein wichtiges Feature bei Latex, das automatische (!) Verpacken von .tex und dazugehörenden .png (Bildern) in einem Ordner, um diesen Ordner dann zu zippen und anderen Usern zur Verfügung stellen zu können.

Man könnte... alle Dateien sowieso in einem einzigen Verzeichnis unterbringen - das halte ich bei einigen tausend Bildern und Dokus für chaotisch. Man könnte... jedes verwendete Bild von Hand in einen Ordner ziehen - das halte ich bei durchschnittlich 20 Bildern pro Dokument für ziemlich mühsam, zumald die Bilder die aus verschiedenen Themenordnern stammen.

Gesucht wäre eine skript-basierte Lösung, irgendein Programmding, welches mir das .tex nach Bildern (mit z.T. langen Pfadangaben) durchsucht, diese Bilder dann in einen "Export-Ordner" kopiert und das .tex (und das .bib) file dazu.
Gibt es das Gesuchte?

Hipokamp

[cookie170]

Hallo,
wie soll das funktionieren? Wenn Du mit \includegraphics einen Pfad zu einem Bild angibst, dann führt das doch zu einer Fehlermeldung, wenn das Bild bei jemand anderem nicht unter diesem Pfad zu erreichen ist, sondern plötzlich im gleichen Ordner?

Gruß + neugierig auf Erklärung,

Alexander

[hakaze]

Mein Gegenvorschlag ist, auch bei deinen Latex-Dokumenten mit Projektordnern zu arbeiten. Intern binde ich Bilder oder andere input/include-Anweisungen über relative Pfadangaben ein. Dadurch kann man dann das Projekt als Ganzes Zippen und verschicken. Zum Beispiel:
Projekt1
|-Bilder
| |-abbildung12.jpg
|-Kapitel
| |-vorwort.tex
| |-hauptteil.tex
|-Literartur
| |-literatur.bib
|-projetkt1.texDadurch hat man zwar ab und zu ein paar Dateien doppelt unter den Projekten. Dafür gibt es aber auch keine Querschläger, falls man doch mal nur einmalige Änderungen vornehmen muss.

[hipokamp]

Alexander hat natürlich recht - da wäre ich laufend am Pfade "suchen-ersetzen": keine gute Idee.

Relative Pfade bieten einen sauberen Weg (smile). Sehe da zwei Varianten: A) so wie von hakaze beschrieben, mit Projektordnern. B) Mich daran machen, mein Ordnerstruktur neu aufzusetzen (nicht wirklich mein Hobby), damit alle Bilder im default-Bilderordner liegen.

Was ich nicht verstehe sind die | im Code von hakaze - hat das etwas mit dem MacOS zu tun? Gehe ich richtig, dass ich unter Windows |-Bilder ersetze mit ./Bilder/Abbildung12 wenn das Bild in einem Unterordner zur Hauptdatei liegt oder dass ich schreibe ../Bilder/Abbildung12 wenn das Bild in einem Bilderordner auf gleicher Hierarchie wie der Hauptdokumentordner liegt?

Kann ich mit relativen Pfaden auch zwei Ebenen höher als die aktuelle Datei suchen lassen, also so, dass ein Bild "eine oder zwei" Ebenen höher in einem Bilderordner liegen könnte?

Vielen Dank für eure Antworten

Kaspar

[hakaze]

Die Striche sind meinen graphischen Skills geschuldet, um eine Ordnerstruktur in der Code-Umgebung abzubilden ;)

Meiner Erfahrung nach funktionieren auch unter Windows relative Pfadangaben in den Latex-Projekten mit "." und "..", wie man sie auch von unixoiden Betriebssystemen kennt.

Um bei meinem Beispiel in Post #3 zu bleiben:
- Bildverknüpfung in projekt1.tex -> ./Bilder/Abbildung12
- Bildverknüpfung in Kapitel/vorwort.tex -> ../Bilder/Abbildung12
- für höhere Ebenen gehen auch Konstruktionen wie "../../Datei-ausserhalb-des-Projekts.xyz"

[klops]

Man kann auch einfach die Umgebungs-/Environment-Variable TEXINPUTS passend setzen. Wer mit seinem OS nicht umgehen kann und deshalb dazu nicht in der Lage ist, kann stattdessen auf \graphicspath in der Dokumentpräambel ausweichen. Danach gibt man dann alle Abbildungen einfach ohne Pfadangabe an. Näheres zu TEXINPUTS ist beispielsweise kpathsea.pdf zu entnehmen. Näheres zu \graphicspath ist der Anleitung zu graphics/graphicx, grfguide.pdf, zu entnehmen.

[hipokamp]

super, das motiviert mich, nun doch diese kpathsea Geschichte zu studieren --- den Angriff mit dem Nichtverstehen des Betriebssystems stecke ich gelassen weg und verzichte auf den graphicspath, denn der schränkt die Flexibilität vielzusehr ein. :)

[hipokamp]

...einfach die Umgebungs-/Environment-Variable TEXINPUTS passend setzen. ... Näheres zu TEXINPUTS ist beispielsweise kpathsea.pdf zu entnehmen...

... so, nun wäre es an der Zeit, hier weiterzuforschen.
Unterdessen habe ich von MikTex und TexStudio auf Windows zu TexLive und Kile auf Linux umgestellt - einige Haare sind immerhin noch dunkel (...), und es läuft.
Kile bietet mir die Möglichkeit, über das Menue settings - LaTex - general folgenden string zu TEXINPUTS einzufügen:
.:/share/{SB_Unterricht/Biologie//,00_SCHULE_DATA-add//}:

Damit findet Kile alle Bilder in allen U-Verzeichnissen von /Biologie/ und von /Data-add/ ABER: das dauert EWIG, denn diese Verzeichnisse sind tief und haben mehrere tausend Dokus drin !!!

An der Dokumentation von Kpathsea habe ich mir die Zähne ausgebissen, das ist nichts für einen Durchschnittsuser (leider). Aber ich denke, dass es möglich sein sollte, die Pfade in ls-R aufzunehmen, so dass die Bilder über Kpathsea von TexLive rasch gefunden werden könnten. Ist das so - und wenn ja, wie würde ein Konsolenbefehl lauten, mit dem ich die oben definierten Pfade einlesen lassen könnte?

... bin ja gespannt!
Hiopkamp

[klops]

Wenn die Bilder alle in Unterordnern des aktuellen Verzeichnisses liegen, genügt doch »./« statt der halben share-Hierarchie zu TEXINPUTS hinzu zu fügen. Im aktuellen Verzeichnis liegen ja hoffentlich nicht 1000 Dokumente wild durcheinander, oder hast Du so ein Chaos? Dann sehe ich ohne gründliche Neustrukturierung schwarz.

Wenn Du gerne ls-R verwenden willst, dann füge eine korrekte TDS-Hierarchie (siehe tds-Doku) via texmf.cnf zu TEXMF hinzu. Danach geht das dann mit texhash.

[hipokamp]

[...] genügt doch »./« [...] nicht 1000 Dokumente wild durcheinander, oder hast Du so ein Chaos? [...]

von "wild" möchte ich nicht gesprochen haben - alles in einem grossen Verzeichnisbaum fein säuberlich nach Themen und Unterthemen abgelegt
aber oft kommen Bilder aus verschiedenen Themen in einem neuen Doku zusammen und es ist da, wo es kompliziert wird

damit nicht die ganze /share (NTFS Partition, auf die ich auch mit Win zugreifen kann) durchsucht werden muss, habe ich mir die Sache mit dem /Biologie und dem /Data-add Pfad reingeschrieben

die texmf Geschichte muss ich in Ruhe nochmals durchdenken

[u_fischer]

Gesucht wäre eine skript-basierte Lösung, irgendein Programmding, welches mir das .tex nach Bildern (mit z.T. langen Pfadangaben) durchsucht, diese Bilder dann in einen "Export-Ordner" kopiert und das .tex (und das .bib) file dazu.

Du kannst das Skript mkjobtexmf versuchen. Es basiert auf der --recorder-Option von pdftex. Aber es kann nicht Dateien erfassen, die – wie die bib-Datei – von pdftex überhaupt nicht gesehen werden.