Sie sind hier

\DeclareNewLayer Option: contents verträgt kein \par (mehr)?

Hallo allerseits,

da kommt man aus'm Urlaub, macht nichtsahnend - ja, ich steht zu meiner Ahnungslosigkeit - ein texlive2018-Update und schon ist die Erholung, bzw. die fehlerfreie LaTeX-Übersetzung dahin ... ;-) Nicht dass ich dafür das zwischenzeitliche Komascript-Paket-Update unbedingt verantwortlich machen würde (es wurden diverse Pakete aktualisiert), es handelt sich eher um einen leisen Anfangsverdacht. Vielleicht benutze ich scrlayer auch ohne Sinn und Verstand, d.h. entgegen der Spezifikation.

Wie dem auch sei, vor dem 20.12.2018 funktionierte der folgende Code. Heute verursacht dieser die Fehlermeldung: "! Paragraph ended before \scr@sp@def was complete."

Kommentiere ich die Zeile "\par%", läuft's fehlerfrei durch, nur funktioniert dann natürlich die Zentrierung des Inhalts nicht.

\documentclass{scrartcl} 
 
\usepackage{scrlayer}
 
\DeclareNewLayer[%
	background,
	align=tl,
	width=\textwidth,
	height=\textheight,
	contents={%
		{\centering
			huhu%
			\par%
		}%<-\centering
	},
]{someLayer}
 
\DeclareNewPageStyleByLayers{customPageStyle}{%
	someLayer,%
}
\pagestyle{customPageStyle}
 
 
\begin{document} 
Hello World!
\end{document}

Ich würde mich sehr freuen, wenn mir jemand von Euch einen Tipp geben könnte, wie sich der Inhalt von content="" fehlerfrei zentrieren lässt - downgraden würde ich ungern.

Vielen Dank im Voraus und - in der Hoffnung, dass es dafür noch nicht zu spät ist - ein glückliches neues LaTeX-Jahr Euch allen!

miniMAX

forum: 
Bild von Markus Kohm

In der Tat ist das ein Bug. Als Workaround kannst Du ausnahmsweise \\ statt \par verwenden. Eine generelle Lösung ist das aber nicht, sondern beschränkt auf den gezeigten Fall.

Zu weiteren Möglichkeiten siehe auch die List bekannter Fehler in scrbase v3.26a.

Der Fehler war übrigens bereits seit Ende Oktober in der Prerelease von KOMA-Script 3.26. Ein Zeichen, dass ein paar mehr Beta-Tester, die sich die veröffentlichten Prereleases anschauen, gut wären. Dort sind Änderungen in dringenden Fällen übrigens innerhalb von Stunden verfügbar, während eine neue Release auf CTAN in TeX Live und in MiKTeX min. einige Tage benötigt.

vielen Dank für Deine schnelle Reaktion, den Workaround und die Aktualisierung Deiner Paketquellen.

Ich habe diesen Bug zum Anlass genommen, Deine Paketquellen dauerhaft in meine tl-2018-Umgebung einzubinden: Nach dem abschließenden "tlmgr install --reinstall koma-script" funktioniert's wie eh und je - Danke sehr!

Gehe ich richtig in der Annahme, dass ich, wenn ich zukünftig ein "tlmgr update --all" befehle, automatisch auch Dein Repository herangezogen wird? Oder gibt's dafür einen extra Aufruf? Bin ich damit jetzt Beta-Tester, oder gibt's dafür noch ein anderes Repository?

Bild von Markus Kohm

Ja, wenn Du das Pinning wie beschrieben vorgenommen hast, dann wird jetzt koma-script dauerhaft aus dem KOMA-Repository bezogen und von dort aktualisiert – so lange, bis Du das Pinning wieder entfernst. Dann wird automatisch wieder das TeX-Live-Repository verwendet.

Es gibt auch noch ganz wenige Beta-Tester, die KOMA-Script selbst aus den Paketquellen des Subversion-Repositories auf SourceForge erzeugen. Vor ein paar Jahren waren das noch fünf oder sechs Anwender. Derzeit weiß ich noch von zwei. Wieviele Leute die Prereleases verwenden, entzieht sich mir hingegen. Da wird nichts protokolliert, also kann ich nicht einmal schätzen. Es gibt nur die Umfrage (siehe Spalte links), die sicher nicht sehr genau ist.

1. dafür diesen zurecht erledigten Thread zu missbrauchen (ich darf leider keinen neuen Thread eröffnen),
2. dafür, dass ich entgegen meinem obigen Versprechen die Updaterei dennoch habe schleifen lassen und
3. dafür, dass ich mit KOMA initial möglicherweise den falschen Adressaten als Problemverursacher verdächtige

Ich hoffe dennoch - zumindest kurz - Gehör zu finden, ...

... denn seit meinem jüngsten Update (TL2020, KOMA aus KOMA-Repository; pinned) habe ich wieder Schwierigkeiten mit der scrlayer-contents-Option (wenn auch nicht die selben wie oben).

Daher würde ich mich sehr freuen das Problem in einem - neuen? - Thread näher schildern zu dürfen. Vielen Dank!

Um was es grob geht:
Ich benutze - missbrauche? - scrlayer um einen Buchumschlag zu gestalten. Das funktioniert[e] - von obigem Bug abgesehen - bis zum jüngsten Update tadellos. Das Problem ist nicht das Handling, bzw. die Anordnung der Layer!
Mir scheint's als übersprechen/überschreiben sich neuerdings die "contents-" Inhalte (tikz-picture; eines pro layer) über Layergrenzen hinweg.
Ich habe ein [M]WE an dem sich das Verhalten demonstrieren lässt. Was ich mir davon verspreche:
Ich hätte zunächst gerne eine Einschätzung, ob ich hinsichtlich einer Lösung/eines Workaround hier richtig bin oder mich anderweitig umschauen sollte.
Disclaimer: Bin leider immer noch kein Latex-Guru. Was ich allerdings weiß: Mein Code funktionierte die letzten 1,5 Jahre. Evtl. funktionierte der Code bisher nur zufällig [wegen eines jüngst in KOMA behobenen Bugs]?

Bild von Markus Kohm

Es gab noch nie einen Mechanismus, um zu verhindern, dass der Inhalt eines Layers die Layergrenzen verlässt. Dagegen kennt beispielsweise TikZ durchaus Clipping.

Und es gibt einen guten Grund, warum nur sehr wenige Benutzer neue Threads anlegen können. Offenbar wird es Zeit, auch neue Kommentare deutlich einzuschränken.

Vermeintliche Bugs können natürlich weiterhin direkt an die Bug-Report-Adresse aus der Anleitung gemeldet werden (wobei ich mit Meldungen ohne Minimalbeispiel ohnehin nichts anfangen kann). Wann immer ich Zeit habe, schaue ich mir aber auch die KOMA-Script-Sektion auf goLaTeX an.

Comments for "\DeclareNewLayer Option: contents verträgt kein \par (mehr)?" abonnieren