Hilfe:Wiki/Druckversion - ein Print-CSS für unsere Seiten

- css
0 Jonathan Harker
0 Rolf B
0 Der Martin
Guten Morgen,
es gibt ja einen Bedarf Wikiseiten auszudrucken, bzw. als PDF zu speichern und zu versenden.
Bis jetzt fehlt dort ein ansprechender Seitenkopf.
Das kann man in den Spezialseiten
MediaWiki:Printheader
MediaWiki:Printfooter, Retrievedfrom
festlegen. Dabei werden (Stand heute) folgende Systemmeldungen verwendet:
Zweck | System Message(s) | Text |
---|---|---|
print header | MediaWiki:Printheader |
- |
print footer | MediaWiki:Retrievedfrom |
Abgerufen von {$1} |
site name | MediaWiki:Sitetitle |
SELFHTML-Wiki |
site slogan | MediaWiki:Tagline |
Aus SELFHTML-Wiki |
Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.
Ich bitte um weitere Vorschläge und eine lebhafte Diskussion.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.
Oder
www.selfhtml.org
Dokumentation seit 1995
Bis bald!
Jonathan
Hallo,
die URL sollte in den Footer, denke ich, zusammen mit einem QR Code der uns Wiki führt.
Rolf
Moin,
es gibt ja einen Bedarf Wikiseiten auszudrucken, bzw. als PDF zu speichern und zu versenden.
ich habe diesen Bedarf in der Regel nicht; ich speichere bzw. versende dann einfach einen Link. Aber klar, wir sollten den Wunsch da, wo er mal aufkommt, auch erfüllen können.
Zweck System Message(s) Text print header MediaWiki:Printheader
- print footer MediaWiki:Retrievedfrom
Abgerufen von {$1} site name MediaWiki:Sitetitle
SELFHTML-Wiki site slogan MediaWiki:Tagline
Aus SELFHTML-Wiki
site name und site slogan sind, so wie du sie examplarisch vorbelegt hast, eine Doppelung. Wäre als site slogan nicht unser Motto "Die Energie des Verstehens" passend?
Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.
Bitte nicht so groß, wie es hier im Forums-Post den Anschein hat. Wenn ich eine Webseite ausdrucke, möchte ich nicht einen Großteil der Print-Seite mit einem Logo oder einem aufwendig gestalteten Header "verschwenden".
Das sollte dann prominent, aber relativ klein und dezent in der Kopfzeile stehen. Gern auch auf jeder Seite eines mehrseitigen Ausdrucks wiederholt, aber mehr als etwa 2..3cm Höhe sollte das nicht einnehmen. Finde ich. YMMV.
Einen schönen Tag noch
Martin
Guten Morgen,
Zweck System Message(s) Text site name MediaWiki:Sitetitle
SELFHTML-Wiki site slogan MediaWiki:Tagline
Aus SELFHTML-Wiki site name und site slogan sind, so wie du sie examplarisch vorbelegt hast, eine Doppelung. Wäre als site slogan nicht unser Motto "Die Energie des Verstehens" passend?
Das ist der Ist-Zustand. Ein Ausdruck sieht derzeit so aus:
Und da erkennst du unterhalb der h1 die mir bisher unbekannte Tagline wieder.
Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.
Und zwar sollen die als Kopf oberhalb der h1 psoitioniert werden.
Das sollte dann prominent, aber relativ klein und dezent in der Kopfzeile stehen.
Ja.
Gern auch auf jeder Seite eines mehrseitigen Ausdrucks wiederholt, aber mehr als etwa 2..3cm Höhe sollte das nicht einnehmen. Finde ich. YMMV.
Eher nein. Weil es doch immer wieder 2-3cm sind.
Problem: In unserer Installation wird noch die nicht mit HTML füllbare Tagline verwendet; (da könnt ich das Logo und Text mit CSS reinbringen) in neueren Versionen wird das über Mediawiki:Printheader erreicht, den man zur Zeit erst mit JS einfügen müsste.
Herzliche Grüße
Matthias Scharwies
Lieber Matthias,
die Box mit der Lesedauer und dem Schwierigkeitsgrad fände ich seitlich gefloated besser, so wie sie auch in der regulären Ansicht dargestellt wird. So verbraucht sie meiner Meinung nach zu viel Platz. Aber das ist sicher eine Kleinigkeit.
Was mir gut gefällt, ist der fehlende Farbverlauf in der Druckansicht. Das spart Druckfarbe (Tinte oder Toner).
Und da erkennst du unterhalb der h1 die mir bisher unbekannte Tagline wieder.
Meinst Du den Schriftzug „Aus SELFHTML-Wiki[br]< Hilfe:Wiki“? Ja, der könnte entweder weg, oder ganz nach oben.
Ich habe die Druckansicht des Produktiv-Wikis getestet und die Hilfeseite zur Druckversion nicht gefunden. Im Test-Wiki aber schon! Dort habe ich dann diesen Screenshot machen können:
Dort im Test-Wiki beginnt der bedruckte Teil für meinen Geschmack viel zu weit unten. Auch muss meiner Meinung nach die Hauptüberschrift nicht in dieser Größe sein, sondern darf kleiner werden.
Ich würde gerne unser Logo und das Wort SELFHTML in groß und drunter einen kurzen Slogan á la „Dokumentation seit 1995“ verwenden.
Und zwar sollen die als Kopf oberhalb der h1 psoitioniert werden.
Gefällt mir! Das sollte aber nur auf der ersten Druckseite so aussehen.
Gern auch auf jeder Seite eines mehrseitigen Ausdrucks wiederholt, aber mehr als etwa 2..3cm Höhe sollte das nicht einnehmen. Finde ich. YMMV.
Eher nein. Weil es doch immer wieder 2-3cm sind.
Da stimme ich Dir zu, da dieser Platz für den zu druckenden Seiteninhalt sein sollte.
Problem: [...]Tagline
Wir „reparieren“ bereits so einiges via JavaScript (z.B. SVG), da kommt es darauf auch nicht mehr an. Wenn wir diese Tagline tatsächlich benötigen.
Liebe Grüße
Felix Riesterer
Hi,
die Box mit der Lesedauer und dem Schwierigkeitsgrad fände ich seitlich gefloated besser,
braucht man die gedruckt überhaupt?
Live sieht man schlecht, wieviel Text da kommt. Aber gedruckt sieht man doch, wie dick der Stapel Papier ist …
cu,
Andreas a/k/a MudGuard
Hallo,
die Box mit der Lesedauer und dem Schwierigkeitsgrad fände ich seitlich gefloated besser,
braucht man die gedruckt überhaupt?
Live sieht man schlecht, wieviel Text da kommt. Aber gedruckt sieht man doch, wie dick der Stapel Papier ist …
das stimmt - daran kann man abschätzen, wieviel Zeit man fürs Lesen braucht. Aber korreliert das auch mit der Zeit zum Verstehen? Manchmal. Eher selten.
Einen schönen Tag noch
Martin
Lieber Felix,
Und da erkennst du unterhalb der h1 die mir bisher unbekannte Tagline wieder.
Meinst Du den Schriftzug „Aus SELFHTML-Wiki[br]< Hilfe:Wiki“? Ja, der könnte entweder weg, oder ganz nach oben.
Das sind sogar 2 Teile: "Aus SELFHTML-Wiki" sollte durch einen besseren Text ersetzt und vor die h1 verschoben werden.
< Hilfe:Wiki
ist das Breadcrumb und sollte ausgeblendet sein!
Meine Idee, die ich die Tage im Test-Wiki ausprobieren werde: Diesen Text durch "Dokumentation seit 1995" ersetzen, ein Pseudoelement mit Logo und fetterem "SELFHTML" dazu!
Ich habe die Druckansicht des Produktiv-Wikis getestet und die Hilfeseite zur Druckversion nicht gefunden. Im Test-Wiki aber schon! Dort habe ich dann diesen Screenshot machen können:
Dort im Test-Wiki beginnt der bedruckte Teil für meinen Geschmack viel zu weit unten. Auch muss meiner Meinung nach die Hauptüberschrift nicht in dieser Größe sein, sondern darf kleiner werden.
ok!
Wir „reparieren“ bereits so einiges via JavaScript (z.B. SVG), da kommt es darauf auch nicht mehr an. Wenn wir diese Tagline tatsächlich benötigen.
In dieser Version ja, in neueren fällt die raus und wird durch Mediawiki:Printheader ersetzt, der sogar html enthalten kann und dann Pseudoelemente obsolet macht.
Wenn man jetzt wüsste, wie lange man die alte Version noch pflegen muss.
BTW: Der Link "Druckversion" links in der Sidebar lädt nicht das Print-Stylesheet:
https://wiki-test.selfhtml.org/index.php?title=Hilfe:Wiki/Druckversion&printable=yes
→ Weg damit!
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
bevor Du alles auf den Kopf stellst und Dir die Finger brichst, sollten wir vielleicht mal über /skins/Selfhtml/skin.json drüberschauen, in wie weit dort Laderegeln stören oder helfen können. Da kann man nämlich relativ feingranular einstellen, welche Ressourcen für Screen oder für Print sind. Der korrekte Weg ist, dass wir unser Content-Stylesheet daraufhin überprüfen, was Screen-only ist und was für Print+Screen gemeinsam gebraucht wird. Und dann drei Teile haben: Common, Screen und Print.
Die "Druckversion" Darstellung macht noch mehr, sie rendert das ganze Bedienbarkeitszeug und die Menüs nicht. Eventuell macht man dort auch andere Dinge, was den Inhalt anbetrifft. Die Screenversion rein per CSS zur Druckversion umzubauen mag gehen, mag aber auch kontraproduktiv oder unnötig schwierig sein.
Rolf
Servus!
Hallo Matthias,
bevor Du alles auf den Kopf stellst und Dir die Finger brichst,
Du merkst aber schon, dass ich den Ist-Zustand analysiere, die SELFer aber sofortige Änderungen verlangen?
Ich würde das gerne mit mehreren Leuten mal gemeinsam besprechen.
sollten wir vielleicht mal über /skins/Selfhtml/skin.json drüberschauen, in wie weit dort Laderegeln stören oder helfen können. Da kann man nämlich relativ feingranular einstellen, welche Ressourcen für Screen oder für Print sind. Der korrekte Weg ist, dass wir unser Content-Stylesheet daraufhin überprüfen, was Screen-only ist und was für Print+Screen gemeinsam gebraucht wird. Und dann drei Teile haben: Common, Screen und Print.
Und warum kann man das nicht anhand des Druckergebnisses, bzw. der Druckvorschau überprüfen?
@media print{}
macht, was es soll, außer breadcrumb[1], .locale-anchor, … Ob die funktionierenden Regelsätze in der mediawiki-internen print.css
oder bei „uns“ sind, ist mir erst mal egal.
Ich möchte einen Seitenkopf haben, der ist zur Zeit über Mediawiki:Tagline, später über Mediawiki:Printheader einstellbar. Das jetzt schon über JS eigenhändig zu machen, halte ich für den falschen Weg.
Die Recherche ist, da Mediawiki eine gut dokumentierte Plattform ist, relativ einfach.
Die "Druckversion" Darstellung macht noch mehr, sie rendert das ganze Bedienbarkeitszeug und die Menüs nicht.
Was meinst du damit?
Eventuell macht man dort auch andere Dinge, was den Inhalt anbetrifft.
Was meinst du damit?
Die Screenversion rein per CSS zur Druckversion umzubauen mag gehen, mag aber auch kontraproduktiv oder unnötig schwierig sein.
Seit wann ist die Gestaltung per CSS unnötig schwierig?
Imho stellt sich doch nur die Frage, ob man Webseiten per Druckdialog des Browsers oder mit einem Link zu ?printable=yes
ausdruckt, bei dem man den Druckdialog erneut auslösen muss. Diesen Druck-Link gibt es anderswo nicht mehr - jetzt lange zu überlegen, was er macht und wie man ihn hinbiegen kann, halte ich für verfehlt.
You might expect:
example.com/wiki/Page?printable=yes
...to trigger CSS rules inside:
@media print { ... }
But this does not happen automatically.
Loads a separate print stylesheet, often defined in MediaWiki's config (print.css or printable.css).
Modifies the HTML markup, often by adding:
<body class="mediawiki ltr sitedir-ltr skin-vector mw-hide-empty-elt mw-printable">
MediaWiki uses that mw-printable class (and possibly server-side logic) to load print-specific layout and hide navigation.
It does not activate the browser’s built-in @media print handling.
It’s not a browser-level media query trigger — just a URL flag used by MediaWiki internally.
Herzliche Grüße
Matthias Scharwies
Das (#contentSub) haben wir im Prod-Wiki nicht mehr. ↩︎
Guten Morgen!
Hallo Matthias,
bevor Du alles auf den Kopf stellst und Dir die Finger brichst,
Nein, ich sichte den Ist-Zustand, diskutiere, was wir wollen und probiere dann im Test-Wiki aus.[1]
Ist-Zustand: Das Print-Layout sieht gut aus; es gibt jedoch einige Mängel.
Hier ein erster Versuch im Test-Wiki:
Die Farben dienen nur der Veranschaulichung!
Grün ist <h3 id="siteSub" class="mw-tagline">
das als Special Page
bereits existiert.
Das Logo und der rote Subtext sind Pseudoelemente. Das Ganze ist per CSS nach oben geschoben worden. @Felix Riesterer Der große Abstand oben ist imho die ausgeblendete Site-Notice. Die font-size von h1 und #siteSub ist auf 2rem begrenzt; vorher war die h1 41.4px groß.
Frage: Wie stellt ihr Euch den Header/Seitenkopf überhaupt vor?
In neueren Skins wird :Tagline mit dem unsemantischen h3 nicht mehr verwendet; Mediawiki:Printheader
übernimmt diese Rolle und kann sogar HTML enthalten.
<body class="mediawiki ltr skin-vector printable">
<div id="mw-print-header">
<div class="print-header">
<h1 class="print-title">SELFHTML</h1>
<div class="print-tagline">Seit 1995</div>
<div class="print-logo">
<img src="...logo.png" alt="Logo">
</div>
</div>
</div>
<strong class="selflink">
auf die gleiche Seite zeigen, tauchen doch auf.Media:Retrievedfrom
kann man formatieren: Ich habe die URL der ausgedruckten Version durch eine „saubere“ URL ersetzt[2] und durch eine Datumsangabe ergänzt:
Rolf hatte erwähnt, dass man da auch einen QR-Code einsetzen könnte.
Sollten die Kategorien und Sponsoren unten auftauchen?
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
Die "Druckversion" Darstellung macht noch mehr, sie rendert das ganze Bedienbarkeitszeug und die Menüs nicht.
Was meinst du damit?
Das, was Du dann selbst zitiert hast. Die Screenversion enthält die Screen-Navigation, die Druckversion nicht.
Eventuell macht man dort auch andere Dinge, was den Inhalt anbetrifft.
Was meinst du damit?
Dass es Renderingunterschiede für den Inhalt geben könnte. Das ist reine Hypothese.
Die Screenversion rein per CSS zur Druckversion umzubauen mag gehen, mag aber auch kontraproduktiv oder unnötig schwierig sein.
Seit wann ist die Gestaltung per CSS unnötig schwierig?
Seit dem Tag, wo wir anfingen, in der common.css Dinge aus dem Selfhtml-Skin zu überschreiben, der wiederum Dinge aus dem Vector-Skin überschrieb, der wiederum Dinge aus dem Mediawiki-Basisskin…
Die common.css-Schicht sind wir noch nicht ganz losgeworden (da sind noch Restarbeiten für's Makeover), da denkst Du schon über eine neuen Print-Schicht nach, die die Screen-Ansicht zur Print-Ansicht umbaut. Das mag für Dich vom Handling her einfacher sein, weil man das über eine mediawiki:xyz.css Ressource tun kann, es ist aber dennoch ein Umweg.
Rolf
Hallo Rolf,
Seit wann ist die Gestaltung per CSS unnötig schwierig?
Seit dem Tag, wo wir anfingen, in der common.css Dinge aus dem Selfhtml-Skin zu überschreiben, der wiederum Dinge aus dem Vector-Skin überschrieb, der wiederum Dinge aus dem Mediawiki-Basisskin…
Die common.css-Schicht sind wir noch nicht ganz losgeworden (da sind noch Restarbeiten für's Makeover), da denkst Du schon über eine neuen Print-Schicht nach, die die Screen-Ansicht zur Print-Ansicht umbaut. Das mag für Dich vom Handling her einfacher sein, weil man das über eine mediawiki:xyz.css Ressource tun kann, es ist aber dennoch ein Umweg.
Ich schau nur, wo's hakt und finde dann einen CSS-Regelsatz dafür. Wo der dann zu liegen kommt ist dann doch der letzte Schritt - so in's Blaue vermutet passt der dann in's Selfhtml.css.
@media screen {
#mw-content-text .cards-list .card {
...
}
}
Warum gilt die Festlegung für Cards nur für den Screen? Entweder blendet man für den Druck alle Cards aus oder stellt sie genauso wie auf dem Screen dar (ohne Hintergrundfarbe natürlich) - ich wäre für zweiteres.
Im Druck haben weder die SVGs noch der Linktext etwas zu suchen.
Erscheint hier als Liste.
Mein Vorschlag für Beispiel 2 und 3:
@media print {
#contentSub {display:none;} /* not needed in Prod-Wiki */
.locale-anchor, .continuation, .selflink {
display:none;
}
}
Das ist doch keine „zusätzliche Schicht“, sondern das Ausbügeln kleinerer Fehler.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
das muss man sicherlich fallweise entscheiden. Was ich aber nicht gewusst habe: Die "Druckbare Version" ist auch bei Mediawiki im Niedergang begriffen und wird missbilligt, mit der Begründung, dass man das nur für Browser wie den IE6 gemacht hätte, die @media print nicht kennen.
D.h. ich war im Irrtum und du bist da insofern auf dem richtigen Dampfer, dass die Styles das Drucklayout erzeugen müssen und man den print preview des Browsers verwenden muss, um zu schauen, wie die druckbare Version aussieht. Der Toolbox-Eintrag "Druckversion" sollte dann weg.
Es heißt aber auch für unsere Styles, dass wir schauen müssen, was im @media-print Fall fehlt, und dass JavaScript, das Dinge tut, die im Print-Modus unnötig sind, zuvor window.matchMedia("screen").matches abfragen sollte. Das muss man eigentlich nur einmal zu Beginn tun, weil der Browserbefehl "Drucken" die Seite neu aufbaut und die Scripte neu laufen lässt. Das kann ich ins Selfhtml-API einbauen (mw.Selfhtml-Objekt).
Beispiel Cards: Wenn deren Layout nur für screen kommt, ist das falsch.
Beispiel .locale-anchor: Hier müsste das Script den Ausgabe-Medientyp ermitteln und die Generierung unterdrücken. Die Anchors erst erzeugen und dann per @media print wieder verstecken ist falsch.
Beispiel Fortsetzung: Wenn die Fortsetzungsvorlage im Druck nicht zu sehen sein soll, muss man das wohl mit CSS lösen. Eine Output-Funktion von Mediawiki, mit der man einen Seitenbereich als "don't print this" markieren kann, kenne ich nicht. Schade eigentlich, aber es ist ja nur konsequent. Mit Abschaffung von "printable=yes" weiß der Server nicht mehr, wohin das Dokument gerendert wird.
Rolf
Hallo Matthias,
der Selfhtml-Skin im Testwiki entspricht nicht dem im Hauptwiki, ich habe das Makeover noch nicht zurückportiert.
Frage: Soll ich den Selfhtml-Skin im Testwiki brutal mit dem des Hauptwiki ersetzen? Das bedeutet dann vermutlich Nachbesserungen an Vorlagen, Grafiken, Frickl2 und Wikitext-Workarounds. Ich würde eigentlich sagen, dass das der richtige Weg ist. Lieber Frickl2 im Testwiki an den Makeover-Skin anpassen, als im Hauptwiki. Das ist dann natürlich erstmal etwas Gefrickel, bis das Testwiki wieder rundläuft.
Anyroad - ich habe - im Hauptwiki - einen Teil der Screen-Styles aus der content-screen.css ausgelagert (cards und continuation) und lade die jetzt aus Wikisicht mit Medientyp all. D.h. der Druckversion-Toolboxeintrag lädt sie immer. Für .continuation habe ich per @media print ein display: none gesetzt.
Aber jetzt muss ich erstmal Schluss machen.
Rolf
Guten Morgen!
Hallo Matthias,
der Selfhtml-Skin im Testwiki entspricht nicht dem im Hauptwiki, ich habe das Makeover noch nicht zurückportiert.
Frage: Soll ich den Selfhtml-Skin im Testwiki brutal mit dem des Hauptwiki ersetzen? Das bedeutet dann vermutlich Nachbesserungen an Vorlagen, Grafiken, Frickl2 und Wikitext-Workarounds. Ich würde eigentlich sagen, dass das der richtige Weg ist.
Ja! Den aktuellen Stand rüberziehen und im Test-Wiki testen!
Evtl. könntest du auch eine neue Version des Offline-Wiki anstoßen. Dann könnte ich durchsuchen, ob manche CSS-Festlegungen überhaupt noch gebraucht werden.
Lieber Frickl2 im Testwiki an den Makeover-Skin anpassen, als im Hauptwiki. Das ist dann natürlich erstmal etwas Gefrickel, bis das Testwiki wieder rundläuft.
Das muss es ja nicht. Aber Frickl 2 sollte eben mit dem neuen Skin harmobieren und das testen wir im Verborgenen. Wenn's läuft, ziehen wir es rüber!
Anyroad - ich habe - im Hauptwiki - einen Teil der Screen-Styles aus der content-screen.css ausgelagert (cards und continuation) und lade die jetzt aus Wikisicht mit Medientyp all. D.h. der Druckversion-Toolboxeintrag lädt sie immer. Für .continuation habe ich per @media print ein display: none gesetzt.
Perfekt! Vielen Dank!
Aber jetzt muss ich erstmal Schluss machen.
Rolf
Herzliche Grüße
Matthias Scharwies
Lieber Matthias,
bei der Frage „Wie wollen wir's haben?“ würde ich gerne fordern, dass ein ?printable=yes
überhaupt nicht notwendig sein darf, sondern schlicht das Druck-Stylesheet alles regeln muss. Es ist meine persönliche Überzeugung, dass ein für den Druck gesondertes Dokument eine vermeidbare Komplexitätsschicht ist und deswegen kontraproduktiv.
Liebe Grüße
Felix Riesterer
Hallo Felix,
das brauchst du nicht zu fordern, das ist uns schon durch die Mediawiki Roadmap auferlegt. Hab ich bis gestern auch nicht gewusst…
Rolf