linux-l: dtp unter linux

[Jens-Uwe Morawski]

On Sun, 11 Feb 2001 Florian Cramer wrote:
> Am Sat, 10.Feb.2001 um 20:59:01 +0100 schrieb Jens-Uwe Morawski:
> 
> 
> > Gut, ich gehe davon aus, daß das Ergebnis zählt. Und dann kann man
> > vieles erreichen, daß sonst nur DTP-Programmen zugeschrieben wird.
> > Für ein ordentliches Plakat reicht es allemal.
> 
> Ich sehe die Stärken von TeX eher beim Satz von Büchern und akademischen
> Zeitschriften, also beim sogenannten Mengensatz. Einen typographisch
> komplexen Techno-Flyer mit TeX zu bauen, erscheint mir schwierig bis
> unmöglich (mangels Farbseparation).
 
Da TeX eigentlich nichts von Farben weiß, ist es Sache des Makro-
Paketes dies zu gewährleisten. LaTeX hinkt da ein wenig hinterher.
ConTeXt macht es schon gut. Zur Not kann man das auch auf
PostScript ebene durchführen.
 
> > Außerdem würde ich nicht an einer Abstraktionsebene rumkritisieren,
> > die du bei anderen Programmen garnicht erst in die Hand bekommst:
> > 
> > Programm      Eingabe       Darstellung       druckbare Ausgabe
> > TeX             tex             dvi                ps/pdf ...
> > XPress          XPress       nur intern            ps/pdf ...
> 
> InDesign          InDesign        pdf                ps/pdf ...
> 
> Der Nachteil scheint mir zu sein, daß dvi nicht mehr leistet (belehre mich
> eines besseren) als ps/pdf und deshalb zu einem erheblichen Umweg im Prozeß
> wird.
Der große Vorteil von DVI ist seien Geräteunabhängigkeit, sonst hätte
TeX nicht so lange überlebt.
Was wir hier gerade machen ist die alte Diskussion, ob den Historischen
Balast den TeX mit sich rumschleppt man nicht mal beseitigen kann.
Ich denke JA. 
Die Frage ist nur: Wenn irgendwann pdf altbacken ist, was soll dann eine
Ausrichtung auf PDF heute, wie du sie verlangst. DVI muß erweitert
werden. (Farbunterstützung, XObjects wie PDF, Grafiken unterstützen ...)

> Die Einbindung selbstinstallierter Postscript-Fonts in LaTeX z.B.
> finde ich, gelinde gesagt, anstrengend.
Auch wieder das Balastproblem.
Vielleicht würde TeX eine interne UTF-16 Darstellung gut tun. Inptfilter
mappen auf die UTF-16 Darstellung. Output-Filter mappen auf die Glyphen
verschiedener Fonts. Wenn dann noch Metrikinformationen nicht mehr
gebraucht werden, bzw. intern berechnet werden, dann braucht man pro
Font nur noch eine bzw. zwei Dateien. (Diese Ansätze in Omega vorhanden)

Grundsätzlich stimme ich dir aber zu. So wie es jetzt ist, kann man
schon mal den Verstand verlieren.
Da teilt aber TeX sich ein Grundübel mit Unix.
Ich habe auf meinem Rechner mindestens dreimal die Standart Laserwriter
fonts installiert, weil jedes Programm es anders haben will.
Und dann finden diese dämlichen Perl-Module in Gimp nichtmal die, die
Gimp ansich aber schon findet.
Schriften unter Unix = vergiß es!

> Daher erscheint es mir sinnvoller,
> ein Linux-DTP-Programm gleich konsequent auf ps/pdf auszurichten.
(Siehe oben)

> Mit
> display ghostscript (dgs) steht für die Bildschirmdarstellung ja
> mittlerweile eine geeignete Software-Grundlage zur Verfügung. 
Das ist genau die Infrastruktur, von der ich in meiner ersten Mail
sprach. Jedoch scheinen wir schon in grundlegenden Dingen eine
andere Anschauung zu haben, denn DTP ist bei nicht unbedingt mit
dem Wort GUI verbunden.

> > Ich würde es mal als Caching bezeichnen, das denke ich einfach
> > abzuschalten ist. (dvips foo.tex && rm -rf /var/lib/texmf/pk/)
> > Du hast aber die Vorteile vergessen, das MetaFont die Charakteristik
> > verschiedener Drucker, nicht nur Auflösung, berücksichtigen kann.
> 
> Was ich mich dabei frage: Was ist der Unterschied zu PPPD-Dateien für
> Postscript-Drucker?
Wenn der runde Teil eines Kommas so stark verläuft (z.B. Tintendrucker),
daß der darunterliegende schlanke Teil nur noch klobig wirkt, dann hast
du über PPPD's da keinen eingriff. Über Metafont schon, denn da läßt man
einfach den ganz dünnen Teil weg, so das dieser Bereich durch das
"Verlaufen" geschlossen wird. Hast du schon mal mit 300dpi Fonts
auf 600dpi bzw. 1200 dpi gedruckt? Dann wirst du diese Maßnahmen sehen.

> Und: Warum dauert das Aufrastern von Metafont so lange,
> während Postscript-Schrift mit Adobe Type Manager selbst auf 486er-Hardware
> in Echtzeit für Bildschirm und Drucker gerastert werden?

Im Drucker macht das eher der interne RIP. Also vergleichbar mit gs, was
ebenfalls sehr schnell geht.

Am Bildschirm werden Fonts nur in 72 oder 96 dpi genutzt. In dieser
Auflösung ist Metafont ebenfalls schnell. Außerdem vergißt du
das umwandeln/packen in das .pk Format, was auch noch Zeit braucht.
Deshalb ja das "Caching".
Außerdem hat Postscript einen geringeren Funktionsumfang bezüglich
Fonts, damit eine kleinere Laufzeitungebung. Beim Einsatz von
Multiple Master Fonts, dessen Funktionsumfang noch unter Metafont
liegt, ist ATM auch nicht mehr so fix.
PostScript ist exact auf das Notwendigste für die Schriftdarstellung
zugeschnitten. Metafont hat da mehr einen allgemeinen "Zeichnen"-Ansatz.

-----------
TeX und Metafont verfolgen sehr allgemeine und flexible Ansätze, die,
wie in jedem solchen Fall, mit einem gewissen Overhead verbunden sind.
Groß geschadet hats bisher nicht. Wer die Vorteile daraus nicht nutzen
kann, der muß eben auf Alternativen zurückgreifen.
So ist es doch eigentlich immer, oder?

Wenn wir von DTP reden, und sagen xPress un InDesign ist DTP, dann
stimme ich zu: sowas hat Linux nicht, und ja, sowas brauchen wir.
Blos ich habe oft genug miterlebt wo nach einem 4000 DM DTP-
Proggi gerufen wurde, die Leute sich dann 4 Stunde die Seele aus dem
Leib geklickt haben, und dann auch nur das dabei rauskam, was ich in
mit LaTeX in einer Stunde genauso hinbekommen hätte. Meist war
meins dann noch flexibler bei Änderungen.


Gruß Jens.