hilfdirselbst.ch
Facebook Twitter gamper-media
« « 1 2 » »  
Be.eM  M  S
Beiträge: 2958
3. Mär 2009, 15:22
Beitrag #1 von 19
Bewertung: |||
(22041 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Hallo miteinander,

eine gewisse Zwiespältigkeit macht sich im Moment bemerkbar. Einerseits soll FM9 ja die bisherigen Farb-Probleme mit RGB etc. lösen, andererseits gibt's da doch ein paar Stolpersteine, die nach wie vor zu unkorrekter PDF-Ausgabe führen. Ich habe mal ein paar Tests gemacht, welche dieser PDF entnommen werden können:

http://www.meissner-dokuteam.de/...est_fm9_p196_mdt.pdf

Kurzfazit: Es wird besser, aber noch ist Vorsicht angesagt. Abhängig vom Verfahren kann's auch noch gnadenlos in die Hose gehen ;-)

Ich habe das Thema jetzt mal "Sticky" gemacht, weil ich persönlich es für sehr wichtig halte. Wenn kommende Bugfixes daran etwas ändern, werde ich auch das melden.

Grüße,
Bernd
---------------
cavete fenestras et nubes! Top
 
X
Be.eM  M  S
Beiträge: 2958
4. Mär 2009, 12:02
Beitrag #2 von 19
Beitrag ID: #387958
Bewertung:
(21940 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Kleines Update in der PDF, ein neues Sternchen:

Auch WMF/EMF-Vektorgrafiken werden in einer PDF zum Pixelbild umgewandelt. Allerdings zu einem 300dpi-Pixelbild, während die platzierten PDFs zu einem 72dpi-Pixelbild werden.

Grüße,
Bernd
---------------
cavete fenestras et nubes!
als Antwort auf: [#387800] Top
 
Be.eM  M  S
Beiträge: 2958
18. Mär 2009, 11:47
Beitrag #3 von 19
Beitrag ID: #389917
Bewertung:
(21793 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Neuer Test, basierend auf dem FrameMaker 9.0.1-Update (p230):

http://www.meissner-dokuteam.de/...est_fm9_p230_mdt.pdf

Ergebnis kurzgefasst: Wieder ein Schritt. PDF als importiertes Grafikformat funktioniert wieder wie gewünscht (Vektor, Farben bleiben erhalten).

Grüße,
Bernd
---------------
cavete fenestras et nubes!
als Antwort auf: [#387958] Top
 
Be.eM  M  S
Beiträge: 2958
1. Okt 2009, 12:41
Beitrag #4 von 19
Beitrag ID: #409877
Bewertung:
(21114 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Der nächste Test, mit FM 9.0.3 (p250):

http://www.meissner-dokuteam.de/...m9_p250_cmyk_mdt.pdf

Fazit: Unverändert, aber die neue Erkenntnis gewonnen, dass der Schalter "CMYK Farben in RGB umwandeln" beileibe nicht alle CMYK-Farben in RGB umwandelt. Vielmehr wird ganz einfach das Verhalten von alten FM-Versionen (bis einschließlich 8) wieder hergestellt, bei dem folgende Dinge passierten:

- Text: Schwarz bleibt Schwarz (Graustufen)
- Text: Farbe wird RGB
- TIFF (Graustufen und CMYK) werden RGB
- EPS (Graustufen, CMYK, Spot) bleibt unberührt, wird als Grau/CMYK/Spot in die PDF geschrieben.

Der Eindruck entsteht also, dass die FM9-"Farbkonvertierung" die Bugs der alten Version zum einschaltbaren Feature macht.

Bernd
---------------
cavete fenestras et nubes!
als Antwort auf: [#389917] Top
 
Dieter Gust
Beiträge: 13
2. Okt 2009, 14:22
Beitrag #5 von 19
Beitrag ID: #410010
Bewertung:
(21087 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


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
Dieter Gust
itl AG
als Antwort auf: [#409877] Top
 
Be.eM  M  S
Beiträge: 2958
2. Okt 2009, 15:39
Beitrag #6 von 19
Beitrag ID: #410022
Bewertung:
(21083 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Antwort auf [ Dieter Gust ] Ich bin mit der Darstellung von Bernds Fehler in FM 9.0.3 etwas unglücklich...


Hallo Dieter,

gleich unglücklich? Ich danke dir für die ausführlichen Erläuterungen, die natürlich in meiner Beschreibung gefehlt haben, aber meine Intention war hier eigentlich ganz simpel: Ich habe FM9 an dem gemessen, was Adobe prinzipiell kann (CS-Familie) und für FM 9 versprochen hat. CMYK-PDF ohne Abstriche. Alles andere ist traditionelles FM-Verhalten in Bezug auf die ebenso traditionellen WIN-PostScript-Probleme und gilt schon fast seit Jahrzehnten.

Antwort auf [ Dieter Gust ] 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".


Die tiefe Kenntnis dieser Sachverhalte war die Grundlage für alle bisherigen Workarounds, spätestens seit der Eliminierung der Mac-Version, ja. Aber da sitzt meine Messlatte nicht (mehr).


Antwort auf [ Dieter Gust ] 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:


Nein, meines Erachtens nicht. Das gilt für das generelle Verhalten von FM x bis FM8, aber nicht mehr für FM9. Wie gesagt, hier stelle ich ganz egoistisch meine Erwartungshaltung in den Vordergrund. Geht das versprochene und verkaufte Feature, oder nicht?


Antwort auf [ Dieter Gust ] 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.


Da FM auf dem Mac einwandfreie Farben lieferte, ist die Identifizierung von Microsoft als ignorantem Schnöselhaufen hier einfach :-)

Antwort auf [ Dieter Gust ] 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.


Genau das ist der Punkt. Adobe kann das ja. Also warum hier nicht?


Antwort auf [ Dieter Gust ] 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...


Dieses Beispieldokument war von vorneherein nur so konzipiert, dass der Weg "B.2" getestet wird. Also das Feature, das für mich einer der relevantesten Unterschiede zu FM 8 und älter ist. Ich hätte natürlich eine zusammenfassende Liste ans Ende hängen können, bezüglich der nicht (wie versprochen) funktionierenden Features. Kann ich auch noch tun, aber eigentlich steht's in der Tabelle. Der Sinn des Neutestens der Variante A erschließt sich mir allerdings nicht. Und zu "B.1" habe ich nur vermerkt, dass die Bezeichnung "CMYK... konvertieren" irreführend ist, da nicht konvertiert wird.


Antwort auf [ Dieter Gust ] 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


Diesen Bug habe ich bereits im April kundgetan http://forums.adobe.com/message/1916080#1916080 und außerdem nebst Testdokumenten an Adobe als Bugmeldung eingereicht. Darüber hinaus habe ich bezüglich der Fontproblematik auch private Kommunikation mit Arnis Gubins gehabt, der als "Community Expert" offensichtlich Kontakt zu den Programmierern hat und die Patches vor deren Erscheinen testen kann, was der "herkömmliche" Betatester nicht kann. Seitdem sind zwei FM-Patches gelaufen, von denen keiner den Bug behoben hat. Das letzte Testdokument (9.0.3) liegt hier: http://www.meissner-dokuteam.de/...t_fm903_cmyk_rgb.pdf. Ich habe auch schon während der Betaphase den Bug mit dem Ignorieren virtueller Fonts (CE, CYR etc.) gemeldet, welcher jetzt erst mit dem dritten Patch seit Release behoben wurde.

Du siehst also, ich bemühe mich… :-)

Schöne Grüße,
Bernd
---------------
cavete fenestras et nubes!
als Antwort auf: [#410010] Top
 
Be.eM  M  S
Beiträge: 2958
2. Okt 2009, 15:49
Beitrag #7 von 19
Beitrag ID: #410024
Bewertung:
(21080 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Antwort auf [ Dieter Gust ] 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



Nachtrag: Die Logik dahinter hat sich mir noch nicht erschlossen, obwohl ich natürlich auch schon gesucht habe. Ähnliche Probleme habe ich ja auch mit diversen asiatischen Fonts, und hier ist zumindest für mich ein Muster sichtbar, bei dem relativ häufig ein bestimmter Schnitt (Medium, W5) nicht funktioniert, andere der gleichen Familie aber schon. Irgendsowas müsste man bei den "normalen" OTFs halt auch herausfinden.

Schöne Grüße,
Bernd
---------------
cavete fenestras et nubes!
als Antwort auf: [#410010] Top
 
Dieter Gust
Beiträge: 13
2. Okt 2009, 17:46
Beitrag #8 von 19
Beitrag ID: #410044
Bewertung:
(21060 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Antwort auf [ Be.eM ] gleich unglücklich? ".


Nun ja, weil die FM RGB-Konvertierung halt kein simpler FM-Bug ist, wie du ja selbst mit "leuchtenden Mac-Augen" sagst.

Antwort auf [ Be.eM ] Die tiefe Kenntnis dieser Sachverhalte war die Grundlage für alle bisherigen Workarounds, spätestens seit der Eliminierung der Mac-Version, ja. Aber da sitzt meine Messlatte nicht (mehr).

Sehe ich genau so und ärgere ich mich über das CMYK-Halb-Feature.
Drum will ich ja auch nur ein Dokument haben, dass genau nur dessen Bugs dokumentiert, d.h. die ausgeschaltete Option "CMYK nach RGB konvertieren"
und da darf auch keine PDF-joboption (!) die Farbe konvertieren! Also "Farbe nicht ändern" wählen.

Als test ich mal kurz....
Feature und Verhalten von FM 9.0.3. Im Folgenden ist das erwartete Verhalten: Die Farbe in FM und die Farbe im PDF sollen identisch sein!
FM-Text Schwarz K 100 = funktionierte in meinem Test
FM-Text Aufhellung von K100 = funktionierte in meinem Test
FM-Text Pantone-Spot = Pantone Spot = funktionierte in meinem Test
FM-Text Aufhellung von Pantone spot = funktionierte in meinem Test nicht!
FM-Objekt Pantone-Spot: = funktionierte in meinem Test
FM-Objekt Aufhellung Pantone-Spot:= funktionierte in meinem Test nicht!
EPS-Import (Pantone-Spot, oder RGB oder )wie die Quelle = funktioniert wie immer!
AI-Import = ...
PDF-Import = ...
WMF/EMF-Import Vektor (RGB) = RGB Vektor = ? auch unter 9.0.3 noch Pixel? noch nicht getestet
TIF-Import (CMYK) = ...
TIF-Import (Graustufen) = ...
Mein Ergebnisse kann ich aus Deinem Dokument nicht 1:1 interpretieren...

Gruß Dieter
Dieter Gust
itl AG
als Antwort auf: [#410022] Top
 
Be.eM  M  S
Beiträge: 2958
2. Okt 2009, 18:57
Beitrag #9 von 19
Beitrag ID: #410051
Bewertung:
(21050 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Antwort auf [ Dieter Gust ] Nun ja, weil die FM RGB-Konvertierung halt kein simpler FM-Bug ist, wie du ja selbst mit "leuchtenden Mac-Augen" sagst.


Stimmt, da war ich in meiner Formulierung unpräzise, man muss das im OS-Kontext betrachten :-)


Antwort auf [ Dieter Gust ] Sehe ich genau so und ärgere ich mich über das CMYK-Halb-Feature.
Drum will ich ja auch nur ein Dokument haben, dass genau nur dessen Bugs dokumentiert, d.h. die ausgeschaltete Option "CMYK nach RGB konvertieren"
und da darf auch keine PDF-joboption (!) die Farbe konvertieren! Also "Farbe nicht ändern" wählen.


?? Habe ich da was übersehen? Mit der gewählten Joboption "High Quality Print" findet keine Farbänderung statt. Ich habe den Test nochmal wiederholt mit einer komplett neu gebastelten Joboption, in der überhaupt nichts mehr angefasst wird (soweit möglich). Gleiches Ergebnis.

Antwort auf [ Dieter Gust ] Als test ich mal kurz....
Feature und Verhalten von FM 9.0.3. Im Folgenden ist das erwartete Verhalten: Die Farbe in FM und die Farbe im PDF sollen identisch sein!


OK, testen wir…

Antwort auf [ Dieter Gust ] FM-Text Schwarz K 100 = funktionierte in meinem Test


Steht bei mir in der Spalte "Korrekt…"

Antwort auf [ Dieter Gust ] FM-Text Aufhellung von K100 = funktionierte in meinem Test


Habe ich nicht getestet.

Antwort auf [ Dieter Gust ] FM-Text Pantone-Spot = Pantone Spot = funktionierte in meinem Test


Steht bei mir unter "nicht richtig", da die Farbe nicht als Pantone, sondern als CMYK ausgegeben wird.

Antwort auf [ Dieter Gust ] FM-Text Aufhellung von Pantone spot = funktionierte in meinem Test nicht!


Habe ich nicht getestet.

Antwort auf [ Dieter Gust ] FM-Objekt Pantone-Spot: = funktionierte in meinem Test
FM-Objekt Aufhellung Pantone-Spot:= funktionierte in meinem Test nicht!


Funktioniert generell nicht, wird beides CMYK statt Pantone. Subjektiv aber besser als RGB ;-)

Antwort auf [ Dieter Gust ] EPS-Import (Pantone-Spot, oder RGB oder )wie die Quelle = funktioniert wie immer!
AI-Import = ...
PDF-Import = ...


EPS und Illu-PDF habe ich auch in meiner Tabelle, dito.

Antwort auf [ Dieter Gust ] WMF/EMF-Import Vektor (RGB) = RGB Vektor = ? auch unter 9.0.3 noch Pixel? noch nicht getestet


Ja, immer noch Pixel, steht so in meiner PDF.

Antwort auf [ Dieter Gust ] TIF-Import (CMYK) = ...
TIF-Import (Graustufen) = ...


Funktionieren beide, steht auch in meiner PDF unter "Korrekt…"

Antwort auf [ Dieter Gust ] Mein Ergebnisse kann ich aus Deinem Dokument nicht 1:1 interpretieren...


Naja, 90% davon stehen drin. Linke Spalte = "OK", rechte Spalte "Nicht OK". Natürlich hätte ich mehr Seiten mit noch mehr Details und Varianten testen können, aber so weit finde ich das nicht von deinen Ergebnissen weg.

Schöne Grüße,
Bernd
---------------
cavete fenestras et nubes!
als Antwort auf: [#410044] Top
 
Dieter Gust
Beiträge: 13
5. Okt 2009, 17:20
Beitrag #10 von 19
Beitrag ID: #410168
Bewertung:
(20949 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


FM-Text Aufhellung von K100 = funktioniert
Antwort auf [ Be.eM ] Habe ich nicht getestet.


Dokument updaten?

FM-Text Pantone-Spot = Pantone Spot = funktioniert
Antwort auf [ Be.eM ] Steht bei mir unter "nicht richtig", da die Farbe nicht als Pantone, sondern als CMYK ausgegeben wird.


Tja frech wie ich bin, meine Vermutung - falsche Parameter:
a) Falsche Joboption? "Press Ready" hat die Farb-Option alle Farben nach CMYK konvertieren
b) Falsche Interpretation der Farbe im PDF?

Funktioniert ja alles bei mir...

FM-Text Aufhellung von Pantone Spot = Achtung!
Korrektur meines eigenen Test-Ergebnisses:
Acrobat 9.1.3 zeigt die Spot Color-Aufhellung im Standard komischerweise als 100 % Spot - nur die visuelle Erscheinung (falsche Grundeinstellung?
Schalte ich jedoch auf Druckvorschau wird auch die Spotfarben-Aufhellung richtig angezeigt!

Antwort auf [ Be.eM ] Habe ich nicht getestet.


Dokument updaten...?

FM-Objekt Pantone-Spot: = funktioniert!
FM-Objekt Aufhellung Pantone-Spot= Achtung!
Korrektur meines eigenen Test-Ergebnisses:
Acrobat 9.1.3 zeigt die Spot Color-Aufhellung im Standard komischerweise nicht an (falsche Darstellung in Acrobat?)
Schalte ich jedoch auf Druckvorschau, wird auch die Spotfarben-Aufhellung richtig angezeigt!

Also der gleiche Widerspruch von mir zu Deinem Testergebnis!

Bei Tabellen-Schattierungen funktionieren die Aufhellungen von Spot-Farben jedoch nicht und werden immer als 100-%-Spot angezeigt

Das Ganze ist also ganz schön kompliziert...
Gruß Dieter

Edit: Reply-Tags auseinanderklabüstert ;-)
Dieter Gust
itl AG
als Antwort auf: [#410051]
(Dieser Beitrag wurde von Be.eM am 5. Okt 2009, 17:57 geändert)
Top
 
Be.eM  M  S
Beiträge: 2958
5. Okt 2009, 17:49
Beitrag #11 von 19
Beitrag ID: #410173
Bewertung:
(20943 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Antwort auf [ Dieter Gust ] Dokument updaten?


Hallo Dieter,

ja, bei Gelegenheit.


Antwort auf [ Dieter Gust ] Tja frech wie ich bin, meine Vermutung - falsche Parameter:
a) Falsche Joboption? "Press Ready" hat die Farb-Option alle Farben nach CMYK konvertieren
b) Falsche Interpretation der Farbe im PDF?


Tja, deine Frechheit in Ehren, aber ich sagte nicht "Press Ready", sondern "High Quality Print" (plus 2. Test mit einer neudefinierte Joboption), und ich habe die Farben in den PDFs nicht mit Acrobat-Bordmitteln, sondern mit PitStop geprüft. Die Joboptions haben sicher nichts geändert.


Antwort auf [ Dieter Gust ] Dokument updaten...?


Nö, jetzt grad extra nicht mehr. Dafür habe ich Sachen getestet, die Du nicht getestet hast ;-P


Antwort auf [ Dieter Gust ] Also der gleiche Widerspruch von mir zu Deinem Testergebnis! (…)

Das Ganze ist also ganz schön kompliziert...


Ich habe auch langsam das Gefühl, dass die Anzahl der Variablen ins Unendliche wächst. So z.B. auch das anzeigende Programm. Ich habe für meine Tests an den fertigen PDFs im Moment Acrobat 8 Pro mit PitStop 7.22 verwendet. Wenn jetzt Acrobat auch noch andere Farbräume anzeigen würde als PitStop, krieg' ich einen Vogel...

Schöne Grüße,
Bernd
---------------
cavete fenestras et nubes!
als Antwort auf: [#410168]
(Dieser Beitrag wurde von Be.eM am 5. Okt 2009, 17:50 geändert)
Top
 
Be.eM  M  S
Beiträge: 2958
5. Okt 2009, 20:33
Beitrag #12 von 19
Beitrag ID: #410179
Bewertung:
(20923 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Antwort auf [ Dieter Gust ]
FM-Objekt Pantone-Spot: = funktioniert!



Hallo Dieter,

ein Update in dieser Sache, das allerdings nicht wirklich klärend wirkt. Das Chaos wächst…
Ich habe jetzt mal Text mit zwei verschiedenen Pantone-Farben getestet, und zwar:

- Pantone-Farbe, die ursprünglich von extern (per EPS) importiert wurde, und anschließend in FM weiter für eigene Objekte verwendet. Diese Pantone-Farben werden zu CMYK, trotz Einstellung "Schmuckfarbe". Das war mein Testergebnis.

- Pantone-Farbe, die intern mittels der FM-Farbbibliothek definiert wurde. Diese Farbe bleibt auch in der PDF Pantone (das war dein Ergebnis).

Der Unterschied besteht letztlich nur im angezeigten Farbnamen, nicht unter "Name", sondern "Name der Farbe" (nicht-editierbares Feld unter "Name"), der bei der ersten Variante fehlt.

Somit gesellen sich die importierten Pantone-Farben funktional zu den FM-internen Schmuckfarben, die auch nicht als solche exportiert werden.

Schöne Grüße,
Bernd
---------------
cavete fenestras et nubes!
als Antwort auf: [#410168] Top
 
Dieter Gust
Beiträge: 13
6. Okt 2009, 08:43
Beitrag #13 von 19
Beitrag ID: #410200
Bewertung:
(20893 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Super, jetzt sind wir doch Dank Dir einen Riesenschritt weiter:
Nicht behobener Bug in FM 9.0.3
"FameMaker übergibt nur Schmuckfarben dann richtig ins PDF über die neue CMYK-Option, wenn diese Schmuckfare in FM einen Namen per Farb-Bibliothek definiert bekommen hat: Anzeigefeld "Name der Farbe" (Das Feld ist mir nie vorher aufgefallen ...)

Richtig, so?

Schöne Grüße zurück
Dieter Gust
Dieter Gust
itl AG
als Antwort auf: [#410179] Top
 
Be.eM  M  S
Beiträge: 2958
6. Okt 2009, 14:45
Beitrag #14 von 19
Beitrag ID: #410262
Bewertung:
(20880 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Antwort auf [ Dieter Gust ] "FameMaker übergibt nur Schmuckfarben dann richtig ins PDF über die neue CMYK-Option, wenn diese Schmuckfare in FM einen Namen per Farb-Bibliothek definiert bekommen hat: Anzeigefeld "Name der Farbe" (Das Feld ist mir nie vorher aufgefallen ...)

Richtig, so?


Hallo Dieter,

ob der fehlende Name die Ursache ist, kann ich nicht feststellen, da dieses Feld nicht editierbar ist. Es ist nur ein INDIZ, das ich bemerke. Aber der Sachverhalt trifft soweit zu.

Ich habe jetzt nochmal eine neue Test-PDF erstellt, die hoffentlich deinen Wünschen an Präzision genügt. Ich habe hier nur FM-eigene Elemente (Text, Grafikobjekt) verwendet, keine importierten Bilder. Für alle habe ich jeweils unterschiedliche Farben benutzt, und das Ergebnis eingetragen. Bei den ersten vier Objekten habe ich auch die resultierenden PitStop-Screens beigefügt. Bei den Texten sind die Ergebnisse analog.

Dieser Test bestätigt außerdem, was du weiter oben festgestellt hast: Aufhellungen von FM-Pantone-Farben erscheinen in der "Normalansicht" der PDF als 100%. Erst wenn man die Überdrucken- oder Ausgabevorschau aktiviert, werden diese Objekte korrekt angezeigt. Die PitStop-Analyse der Aufhellung zeigt den korrekten Wert (hier 50%) an.

Siehe PDF: http://www.meissner-dokuteam.de/...0_FM_elements_A3.pdf

Schöne Grüße,
Bernd
---------------
cavete fenestras et nubes!
als Antwort auf: [#410200] Top
 
Dieter Gust
Beiträge: 13
6. Okt 2009, 16:43
Beitrag #15 von 19
Beitrag ID: #410278
Bewertung:
(20866 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen

FM 9 und Farben in PDFs... getestet


Echt Super!
FM-eigene Schmuckfarben werden also wie importierte Schmuckfarben nach CMYK konvertiert - konnte das gerade im Test bbestätigen ("Immerhin" die Aufhellung bleibt erhalten)
In Deinem Dokument fehlt nur noch die fehlerhafte Umsetzung bei der Tabellen-Zellen-Schattierung: Hier werden ja Spot-Farben-Aufhellungen von FM-Spotfarben einfach auf 100-%-Spotfarbe gesetzt.

Das Acrobat die richtige Aufhellung der Spotfarbe im Standard falsch (als 100 % ) anzeigt - welcher Acrobat-Experte kann mir die Logik erklären?
Oder gehört das zur Liste der unsäglichen Acrobat 9-Probleme
http://www.prepress.ch/.../Acro91_buglist.html

Nun bräuchte ich (wir anderen freudigen Tester) noch das FM-Dokument, um es Adobe zu schicken und noch weitere Bugs evtl. vielleicht "hineinzudokumentieren".
Und dabei überlege ich mir gerade, ob ein generelles englisches FM-Test-Template Sinn macht…
Gruß Dieter
Dieter Gust
itl AG
als Antwort auf: [#410262] Top
 
« « 1 2 » »  
X