wozu blog software ?

[mermshaus]

@Julius

Ich stricke mir gerade etwas Eigenes für HTML (im Prinzip über alle (Unicode-)Zeichen iterieren und nach < bzw. > suchen), CSS und JavaScript (mit etwas Trickserei lässt sich das auch durch highlight_string jagen) – wenn PHP-Code auftaucht, wird der an den in PHP integrierten Syntax-Highlighter weitergereicht. Eventuell ergänze ich noch Python und SQL; C und Konsorten sollten sich ebenfalls mit highlight_string verwursten lassen. Bestimmt kann man das besser bzw. übersichtlicher lösen (OOP?!), aber ich im Moment nicht.

Das ist leider alles nicht so leicht, dass man das mal eben aus dem Ärmel schüttelt, weil es immer Cornercases gibt. In HTML sind das zumindest Script-Tags und Kommentare, die Winkelklammern enthalten können. In PHP-Code kann auch ein ?> in einem String oder einem Kommentar stehen und damit keine syntaktische Funktion ausüben. Wenn du wirklich versuchen möchtest, einen CSS-Parser/-Highlighter zu schreiben, wünsche ich schon jetzt viel Spaß und gute Nerven. :)

Der Nachteil an highlight_string ist, dass man die Rückgabe noch mal als HTML verarbeiten muss, wenn man aus den Inline-Styles saubere CSS-Klassennamen machen möchte (für Syntax-Highlighter-Themes). Das ist aber vermutlich immer noch besser, als sich einen eigenen PHP-Parser schreiben zu müssen.

Für andere Sprachen als PHP halte ich die Funktion aber für ungeeignet. Man wird sehr schnell in Probleme laufen.

Ein, zwei Sachen, die mir (oder eher meiner IDE) spontan an deinem Code aufgefallen sind:

• $content=false; müsste $comment=false; heißen? Zumindest ist $content ungenutzt und $comment wird nicht initialisiert.

• Ebenfalls nicht initialisiert werden $highlight_php und $attr_marker.

• Hier eine Eingabe, die einige Probleme demonstriert:

  $input = <<<'EOT'
  <?php echo 'foo ?> "\' bar\\'; /* ?> */ // ?>
  EOT;
  

  (Was der Foren-Highlighter da macht, stimmt übrigens auch hinten und vorne nicht.)

  Ausgabe (oben dein Highlighter, unten direkt highlight_string):

  

• Der Code wirft dabei auch Fehlermeldungen:

  PHP Notice:  Undefined offset: -1 in /var/www/www/fiddle/julius.php on line 45
  PHP Stack trace:
  PHP   1. {main}() /var/www/www/fiddle/julius.php:0
  PHP   2. julius() /var/www/www/fiddle/julius.php:174
  PHP Notice:  Undefined offset: 45 in /var/www/www/fiddle/julius.php on line 22
  PHP Stack trace:
  PHP   1. {main}() /var/www/www/fiddle/julius.php:0
  PHP   2. julius() /var/www/www/fiddle/julius.php:174
  PHP Notice:  Undefined offset: 45 in /var/www/www/fiddle/julius.php on line 29
  PHP Stack trace:
  PHP   1. {main}() /var/www/www/fiddle/julius.php:0
  PHP   2. julius() /var/www/www/fiddle/julius.php:174
  PHP Notice:  Undefined offset: 45 in /var/www/www/fiddle/julius.php on line 37
  PHP Stack trace:
  PHP   1. {main}() /var/www/www/fiddle/julius.php:0
  PHP   2. julius() /var/www/www/fiddle/julius.php:174
  

  Der Einfachheit halber hier mein gesamter Test.

Auch das habe ich mittlerweile ohne JavaScript lösen können: Auf dem Server läuft $$\LaTeX$$ und dvisvgm, das SVGs erzeugt, die ich dann in die Dokumente einbinde. Es ist zwar leider keine reine PHP-Lösung, aber immerhin eine für den Fall, dass man die Software auf dem Server selbst installieren kann oder einen netten Hoster hat, den man darum bitten kann.

Das ist sicherlich ein denkbarer Ansatz^[1], aber eine LaTeX-Installation auf dem Server ist für den Fokus meines Tools fünf Nummern zu krass. (Das ist ehrlich gesagt wohl auch für 99 % der Anwender/Webspaces zu krass.) Besser wäre eine LaTeX-Installation auf dem Rechner, auf dem die fertige (und bis auf das Einbinden von clientseitigem JS-Code statische) Seite generiert wird. Man würde dann eben die fertigen SVG-Grafiken während des Build-Vorgangs erzeugen und am Ende mit hochladen. Es bleibt natürlich eine dicke Abhängigkeit, die man erst mal aufsetzen muss, und, ja, es steht dem Ansatz entgegen, eine reine PHP-Lösung für die Grundfunktionalität zu haben.

Mit MathJax bekommt man das alles halt verhältnismäßig unkompliziert „frei Haus“ geliefert. Aber darin steckt schon auch ein wenig eine umfassendere Diskussion um den Einsatz von JavaScript und das Nutzen von extern gehosteten Libs und dergleichen.

Ich bin der Meinung, dass Syntax-Highlighting und das Rendern von Formeln nach Möglichkeit auf dem Server laufen sollten[^1]: Wenn ich ein Notebook bestelle, baut man bei mir ja auch nicht zuerst eine Fabrik im Wohnzimmer auf und danach wieder ab, sondern liefert mir direkt das Endprodukt!

Volle Zustimmung. Leider mit den bestehenden Tools nicht so wirklich praktikabel (siehe oben). Beim Syntax-Highlighting kenne ich an reinen PHP-Tools auch nur GeSHi, mit dem es leider mindestens zwei Probleme gibt (GPL-lizenziert, keine brauchbare Composer-Anbindung). Deshalb habe ich es zurückgestellt und werde wohl erst mal auf eine JS-Lösung setzen, die halt unkompliziert ist und funktioniert.

---

1. Ich habe das auch mal gemacht mit pdflatex und pdf2svg (SVG) beziehungsweise mit pdflatex und convert (PNG). Die Ergebnisse waren ganz okay, aber noch nicht perfekt. Falls ich das mit den SVGs nachher noch mal zum Laufen kriege, schreibe ich dazu noch was. Würde mich durchaus interessieren, ob das bei dir besser aussieht und wie du es konkret gemacht hast. So eine LaTeX-Anbindung wäre auch für meinen Generator zumindest was für eine Erweiterung. ↩︎