Ich bin mit der Darstellung von Bernds Fehler in FM 9.0.3 etwas unglücklich...
Zu genauen Interpretation der Probleme und Bugs unter FM 9.0.3(9.0p250)
muss man wissen, wie Windows und FrameMaker beim Thema Farbe "ticken".
1. FrameMaker speichert intern alle Farben in CMYK ab (nicht als RGB wie viele immer noch glauben!)
Zusätzlich bleibt der Farbname erhalten.
Die jeweiligen "richtigen" Farbwerte für die Anzeige am Monitor errechnet sich FrameMaker
im Standard mit einer simplen von CMYK nach RGB-Konvertierung (nicht andersherum!)
oder er holt sich die Werte aus der Farbbibliothek
Da der Algorithmus CMYK->RGB wegen K kein simples 1:1 Mapping sein kann,
bietet FrameMaker als Alternative zu seiner simplen internen Konvertierung an,
für Schmuckfarben die feststehenden Konvertierungswerte RGB bzw. CMYK aus den Farbbibliotheken zu nehmen,
und zwar mittels Schalter in der maker.ini:
GetLibraryColorRGBFromCYMK
Das Thema ist sehr komplex aber hervorragend dokumentiert an zwei Stellen:
1.
http://www.techknowledgecorp.com/help/color.html 2.
http://forums.adobe.com/message/1237968 Für Schmuckfarben ist noch wichtig zu wissen, dass im gesamten Druckprozess hier eigentlich keinerlei Colormanagement
und sonstige komplizierte Farbtechnologie nötig ist,
sondern nur das Hinüberretten des Farbnamens in das jeweilige Medium
(z. B. PDF), das dann die gleichen Farbbibliotheken benötigt.
Da aber RGB keine Schmuckfarben kennen kann ...
gehen bei allen Farbtranformationen nach RGB die Farbnamen flöten - sie machen ja in der RGB-Welt keinen Sinn...
Die Weltfirma Adobe könnte ja das banale Schmuckfarbenthema ganz simpel über RGB-Prozesse hinweg retten, während die unsinnigen CMYK-RGB-Konverterungen (und zurück!) im Windows-Druckprozess äußerst komplex bleiben würden.
Aber mit Adobe-eigenen Prozessen, z. B. für FrameMaker und Acrobat oder FrameMaker und einem Adobe-eigenen-PostScript-Druckprozess
könnte man ja "ganz einfach" CMYK und Schmuckfarbennamen z. B. nach PDF hinüberretten.
Den alternativen PostScript-Prozess hat FrameMaker 9 erstmals als zusätzliche(!)Option bekommen,
während eine direkte FM->PDF-Konvertierung ohne PostScript für mich an 2. Stelle der Feature-Wunschliste steht.
Um zur Frage Bugs in FrameMaker 9.0.3 weiter zu kommen,
müssen wir nun noch das grundsätzliche Windows CMYK-Drama etwas mehr untersuchen:
2. Das von Microsoft Windows zur Verfügung gestellte Drucksystem kann nur RGB, kein CMYK (zummindest bis Windows XP),
obwohl der PostScript-Treiber von Adobe kommt und CMYK natürlich kennt.
Das liegt daran, dass alle Druckprozesse im Standard über das Windows GDI (Graphical Device Interface) laufen,
das zumindest in alten Versionen(siehe oben) nur RGB und kein CMYK kennt.
Es gibt dann für spezielle einfache K(aus CMYK)- bzw. "Graustufen-Anforderungen"
noch zwei "unglücklich" benannte Schalter im PostScript-Druckertreiber:
"Grauen Text in PostScript Grau konvertieren" (Gemeint ist RGB-grauer Text).
"Graue Grafiken in PostScript Grau konvertieren". (Gemeint sind RGB-graue Pixelgrafiken).
Mit diesen Optionen kann der Windows-Druckprozess trotz RGB-Grundsatz
doch K-Werte z. B. für typischerweise schwarze oder graue Schrift ins PDF rüberretten.
Das Ganze ist aus Sicht eines lösungsinteressierten Anwenders eine blamable und miserable CMYK-Adobe-Microsoft-Ruine!
Warum zwei Weltmarktfirmen zusammen nur so ein unsinniges Konzept den Applikationen zur Verfügung stellen:
Ich denke hier ist primär die Microsoft Arroganz die Ursache.
Adobe müsste also für saubere CMYK-Lösungen den gesamten Druckprozess doppelt anbieten (mit entsprechenden Dialogen!)
einmal für die angeschlossenen Windows-Drucker und einmal jenseits vom GDI (wie bei InDesign),
was dem Adobe Management für FrameMaker sehr wohl bekannt ist.
3. Mit FrameMaker 9 kam also zusätzlich zum unveränderten(RGB-)Standard-Druckprozess einfach eine Option hinzu,
nämlich das ProstScript auf alternativem Weg zu erzeugen,
um CMYK-Werte und Schmuckfarbennamen in das PostScript und damit in das PDF hinüberretten zu können..
Tja und das Schreiben von PostScript-Treibern soll ja ein immenser Knochenjob sein,
also bekamen wir in FrameMaker leider eine unausgereifte, alternative PostScript-Lösung, sprich eine mit Bugs.
Jetzt können wir aus Anwendersicht, das ganze Windwos-Druckkonzept als Bug bezeichnen,
oder wir nehmen den miserablen Microsoft(!)-Zustand unter Windows erst einmal hin und fragen nur,
ob die Ergänzungen in FM 9.0.3 ohne Bugs sind.
Und damit wünsche ich mir das Dokument von Bernd etwas anders umgesetzt.
Das Thema ist ja: Dokument nach PDF konvertieren, was passiert mit den Farben und den Fonts?
Zwei Vorgehensweisen gibt es:
A) Aufruf über Datei drucken = das ist der bisherige Windows Standard-Druckprozess, d.h. keine CMYK-Option!
Es gilt also alles wie auch bereits in FM 7,8: Informationen unter 1 beachten
B) Aufruf über "Sichern als PDF"
Nur hier gibt es den Optionsschalter: CMYK-Farben nach RGB konvertieren
...aber FrameMaker konvertiert da selber nix nach RGB!
B.1 Aktiviert = Windows Standard-Druckprozess, siehe also unter A,
B.2 Deaktiviert = Alternativer PostScript Prozess
Mit B.2 sollte funktionieren: Schmuckfarben und deren Aufhellungen bleiben erhalten, CMYK-Werte bleiben erhalten
Und natürlich sollten alle Fonts verarbeitet werden, ob eingebettet oder nicht.
So und nun hätte ich gern die Liste der Bugs für FM 9.0.3,
was mir aus dem Beispieldokument nur sehr, sehr indirekt klar wird...
Liste der Probleme mit Bezug auf Michael Müller Hillebrand
(nur Nicht XML-Themen) 1. Zeichen bestimmter Fonts erscheinen nicht oder sind ersetzt durch Times New Roman
Getestete Beispiele: Cambria Math, SanvitoPro, Helvetica Neue LT Com, Helvetica Neue LT W1G auch Helvetica Neue Com-Fonts, Meta Pro
Logik dieser Fonts?
Gilt nur für die neue Option B.2: CMYK nicht konvertieren
Alle diese Fonts funktionieren, wenn der Standard-Windows-Druckprozess gewählt ist (Option B.1 CMYK-nach-RGB konvertieren aktiv)
2. Die OpenType Paar-Unterschneidung (Kerning) von Fonts (Cambria und andere) führt zu unsauberen Kerning-Ergebnissen in FrameMaker and PDF
gilt für alle Optionen
3. EMF-Grafiken von Visio können nicht mit Option B (CMYK nicht konvertieren) gedruckt werden, man erhält nur schwarze Streifen
gilt nur für die neue Option B.2 (CMYK nicht konvertieren)
4. Text in der PDF-Tag-Struktur (gilt nicht für die normale Layout-Seite) verliert alle Leerzeichen zwischen Wörtern beim Druckprozess "Speichern als PDF"
Trifft denke ich für alle Optionen zu.
5. Aufhellungen von Schmuckfarben als Zellen-Schattierung in Tabellen wird nicht berücksichtigt (= immer 100 %)
gilt nur für die neue Option B.2 (CMYK nicht konvertieren)
Dieter Gust
Leitung Forschung und Entwicklung
itl Institut für technische Literatur AG
Moosacher Str. 14
80809 München
Tel: +49 (089) 892623-600
http://www.itl.eu
itl – Ihr Full-Service-Dienstleister
- Übersetzungsdienstleistungen
- Technische Dokumentation
- Produkt- & Prozesslösungen
- Wissenslösungen
Besuchen Sie unsere neuen Produkt-Websites
http://www.i-flow.itl.info Die Logistiklösung für Dokumentation, Übersetzung und Publishing
http://www.i-match.itl.info Die intelligente Autorenunterstützung
http://www.i-frame.itl.info Die FrameScript-Lösung für effizientes Arbeiten in FrameMaker
http://www.itl.eu/19.html?&tx_ttnews[tt_news]=141&tx_ttnews[backPid]=1&cHash=66be5ab82d
15. f.i.t. FrameMaker Informationstagung
FrameMaker 9, die Adobe Technical Communication Suite und die Praxis des Desktop Publishing
Die itl-FrameMaker-Profis und Adobe stehen zu Ihrer Verfügung.
Do 22.10.2009 itl München
Vorstand: Christine Wallin-Felkner, Aufsichtsratsvorsitzender: Bernd R. Weber
Eingetragen beim Handelsregister des Amtsgerichts München unter HRB 135571, USt.-ID: DE129390101