Hallo Alex,

Zitat

Man könnte die Einstellungen unter "Zeichenfarbe" auch wie in der Anlage einstellen.

Ich will meinen Vorschlag nochmal erläutern:
Ich vermute mal, dass in der Prozesskette an irgendeiner Stelle nicht der 85%-Farbton verwendet wird, sondern auf die Basisfarbe zugriffen wird. Lösche doch mal die beiden Farbtonfelder in der Farbpalette und nimm die Prozenteinstellungen ausschließlich über die Zeichenformate vor. Vielleicht lässt das Problem dadurch umgehen.

Viele Grüße Peter

Hallo, frischhut!

Ich komme ja hier ziemlich spät zur Party. ;-)

Habe Deine InDesign-Datei heruntergeladen und in InDesign CS3 v5.0.4.682 auf Mac OSX 10.6.8 geöffnet. Ich kann den Bug *nachvollziehen*.

Wie ich sehe, hast Du die Datei mit der gleichen InDesign-Version auf Mac OSX 10.7.5 erstellt. Hm. Die Censhare-Plugins habe ich natürlich nicht installiert.

Aber was mir aufgefallen ist: Hier wurde *nicht* mit Absatzformaten gesetzt, nicht einmal mit "[Einfacher Absatz]", sondern für den Anwender nicht direkt sichtbaren Absatzformat namens "[Kein Absatzformat]".

Die Formatierung wird, die Formulierung sei erlaubt, Quark-Stile-mäßig, ausschließlich versucht mit Zeichenformaten zu erzielen. Das kann auch mal in die Hose gehen…

Unabhängig davon, dass ich das für äußerst gefährlich halte, besitzt der Absatz, der diesen Bug zeigt, eine Abweichung. Wird diese Abweichung getilgt (Menü Absatzformat), dann hat sich auch der Bug erledigt. Wenn es denn überhaupt ein Bug ist…

Ich habe da eine andere Vermutung, muss aber den Fall aber noch genauer untersuchen.

Kommen wir zum Übersetzungs-Workflow: Ich nehme stark an, dass im Laufe dieses Workflows eine inx-Austauschdatei erzeugt wird, die nach der Übersetzung zurückgespeichert und in InDesign CS3 wieder geöffnet wird.

Ahme ich diesen Workflow nach, indem ich aus InDesign CS3 eine inx-Datei exportiere und wieder dort öffne, ist das Kind bereits in den Brunnen gefallen, sprich die Farbe der Überschrift in Zelle 1 Deiner Beispieldatei hat sich geändert. Nämlich in die besagten 100% der Volltonfarbe. Also kein Farbtonfeld mehr! Das ist dann vermutlich auch so gedruckt worden. Also abweichend vom Design in Deinem Layout.

Wende ich nun auf einige wenige Zeichen des falsch eingefärbten Textes in der *Palette Absatzformate* unter Absatzformatoptionen die Option "Abweichungen löschen" an, ist für genau die Auswahl der Zeichen der alte Zustand Deiner Layoutdatei wieder hergestellt, die Färbung also korrekt: Der korrekte Farbton mit den 85% und auch oben sind die 85% eingetragen.

Anbei die exportierte inx-Datei zum Ausprobieren: "85Prozent.inx".
Dazu die von mir korrigierten Abweichungen in ein paar Zeichen ebenfalls als inx-Datei. Da wird das Phänomen schön sichtbar: "85Prozent.inx.indd.inx".

Per ExtendScript habe ich mal die Farb-Eigenschaften der Füllfarbe eines Zeichens in der ersten Tabellenzelle Deiner InDesign-Datei nachgeschaut. Tatsächlich, da ist das *Unerhörte* definiert:

fillColor.name : 5. FARBWERK TEXT SCHWARZ 100% 85%
fillColor.model : ColorModel.SPOT
fillColor.space : ColorSpace.CMYK
fillColor.colorValue : 0,0,0,100

Das geht irgendwie nicht zusammen und wird deshalb beim *reinwaschen* durch den inx-Export / das Öffnen der inx-Datei in Folgendes gewandelt:

fillColor.name : 5. FARBWERK TEXT SCHWARZ 100%
fillColor.model : ColorModel.SPOT
fillColor.space : ColorSpace.CMYK
fillColor.colorValue : 0,0,0,100

Ursachen? Da fische ich noch etwas im Trüben.
Kommen bei Dir Skripte zum Einsatz? Skripte, die mit dem Formatieren von Texten zu tun haben? Eventuell sogar Plugins, die das übernehmen? Stichwort: Censhare-Module?

Kann mir aber auch vorstellen, dass es mit der Nichtanwendung von Absatzformaten zu tun hat. Bzw. mit der Option: "Verknüpfung mit Format aufheben". Entweder in der Palette "Absatzformate" oder in der Palette "Zeichenformate" (oder beides zu einem früheren Zeitpunkt).

Weiter geht's auf Spurensuche.

Da inx-Dateien (oder deren kleiner Brüder, die inds-Snippet-Dateien) ziemlich unlesbar sind, im Gegensatz zu IDML oder IDMS ab InDesign CS4, habe ich mal Deine InDesgn CS3-Datei in CS4 geöffnet.

Die Seuche wurde mit eingeschleppt.
Dann habe ich den Textrahmen mal nach IDMS (Snippet) exportiert. IDMS kann man getrost mal in TextEdit app aufmachen. Und siehe da, die Abweichung ist im Code definiert (hab's mal rot und fett hervorgehoben):

<CharacterStyleRange AppliedCharacterStyle="CharacterStyle/05 Head Innen 85%25K 13/13" FillTint="100">
<Content>SITZEND PRIORITÄTEN SETZEN.</Content>
</CharacterStyleRange>

Lösche ich nun diesen Passus FillTint="100" und speichere die IDMS-Datei mit neuem Namen ab, kann ich mal vergleichen: einmal original, nichteditierte IDMS-Datei platziert (gewandelte Farbe), einmal editierte Datei platziert (korrekte Farbe).

Anbei die beiden IDML-Dateien meiner Platzierexperimente mit den den beiden IDMS-Dateien.

Was ergibt sich also daraus?
IDML/IDMS, aller Voraussicht nach auch INX und INDS können die Formatierung Deiner Originaldatei ausgeben, nicht jedoch korrekt einlesen! Beim Export wird nämlich ein Attribut, eine Abweichung geschrieben, die so beim Interpretieren (während des Platziervorgangs) nicht in InDesign abgebildet werden kann. Daraus resultiert dann der eigentliche Fehler: Farbänderung der Überschrift.

Würden ausschließlich InDesign-Dateien während des Übersetzungsworkflows benutzt werden, wäre keine Farbänderung aufgetreten. Die Interpretation, bei wem nun die Schuld für den Fehler liegt, überlasse ich besser den Juristen oder den Auguren…

Anbei die IDML/IDMS-Dateien aus InDesign CS4.

Ich wünsche trotzdem eine angenehme Nachtruhe…

Doch noch etwas: Da ich nicht weiss, ob Du auch über InDesign CS4 oder höher verfügst, habe ich die beiden Platziervarianten auch im INX-Format gespeichert, Das bekommst Du auch in CS3 auf.

Noch als Ergänzung zum Thema Workflow mit IDML oder INX-Austauschformaten, die ja zwingend für Übersetzungsumgebungen wie zB. von Trados benötigt werden:

1. Es ist nicht zu 100% gesichert, dass nach dem Austausch das Layout, der Umbruch, die Formatierung, ja sogar die Seitengröße nicht verändert wurde.

2. Fälle, die hier oder im Adobe Forum unlängst aufgetaucht sind:

a. Tracking-Informationen in Zeichenformaten gehen verloren (CS4 und aufwärts, Zeichenformat enthält Tracking-Information, nach dem Öffnen der IDML-Datei nicht mehr)
b. Ganze Tabelle sind verschwunden (CS5 und aufwärts, Tabellen mit mehr als 200 Spalten)
c. Seitengrößen haben sich verändert (CS6 und aufwärts, Themenbereich Liquid Layout)

Natürlich stellen diese Beispiele Sonderfälle dar. In 99,9% der Fälle geht's ja gut, wenn die Austauschdatei von der gleichen Programmversion geöffnet wird, die sie geschrieben hat. Aber eben nicht zu 100%. Bedingt durch Bugs beim Schreiben der Austauschformatdateien oder beim Einlesen und Interpretieren von *normalen* Featuren oder versteckten Featuren (zB. Tracking in Zeichenformaten).

Was dabei bemerkenswert ist: das Öffnen einer InDesign-Datei in einer höheren Version scheint der Weitergabe dieser Eigenschaften meist nicht im Wege zu stehen. Jedenfalls bei den weiter oben gelisteten Fällen. Die Tracking-Info bleibt erhalten, die Tabellen verschwinden nicht, auch die Seitengröße ändert sich nicht.

Ich glaube, Deinen Fall können wir der Liste unter 2. hinzufügen. Abteilung "Interpretieren", denn das versteckte "Feature" ist ja im Austausch-Code nach dem Export enthalten.

Hallo Uwe,

das klingt alles iwie nachvollziehbar, was bei der Umwandlung entsteht, danke für die Erklärung. Ist auch interessant, dass er die Farbe richtig umwandelt, wenn man bei den Absatzformaten die Abweichungen löscht. Denn eigtl ist ja hier alles ausgegraut.

Dass wir nicht mit Absatzformaten arbeiten dürfen (wegen Censhare) hab ich ja geschrieben. Glaub aber auch nicht, dass es an den Zusatzpaketen liegt, diese hab ich nämlich hier auch nicht installiert.

Aber so richtig nachvollziehbar, wo das Problem entsteht ist es immer noch nicht oder? Jetzt wissen wir nur, wie genau der Umwandlungsfehler entsteht.

Ich versteh sowieso nicht, warum das Feld "Farbton" oben in der Farbpalette bei einer Farbabstufung NICHT ausgegraut ist (so, wie z.b. in den Zeichenformate). Das wäre doch ziemlich sinnvoll oder?

Hallo,

ich hab mich da wohl irgendwie an Begrifflichkeiten festgebissen. Aber ihr habt ja viel Geduld mit mir gehabt ;-)

Wäre es vielleicht eine Möglichkeit, eine Farbe mit 85% Schwarz anzulegen um das Problem zu lösen? Anstatt eines Farbtonfeldes?

Gruß Kurt

Hallo,

ich konnte die beschriebene Abweichung wie folgt herstellen:
1. Irgendeinen neuen Text schreiben, der hat dann erst mal als Absatzformat "Kein Absatzformat" und Zeichenformat "Ohne".
2. Diesem Text dann das Zeichenformat "Copy 85%…" zuweisen. Das Farbfeld springt auf das 85%-Farbtonfeld.
3. Jetzt oben irgendeinen anderen Wert eingeben, z.B. 100% oder was auch immer. Das Farbfeld springt zurück auf den 100%-Ausgangswert.
4. Dann dem Text das Überschriftenformat "Head…" zuweisen. Jetzt kommst: das Farbfeld springt wieder auf die 85%, der Prozentwert oben bleibt aber auf dem vorhin geänderten Wert stehen.
Ich denke, das kommt daher, weil man im Zeichenformat dem Farbtonfeld keinen expliziten Prozentwert mitgeben kann. Daher kann er die händisch veränderten Werte auch nicht überschreiben.

Gruß, Michael

Hallo, Michael!
Danke für die Ursachenforschung.

Ja, es scheint damit zu tun haben, dass das eine Zeichenformat auf das andere basiert. Hab's gerade mal mit InDesign CS5.5 mit selbst frisch angelegten Zeichenformaten hingefummelt.

Auch hier ist dieser Effekt beim Export zu beobachten: Farbänderung zur Hauptfarbe, wenn das IDML geöffnet, das IDMS in einer frischen Datei platziert wird.

Das scheint "systemimmanent" zu sein…

Ach ja, hier noch nachgereicht, der Screenshot aus InDesign CS5.5.

DieSonderfarbenfalle.zip

HiddenInhartitance_ColorMapped_CS5.5.idms
HiddenInhartitance_ColorMapped_CS5.5.indd
VersteckteAbhaengigkeit.png

ist von meinem Dropbox-Account ladbar:

https://www.dropbox.com/...onderfarbenfalle.zip

Um das Problem kommt man nicht herum. Außer man bereitet die Datei vor dem Austausch über INX / IDML entsprechend vor (was soll welche Farben haben) und kommuniziert das Farbproblem dem Workflowpartner.

Ich hatte ein sehr ähnliches Problem bei einer PR Agentur in Wien, mit der ich zusammen gearbeitet habe. Die Beiträge hier waren sehr hilfreich, wir sind im Endeffekt dem Problem auf die Schliche gekommen!