Liebe Liste!
Ich begrüße den Trend, dass WYSIWYG-Editoren im Web-Bereich sterben. Die waren schon immer scheiße, aber erst mit den Page-Buildern verschwanden sie aus den Admin-Bereichen. Bei Django CMS, Django Wagtail und vielen Wordpress Themes werden die Seiten in einer langen Liste aus aus Komponenten zusammengeklickt und nicht mehr in ein Textfeld eingegeben.
Meine Frage ist: Gibt es das auch für Print? Hat schonmal ein Verlag ein Programm an seine Autoren geschickt, mit dem sie Textbereiche, Infoboxen und Bilder zusammenklicken? Es gibt bunte XML-Editoren, die genau das mit DocBooks können. Aber die sind schon sehr generisch. Da muss man für eine neue Tabellenzeile eingeben, dass man jetzt das Zeilen-Element haben möchte.
Die Grundvoraussetzung für diese Art Bücher zu schreiben wäre wohl eine Editor-Beschreibungs-Sprache. Darin wird festgelegt, welche Layout-Vorlagen es gibt und welche Eigenschaften sich daran einstellen lassen.
Das Wordpress-Plugin Advanced Custom Fields liest so eine json-Datei ein, die genau festlegt, was in welchem Zusammenhang eigegeben werden kann und muss. Wie das später auf der Seite aussieht, ist dem Plugin egal. Eigentlich wäre dieses Plugin als Stand-Alone-Anwendung schon das, was ich meine.
Als netter Nebeneffekt lassen sich Bücher mit Page-Builder gut im Team bearbeiten und beliebig skalieren. Man könnte jedes Layout (Text, Tabelle, Galerie, Infobox) als eigene Datei ablegen und mit Git verwalten. In den Dateien stehen Vorgänger und Nachfolger. Auf diese Weise fallen Inkonsistenzen automatisch auf. Kollisionen gibt es nur, wenn wirklich das selbe Layout von mehreren bearbeitet wurde.
Mediawiki hat seit ewigen Jahren einen Markdown-Editor. So etwas geht eigentlich nur für Fließtext. Links und Bilder erfordern Konzentration. Galerien, Infoboxen und Tabellen gehen mit normalem Aufwand gar nicht. LaTeX ist am gleichen Problem gestorben. Und gleichzeitig der Beweis, dass automatischer Textsatz ganz OK funktioniert, wenn die Quelle da ist.
Viele Grüße Thomas
Hallo,
Vorab: Wenn Dir DTP-Software wie Scribus oder Adobe Indesign nicht zusagen, dann kenne ich keine WYSIWYNG-Software in dieser Richtung.
Zwei Ideen dazu: 1. LaTeX besitzt entsprechende Pakete. Möglicherweise könnte man mit LyX oder einer eigenen GUI was basteln.
2. HTML ist nicht auf Webseiten beschränkt. Der Unterschied zwischen Browser- und Drucklayout liegt im CSS. Allerdings kenne ich außer diversen LaTeX-Paketen keine Software, die HTML vernünftig setzen kann. Und bei den LaTeX-Paketen bin ich mir nicht sicher, ob die CSS ordentlich unterstützen. Jedenfalls wäre das ein Weg ein Webradaktionssystem aufzubauen.
3. Möglicherweise hilft auch BaKoMa TeX in der Richtung weiter.
Grüße
Tobias
On 07.03.2016 14:13, Thomas Schmidt wrote:
Liebe Liste!
Ich begrüße den Trend, dass WYSIWYG-Editoren im Web-Bereich sterben. Die waren schon immer scheiße, aber erst mit den Page-Buildern verschwanden sie aus den Admin-Bereichen. Bei Django CMS, Django Wagtail und vielen Wordpress Themes werden die Seiten in einer langen Liste aus aus Komponenten zusammengeklickt und nicht mehr in ein Textfeld eingegeben.
Meine Frage ist: Gibt es das auch für Print? Hat schonmal ein Verlag ein Programm an seine Autoren geschickt, mit dem sie Textbereiche, Infoboxen und Bilder zusammenklicken? Es gibt bunte XML-Editoren, die genau das mit DocBooks können. Aber die sind schon sehr generisch. Da muss man für eine neue Tabellenzeile eingeben, dass man jetzt das Zeilen-Element haben möchte.
Die Grundvoraussetzung für diese Art Bücher zu schreiben wäre wohl eine Editor-Beschreibungs-Sprache. Darin wird festgelegt, welche Layout-Vorlagen es gibt und welche Eigenschaften sich daran einstellen lassen.
Das Wordpress-Plugin Advanced Custom Fields liest so eine json-Datei ein, die genau festlegt, was in welchem Zusammenhang eigegeben werden kann und muss. Wie das später auf der Seite aussieht, ist dem Plugin egal. Eigentlich wäre dieses Plugin als Stand-Alone-Anwendung schon das, was ich meine.
Als netter Nebeneffekt lassen sich Bücher mit Page-Builder gut im Team bearbeiten und beliebig skalieren. Man könnte jedes Layout (Text, Tabelle, Galerie, Infobox) als eigene Datei ablegen und mit Git verwalten. In den Dateien stehen Vorgänger und Nachfolger. Auf diese Weise fallen Inkonsistenzen automatisch auf. Kollisionen gibt es nur, wenn wirklich das selbe Layout von mehreren bearbeitet wurde.
Mediawiki hat seit ewigen Jahren einen Markdown-Editor. So etwas geht eigentlich nur für Fließtext. Links und Bilder erfordern Konzentration. Galerien, Infoboxen und Tabellen gehen mit normalem Aufwand gar nicht. LaTeX ist am gleichen Problem gestorben. Und gleichzeitig der Beweis, dass automatischer Textsatz ganz OK funktioniert, wenn die Quelle da ist.
Viele Grüße Thomas
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Hallo Tobias!
Wenn Dir DTP-Software wie Scribus oder Adobe Indesign nicht zusagen, dann kenne ich keine WYSIWYNG-Software in dieser Richtung.
LaTeX
HTML ist nicht auf Webseiten beschränkt.
Ich habe mich wohl sehr unklar ausgedrückt. HTML, TeX und DTP sind genau das, was ich nicht meine. :-)
Bei einem Page Builder beginnt man nicht mit einer leeren Seite wie bei vi oder Libreoffice. Viel mehr sieht man nur eine Liste der möglichen Layouts. Fließtext, Überschrift, Galerie, Tabelle, Infobox, Zeug. Davon wählt man eines aus und gibt die nötigen Daten ein. Darunter klickt man das nächste Layout und so weiter, bis das Dokument fertig ist. Es ergibt sich eine lange Liste Layouts. Kein weißes Blatt, keine Auszeichnungssprache.
So sieht ein schöner Page Builder im Web-Bereich aus: https://wagtail.io/features/streamfield/
Meine Überlegung war jetzt: Warum gibt es so etwas nicht zum Bücher-Schreiben mit einer schönen Oberfläche und Docbook-Export?
Oder anders: Warum tun sich LaTeX-Autoren eine Sammlung Textdateien an, wenn sie eigentlich Texte, Tabellen, Diagramme und so weiter bearbeiten wollen?
- Thomas
Hallo Thomas,
Am 10.03.2016 um 12:49 schrieb Thomas Schmidt:
Ich habe mich wohl sehr unklar ausgedrückt. HTML, TeX und DTP sind genau das, was ich nicht meine. :-)
Vielleicht ist skribilo http://www.nongnu.org/skribilo/ (oder seine Vorfahren und Geschwister -- siehe "Related Links") die Skriptentsprechung von dem was du suchst. Ich weiß selbst nichts darüber, musste aber, als ich es zufällig entdeckt habe, an deine Anfrage denken.
Uwe
Hallo,
On 10.03.2016 12:49, Thomas Schmidt wrote:
Hallo Tobias!
Wenn Dir DTP-Software wie Scribus oder Adobe Indesign nicht zusagen, dann kenne ich keine WYSIWYNG-Software in dieser Richtung.
Wenn diese Systeme eine vernünftige Vorlagenverwaltung haben, bieten sie Dir so etwas ähnliches wie einen Pagebuilder, ähnlich wie es Präsentationsprogramme á la LibreOffice Presenter oder MS PowerPoint.
Das ist das, was die Leute kennen. Wenn Du es restriktiver haben willst, dann vermute ich, dass es einfach schwer wird, sowas gegen die Word+Excel-Experten durchzusetzen. Mit den Office-Programmen wird heutzutage wirklich *alles* gemacht, egal, ob es sinnvoll ist oder nicht.
Im Webbereich hat sich das nicht durchgesetzt, weil es zu kompliziert ist, mit Word direkt auf dem Server zu arbeiten, insbesondere wenn dynamische Inhalte eingebunden werden sollen, und weil die Leute Angst davor haben, kryptische Sprachen wie HTML zu lernen.
Außerdem möchten sich die Programmierer ihr HTML/CSS nicht von DUs zerschießen lassen. Das kann man auf zweierlei Art erreichen: Einerseits kann man versuchen kaputte Eingaben zu reparieren und andererseits kann man sie gar nicht erst zulassen. Letzteres ist der Punkt, der zur Entwicklung von Pagebuildern geführt hat. Mit dynamischen Inhalten muss man u.U. HTML durch Platzhalter oder ähnliche Konstruktionen ergänzen, das spart man sich mit einem Pagebuilder.
LaTeX HTML ist nicht auf Webseiten beschränkt.
Ich habe mich wohl sehr unklar ausgedrückt. HTML, TeX und DTP sind genau das, was ich nicht meine. :-)
Das glaubst Du.
Wenn Du von einem Webseiten-Pagebuilder sprichst, redest Du automatisch von HTML. Alternativen wären Java und Flash und das will heutzutage niemand vernünftiges.
Mal sachlich: Dein Page-Builder setzt auf einer der bekannten Text-Markup-Sprachen auf. Egal mit welcher Programmiersprache und (virtuellen) Maschine er geschrieben wurde, macht er auch nichts weiter, als irgendwo im Hintergrund eine HTML-Datei zu generieren, die im Browser angezeigt wird. Je nach System geschieht das beim Ersteller, auf dem Server, beim Leser auf im Browser oder überall ein wenig.
Meine Aussage ist: Nimm einen Webseiten-Pagebuilder, lass Dir HTML+CSS produzieren und verfüttere das an ein Textsatzsystem, das mit HTML umgehen kann.
Das kann man alles auf einem Intranet-Server verstecken. Oder was glaubst Du, wie Vistaprint & Co. funktionieren?
Bei einem Page Builder beginnt man nicht mit einer leeren Seite wie bei vi oder Libreoffice. Viel mehr sieht man nur eine Liste der möglichen Layouts. Fließtext, Überschrift, Galerie, Tabelle, Infobox, Zeug. Davon wählt man eines aus und gibt die nötigen Daten ein. Darunter klickt man das nächste Layout und so weiter, bis das Dokument fertig ist. Es ergibt sich eine lange Liste Layouts. Kein weißes Blatt, keine Auszeichnungssprache.
Die Oberfläche ist orthogonal zur Datenhaltung. Ich wage zu behaupten auch ein Pagebuilder kommt nicht ohne Auszeichnungssprache aus. Allein für Links und Hervorhebungen braucht man sowas.
So sieht ein schöner Page Builder im Web-Bereich aus: https://wagtail.io/features/streamfield/
Das ist mir schon klar.
Meine Überlegung war jetzt: Warum gibt es so etwas nicht zum Bücher-Schreiben mit einer schönen Oberfläche und Docbook-Export?
Von welchen Büchern redest Du? Ein Roman besteht meist aus reinem Text. Den bekommt man gut lesbar in einer Textdatei unter. Bilder kommen meist von ganz woanders her. Bei Kinderbüchern und Anatomieatlanten sieht das schon anders aus.
Oder anders: Warum tun sich LaTeX-Autoren eine Sammlung Textdateien an, wenn sie eigentlich Texte, Tabellen, Diagramme und so weiter bearbeiten wollen?
Es gibt viele Gründe, warum man ein Textformat bevorzugt. Meinereiner, weil der Overhead für Fließtext relativ gering ist. Dazu gibt es den Vorteil, dass ich quer durch die Datei editieren kann. Ich kann Teile einer Formel, einer Aufzählung und eines Bildes kopieren und einfügen. Damit kann ich mir relativ schnell aus verschiedenen Ecken meines Textes Daten zusammensuchen.
Mein Texteditor besitzt eine Schrift mit fester Breite. Das ist sehr entsprannend beim Editieren. Ich kann einfach abschätzen, wie lange der Cursor braucht, um eine bestimmte Stelle zu erreichen. Das geht so einfach, dass es unterbewusst passieren kann.
Ich werde beim Arbeiten nicht dadurch gestört, dass ich mich ums Layout kümmern muss. Dafür kann ich mich darum kümmern, wenn ich mal keinen Bock auf Arbeit habe und trotzdem vorwärts kommen möchte.
Es ist eindeutig definiert, in welchem Formatbereich ich mich befinde, also ob ich vor oder hinter der schließenden Klammer bin.
Ich werde nicht gezwungen, die Maus anzufassen, um ein Bild einzufügen.
Langer Rede, kurzer Sinn: Textdateien sind eine gute Darstellung von Text. Grafikdateien sind eine gute Darstellung von Grafik. Tabellenformate sind kompliziert, egal, wie man es dreht und wendet.
Zu letzterem: Ich habe mal eine Zeitlang Termintabellen für eine Homepage aufgearbeitet. Am Anfang stand Lotus Wordpro mit HTML und Tabellen. Es dauerte nicht lange und ich entdeckte, dass ich mit LaTeX genauso schnell bei der Eingabe bin, wenn nicht sogar schneller. Deshalb habe ich sie dann aus der HTML-Datei herausgenommen und aus einem Dateiformat generiert. Das Problem bei Tabellen ist: Du hast eine Zweidimensionale Struktur mit vielen kleinen Textschnipseln. Weil jeder Textschnipsel an sich linear ist, bekommst Du insgesamt eine Struktur, die Du weder mit der Maus noch mit der Tastatur wirklich komfortabel bedienen kannst.
VG
Tobias
lug-dd@mailman.schlittermann.de
-
Thomas Schmidt -
Tobias Schlemmer -
Uwe Koloska