Aus Illustrator oder InDesign exportierte PDFs mit Sonderzeichen in Schmuckfarbnamen erzeugen bei der PDF/X4-Erstellung bzw. -Validierung den im Betreff genannten Fehler. Kennt hier jemand vielleicht einen Lösungsansatz, der mit Acrobat-Bordmitteln durchführbar ist?

hallo,

via Druckfarbenmanager auf eine korrekt bezeichnete Sonderfarbe ohne Sonderzeichen im Namen lenken?

Edit: Über Farben Konvertieren bleibt das - meine ich - dann nach dem Speichern erhalten, über Ausgabevorschau NICHT!

Gruß

Ulrich

Antwort auf:

Lösungsansatz, der mit Acrobat-Bordmitteln durchführbar ist?

sorry, PitStop fährt bei mir immer mit...

Also, wenn denn Illustrator oder PSD nicht zur Verfügung stehen, um via Touchup-Objektbearbeitung in einem anderen Programm als Acrobat wenigstens ein Objekt mit einer richtig geschriebenen Sonderfarbe einzufärben, (auf die dann via Druckfarbenmanager gelenkt werden kann) oder keine andere PDF mit Sonderfarbe zur Verfügung steht, aus dem mittels Touchup-Werkzeug ein Objekt kurzeitig - für die Farbumlenkung - hineinkopiert werden kann ...

... fand ich mit "Bordmitteln" nur noch die Preflight Korrektur "zu Schmuckfarbe wandeln":
Das zieht aber wohl auch nur, wenn die Sonderfarbe immer in der gleichen Tonwertigkeit daherkommt, bzw nur wenige Male in verschiedenen, jedenfalls nicht bei Verläufen.

Dazu zuerst "die" (falsch benannte) Sonderfarbe in einen Alternativfarbraum konvertieren/wandeln und dann exakt diese(n) Wert(e) EINZELN in neu benannte Schmuckfarbe wandeln. Zuvor kann über Inventar-Report->Farbe ein Alternativ-Farbraumwert ermittelt werden, um das Erscheinungbild zu erhalten.

Bin mal gespannt, ob Sonderfarbbehandlungsfunktionen via Preflight in kommenden Updates von Acrobat noch erweitert werden. Ich habe (noch) Version 9, ist 10 da vielleicht schon ausgebaut worden oder "sollen" Zusatztools auch weiterhin einen Funktionsvorsprung als Reserve für die eigene Existenzberechtigung behalten?

Ulrich

Danke für deinen Einsatz, Ulrich.

Allerdings sind das für mich leider keine praktikablen Optionen.

Danke Dir für die Aufgabenstellung ;-)

Antwort auf [ kkauer ]

Allerdings sind das für mich leider keine praktikablen Optionen.

Warum denn nicht? Suchst Du eine Lösung für jemand anders? Ich wäre wirklich (angenehm) überrascht, wenn hier noch eine deutlich weniger komplizierte "nur mit Acrobat"- Lösung auftaucht...

Gruß,

Ulrich

Das PDF im Textedit öffnen, den Betroffenen Farbnamen durch Suchen/Ersetzen korrigieren und dann aus Textedit wieder mit .pdf Endung absichern. Klappt allerdings vielleicht nicht immer und ist eher ein experimenteller Weg für Freunde des Risikos, ich übernehme keine Haftung :-)

Gruss,
BERND

... die Spielregel lautet: Mit Acrobat-Bordmitteln! ;-)

Ulrich

Das es aus Photoshop heraus geht, würde ich, bevor ich das Spiel überhaupt anfange, das ganze als Bug an Adobe melden.


MfG

Thomas

---

Und wenn dir geholfen wurde, hilf uns, dies auch weiterhin zu können.
http://www.hilfdirselbst.ch/info/

---

Hallo,

ich habe das versucht zu reproduzieren und es scheint so zu sein, dass bei der Nutzung von Umlauten im Namen der in InDesign angelegten Sonderfarbe - nicht bei Sonderzeichen wie &%$ - die Prüfung anspringt.

Wenn ich mit PitStop eine neue Sonderfarbe anlege, und diese z.B. Grün nenne und ein Objekt einfärbe, kann ich eine PDF/X-4-Datei erstellen. Bei der Validierung in Acrobat ist diese dann, im Gegensatz zu der aus InDesign exportieren Datei, auch gültig.

Woher diese Fehlermeldung kommt, kann ich allerdings nicht sagen.


Gruß,
Karsten Schwarze

--------------------------
www.impressed.de

Ich würde einfach mal vermuten, dass zwar grundsätzlich UTF-8 Zeichen in den Sonderfarbnahmen vorkommen können und dürfen, sie aber beim Export aus ID nicht sauber gequoted werden, und er sich dabei verschluckt. Aus PS CS5 heraus hatte ich es heute Mittag mit "hallöläß" probiert, das gab zwar auch eine Meldung beim PDF/X-4 check in Acrobat 9, aber die kommt m.E. wo anders her:

Zitat

XMP hat keinen “RenditionClass”-Eintrag im “XMP Media Management”-Schema

MfG

Thomas

---

Und wenn dir geholfen wurde, hilf uns, dies auch weiterhin zu können.
http://www.hilfdirselbst.ch/info/

---

Antwort auf [ karsten schwarze ]

Sonderzeichen wie &%$

Sorry für den (vielleicht) unglücklich gewählten Ausdruck "Sonderzeichen", aber "&%$" sind keine und damit auch kein Problem.

Antwort auf [ Ulrich Lüder ]

Danke Dir für die Aufgabenstellung ;-)

Antwort auf [ kkauer ]

Allerdings sind das für mich leider keine praktikablen Optionen.

Warum denn nicht? Suchst Du eine Lösung für jemand anders? Ich wäre wirklich (angenehm) überrascht, wenn hier noch eine deutlich weniger komplizierte "nur mit Acrobat"- Lösung auftaucht...

Ich kenne eben auch keine praktikable Lösung, daher habe ich ja nachgefragt.
Der Lösungsansatz sollte sich aber auf das Korrigieren des "ungünstig" kodierten Namens beschränken.

Welche Version von ID bzw AI?

Olaf
--
Olaf Druemmer | Geschäftsführer
callas software gmbh | www.callassoftware.com
axaio software GmbH | www.axaio.com

Zitat

Welche Version von ID bzw AI?

ich habe mit der cs5 (id 7.0.3 und ill 15.0.1) den fehler nachvollzogen.

Antwort auf [ olaflist ]

Welche Version von ID bzw AI?

CS3 bis CS5 / Mac (andere kann ich nicht testen)

Hallo, zusammen.
Ich konnte den Fehler auch mit InDesign CS5.5 (7.5) nachvollziehen. Ebenso mit InDesign CS4(6.0.6) und InDesign CS5(7.0.4).

Importierte Sonderfarben mit Umlaut im Namen, egal ob aus Illustrator oder PhotoShop importiert.

Auch über PostScript ausgegebene und distillte PDFs konnten nicht nach PDF/X-4 konvertiert werden (Acrobat Pro 9.4.4).
Direkt aus PhotoShop gespeichert, ergab die Prüfung in Acrobat Pro keine Fehlermeldung in Richtung Farbname. Der XMP-Fehler tauchte auch auf; durch eine Konvertierung nach PDF/X-4 über den Acrobat-Preflight konnte ich diesen beseitigen.

MacBook Pro 2.4GHz | OS X 10.5.8 | Adobe CS3/CS4/CS5/CS5.5 Design Premium
*****
Mit herzlichem Gruß,
Uwe Laubender

Follow-up:
Platziere ich ein aus PhotoShop exportiertes PDF/X-4 mit z.B. Sonderfarbenname "ÄöÜß-Farbton_2", wird der Farbname in InDesign nicht mehr korrekt dargestellt. Im Acrobat hingegen schon.

Siehe angehängter Screenshot: "Farbnamen.png"

MacBook Pro 2.4GHz | OS X 10.5.8 | Adobe CS3/CS4/CS5/CS5.5 Design Premium
*****
Mit herzlichem Gruß,
Uwe Laubender

Uwe, das kann ich bestätigen. Interessnt ist in dem Zusammenhang auch, dass aus der urspürnglichen Lab-Definition der Sonderfarbe eine RGB Definition wurde!?
Immerhin sieht sie noch gleich aus ;-)


Schaue ich ins PS PDF/X-4 steht die Sonderfarbe "hallöläß" da so drin:

Zitat

14 0 obj
[/Separation/Hall#C3#B6l#C3#A4#C3#9F 16 0 R 17 0 R]
endobj

im PDF mit der PSD Datei drin,die aus ID heraus exportiert wurde:

Zitat

17 0 obj
[/Separation/Hall#9Al#8A#A7 18 0 R<</C0[100.0 0.0 0.0]/C1[85.4902 13.0 26.0]/Domain[0 1]/FunctionType 2/N 1.0/Range[0.0 100.0 -128.0 127.0 -128.0 127.0]>>]
endobj

PS verwendet 2-bytige Codierung:

#C3#B6 = ö
#C3#A4 = ä
#C3#9F = ß

ID nur 1 Byte je Umlaut:

#9A = ö
#8A = ä
#A7 = ß


MfG

Thomas

---

Und wenn dir geholfen wurde, hilf uns, dies auch weiterhin zu können.
http://www.hilfdirselbst.ch/info/

---

Antwort auf [ Thomas Richard ]

Immerhin sieht sie noch gleich aus ;-)

Hallo, Thomas!
Das ist Deinen Farbeinstellungen im InDesign geschuldet.

Hier ein Gegenbeispiel aus InDesign CS3. Siehe Screenshot: "Farbnamen_und_Darstellung_CS3.png".

Hier war der RGB-Arbeitsfarbraum bei nicht geöffneter Datei auf "eciRGB v2" eingestellt, danach neue Datei erstellt und die beiden Abbildungen platziert. Die Farbmanagement-Richtlinien für RGB und CMYK standen auf "Eingebettete Profile beibehalten".

Mit z.B. "sRGB" oder "Adobe RGB (1998)" als RGB-Arbeitsfarbraum konnte ich keine Darstellungsunterschiede zwischen den beiden Abbildungen feststellen.

MacBook Pro 2.4GHz | OS X 10.5.8 | Adobe CS3/CS4/CS5/CS5.5 Design Premium
*****
Mit herzlichem Gruß,
Uwe Laubender

Nein, ich meinte damit, dass nicht einfach der L*-Wert zu R der a*wert zu G und der b* Wert zu B umgelabelt wurde. Das mit dem Sprung von Lab auf RGB je nach verwendeter Farbe auch Verschiebungen auftreten können, ist selbstverständlich.

Bleiben allerdings die 2 Fragen:
• Warum ist der Name aus ID Heraus nicht in UTF-16
und
•Warum wird aus einer Lab-definierten Sonderfarbe plötzlich und ungefragt eine RGB definierte?

Zumal beim Platzieren eines PSDs in ID wenigstens der 2. Teil keine Probleme bereitet.


MfG

Thomas

---

Und wenn dir geholfen wurde, hilf uns, dies auch weiterhin zu können.
http://www.hilfdirselbst.ch/info/

---

Antwort auf [ Thomas Richard ]

Photoschop verwendet 2-bytige Codierung:

#C3#B6 = ö
#C3#A4 = ä
#C3#9F = ß

ID nur 1 Byte je Umlaut:

#9A = ö
#8A = ä
#A7 = ß

Hab mir die Werte gerade noch mal herausgesucht.

Die Photoshop’schen Werte entsprechen 2bytigem UTF-8.

Also ist
ö = U+00F5 korrekt als 0xC3 0xB6 codiert,
ä = U+00E4 mit 0xC3 0xA4 und
ß = U+00DF mit 0xC3 0x9F.
http://de.wikipedia.org/wiki/UTF-8


Dagegen sind die Indesign’schen Werte 1-bytig MacRoman codiert:

ö = 0x9a
ä = 0x8a
ß = 0xA7
http://de.wikipedia.org/wiki/Macintosh_Roman
Somit stimmt die Fehlermeldung in Acrobat, dass es sich nicht um eine UTF-8 Zeichenkette handelt.


MfG

Thomas

---

Und wenn dir geholfen wurde, hilf uns, dies auch weiterhin zu können.
http://www.hilfdirselbst.ch/info/

---