Volltonfarb-Problem: Farbton zeigt 100%, Farbtonfeld ist aber auf 85% angelegt.

ToniMontanaa

Hallo,

ich habe auch grad versucht deinen Fehler zu reproduzieren. Ist mir auch nicht gelungen. Habe es mit Vollton- sowie auch Prozessfarben versucht.

Lad doch mal die InDesign-Datei mit dem Fehler hoch. Vielleicht kommt dann jemand auf ne Lösung.

Gruß
Stefan

frischhut

Hey,
ich hab hier mal das InDesign hochgeladen:

www.extraelement.de/85Prozent.zip

In der Headline befindet sich der Fehler,
die Copy ist fein (hab durch Blindtext ersetzt).

Wer was findet, Danke!
lg

ToniMontanaa

Hallo Alex,

hab mir grad mal deine Datei angeschaut. Hab bis jetzt auch noch nicht rausgefunden wie das zustande kommt, allerdings würde ich mal behaupten das es sich hier um einen Darstellungsfehler von InDesign handelt. Wenn du von der Datei einen PDF erstellst ist alles richtig. Oder ist hier bereits irgendwas in die Hosen gegangen, da du in einem früheren Posting erwähnt hattest das du das dem Kunden erklären musst.

Gruß
Stefan

frischhut

Ja wenn man's so drucken würde, wäre alles gut.

aber leider gings in die hose:

hab ja geschrieben, dass wir die Master-Indesign in ein tool hochladen, welches dann von der MASTER indesign datei verschiedene sprachversionen (identische indesigns) erstellt, die mit dem master verknüpft sind. soweit noch alles gut... die übersetzer schreiben in die jeweilige sprache rein (nur Textstand wird geändert) und speichern es ab. Wird jetzt aber am Master z.b. am Bildstand was geändert kann man das über eine "Automatisierungsfunktion" in alle angelegten Sprach-InDesigns übertragen lassen. Und genau hier passiert der Fehler: Das Übersetzungstool (Censhare Client) nimmt beim AutoUpdate für alle Sprachen den Farbwert aus der oberen Zeile und färbt somit das ganze in 100% schwarz um. Was letztendlich falsch ist.

Deswegen die Frage, wie die 100% da oben reinkommen können. Es ist schwierig es dem Kunden zu erklären, wenn man sich ja schon schwer tut es euch zu erklären ;-)

Michi-F

Hallo, ich habe mal folgendes probiert:

ein Wort in der Überschrift markieren, dann das Zeichenformat aufrufen, den Reiter Farbe anwählen und die Vorschau aktivieren.
Hier ist jetzt die 85%-Farbe angewählt. In der Farbpalette steht aber wie beschrieben 100%. Egal, ob ich 85% oder 100% anwähle, der Wert in der Farbpalette bleibt immer auf 100% stehen. Das Feld "Farbton" in der Zeichenformatpalette ist dabei immer leer.
Wenn ich jetzt aber den 100%-Ton anwähle und in das leere Farbtonfeld auch 100% eintrage, dann ändert sich erst mal gar nichts. Klicke ich dann aber wieder auf das 85%-Feld, dann springt auch der Wert in der Farbpalette auf 85%.
Nach dem Schließen des Zeichenformats stehen dann die richtigen Werte in der Palette.
Vielleicht hilft das ja irgendwie. Warum das allerdings so ist, weiß ich auch nicht.

Gruß, Michael

ToniMontanaa

Tritt der Fehler bereits im MASTER auf oder erst nachdem da irgendwelche Übersetzer rumgefroscht haben?

Michi-F

Hallo, noch ein Nachtrag.

Ich denke, es hat was mit dem Zeichenformat zu tun, ohne dass ein richtiges Absatzformat hinterlegt ist. Das Zeichenformat definiert irgendwie nur die Farbe, aber nicht den Tonwert davon.
Wenn ich aus der Überschrift ein neues Absatzformat anlege, und dieses dann anwende, dann zeigt er gleich mit "+" eine Abweichung davon an, eben diese Änderung auf 100%.

Gruß, Michael

Peter_Lenz

Hallo Michael,

Du bist auf jeden Fall auf einer sehr heißen Spur.

Man könnte die Einstellungen unter "Zeichenfarbe" auch wie in der Anlage einstellen. Dann müsste man das Ganze nur nochmal durch das Übersetzungstool (Censhare Client) schleusen, um zu sehen, ob es dann korrekt rauskommt.

Viele Grüße Peter

frischhut

Erstmal danke euch, dass ihr euch dem Problem so annehmt.

@ToniMontanaa: der "Bug" passiert offline auf dem Rechner... Die tatsächliche Umrechnung von 85% schwarz auf 100% passiert beim "GeoUpdate", also dem Automatischen Update aller Übersetzungs-Indesigns auf den gleichen Bildstand.

Absatzformate dürfen leider bei "CenShare" Client nicht angelegt werden. Ein sehr sensibles Programm, bei dem man viele Voreinstellungen treffen muss (z.b. darf nicht das voreingestellte "papier" weiß verwendet werden sondern hierfür braucht man auch ne extra farbe ;-)

An das Zeichenformat hab ich auch schon gedacht. Hier wird nämlich NACH dem Geoupdate auch ein + hinter dem Zeichenformat angezeigt. Durch einfaches Klicken aufs Zeichenformat ist der Fehler auch wieder behoben. Oder man klickt einfach nochmal auf die 85% Farbe. (Aber das wäre zu viel von den Übersetzern verlangt ;-) ) das sei auch dahingestellt.
Ich hab nur noch nicht rausgefunden wie das Problem zustande kommen kann.

frischhut

@Peter: Ja es klappt eigtl immer alles super, außer man hat eben diesen "bug" drinnen, wo keiner weiß woher er kommt. Wenn nämlich die Farbe so angelegt ist wie in der Copy der Tabelle macht es ja auch keine Probleme.

Peter_Lenz

Hallo Alex,

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

Uwe_Laubender

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).

Uwe_Laubender

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):

[#cc0000] FillTint="100"[/#cc0000]>
SITZEND PRIORITÄTEN SETZEN.

Lösche ich nun diesen Passus [#cc0000] FillTint="100"[/#cc0000] 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.

Uwe_Laubender

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.

frischhut

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?

kurtnau

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

Michi-F

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

Uwe_Laubender

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…

Uwe_Laubender

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/s/o5cjayl3ay7rlqz/DieSonderfarbenfalle.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.

Teufelsfrucht

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!

« Vorherige Seite Nächste Seite »