Mac OS X, 10.3.9
ID 3.01 -> ID 4.0.4

hallo IDler,

folgendes problem: wir öffnen ein dokument aus ID 3.01 in 4.0.4 und drucken. ergebnis ist ein leicht rotstichiger - ehemals gelber hintergrund (oder was anderes passt nicht - egal!)
geprüft haben wir: farbeinstellungen, profile, usw - alles OK! der druck sollte passen.

nehme ich eine seite dieses frisch konvertierten dokuments (oder auch nur ein element davon) und kopiere sie/es in ein neues 4.0.4er dokument (farbmanagement, druckersettings, usw unverändert und überprüft!!!) passts! das selbe ergebnis wie in 3.01 !!

habe im forum schon gesucht! leider habe ich keinen ähnlichen fall gefunden! wir haben das problem aber an allen computern. reproduzierbar!

danke für jede hilfe,

ulf neubauer

Hallo Ulf,

Sieht wie ein Farbmanagement-Problem aus. Wenn du eine
neue Datei erstellst wird die mit deinen aktuellen
Arbeitsfarbraum-Einstellungen getaggt. Bei der Datei aus ID CS1
war vielleicht eine andere Einstellung aktiv, dann wirst du beim
Öffnen in ID CS2 eine Profilabweichungs-Meldung bekommen?
Was hast du da angegeben? Sind die CMS-Einstellungen identisch?
Sind auch die Einstellunegn im Druckertreiber selbst identisch?

Gruß,
Sacha Heck
.

Es könnte auch sein, das es damals falsch parametriert war. Auch dann kommt ihr jetzt zu einem anderen Ergebnis.
Was nun falsch ist, und was nicht, ist ja immer die Frage, was man zur Referenz erhebt. Im Normalfall das ältere, aber das muss nicht immer das richtigere sein.

hallo zusammen! danke fürs mitdenken ;-)

aber nein, ich habe farbmanagement bereits in ein paar workflows eingeführt (will sagen: ich kenne mich damit ein bischen aus ;-) und bin mir sicher, dass die einstellungen identisch sind... ich habe dieses problem einen halben tag lang versucht einzugrenzen. sowas wie bei diesem kunden hatte ich noch nicht... ich tippe eigentlich auf einen bug. das in einem testworkflow nachzustellen wäre für mich allerdings sehr aufwendig, da wir nirgends mehr 10.3.x haben :-)
ich werde das diese woche bei mir mal innerhalb einer 10.4.x umgebung testen. habe mir vorsichtshalber die dateien mitgenommen...

zur diskussion, vielleicht liegt hier ja doch der hund begraben:
ID einstellungen: (sRGB/CMYKhausprofil/15%/AUS/AUS/relativ) ... so in etwa zumindest.
den dateien selbst sind keine profile zugewiesen und den bildern auch nicht. ich habe das problem bei technischen farben wie hintergründen, aber auch bei bildern.

irre ist halt, dass ich keine weitere einstellung finde, die sich darauf auswirken könnte (farbräume unter farbeinstellungen / profile zuweisen / proof einstellungen / einstellungen beim drucken / druckertreiber)
das passt alles.

ach so: mit iso profilen passiert das selbe! diese können wir aber aus anderen gründen nicht einsetzen...

lg

ulf

Ist im Druckfenster unter den Farbmanagement-Optionen "InDesign bestimmt Farben" eingestellt? Diese Einstellung gab es in der CS1-Version noch nicht und sie hebelt normalerweise manche "Profilneurosen" aus - zumindest beim Drucken.

Wenn es daran nicht liegt, weiß ich auch keine Lösung. Viel Glück!

designette

ja, so ist es.
im alten ID ist das "druckerprofil" angegeben und oben ist "Dokument" aktiviert (nicht proof)
im neuen ID ist "ID bestimmt Farben" und das "druckerprofil" drin und auch "Dokument"...

somit sollte er eigentlich in beiden versionen als "quellfarbraum" die arbeitsfarbräume nehmen und als ziel, mein druckerprofil. da wir nur cmyk daten haben, ohne getaggte profile sollte da eigentlich nichts dazwischen funken (vor allem nicht bei den technischen farben - und die verreißt es ja auch)

nachdem offensichtlich niemand dieses problem kennt, werde ich es in einer testumgebund nachstellen müssen. ich behaupte es ist ein bug, der auftritt wenn man 10.3.9 und ID nutzt. weil keiner unserer 10.4er kunden hat das problem und die wenigsten unserer kunden schrubben noch mit 10.3 rum. allerdings tritt das bei diesem workflow auf etlichen rechnern auf. es ist also kein einzelfall!

normal verlagere ich das farbmanagement in das rip des druckers. das geht aber hier nicht... deshalb haben wir den fehler vermutlich erst entdeckt.

es ist verhext...

danke und lg

ulf