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)

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)