Project

General

Profile

Actions

Feature #13827

open

Auswertung des TeX-Protokolls

Added by Maren Pufe over 1 year ago. Updated over 1 year ago.

Status:
In Bearbeitung
Priority:
Normal
Start date:
11/17/2022
Due date:
% Done:

0%

Estimated time:

Description

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)

Files

Actions #2

Updated by Maren Pufe over 1 year ago

  • Project changed from 109 to xerif
Actions #3

Updated by Fränze Gramsch over 1 year ago

  • Status changed from Neu to In Bearbeitung
  • Assignee set to Fränze Gramsch

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

Actions #4

Updated by Patrick Schulz over 1 year ago

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.

Actions #5

Updated by Fränze Gramsch over 1 year ago

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?

Actions #6

Updated by Fränze Gramsch over 1 year ago

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?

Actions #7

Updated by Patrick Schulz over 1 year ago

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

Actions #8

Updated by Fränze Gramsch over 1 year ago

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

Actions #9

Updated by Maren Pufe over 1 year ago

  • Description updated (diff)
Actions #10

Updated by Maren Pufe over 1 year ago

  • Description updated (diff)
Actions

Also available in: Atom PDF