Unterstützung #428
alte/falsche Tabellen in LaTex-Vorlagen, die package filecontents u. lxtable verwenden
0%
Beschreibung
Einige Vorlagen (Kundeninstallationen, f-tex) verwenden ltxtable mit filecontents. Die Umgebung filecontents gibt es sowohl in Core-LaTex, als auch als Paket. Bisher hatte die Version im Core-LaTeX die Einschränkung, dass bestehende Dateien mit filecontents nicht überschrieben wurden. Deshalb wird an dieser Stelle die Umgebung aus dem Paket (\usepackage{filecontents}) verwendet, die diese Einschränkung nicht hat.
Seit LaTeX 2019 kann auch die Core-Umgebung Dateien neu erstellen, allerdings muss man dann die Option [overwrite] angeben. Das Paket gibt es immer noch, allerdings prüft es ab Version 1.5, ob die Core-Umgebung in der neuen Version vorhanden ist und verwendet dann diese.
Das führt dazu, dass z.B. bei Ubuntu 20.04 eben die Tabellen nicht neu geschrieben werden. Man hat z.B. dann ein aktuelles Angebot mit einer Tabellen aus einem anderen Beleg.
Leider kann die Paket-Version vor 1.5 kein [overwrite], so dass man es nicht einfach angeben kann, möchte man, dass die Vorlagen auf sowohl einem "neuen" (z.B. Test/Entwicklersystem), als auch einem "alten" laufen.
Ich wollte da hier nur mal festhalten - muss man eben dran denken, wenn man das OS upgraded. Wenn jmd. eine Idee für das Problem mit gleichzeitig "neu" und "alt" hat, wäre das natürlich auch gut.
(siehe auch https://www.ctan.org/pkg/filecontents, https://tex.stackexchange.com/questions/511502/filecontents-this-package-is-obsolete und http://mirrors.ctan.org/macros/latex/base/ltnews30.pdf)
Historie
Von Moritz Bunkus vor fast 4 Jahren aktualisiert
Aus einem ähnlichen Grund1 hatte ich den kompletten Druck-Mechanismus so umgestellt, dass er nicht mehr direkt in …/users arbeitet, sondern in einem temporären Unterverzeichnis davon, sprich pro Druckjob ein Unterverzeichnis mit eindeutigem Namen. Damit ist's dann egal, weil das Verzeichnis vor Anfang des Druckjobs immer leer ist. Das Ganze ist in dc8ffeaa1211987d6b3e0a3f1d2c576c82584d37 in der unstable.
Somit sollte das von dir beschriebene Problem mit der aktuellen unstable nicht mehr auftreten.
1 Grund war, dass die ZUGFeRD-Sachen zwingend eine Datei mit einem festen Namen für die XMP-Metadaten anlegen, sodass mehrere gleichzeitig laufende Jobs sich die Dateien problemlos überschreiben konnten.
Von Bernd Bleßmann vor fast 4 Jahren aktualisiert
- Status wurde von Neu zu Erledigt geändert
Moritz Bunkus schrieb:
Aus einem ähnlichen Grund1 hatte ich den kompletten Druck-Mechanismus so umgestellt, dass er nicht mehr direkt in …/users arbeitet, sondern in einem temporären Unterverzeichnis davon, sprich pro Druckjob ein Unterverzeichnis mit eindeutigem Namen. Damit ist's dann egal, weil das Verzeichnis vor Anfang des Druckjobs immer leer ist. Das Ganze ist in dc8ffeaa1211987d6b3e0a3f1d2c576c82584d37 in der unstable.
Ja, damit geht es - danke.