Ilaris IlarisTex - Eine weitere Latex Ilaris Klasse

[Kapaneus]

Ich finde die Idee ziemlich geil und denke: Wer sie nicht mag, muss sie nicht nutzen. Ich würde sie in die LaTeX-Klasse aufnehmen. Ich persönlich kann mir auch sehr gut Fälle vorstellen, wo ich das Gerüst nicht nutzen möchte, aber um einfache Proben zu vereinheitlichen, halte ich den Vorschlag für sehr brauchbar! Für den Meister deutlich übersichtlicher als das, was ich bisher in Abenteuern gesehen habe.

Die Fragen, die offen bleiben, sind für mich nur technischer Natur: Soll das floaten, wie sieht das im Text aus, wenn's nicht floaten darf ...

[Lukr]

Wie sieht's aus: Könntest du dein Probenkästen mit den Fertigkeits-Symbolen noch auf die Attribute erweitern? Symbole gibt es ja - wenn auch nicht ganz so schick - in Verbindung mit den Vorteilen

Ist das noch aktuell, oder nimmst du eh neue Probenkästen?

Außerdem wäre es auch nicht schlecht, "verbergen.png" in "heimlichkeit.png" und "metallbearbeitung.png" in "handwerk.png" umzubenennen, damit es wieder mit dem Regelbuch übereinstimmt.

Erledigt.

Eine Grundidee ist, das vertraute zweispaltige Layout aufzugeben, um Platz für Proben mit "doppeltem Ausgang" zu gewinnen.
Dabei würde ich jedoch im Fließtext die Informationen zur Gestaltung einer Szene und Meta-Informationen (Regelverweise, Kommentare, etc.) trennen. Das mag an die "Speziellen Informationen" und "Meisterinformationen" erinnern... Ich will diese jedoch grundsätzlich nebeneinander anordnen.

Wow! Die Vorschau sieht echt cool aus. Notecolumn hab ich noch nie benutzt, aber wenn es damit gut anzuordnen ist, why not. Den meisten deiner Punkte (bzgl. Anforderungen an eine Probe im Probenkasten), stimme ich so zu. Was mir allerdings in der Aufzählung fehlt sind Recherche-Proben im weitesten Sinne. Bei denen gibt es ja nicht umbedingt ein JA/NEIN Ergebnis, sondern eher mehrere Fakten, aber dafür könntne ja auch entsprechend angepasste Probenkästen ergänzt werden.

Am liebsten würd ich mich sofort hinsetzen und eine zweite Dokumentenklasse ergänzen, aber ich hab jetzt schon zu wenig Zeit und noch viele TODOs. Dennoch fänd ichs cool sie in irgendeiner Form im selben Projekt unterzubringen um nicht alle Arbeit doppelt zu machen. Ich weiß nicht was da der cleverste Ansatz wäre:
- eine Ilaris-Klasse als Basis zu pflegen und dann einzelne, dokumentspezifische Klassen, davon erben zu lassen (falls sowas in Latex gut funktioniert)
- zwei einzelne Klassen schreiben die beide häufig benutzte Befehle aus einer gemeinsamen .tex file importieren
- Eine Ilaris-Klasse behalten, die durch unterschiedliche Befehle/Variablen in der Lage ist unterschiedliche Layouts zu produzieren (es kann ja auch gut sein, dass man 10 Seiten so und den Anhang aber anders haben will)

Vielleicht wäre letzteres das einfachste um erstmal mit dem zu arbeiten was wir haben, trennen kann man es später immernoch.

[Lukr]

Ich versuche gerne zu helfen, wo ich kann. Ich bin zwar ziemlich erfahren mit LaTeX, bislang aber als reiner "Anwender". Mit dem Schreiben eigener Klassen habe ich mich noch nicht befasst.

Was ich mal machen könnte, wäre zu versuchen das Ilaris Layout mit KOMA-Script Mitteln (und ggf. noch einigen anderen Paketen) nachzubauen. Vom ersten Eindruck her sollte das eigentlich keine größeren Schwierigkeiten machen (bis vlt. auf Fonts ...). Das ergäbe dann einfach eine Muster-TeX-Datei. Die enthält dann natürlich "den ganzen frickeligen Code", wie du ihn nennst. Aber vielleicht kann man daraus dann Dinge in die Klasse übernehmen?

(Wenn ich mir "Klassen" erstelle für den Eigenbedarf, dann erschaffe ich dazu einfach eine separate .tex Datei mit all den Pakten, Definitionen, etc. die ich brauche und die lade ich dann mittels \include. Eine richtige Klasse ist aber natürlich schöner).

Hey @pmd sorry ich bin da garnicht mehr wirklich drauf eingegangen, da ich nur am Handy war. Im Prinzip bin ich zuerst genau so vorgegangen, bis ich einige Befehle ersetzt und die Datei von .tex in .cls umbenannt habe. (im wesentlichen nur die Definition der Klasse und \usepackage in \RequirePackage umbenannt ). Wenn du in die ilaris.cls schaust siehst du ab ca Zeile 80 nur eine Sammlung von ganz normalen Latex Befehlen und Umgebungen. Die Klasse selbst basiert auf der Koma-Klasse (spricht man bei Latex dabei schon von vererben?), das heisst sowohl in der .cls als auch in der .tex die sie benutzt kann man alle möglichen Koma-Befehle regulär benutzen, sofern sie nicht überschrieben wurden (was ich durch deutsche Befehle zu vermeiden versuche). Falls du/ihr keine GitHub-User seid, sollte es das Einfachste sein, in der template.tex (oder irgendner anderen Datei) neue Befehle zu ergänzen oder welche aus der Klasse zu überschreiben. Alles was davon nützlich für andere sein könnte kann dann gern hier oder per Discord geteilt werden und ich füge es ein.

Ich bin am Anfang nicht davon ausgegangen, das die Vorlage direkt so gut angenommen wird, das freut mich sehr und sollte mich jetzt echt mal beflügeln, das Template und eine vernünftige Dokumentation der Befehle fertig zu machen .

[Alrik Normalpaktierer]

Wie sieht's aus: Könntest du dein Probenkästen mit den Fertigkeits-Symbolen noch auf die Attribute erweitern? Symbole gibt es ja - wenn auch nicht ganz so schick - in Verbindung mit den Vorteilen

Ist das noch aktuell, oder nimmst du eh neue Probenkästen?

Hängt davon ab, wie weit wir mit der LaTeX-Klasse kommen, bevor ich in den Wettbewerbs-Band eine Nadel reinmache. In den Wettbewerbs-Abenteuern gibt es Attributproben, da wäre eine kohärente Darstellungsmöglichkeit natürlich klasse.
Ich glaube aber, im Notfall würde ich das grafisch doch hinkriegen Konzentriere du dich erstmal auf anderes...

Was mir allerdings in der Aufzählung fehlt sind Recherche-Proben im weitesten Sinne. Bei denen gibt es ja nicht umbedingt ein JA/NEIN Ergebnis, sondern eher mehrere Fakten, aber dafür könntne ja auch entsprechend angepasste Probenkästen ergänzt werden.

Da hast du völlig recht! Ich habe die Rededuelle genannt, aber Recherchen/Ermittlungen bräuchten ebenfalls eigene Formate, die auf der "Grundprobe" basieren. Das werde ich oben ergänzen.

- Eine Ilaris-Klasse behalten, die durch unterschiedliche Befehle/Variablen in der Lage ist unterschiedliche Layouts zu produzieren (es kann ja auch gut sein, dass man 10 Seiten so und den Anhang aber anders haben will)

Scheint mir ein gangbarer Weg. Ich bin kein so großer LaTeX-Fex, aber ich sehe nicht, wo da Probleme herkommen sollen. Wir bleiben ja immer in der KOMA-Welt. Also warum sollte es nicht neben \spaltenanfang auch \marginalspaltenanfang geben können, die ein (schmaleres) einspaltiges Layout nebst Marginalspalten aktiviert?

[Alrik Normalpaktierer]

Erste Erfahrungen mit 0.0.8:

Schriftenproblem sieht für mich gelöst aus. Ich bekomme noch folgende

FehlermeldungenShow

Please consider loading "fourier-otf.sty" instead of(fourier) "fourier.sty" with Unicode engines LuaTeX or XeTeX,(fourier) so that Type1 fonts get replaced by OpenType fonts.
Functionality similar to this package has recently(everypage) been implemented in LaTeX. This package is now in(everypage) legacy status.
You appear to be running a version of LaTeX(everypage) providing the new functionality.
Font shape `TU/CrimsonPro-Regular.ttf(1)/b/n' undefined(Font) using `TU/CrimsonPro-Regular.ttf(1)/m/n' instead
Font shape `TU/Aniron-Bold.ttf(0)/b/n' undefined(Font) using `TU/Aniron-Bold.ttf(0)/m/n' instead
Font shape `TU/cormorant.sc-bold.otf(0)/b/n' undefined(Font) using `TU/cormorant.sc-bold.otf(0)/m/n' instead
Font shape `TU/CrimsonPro-Regular.ttf(0)/m/sc' undefined(Font) using `TU/CrimsonPro-Regular.ttf(0)/m/n' instead
Font shape `TU/cormorant.sc-bold.otf(0)/m/sc' undefined(Font) using `TU/cormorant.sc-bold.otf(0)/m/n' instead

, erkenne aber ehrlich gesagt an der Ausgabe nicht, wo das konkret etwas ändern würde.

\link bricht wegen der uline-mbox nicht vernünftig um. Falls noch nicht geschehen, kannst du die von mir korrigierte Definition oben verwenden.

Für die Einbindung externer PDFs (hier Charakterbögen) habe ich das Package pdfpages geladen. (Die Charakterbögen werden leider ohne die Formularwerte - also leer - geladen. Das ist aber nicht der Fehler der LaTeX-Klasse. Genausowenig die resultierende Dateigröße von 60 MB.)

[Lukr]

Please consider loading "fourier-otf.sty" instead of(fourier) "fourier.sty" with Unicode engines LuaTeX or XeTeX,(fourier) so that Type1 fonts get replaced by OpenType fonts.

Die Warnung bekomme ich auch. Habe mich auch mal kurz eingelesen und auch probiert fourier-otf.sty zu benutzen, dann bekomme ich stattdessen andere (mehr) warnungen und es hat nichts geändert, daher hab ich mich einfach damit abgefunden. Man kann die Warnung bestimmt auch irgendwie ignorierne, sollte aber keinen Einfluss auf die Funktionalität haben. Bei den Schriftarten muss ich glaub ich die Schriftart nochmal explizit für alle font-styles angeben, damit die verschwinden. \link hab ich glaub ich deinen schon drin, sollte dann beim nächsten release (wenn ich schaffe sonntag) auch gehen.

[Galjan]

Hab' die Klasse jetzt mal mit MiKTeX unter Windows verwendet. Geht nach Überwindung der Einstiegshürde gut, insbesondere durch das Template, welches Anleitung und Beispiel kombiniert. Was mir auffiel:

• Es funktioniert nur mit XeLaTeX, LuaLaTeX macht den Hintergrund manchmal nicht richtig und pdflatex wird von einem Paket nicht unterstützt
• Das \schluss war nötig, damit zuverlässig richtig gesetzt wird
• Die 8 Karten wurden mit \handout drumherum auf 2 Seiten verteilt, ohne \handout sogar auf 3 Seiten. Eigentlich sieht's so aus, als müssten bis zu 9 Karten auf eine Seite passen. Dabei gibt's auch eine Nachricht bezüglich einer underfull \vbox.
• Ein paar font shapes waren nicht verfügbar, es gab aber anscheinend sinnvollen Ersatz.

[Lukr]

Die Umbrüche zwischen den Karten sind tatsächlich etwas unnötig und ich kann auch nochmal ein Beispiel hochladen, wie man das umgehen kann. Die Karten waren nur so auf die schnelle eingebaut und auch der \handout befehl macht noch nicht ganz was er soll.

Auf XeLaTex würd ich es erstmal begrenzen mit dem Support allein schon wegen der Schriftarten. Eventuell kann man irgendwann schauen, auch die anderen Compiler zu unterstützen.

Ich werd zusehen, dass ich bald die Anleitung etwas überarbeite sodass die Einstiegshürde möglichst niedrig ist. Danke fürs Feedback!