linux-l: dtp unter linux

Jens-Uwe Morawski morawski at gmx.net
Mi Feb 14 21:53:48 CET 2001


On Wed, 14 Feb 2001 Stefan Tietke wrote:
> On Fri, 9 Feb 2001, Jens-Uwe Morawski wrote:
>  
> > Dem letzteren schließe ich mich nicht an: Wenn du auf Farbverläufe
> > und Pfadtexte verzichten kannst, geht pdfLaTeX für fast alles.
> > (Vergiß LyX!)
>  
> Das ist für mich die erste grosse Frage: ist TeX, bzw. ein Ableger /
> eine Erweiterung davon die Antwort? TeX ist für vieles sehr gut
> geeignet, aber ich weiss wirklich nicht, ob es vom Design her
> für intuitives, visuelles, spontanes und grafikorientiertes Arbeiten
> geeignet ist. Das wäre eine wirklich zentrale Frage.

Mit den von dir gewählten Attributen fällt TeX natürlich aus.
Aber im Grunde kann man jede Seite durch Rahmen beschreiben.
Im Namensraum von TeX also Boxen.
Was spricht dagegen verschiedene Boxtypen zu deklarieren,
und die Boxen beliebige Formen annehmen zu lassen.
Wie man das syntaktisch beschreibt ist erstmal egal, aber auch
für ein GUI basiertes System muß man sich um so eine Beschreibung
kümmern. Ob man dann den Inhalt für die Boxen per GUI eingibt,
oder sagt
\boxcontent{<BOXID>}{Das ist der Inhalt einer Box ...}
ist doch völlig egal.

> > Das Problem bei *wirklicher* DTP-Software stellen Lizenzen und Patente
> > für Hersteller gebundene Informationen dar. (Pantone-Farbsystem,
> > Algorithmen für CMYK-Umrechnung)
> 
> Kannst Du mir dazu noch ein paar Hinweise geben? Wo genau liegen
> da die Probleme? Wenn Du das zu OT für die Liste findest, kannst es auch
> direkt an mich schicken.
> Die von Dir genannten Dinge fallen wohl in die Rubrik' Color-Management'.
> Mir ist klar, dass das ein zentraler Aspekt ist, den es zu lösen gilt,
> zumal es
> für Linux, wenn ich das richtig sehe, wohl noch _überhaupt_ keine richtige
> Lösung (im MacOS gibt es das ColorSync schon seit Version 7.x).

Ich habe keine genauen Hinweise dazu, doch wenn ich sehe was für
Lizenzen aktuelle DTP-Software vereinigt, dann kann ich mir schon ein
paar Probleme ausmahlen. Mußt nur mal im INFO-Dialog der Programme
suchen.

> > Dann die vielen Font-Formate. Da gehts im Freien nur sehr langsam voran.
> > Erst wenn diese "Infrastruktur" in Form von Bibliotheken existiert,
> > sollte man über ein ernsthaftes DTP-Programm nachdenken.
> > Sonst wird's nix. Auch in Gimp wird bis Version 2.0 keine Zeile Code
> > auf der anderen bleiben, da sich die interne Struktur als Mist
> > herausgestellt hat.
> 
> Thema 'Fonts': Zur Wahl stehen wohl TeX Metafont, PS und TrueType.
> Im professionellen Bereich dominieren wohl PS-Fonts. Hätten auch den
> Vorteil der natlos(er)en Einbindung in den Gesamtprozess. Das müsste
> aber auf jedenfall auch diskutiert werden.
Wer sagt denn das es dabei bleibt. MultipleMasterFonts sind da, was wird
mit 2-Byte-Fonts und Unicode ...?
Wer sich eine interne Darstellung nah an PostScript wählt, der
hat eigentlich schon verloren.
Der einzige Weg ist eine interne Darstellung die soweit wie
möglich abstrakt den Inhalt beschreibt.
Womit wir wieder nah an TeX und seinen Boxen wären.

> > Das beste ist man startet damit, wie der wirklich geniale
> > Absatzalgorithmus von TeX funktioniert.
> > Dann wie dieser in beliebigen durch Bezier-splines geformte
> > "Boxen" funktionieren kann.
> > Das alles am besten kombiniert mit den 4 Forderungen des
> > HZ-Algorithmus (Hermann Zapf):
> > 1. optischer Randausgleich (kann zumindest pdfTeX)
> > 2. optisches Kerning
> >  (keine Metrikinformationen mehr, Zeichen werden anhand ihrer
> >   Umrisse positioniert)
> > 3. Benutzung verschiedener Laufweiten einer Schrift, durch
> >    horizontales Skalieren. Geht nur wirklich gut mit
> >    MultipleMasterFonts
> >    (Ansätze davon in pdfTeX vorhanden)
> > 4. Absatzweiser Umbruch, nicht nur eine Zeile
> >    (kann TeX seit Urzeiten)
> 
> Hört sich auch gut an...

Ich denke das hört sich nicht nur gut an, ich denke das ist ein MUSS!
  
> > So leg los ;)
> 
> Ay. ay, Sir!

Schön zu sehen, daß es noch Leute mit Humor in dieser Liste gibt.

Gruß Jens



Mehr Informationen über die Mailingliste linux-l