|
Hallo, ich erzeuge ein Dokument und habe folgende Ausgangssituation. \documentclass[10pt,a4paper]{article} \usepackage{longtable} \newcommand{\row}[9]{#1 & #2 & #3 & #4 & #5 & #6 & #7 & #8 & #9 \\ } %Tabellenzeile (Tag, Art, Kommen, Gehen, Kommen, Gehen, Std., Tage, Projekt \newenvironment{timesheet}[1] {\begin{longtable}{lllllllll} \multicolumn{2}{c}{} & \multicolumn{2}{c}{Arbeitszeit}& \multicolumn{2}{c}{Pausenzeit} \\[2ex] Tag & Art & Kommen & Gehen & Kommen & Gehen & Std & Tage & Projekt \\[2ex] \endhead \row{Freitag, 01.05.2015}{U}{08:00}{17:00}{12:00}{13:00}{8,00}{1,00}{BMW} \hline }{\end{longtable}} \begin{document} \begin{timesheet} \end{timesheet} \end{document} Ich bekomme die Daten für row von einem anderen Programm übergeben, allerdings werden wie bei "Tag" zu sehen, der Wochentag und das Datum gemeinsam kommasepariert in einem Parameter übergeben. Ich würde gern wissen, wie ich diese nun trennen und in einzelnen Spalten (Tag UND Datum) darstellen? Sollte etwas nicht verständlich sein, bitte gern fragen. :)
Ergebnis 5 von 15
show 10 more comments
|
|
Allgemein kann man Argumente auch als delimited arguments, also als Argumente mit einem Begrenzer definieren. Das geht allerdings nicht auf LaTeX-Ebene, sondern nur auf TeX-Ebene: \documentclass{standalone} \makeatletter \newcommand*\TagUndDatum[1]{\expandafter\@TagUndDatum#1\@nil} \newcommand*\@TagUndDatum{}% sichergehen, dass nichts umdefiniert wird \def\@TagUndDatum#1,#2\@nil{Argument 1: #1, Argument 2: #2} \makeatother \begin{document} \TagUndDatum{Freitag, 01.05.2015} \makeatother \end{document} Schaut man ganz genau hin, dann ist hier allerdings am Anfang von Argument 2 noch ein zusätzliches Leerzeichen. Das kommt daher, dass eben im Argument nach dem Komma auch noch ein solches steht. Um das los zu werden, muss man es zum Teil der Begrenzung des ersten Argument machen von \documentclass{standalone} \makeatletter \newcommand*\TagUndDatum[1]{\expandafter\@TagUndDatum#1\@nil} \newcommand*\@TagUndDatum{}% sichergehen, dass nichts umdefiniert wird \def\@TagUndDatum#1, #2\@nil{Argument 1: #1, Argument 2: #2} \makeatother \begin{document} \TagUndDatum{Freitag, 01.05.2015} \end{document} Dann muss allerdings auch sichergestellt sein, dass dieses Leerzeichen immer vorhanden ist. Sollte man das nicht sicherstellen können, so kann man beispielsweise \documentclass{article} \usepackage{xstring} \makeatletter \newcommand*\TagUndDatum[1]{\expandafter\@TagUndDatum#1\@nil} \newcommand*\@TagUndDatum{}% sichergehen, dass nichts umdefiniert wird \def\@TagUndDatum#1,#2\@nil{Argument 1: #1, Argument 2: \IfBeginWith{#2}{ }{\StrGobbleLeft{#2}{1}}{#2}} \makeatother \begin{document} \TagUndDatum{Freitag, 01.05.2015} \TagUndDatum{Freitag,01.05.2015} \end{document} Das Paket bietet übrigens auch selbst bereits eine Möglichkeit, Strings anhand anderer Strings (beispielsweise einem Komma) zu unterteilen. Näheres dazu verrät die Anleitung. \documentclass{standalone} \usepackage{xstring} \newcommand*\TagUndDatum[1]{\StrSubstitute{#1}{, }{&}} \begin{document} \begin{tabular}{ll} \TagUndDatum{Freitag, 01.05.2015}\\ \end{tabular} \end{document} Was hier im einfachen Beispiel funktioniert, kann bei komplexeren Anwendungen allerdings auch schon einmal problematisch werden und zu noalign-Fehlern führen. @saputello, könntest Du mir vielleicht noch erklären, was genau der Befehl @nil in Deinem ersten Beispiel macht?!
(25 Sep '15, 12:12)
Snoopy EL
@Snoopy EL: Genau dasselbe wie das Komma bzw. das Komma gefolgt von einem Leerzeichen: Es begrenzt das Argument, in dem Fall nach hinten. Ohne das, wäre
(25 Sep '15, 12:39)
saputello
|
Wenn Du schon danach fragst: Warum kann das Programm die
\row-Anweisung nicht direkt als Tabellenzeile mit&als Spaltentrenner erzeugen? Das wäre doch die einfachste Lösung.Warum wird ein Umgebung definiert, die gar keinen Inhalt hat, statt die
\row-Anweisungen (oder direkt die Tabellenzeilen) als Inhalt einer Umgebung (sei es eine entsprechend definiertetimesheetoder ein allgemeinere Tabelle) zu verwenden?Dein Beispiel ist doch Quatsch. Du definierst row mit 9 Argumenten und benutzt dann nur 6. Und die Tabelle hat mit der Frage gar nichts zu tun. Nur wer deine früheren Fragen gesehen hat, versteht vielleicht was das soll. Warum investierst du nicht ein paar Minuten und machst ein besseres Beispiel?
Saputello, ich muss die Daten so in eine Tabellenzeile verpacken, dass später die Darstellung auch noch veränderbar ist. Die einzelnen Werte stehen zwar fest, aber wir geben jetzt erstmal vor, sie in einer Tabelle darzustellen, es kann aber sein, dass jemand das später anders haben möchte. Deshalb definiere ich die Anweisung mitsamt Spaltentrenner bereits im newcommand.
Vielleicht versteif ich mich gerade zu sehr auf mein Beispiel und auf das, was ich schon so probiert habe und es gibt einen viel besseren Ansatz, den ich nur nicht sehe... :-(
Du verwendest aber gerade kein
\newcommand, sondern völlig unsinnig ein\newenvironment. Ich habe deshalb die Frage etwas allgemeiner aufgefasst und entsprechend beantwortet. Dass das u. U. gar keine Tabelle werden soll, wäre ein Grund mehr, das Problem allgemeiner anzugehen. Auch dann wäre es sinnvoller,\rowin die Umgebung (statt in ihre Definition) zu schreiben und eben ggf. die Umgebung anders zu definieren. Dabei würde dann ggf. auch die Umgebung die Definition von\rowvorgeben. So wie jetzt ist es wirklich nicht sinnvoll!Vielleicht versteh ich Dich falsch oder meinen Code, aber ich definiere doch über das newcommand die row und definiere dann per newenvironment die Umgebung in der row dann verwendet werden soll, in diesem Fall eben die longtable.
Oder bin ich jetzt völlig auf dem falschen Dampfer und hab das Prinzip einfach noch nicht verstanden..?? :-(
Ja, Du hast das Prinzip nicht verstanden. Umgebungen definiert man dann, wenn deren Inhalt, also das zwischen
\begin{foo}und\end{foo}in spezieller Weise formatiert werden soll. Du hast aber gar keinen Inhalt intimesheet. Damit ist es unsinnig an der Stelle eine Umgebung zu verwenden!Okay, soweit kann ich Dir folgen und es klingt so, als wäre es genau das, was ich ja machen will mit den Daten, die ich von extern bekomme. Könntest Du mir dafür einen besseren Ansatz verraten oder bräuchtst Du dafür mehr Infos...?! Ich will mich hier einfach nicht noch mehr verzetteln, nachher weiss ich gar nicht mehr weiter, auch wenn ihr mir hier echt schon super geholfen habt, bei dem ein oder anderen Problem. :)
Ich habe Dir bereits im zweiten Beispiel einer meiner Antworten auf Deine andere Frage zu dem Thema gezeigt, wie man eine Umgebung richtig einsetzt. Du kannst dort statt der einzelnen Befehle für jede Spalte auch einen Befehl einsetzen, der die ganze Zeile generiert. Ein entsprechendes Beispiel habe ich nun in der zweiten Antwort zum Verständnis noch ergänzt. Wobei das, wie mehrfach erwähnt, nicht ideal wäre und bei komplexeren Befehlen auch einmal daneben geht.
Mir ist übrigens gerade noch ein Fehler in Deinem Code aufgefallen.
timesheetwird bei Dir als Umgebung mit einem obligatorischen Argument definiert. Du verwendest aber gar kein Argument beim Aufruf. Das passt nicht zusammen! Vielleicht solltest Du Dich einmal etwas grundlegender mit den Prinzipien von LaTeX und der Definition eigener Befehle und Umgebungen befassen. Für so etwas reicht eine Kurzeinführung eher nicht. Manche ausführliche Einführung behandelt das wenigstens etwas.Ich verstehe dich nicht. Warum benutzt du erzeugst du nicht eine normale csv-Datei aus deinen Daten und benutzt dann datatool?
Ulrike Fischer: Das ist ja nett gemeint, mit der Idee einer CSV-Datei, aber dafür reicht mein Wissen dann doch nicht. Ich denke ich werde saputellos Rat befolgen, mich noch einmal in Ruhe mit dem ganzen Thema befassen und nochmal ganz von vorn anfangen. Trotzdem danke für Eure Hilfe!
@Snoopy EL: Wenn Du andere Leute als den Verfasser der Frage oder Antwort direkt ansprechen willst, solltest Du den
@Operator verwenden und beispielsweise @Snoopy EL schreiben.Zum Thema
datatoolgibt es bereits einige Beiträge hier auf TeXWelt.@Snoopy EL: Wissen kann man sich aneignen. datatool hat eine Dokumentation mit diversen Beispielen.
@Ulrike Fischer, nach Rücksprache mit Kollegen ist die CSV-Variante keine Alternative für uns.
Ich habe ja stark den Verdacht, dass die Kollegen einfach zu faul sind, einen Report/Export zu erstellen, der die Daten so liefert, wie sie für Dich günstig wären. Stattdessen laden sie die Arbeit, die Daten nachträglich so umzuformen, wie sie benötigt werden, auf das Satzbackend und denjenigen ab, der das programmieren soll. Das ist zwar verständlich, aber in der Tat nicht wirklich sinnvoll. Ulrikes Anregung mit CSV und
datatoolist dabei bereits ein Kompromiss, allerdings ein sehr guter, da er sehr universell ist. Er bietet u. a. die Möglichkeit nur die gewünschten Felder auszugeben.