Feature #13827
offenAuswertung des TeX-Protokolls
Von Maren Pufe vor etwa 2 Jahren hinzugefügt. Vor fast 2 Jahren aktualisiert.
0%
Beschreibung
Einige Probleme sollten in Zukunft aus dem Log des TeX-Laufs ausgelesen werden, um dem Nutzer besseres Feedback über Probleme geben zu können.
In diesem Ticket werden solche Probleme gesammelt.
- fehlende Glyphen
- fehlende Sprungziele (#14104)
Dateien
| vr_SB_525-56737_Ferrari.neu-report.xhtml (3,33 MB) vr_SB_525-56737_Ferrari.neu-report.xhtml | Fränze Gramsch, 20.01.2023 15:09 | ||
| vr_SB_525-56737_Ferrari.log (192 KB) vr_SB_525-56737_Ferrari.log | Fränze Gramsch, 20.01.2023 15:09 |
Von Fränze Gramsch vor fast 2 Jahren aktualisiert
- Status wurde von Neu zu In Bearbeitung geändert
- Zugewiesen an wurde auf Fränze Gramsch gesetzt
Wir haben mal unterschiedliche Möglichkeiten diskutiert:
Möglichkeit 1:
Nach der Konvertierung und dem anschließenden TeX-Rendering wird die erstellte Log-Datei in eine neue Pipeline gekippt, die dann die Fehlermeldungen vom TeX-Lauf analysiert und in eine neue Ausgabe bringt: entweder eine besser lesbare Text-Datei oder man versucht die ausgelesenen Fehler recht dirty an den vorher produzierten HTML-Report ranzupatchen.
Möglichkeit 2:
Man macht direkt in der Konvertierungspipeline in xml2tex einen ersten Probe-TeX-Lauf (mit p:exec) und verarbeitet dort dann direkt das entstandene Log-File und konvertiert die Meldungen nach SVRL um sie dann direkt in den HTML-Report zu patchen.
Egal welche Variante man wählt, müsste man mal analysieren welche Probleme/Warnungen das TeX-Log auspuckt, die dann für den Nutzer sinnvoll sind.
Mögliche Einschränkung bei Möglichkeit 2: Die Seitenzahlen verändern sich ja beim Umbruch ziemlich: Ergibt es dann Sinn, die Seitenzahlen, die beim ersten "Probe-"Lauf erzeugt werden, dem Nutzer auszugeben, wenn sie am Ende im fertig gerenderten TeX ganz anders sind?
Stand jetzt: Leichte Tendenz zu Möglichkeit 1
Von Patrick Schulz vor fast 2 Jahren aktualisiert
Wenn ich mich hier kurz einschalten darf; Die zweite Möglichkeit wäre suboptimal, weil einige potenzielle Fehler in den tex-log-Dateien erst nach einem wiederholten TeX-Lauf entstehen: Dynamische Textteile (Bookmarks, IHV, Tabellen- und Abbildungsverzeichnisse etc.) werden beim ersten TeX-Lauf generiert und erst bei den nachfolgenden Läufen mit eingelesen. Wenn da dann irgendwelche Fehler drin sind, würdet ihr die bei der Variante nicht mitkriegen.
Von Fränze Gramsch vor fast 2 Jahren aktualisiert
Ich habe gerade mal wieder angefangen, eine Pipeline zu schreiben, die das Log analysiert. Was aber ein bisschen blöd ist: Die Zeilen im Log umbrechen ja, wie z.B.
! Package luatex.def Error: File `../images/rgb/vr_SB_525-56737_Leshem_fig01.rg b.jpg' not found: using draft setting. See the luatex.def package documentation for explanation. Type H <return> for immediate help.
Gibt's da vielleicht eine Möglichkeit dem Renderer mitzugeben, dass dieses Log nicht umbrechen soll?
Von Fränze Gramsch vor fast 2 Jahren aktualisiert
Oder bringt uns vielleicht auch sowas weiter:
https://www.ctan.org/pkg/texlogfilter
?
Oder könnte man direkt im TeX-Lauf ein weiteres aux-file schreiben, das schon eine gewisse Filterung von Fehlern/Problemen vornimmt? Das könnte man dann per XProc einlesen und als <c:errors> Dokument (und später eigenen HTML-Report?) generieren?
Von Patrick Schulz vor fast 2 Jahren aktualisiert
Du kannst dem latex-Lauf einen Parameter max_print_line voranstellen, mit dem sich die Breite der shell- und log-Ausgabe festlegen lässt, z.B:
max_print_line=999 lualatex <filename>.tex
Von Fränze Gramsch vor fast 2 Jahren aktualisiert
- Datei vr_SB_525-56737_Ferrari.neu-report.xhtml vr_SB_525-56737_Ferrari.neu-report.xhtml wurde hinzugefügt
- Datei vr_SB_525-56737_Ferrari.log vr_SB_525-56737_Ferrari.log wurde hinzugefügt
Ahja, das hat mir schon mal gut weitergeholfen, vielen Dank!
Ich habe hier mal eine Pipeline geschrieben, die also das Log und den ursprünglich generierten HTML-Report nimmt und die Fehler und Warnings ein bisschen filtert und dann wieder an den HTML-Report patched.
Alles noch nicht perfekt, da könnte/müsste man noch einiges verbessern.
Aber seht es euch gern mal an und sagt mir, wie sinnvoll ihr das so findet. Leider ist es auch mit der Seitenzahl nicht immer ganz so einfach, weil die ja auch im log nicht so super steht. Zusätzlich müsste man wahrscheinlich auch den Fehlertext komplett umschreiben, damit es dem Nutzer etwas bringt?
Also als Proof-of-Concept Okay, aber wirklich sinnvoll in der Anwendung? Ich bin noch unschlüssig