Hallo Uwe,
ich habe nochmals etwas herumexperimentiert und dabei erkannt, dass ich gestern unüberlegt einen falschen Schluss gezogen habe.
Die IDML-Konvertierung eines CS3-Dokuments löst nicht automatisch das CS3-CS4 Fontdilemma des Stammformats. Das in CS6 neu aus der IDML-Datei erzeugte Dokument hat keineswegs automatisch ein Stammformat mit der Minion Pro Regular, sondern (auf dem Mac) weiterhin ein Stammformat mit Times Regular.
Es könnte also etwas dran sein, dass das Stammformatproblem aus alten Zeiten in einem weiterentwickelten Datenbestand fortwirkt.
Aber im Moment liefert es mir noch keine Erklärung für den Sprung auf Minion Pro Roman in einem benutzerdefinierten Basisformat, das auf dem Stammformat (mit Times Regular bzw. Minion Pro Regular) basiert.
Beim Kunden mit CC 2014 ist dieses Einschleichen eines falschen Roman-Schnitts bei der Helvetica möglicherweise auf die Konvertierung der XPress-Daten oder bei neu angelegten Daten auf eine Übernahme des Fehlers aus einer konvertierten Datei über Copy & Paste von formatiertem Text zurückzuführen sein.
Weise ich in InDesign CS6 einem Text, der mit einem Absatzformat mit Minion Pro Roman ausgezeichnet ist und der mit dem Regular-Schnitt angezeigt wird, ausdrücklich nochmals den Regular-Schnitt zu, dann zeigt die Absatzformatpalette ein Plus. Und der Hilfetext weist den Regular-Schnitt als Abweichung aus. Das Format lässt sich unter Einbeziehung dieser Abweichung neu definieren und trägt fortan den echten Regular-Schnitt.
InDesign zeigt sich also auf der Benutzeroberfläche gegenüber der Unterscheidung Roman oder Regular tolerant und reklamiert es nicht als Fehler, wenn ein Absatzformat einen nicht existierenden Roman-Schnitt einer Schrift besitzt und ersetzt diesen unter der Hand durch den existierenden Regular-Schnitt, ohne weiteres Aufsehen zu erregen. Regular und Roman werden als äquivalent (einander entsprechend) behandelt. Das rechtfertigt den Lösungsvorschlag von Hans, Regular und Roman als gleichwertige Alternativen zu behandeln.
Wird der Minion Pro Regular-Font temporär deaktiviert, findet sich im
Schriftart suchen-Fenster die Minion Pro "Roman" als "Minion Pro" (ohne Schnitt). Als Postscript-Name ist jedoch die MinionPro-Regular hinterlegt, als Schriftschnitt Regular.
Das Rätsel um die
Herkunft des Schnitts "Roman" der Minion Pro in meinen Dokumenten lässt eventuell folgendermaßen lösen:
Möglicherweise hat sich dieser bei mir zu dem Zeitpunkt eingeschlichen, als ich verschiedene Dokumentvorlagen mit unterschiedlichen Grundschriften eingerichtet habe. Und als Ursprung für die Minion-basierte Vorlage diente möglicherweise eine Datei mit einer Schrift mit einem echten Roman-Schnitt, bei dem ich nur die Schriftfamilie austauschte. So lässt es sich heute zumindest nachstellen.
Allerdings widerspricht das meinem gewöhnlichen Vorgehen: Ich hätte eher angenommen, abweichende Dokumentvorlagen aus einer auf der Minion Pro-basierten Dokumentvorlage erstellt zu haben.
Im Experiment klappt es auch umgekehrt: Beim Ändern nur der Schriftfamilie der Grundschrift Minion Pro Regular in Stempel Garamond Lt Std erscheint im Absatzformat der nicht existierende Schnitt Stempel Garamond Lt Std Regular. Im Zeichenfenster und in der Absatzformatpalette werden jeweils die Roman-Schnitte angezeigt.
Die Suche über die Benutzeroberfläche interessiert sich nicht für den Schnitt, der in den Paletten dargestellt wird, sondern für den Schnitt, der – wenn auch versteckt – tatsächlich angewandt ist. So bleibt die Suche nach einem angezeigten und zur Schriftfamilie passenden Regular-Schnitt erfolglos, wenn dieser unter der Haube (nicht über die Benutzeroberfläche, aber über ein Skript erkennbar) ein nicht zur Schriftfamilie passender Roman-Schnitt ist. Dieser Schnitt lässt sich nur über die Suche nach dem nicht zur Familie passenden Roman finden.
Es bleibt die Erkenntnis, dass man bei der Suche nach einem Regular-Schnitt berücksichtigen muss, dass sich ein solcher auch unter einem Roman-Deckmantel versteckt halten kann. Und umgekehrt.
Die Untersuchung anderer Fallen wie z.B. Italic-Oblique ist an anderer Stelle in Ansätzen dokumentiert:
Italic, das kein Italic ist ... Die Toleranz, die InDesign hier bei der Nichtunterscheidung einander ähnlicher Schnitte zeigt, ist unter einem bestimmten Betrachtungswinkel als benutzerfreundlich zu bewerten, birgt aber Risiken, wenn dem Anwender nicht bewusst ist, dass diese manchmal namentlich austauschbar sind und manchmal doch nicht (z.B. Analyse und Vergleiche per Skript).
Nach meinem Dafürhalten gehört die Verwendung eines nicht zur Schriftfamilie gehörenden Schnitts immer und klar und deutlich als Fehler reklamiert. Viele Grüße
Martin
Hier eine kleine Anleitung hinsichtlich Bedeutung der auszufüllenden Formularfelder.
