nicht angemeldet
SELF-Wiki: Dateien und Bilder
Matthias Scharwies
SELF-Wiki: Dateien und Bilder
Matthias Scharwies
Rolf BFrohe Ostern!
Seit einigen Jahren gab es unter den ToDos einen Bereich mit Rastergrafiken, die vektorisiert werden sollten.
@Bertie hat diese Aufgabe dankenswerterweise übernommen und gleich weitere pngs ebenfalls in SVGs umgewandelt. Vielen Dank!
Dabei habe ich gemerkt, dass wir eigentlich keine Übersicht über unsere hochgeladenen Dateien haben.
- Spezial:Dateien - Dateiliste aller Dateien nach Datum absteigend
- Spezial:Nicht_kategorisierte_Dateien - eine Gemengelage von jpgs, pngs und svgs, die durchforstet werden müssen - alphabetisch sortiert
Ich habe erst mal folgende Kategorien angelegt:
- Kategorie:Icon - SVGs, die als Beitragsbilder im SELF-Blog oder auf Portalseiten von Kursen verwendet werden können.
- Kategorie:Infografik - hier müssen wir am Tag X schauen, ob der Text im Dark Mode auf hell[1]umschaltet. (Viele Dateien habe ich schon vorbereitet auf der Platte!)
- Neu: Kategorie:Beispiel-Bild - Es gibt Bilder, bei denen unter Dateiverwendung steht, dass sie auf keiner Seite eingebunden sind.
Das stimmt so nicht, da sie in Live-Beispielen verwendet werden, was nur über die Datenbank überprüft werden kann.
Hier sollten vorzugsweise SVGs verwendet werden, um die Dateigrößen gering zu halten.[2]
Diesen Thread habe ich angelegt, um neue Dateien vorzuschlagen und zu diskutieren, wie man sie einsetzen, bzw. weiter verbessern kann.
Herzliche Grüße
Matthias Scharwies
Hilfe:Infografiken in SVG beschreibt, was man beachten sollte ↩︎
Im OnePager-Final.html habe ich z.B. die Möbel aus der Schreinerei Meier in SVG verwendet. ↩︎
-
Ein Vorschlag für die PNG-Datei: https://wiki.selfhtml.org/wiki/Datei:Verarbeitungsvorgang.png
Vorschlag als SVG: https://wiki.selfhtml.org/wiki/Datei:Verarbeitungsvorgang.svg
Ich bin unsicher, ob die gestrichelte Linie unten nach «komprimiertes HTML» Absicht oder Unsauberkeit war.
Und für bessere Lesbarkeit würde ich in den dunkelroten Boxen weissen Text vorschlagen.
Was meint Ihr?
-
Frohe Ostern!
Herzlich willkommen im Forum!
Ich bin unsicher, ob die gestrichelte Linie unten nach «komprimiertes HTML» Absicht oder Unsauberkeit war.
Keine Ahnung, wo ich die Grafik her hatte.
Hier ist eine ähnliche Grafik mit gestrichelter Linie: https://mathewjosephh.wordpress.com/2018/10/22/how-php-interpreter-works/
Und für bessere Lesbarkeit würde ich in den dunkelroten Boxen weissen Text vorschlagen.
Ja, das sieht sehr gut/ besser als vorher aus! Vielen Dank!
Herzliche Grüße
Matthias Scharwies
-
Lieber Bertie,
Was meint Ihr?
visuell stimme ich Dir voll und ganz zu.
Inhaltlich sehe ich aber ein Problem, weil ich mit PHP nicht nur HTML generiere, sondern auch JavaScript, Bilddateien, MP3, PDF und vieles mehr. In der Abbildung könnte ich mir vorstellen, dass man den Begriff „HTML“ durch „Dokument“ ersetzt. Vielleicht sogar „angeforderte Daten“?
Liebe Grüße
Felix Riesterer
-
Hallo Felix,
du kannst Bertie nicht den Inhalt des SVG „anlasten“, er hat zunächst einmal nur das PNG vektorisiert. Dafür übrigens auch von mir ein herzliches Dankeschön.
Das PNG wurde 2016 von Matthias Scharwies hochgeladen. Inhalte zu rechtfertigen oder das Bild zu bequellen wäre demnach seine Aufgabe.
Mein Einwand gegen die Grafik wäre noch ein ganz anderer: gecachtes HTML? (oder auch SVG, CSS, text/foo-Dokument, whatever). PHP hat einen Output-Cache? Ja, man kann grundsätzlich etwas in PHP Programme einbauen um Output zu cachen, und es gibt Funktionen zum kontrollierten Zwischenspeichern von Output, aber von einer "built-in" Caching-Lösung wüsste ich nichts und finde auch nichts.
Diese Grafik müsste auf jeden Fall bequellt werden. Der Verweis zu Nikita Popovs Blog ist schon mal gut, er ist sogar so gut, dass selbst das PHPinternals Buch, das von PHP Entwicklern gepflegt wird, für die Internals dorthin verweist. Aber von einem Output-Cache redet er, meine ich, auch nicht. Output-Caching kann man auf 2 Stufen betreiben: zum einen der komplette Output zu einer URL – das ist nach meiner Ansicht ein Job für den Webserver. Und man kann Seitenbereiche cachen, deren Generierung aufwändig ist. Das macht bspw. Mediawiki mit den Artikelinhalten, aber das ist nichts, was die ZEND Engine tut, das muss man selbst bauen.
Ob man den ob_gzhandler in dieses Bild aufnehmen soll oder muss, weiß ich auch nicht. Okay, es gibt ihn, aber aus meiner Sicht ist das ein 25 Jahre alter Klotz am Bein. IIS und Apache können Output selbst komprimieren. In einer FastCGI Umgebung laufen PHP und Webserver asynchron, d.h. GZip Compression im Webserver entlastet die PHP Engine. Das Wechselspiel zwischen PHP als CGI oder FastCGI Einbindung fehlt ohnehin in dem Bild – und sollte auch fehlen.
Was man aber aufnehmen kann, wäre der JIT. Der kam in PHP 8 ganz unauffällig als Opcache-Komponente hinzu und ist per Default disabled, offenbar trauen sie ihm noch nicht so recht.
Rolf
--
sumpsi - posui - obstruxi-
Hallo zusammen,
Ja, man kann Infografiken nicht vom Textinhalt und nicht vom umgebenden Artikel trennen. Der ist von Christian Seiler vom März 2010.
und jetzt kommt das …
aber das wäre imho etwas für eine Diskussion SELF-Wiki: ToDos & Baustellen, in der wir
- listen, was uns auffällt und
- dann priorisieren
- und Stück für Stück abarbeiten
Da wäre diese Artikelreihe für mich eher weiter unten angesiedelt.
Herzliche Grüße
Matthias Scharwies
-
Hallo Matthias,
und jetzt kommt das…
Das ist nun mal so - wenn jemand den Kopf ins Licht hält dann gucken Leute drauf, die die dunklen Ecken sonst nicht beachten. Das PNG ist auch von Christian? Wenn der Artikel von 2010 ist, dann ist das alles bestenfalls auf Stand von PHP 5.4.
Das müssen ja auch nicht wir 2 bearbeiten, vielleicht findet sich jemand, die in PHP soweit drin ist, dass sie das überarbeiten kann. Oder er. Oder wir schreiben einen "Stand von PHP 5.4" Disclaimer dazu.
Dass es wenig Prio hat, da würde ich zustimmen.
Rolf
--
sumpsi - posui - obstruxi
-
-
-
