Diskussion:Groff

Was für ein ausgezeichnetes Beispiel für einen wirklich schlechten Artikel!

... und erst der Diskussionstil --Hubi 07:38, 14. Sep 2004 (CEST)

Ich hab' den Artikel mal komplett neu geschrieben, ich denke das entkräftet vorherige Aussage. -- Poc 17:53, 28. Okt. 2006 (CEST)

Schriften bei groff

Im Artikel heisst es: Im Beispiel devps liegen Beschreibungsdateien mit dem Kurznamen der Schriftarten, in welchen die geometrischen Daten der referenzierten Schriftart (Zeichenbreiten, Kerningpaare, Ligaturen, Zeichenzuordnungen) usw. aufgeführt werden. Das ist aus meiner Sicht missverständlich formuliert. Es liegen die Metriken der Schriftarten vor (die die in Klammern angegebenen Punkte umfassen), aber das ist weniger als die gesamten geometrischen Daten, zu denen auch die konkrete Gestaltung eines Zeichens gehören würde (Bézier-Kurven etc). Ich habe daher »geometrische Daten« durch »Metriken« ersetzt. --AFBorchert 07:19, 17. Apr. 2007 (CEST)

Lesenswert-Diskussion (gescheitert)

Groff ist das GNU-Pendant zu Troff, einer Textsatzsoftware wie z. B. LaTeX. --Poc 19:51, 13. Aug. 2008 (CEST)

Stellst Du jetzt hier beide Artikel zur Wahl oder nur einen? Wie hätt´s denn der Herr gern? --Grüße aus Memmingen 20:05, 13. Aug. 2008 (CEST)

Kurze Frage was soll bei groff bitte schön lesenswert sein? Die Programmcodes oder die Eingabeaufforderungen in Listenform? Dann kann ich mir auch den Quelltext einer x-beliebigen Software anschauen und mich dran erfreuen -Armin P. 20:09, 13. Aug. 2008 (CEST)

•  Kontra - lachen tue ich später. Marcus Cyron 20:29, 13. Aug. 2008 (CEST)
• wow - bei Troff kann ich zumindest eine Artikelstruktur erkennen - trotzdem reicht mir dies auch nicht bei diesem Artikel aus und empfehle dem Einsteller diese beiden Textwüsten aus der Kandidatur zu entfernen. Ansonsten ein  Kontra  Kontra von mir. -- Rolf H. 20:38, 13. Aug. 2008 (CEST)
• 2 mal  Kontra, kann der Antrag noch zurückgezogen werden, würde eine große Blamage ersparen--Cartinal 20:45, 13. Aug. 2008 (CEST)
• Wie wäre es, die Knoff-Hoff-Show noch mit in den Kandidatenpool zu werfen?  Kontra --Andibrunt 00:08, 14. Aug. 2008 (CEST)
• Aus formalen Gründen  Kontra für Groff, da die Gliederung wirsch ist und man als Laie nur ansatzweise versteht, um was es überhaupt geht. Troff ist etwas verständlicher, da die Einleitung Laien-kompatibler ist. Im Text gibts dann viele inhaltliche Fragezeichen. Der geschichtliche Abschnitt ist sehr aus der Innenperspektive eines entsprechenden Fachmanns geschrieben. Der Laie versteht oft nur Bahnhof (was z.B. ist „McIllroy's troff“?). Beide Artikel wären wohl besser erstmal ein Fall für die Review, um sie halbwegs in Form zu bringen. Dann gerne wieder hier gesehen. Grüße-- · peter schmelzle · d · @ · 00:36, 14. Aug. 2008 (CEST)
• Da fällt mir doch glatt ein: "Remember this when angry at noobs: Player 1 has a kick command." Seid nett zum Anfänger! Für genau so Fälle gibts ja die 5-Contra-Regel. -- Ben-Oni 04:21, 14. Aug. 2008 (CEST)

Leistung: Edit von IP-Adresse 78.53.84.240

Hallo, bitte nicht einfach nur löschen, sondern verbessern. Die Leistungsdaten sind als Anhaltspunkte zu verstehen, nicht als sekundengenaue präzise Angabe. Das ist auch nicht möglich, da sich Hardware in mehr als nur der CPU unterscheidet. --Poc 17:54, 5. Nov. 2008 (CET)

Diesen Abschnitt kann man nicht "verbessern", er ist komplett unsinnig. Mein Rechner hat nur 1,5GHz, benötigt für groff 0,1s und für ps2pdf 1,1s - wie soll das in die Tabelle passen? Es ist auch keine "groff-Leistung", da es kein pdf erzeugen kann und in die Tabelle zwei verschiedene Programme eingehen (eigentlich noch weit mehr, wenn man sich ps2pdf ansieht und weiss, dass der ganze Ghostscriptrattenschwanz in x Versionen, Varianten und Kompilaten dazu kommt). Welche nachvollziehbare Aussage soll diese Tabelle haben? 78.53.84.240 21:48, 5. Nov. 2008 (CET)

Nein, er ist nicht unsinnig. Ich gebe allerdings zu, daß die Daten aus heutiger Sicht, mit modernen Prozessoren weitgehend uninteressant geworden sind. Die Aussage der Tabelle soll schlichtweg die zu erwartende Zeit sein, die ein Benutzer auf die PDF-Ausgabe warten muß, wenn größere Mengen an Daten zu verarbeiten sind. Wenn man ohne WYSIWYG auskommen muß, und immer mal wieder zwischendurch ein PDF als Proof (Druck) erzeugen muß, ist das durchaus relevant. Bitte aus dieser Sichtweise nochmal kommentieren. Danke. --Poc 17:47, 6. Nov. 2008 (CET)

1. Der angegebene PIV mit 3GHz ist mindestens 2 Jahre jünger als mein Prozessor, also muß die Testplattform extrem langsam oder miskonfiguriert sein, denn in sämtlichen Benchmarks ist der PIV schneller. Auch Speicher oder Platte können nicht so unterschiedlich sein, daß 400% mehr Zeit benötigt werden.

Ich halte es für wahrscheinlicher, daß hier die Quelldaten einiges an Unterschied ausmachen. Außerdem ist jedes Programm, was vorher schonmal lief, auf jeden Fall schneller gestartet. Getetstet hatte ich mit 'nem Debian Sarge und dessen Groff auf den genannten Plattformen. --Poc 17:18, 7. Nov. 2008 (CET)

Das Programm lief nicht vorher und der Vergleich war ja so intelligent, dass man die Testdaten nicht einmal angegeben hat. Hier liefen groff/ps2pdf auf einem Gentoo, log'weise komplett auf das System abgestimmt. 78.53.87.101 17:50, 7. Nov. 2008 (CET)

Nochmal: Es ging mir niemals um eine 100%ige Nachvollziehbarkeit, sondern um einenm Anhaltspunkt! --Poc 19:50, 7. Nov. 2008 (CET)

2. Halte ich diesen Vergleich nicht nur für (statistisch) fehlerhaft, sondern auch in seiner Intention für mangelhaft. Du selbst hast es noch einmal bestätigt - die ein Benutzer auf die PDF-Ausgabe warten muß. Groff - und wir erinnern uns, darum geht es in diesem Artikel - kann kein pdf! Wozu auch? Damals (und auch heute) genügte PostScript vollkommen, wieviele Drucker sprechen schon nativ pdf? Und wenn Du als Vergleich die wysiwyg-Fraktion benutzt, müsstest Du ebenfalls pdf-Filter... angeben, denn außer ein paar Adobeprodukten versagen fast alle beim pdf-Export (inkl. oo.org und MS).

Nochmal; Es sollen keine total exakten, 100% nachvollziehbaren Angaben sein, sondern Richtwerte, wie lange man z. B. beim Proofen warten muß. Selbst eine Abweichung von 400% ist in meinen Augen bei Absolutwerten im einstelligen Sekundenbereich die ganze Diskussion nicht wert. Es geht nicht ums direkte Drucken mit PDF. Ich weiß, daß Groff u. A. PostScript hinten 'rauswirft. Es geht um den Workflow. Was hilft es in der Praxis, wenn ein umfangreicher Text in wenigen Sekunden fertig ist und die PDF-Konnvertierung hintendran dann nochmal ewig dran 'rumknuspelt. Richtig, das ist kein Groffproblem, aber es ist aux Anwendersicht praxisnah, und darum geht es. Was ich mit PDF-Filtern angeben soll und wie jetzt plötzlich OO oder MS ins Spiel kommen, verstehe ich schlichtweg nicht. Bitte hier nochmal zum Start dieses Absatzes springen und ein weiteres mal aufmerksam lesen. 90% aller Mißverständnisse lassen sich auf Kommunikationsprobleme zurückverfolgen. --Poc 17:18, 7. Nov. 2008 (CET)

Mir ging es ebenfalls um den "Workflow". Die pdf-Konvertierung ist sinnfrei, da sie von vielen groff-Nutzern nicht verwendet wird, genausowenig wie der durchschnittliche Word-Nutzer pdf-Dateien erstellt (und das war der Bogen zu den von Dir angesprochenen wysiwyg-Programmen).

Nochmal ganz deutlich: Es geht um das Proofen!! Natürlich macht das keiner in wysiwyg-Programmen, weil ich da ja schon gleich sehe, wie's rauskommt. Bei Groff sehe ich das am Besten in PDF, auch wenn es einen (IMO ziemlich grottigen) X11-Viewer gibt. --Poc 19:50, 7. Nov. 2008 (CET)

Kann es ein, daß Du etwas komplett durcheinander haust? Die wenigsten (gibt es überhaupt welche?) wysiwyg-Programme sind in der Lage auch nur annähernd eine Anzeige zu liefern, die dem Druckergebnis nahekommt. Es gibt auch keine X11-Viewer für groff oder meinst Du gv,ggv,gsview,... für Postscript oder xdvi,kdvi,... für dvi? Und auch das "Proofen" ist kein Argument, da nur wenige in der Praxis (nicht immer verlustfrei) von ps nach pdf umwandeln, um das ps zu drucken, aber sich vorher unbedingt ein pdf anschauen zu können?! Muss ja eine komische Firma sein, wo Du das gesehen hast. Der Vorgang bietet nämlich genau 0 Vorteile. 78.53.87.101 00:41, 8. Nov. 2008 (CET

Möglicherweise haue ich was durcheinander, ich wüßte aber nicht was. WYSIWYG: Auch hier kommt es sehr auf die Anforderungen an. Ich persönlich neige dazu, (beispielsweise in dieser Sache) auf eine 105%ige Genauigkeit zugunsten einer übersichtlicheren und einfacheren Erklärung zu verzichten. Natürlich entspricht es nicht wirklich dem Druckergebnis, dazu reicht die Bildschirmauflösung z. B. schon gar nicht aus. Aber es reicht mir zu sehen, wie der Umbruch aussieht und daß die Grafik x an dem Platz steht, wo sie hin soll. Im Quellcode von Groff sehe ich das nunmal eben nicht, in z. B. PageMaker (hier ist nicht der Quellcode oder die PM-Datei gemeint, sondern das Programmfenster, nur damit hier nicht weitere Mißverständnisse auftreten) aber schon. (Ja, PM ist alt, aber ich benutze ihn noch immer gern.) Es gibt xditview im Groff-Paket als Viewer. Proofen ist für mich das zentrale Argument für eine praxisnahe Vorschau, wie's auf'm Drucker 'rauskommt, wenn ich die PostScript-Ausgabe von Groff zum Drucker schiebe. Gesetzt den Fall ich habe die notwendigen Fonts für gs auch zu Verfügung. Das mit dem Verlustfrei spielt in dem Fall auch keine Rolle, weil das PDF nur zum Anschauen, zur Layoutkontrolle, zum gucken, daß ich in Pic alles richtig gemacht habe und z. B. kein Text links und rechts über Box ragen dient. Zum Drucker geht die ursprüngliche PS-Datei. Die "komische Firma" hat ein Rechnungssystem auf Groff-Basis etabliert, nachdem ich Groff beim technischen Leiter vorgeführt habe. Umgekehrte Frage: Wie kontrollierst Du denn, daß das, was Du in Groff gesetzt hast auch Deinen Erwartungen entspricht? Jedesmal Papier 'raushauen? Die angeblichen 0 Vorteile sind aus meiner Sicht: Geht schnell, verbraucht kein Papier und keinen Toner und ist hinreichend genau. Ich hoffe, wir kommen dem Mißverständnis langsam auf die Spur. --Poc 08:33, 8. Nov. 2008 (CET)

Die wysiwyg-Diskussion lasse ich mal weg, denn oft genug sind Anzeige und Ausdruck verschieden - auch der Umbruch oder die Position/Überlappung von Boxen ist falsch.... Ich muß zugeben, daß ich xditview nicht kannte und auch noch nie im Einsatz gesehen habe, war bei mir auch nie bei groff dabei. Wie kontrollierst Du denn, daß das, was Du in Groff gesetzt hast auch Deinen Erwartungen entspricht?: indem ich mir das nativ erzeugte ps ansehe?! Dazu ist es doch da. Manche bevorzugen dvi, ich nicht. Aber der Sinn einer zusätzlichen Konvertierung, will sich mir immer noch nicht erschließen. 78.53.86.118 11:07, 8. Nov. 2008 (CET)

Wie schaust Du Dir direkt ein PostScript File an? --Poc 21:04, 8. Nov. 2008 (CET)

Mit einem der zahlreichen PostScript-Viewer. Ich bevorzuge gv. 78.53.84.249 08:20, 9. Nov. 2008 (CET)

War seinerzeit (vor ca. 8 Jahren) vom Handling her zu spröde, aber das ist meine persönliche Meinung. --Poc 10:51, 9. Nov. 2008 (CET)

Daher gibt es auch unzählige Alternativen, auch von den großen Desktopprojekten. Wenigstens bleiben einem so acroread und Konsorten erspart. 78.53.84.249 19:24, 9. Nov. 2008 (CET)

Und daher ist auch eine Zeitmessung unsinnig, in der über 90% die Laufzeit von ps2pdf eingeht. Um viel mehr ging es nicht. In "der Praxis" kommt man gut mit ps aus und das seit Jahrzehnten. 78.53.87.101 17:50, 7. Nov. 2008 (CET)

Eben genau das ist nicht unsinnig, weil ich in der Praxis, beim Proofen nicht nur PS erzeuge, sondern (auch) PDF, eben für die Voransicht!--Poc 19:50, 7. Nov. 2008 (CET)

Was bleibt also? Eine Tabelle mit stark abweichenden nicht repräsentativen Werten, mindestens falscher Übeschrift und einem nicht angedachten Datenfluß. 78.53.87.101 13:29, 7. Nov. 2008 (CET)

Ich verweise auf meine vorherigen Einwände, was zu sagen ist, wurde gesagt. Was an der Überschrift falsch sein soll, wurde auch nicht weiter erklärt. Ich lösche die Tabelle jetzt wieder, und zwar aus dem einzigen Grund, daß die Werte überholt sind; so alte Kisten haben wohl keine nennenswerte Benutzerbasis mehr. --Poc 17:18, 7. Nov. 2008 (CET)

Die Überschrift ist falsch, weil es weder um groff, noch um dessen Leistung geht. 78.53.87.101 17:50, 7. Nov. 2008 (CET)

Es geht um Groff, im Rahmen eines kompletten Workflows. Es ist auch im Text vermerkt gewesen, daß da eine PDF-Erzeugung dahinterklemmt. Das ist jetzt aber müßig, weiter Rosinen zu picken. Der fragliche Abschnitt ist weg. --Poc 19:50, 7. Nov. 2008 (CET)

Poc: Die Vorschau des PostScript-Texts erfolgt typischerweise mit dem ebenfalls auf Ghostscript basierenden gv – es ist also nicht notwendig, wegen einer Vorschau den PostScript-Text noch zusätzlich in PDF zu konvertieren. --AFBorchert 00:36, 9. Nov. 2008 (CET)

War seinerzeit (vor ca. 8 Jahren) vom Handling her zu spröde, aber das ist meine persönliche Meinung. --Poc 10:51, 9. Nov. 2008 (CET)

Stil

Im Abschnitt Groff heute heisst es:

Im Laufe der Zeit ist Groff – vielleicht auch in Anbetracht der gewöhnungsbedürftigen Syntax – in Vergessenheit geraten. Wenn man aber mal den sauber formatierten Output einer in PostScript übersetzten Manpage sieht, könnte das vielleicht doch ein Ansporn sein, sich ein wenig mit Groff zu beschäftigen.

Das ist kein geeigneter Stil für einen Wikipedia-Artikel. Es geht hier nicht darum, den Leser in dieser expliziten Form dazu „anzuspornen“, sich mit groff zu beschäftigen. Und die selbstgewonnenen Eindrücke wie „gewöhnungsbedürftig“ sind nicht zu übernehmen, es sei denn, es findet sich zitierfähige Literatur, in der so ein Urteil gefällt wird. (Es ist auch nicht sehr sinnvoll, in diesem Artikel die Syntax zu kommentieren, da groff diese von troff übernommen hat. Reizvoller wäre es ggf., die zahlreichen Erweiterungen von groff gegenüber troff zu diskutieren bzw. die daraus resultierenden Inkompatibilitäten). --AFBorchert 00:36, 9. Nov. 2008 (CET)

An diesem Artikel könnte man so einiges verbessern, den Stil wikipediakompatibler gestalten, usw. Im gleichen Zuge müßte allerdings auch Troff überarbeitet werden. Die genannten Satzteile stammen aus meiner Anfangszeit bei der WP und sind (evtl. verständlicherweise) nicht konform. Bisher hat mir aber eine zündende Idee für eine (erneute) komplette Überarbeitung gefehlt. --Poc 10:44, 9. Nov. 2008 (CET)

Vergleich mit TeX

Aus dem Abschnitt GNU troff: groff:

Da die meisten troff-Befehle ähnlich wie bei TeX äußerst primitiv sind, [..]

Der Grundbefehlssatz ist bei TeX deutlich umfangreicher und komplexer – man denke etwa an den gesamten mathematischen Formelsatz, der bei TeX zum Grundbefehlssatz gehört. Ich habe diesen Vergleich daher gestrichen. --AFBorchert 00:36, 9. Nov. 2008 (CET)

Ich habe dies auf Äußerungen im Bekanntenkreis hin eingefügt. Zitat (sinnhaftig, nicht wörtlich, da schon einige Zeit zurückliegend):

Das ist ja wie TeX, das will auch keiner benutzen. LaTeX ist da viel angenehmer.

Aus meiner Sicht hätte ich einen solchen Querverweis schon gerne drin, da m. E. durchaus legitim. --Poc 10:49, 9. Nov. 2008 (CET)

Solange er sachlich inkorrekt ist, bleibt er besser draußen. Es ist dabei völlig irrelevant, ob Dein Bekannter LaTeX bequemer als plain TeX empfindet. Fakt ist, dass TeX um mehrere Größenordnungen komplexer ist und auch komplette Bücher mit plain TeX produziert worden sind (wie etwa die von Donald E. Knuth selbst). troff (und in Folge davon groff) und TeX verfolgen zwei gegensätzliche Philosophien. troff entspricht der UNIX-Philosophie, kleine Werkzeuge zu schreiben, die einen überschaubaren Funktionsumfang gut erfüllen und leicht mit anderen Werkzeugen kombiniert werden können. Folgerichtig gibt es auch eine ganze Familie einzelner Werkzeuge und so wurde beispielsweise der mathematische Formelsatz in eqn ausgelagert. TeX folgt dem Ansatz typografischer Perfektion und dazu ist ein integrativer Ansatz mit integriertem mathematischen Formelsatz vorteilhafter, auch wenn dies zu einem deutlich komplexeren Werkzeug führt. Aber auch aus programmiersprachlicher Sicht liegen zwischen den beiden Systemen Welten. TeX kennt beispielsweise Blockstrukturen und lokale Sichtbereiche, während bei troff/groff alles global ist. Und TeX ermöglicht den direkten Zugang zu seiner Abstraktion der vertikalen und horizontalen Schachteln. Das ist bei troff/groff in dieser Form nicht möglich. --AFBorchert 11:25, 9. Nov. 2008 (CET)

Groff und (eigene) Fonts

Das hat im Artikel eigentlich nichts zu suchen, damit es nicht verloren geht, verfrachte ich das aber mal hierhin.

Für jedes Ausgabegerät von Groff gibt es (üblicherweise) ein Verzeichnis in /usr/share/groff/<version>/font, benannt nach dem Muster devgerät (z. B. devps, devlj4, …). Anders als bei TeX werden bei Groff keine Schriftarten für das jeweilige Ausgabegerät optimiert in Pixeldaten umgewandelt.

Im folgenden Beispiel devps liegen Beschreibungsdateien mit dem Kurznamen der Schriftarten, in welchen die Metriken der referenzierten Schriftart (Zeichenbreiten, Kerningpaare, Ligaturen, Zeichenzuordnungen) usw. aufgeführt werden. Üblicherweise liegen hier ausschließlich Standardschriftarten vor, die jedes PostScript fähige Ausgabegerät schon im Festwertspeicher eingebaut hat. So bleiben die PostScript Daten klein und das Ausgabegerät kann auf seine internen Schriften zum Ausdruck zurückgreifen. Es besteht aber die Möglichkeit, eigene PostScript Type1-Font Schriftarten einzubinden:

1. Ggfs. Umwandlung von PostScript Schriftart im Apple-Macintosh-Format nach Unix mit t1unmac – t1utils-1.26.
2. Ggfs. Umwandlung der PostScript Schriftart ins ASCII Format (pfa) mittels pfbtops (Groff) bzw. pfbtopfa (GhostScript).
3. Generieren einer Adobe Font Metrics Datei (AFM) aus der ASCII-Schriftart mittels pfa2afm – pfa2bdf.
4. Umwandlung der Metrikdatei in das Groff-Fontbeschreibungsformat mittels afm2dit (Groff).
5. Ablegen dieser Beschreibungsdatei mit einem neuen, selbstgewählten Kurznamen.
6. Eintragen des Schriftartnamens in der Datei download, damit das Ausgabegerät auch die tatsächlichen Fontdaten mit dem PostScript Job erhält. (Die ASCII Schriftart enthält eine Zeile, „internalname“, dieser Name muss in der Download vermerkt werden.

Jetzt kann der Font mit den üblichen Befehlen geladen und referenziert werden.