Hallo zusammen

Wenn normalerweise aus einem Doku (Quelle) Text mit dem Absatzformat "Titel" ins Doku (Ziel) kopiere, und dort schon ein gleichnamiges Absatzformat besteht, übernimmt es mir die im Zieldoku angegeben Formateinstellungen. Wunderbar.

Das funktioniert bei mir auch in allen Testläufen.
Aber es funktioniert nicht bei einem Workflow, wo ich es eigentlich brächte.

Im Zieldoku ist im Absatzformat die Schrift "Helvetica Neue LT Com 57 Condensed" angegeben. Es übernimmt mir beim Reinkopieren alles (Laufweite, Grösse, Zeilenabstand usw..) aber es übernimmt nicht die Schrift sondern wählt eine Minion 57 Condensed (es übernimmt damit sogar den Schriftschnitt), die es so gar nicht gibt; ergo Schrift nicht geladen.

Wenn ich im Zieldoku eine andere Schrift im Absatzformat eingebe, dann gehts.
An was könnte das liegen?

Herzlichen Dank!
Matthias


CS 5.5
OS 10.6.8
Fontxplorer X Pro 2.5.2

Vielelicht sind es die Lizenzrechte bei der Schrift?

Liegt ein Zeichenformat auf der Schrift. Oder ist das Schriftformat in Abhängigkeit von einem anderen definiert, wo Zeichenformate durch verschachtelte FOrmate, Zeilenformate oder GREP-Stile durchschlagen?

Oder ist das Absatzformat doch nicht gleich und basiert auf dem Basisabsatzformat? Da ist seit CS5 die Minion die Standardschrift.

@ MoHil:
ähm, da komme ich jetzt nicht ganz draus. Wie ist das zu verstehen?

@Adelberger:
Ich habe kein manuelles Zeichenformat auf der Schrift, aber über die GREP-Stile hab ich eine Abhängigkeit. Wenn ich diese zu Testzwecke lösche gehts aber immer noch nicht.
Komischerweise gehts mit dieser Helvetica in einem Testdoku wunderbar. Also kann es nicht grundsätzlich an der Schrift liegen, sondern muss an der Kombination "Schrift und Doku" liegen.

Das Absatzformat des Zieldokus "Basiert auf: [kein Absatzformat]". Also kanns an dem vermutlich auch nicht liegen...

Danke. Habt ihr noch weitere Ideen?

Matthias

Hat niemand mehr eine Idee? Ich bin echt aufgeschmissen, da ich keinen Schriftwechsel vornehmen kann; die Schrift ist vorgegeben...

Wäre euch wirklich sehr sehr dankbar...

msg

Hallo MCMessagemaetens3D,

vlt hiflt Dir die Option "unformatiert einfügen" weiter. Ansonsten kann man durch das Klicken bei gedrückter Alt-Taste alle Absätze auf das verwendetete Format zurücksetzen, wodurch alle manuellen Formatierungen gelöscht werden, und dadurch die Zuweisung des neuen Formats in Reinkultur passiert.

Grüße
Frank

Hallo Frank

Nun, leider hilft mir das nichts. Die Ausgangslage ist folgende:
Wir haben eine Zeitschrift, die nach Druck-Abgabe auch noch als Tablet-Version erscheinen sollte. Und da sehe ich als weitaus schlausten Weg, dass ich den Text aus der Druckversion in die Tablet-Vorlage hinüber kopiere und der Text durch die anders formatierten Absatzformate gleich korrekt umformatiert wird.
Bei "unformatiert Einfügen" erhaltet sich nur das erste Absatzformat, die restlichen gehen verloren...

Ich habe keine Ahnung, was ich noch ausprobieren müsste. Es ist sogar ein opentype-font ...

Matthias

Hallo Matthias,

wenn Du möchtest, kannst Du mir zwei Musterdokumente an meine email-Adresse im Profil zukommen lassen.
Wenn Du inhaltliche Bedenken hast, brauchen keine Live-Daten drin sein, nur Platzhaltertext mit den Formaten, die Probleme bereiten.

Ich würde dann versuchen, die Ursache für das unerwartete Verhalten an den konkreten Daten herauszufinden.

Hallo Mathias,
habe zwar noch keine EPub-Erfahrung, weiß nur das da CSS zum Einsatz kommt. Wenn dem so ist, dann dürfte die Schriftzuweisung an dieser Stelle sinnvoller sein. Sprich bei der Ausgabe darauf achten, dass die Schrift via CSS-Stile angesprochen werden kann, und diese sind ja ganz schnell umgeschrieben.
Denkbar wäre auch einfach eine Kopie machen, und über "Schriftart suchen…" die Schrift global ändern und weiterverarbeiten.

Grüße
Frank

@Martin
Herzlichen Dank, ich nehme dein Angebot gerne an. Ist unterwegs...

@Frank
Ich wüsste nicht, wo ich da mit CSS in Berührung komme. Ich erstelle ein Layout und mache dann über den Adobe-Workflow einen Content für das von Adobe programmierte App. Da kommt meines Wissens nirgends CSS zum Einsatz.

"Schriftart suchen…" ist halt nur ein Workarround. Den Tipp nehme ich aber gerne wieder zur Hand, falls ich zu keiner Lösung komme. Danke!

Grüsse
Matthias

Beim ePUB und HTML-Export kommen CSS zum Einsatz und man kann entweder über die Absatzformate einzeln oder über das Panel zum Taqggen von HTML- und PDF-Stilen die Tags für den Export zuweisen. Dann kann man beim Export eben ein vorhandenes CSS nehmen.
Aber mich würde die Datei auch interessieren, mich interessiert die ausschließlich technisch, also ohne Bilder und es kann nur Blindtext sein.
willi (at) adelberger (Punkt) name

Hallo Matthias,

ich habe mal einen Blick in die Dateien reingeworfen.
Das beschriebene Verhalten kann ich bestätigen.

Über Experimente mit 'Absatzformat basiert auf' bin ich nicht weitergekommen.

Allerdings habe ich eine Beobachtung gemacht:
Wenn diese 'Helvetica Neue'-Familie in allen Absatzformaten in beiden Dokumenten z.B. durch die 'Myriad' und die entsprechenden Schnitte ersetzt wird, dann funktioniert Copy & Paste problemlos: Die ankommenden Textrahmen beinhalten den Text mit demselben Font formatiert wie im abgeholten Textrahmen bzw. mit dem im AF definierten Font. Die Abweichung, die bei Copy & Paste mit 'Helvetica Neue' passiert, wiederholt sich mit der Myriad nicht.

U.U. liegt es an den ungewöhnlichen Schriftschnittbezeichnungen der 'Helvetica Neue LT Com'. Werde mal einen Test mit der Frutiger machen. ...

Mit der 'Frutiger Lt Std' und ihren eigenartigen Schnittbezeichungen ist alles ok.

Es genügt, wenn im Zieldokument die 'Helvetica Neue LT Com' durch Myriad oder Frutiger ausgetauscht wird. Dann kommt der kopierte Text korrekt im Font der AF-Definition im Zieldokument an.

Das Problem scheint mit der 'Helvetica Neue LT Com' zusammenzuhängen.
Eine simple Lösung habe ich im Moment nicht zu bieten.


Die Helvetica Neue scheint schon längere Zeit mit InDesign auch in anderen Zusammenhängen auf Kriegsfuß zu stehen: http://www.hilfdirselbst.ch/...=post_time&mh=50

Ein weiterer Versuch:

Habe in beiden Dokumenten in allen Absatzformaten die 'Helvetica Neue LT Com' durch die 'Helvetica Neue LT Std' ausgetauscht.

Und siehe da: Copy & Paste funktioniert wie es soll – ohne Schriftabweichungen.

Es scheint also direkt mit der COM-Familie der 'Helvetica Neue' zusammenzuhängen.

Gegenprobe:
In beiden Dokumenten in allen Absatzformaten die 'Helvetica Neue LT Std' durch die 'Helvetica Neue LT Com' wieder zurückgetauscht: Das Copy & Paste-Problem zeigt sich wieder wie zuvor.

Kennt jemand dieses Phänomen mit anderen COM-Fonts?

Antwort auf [ Martin Fischer ]

Kennt jemand dieses Phänomen mit anderen COM-Fonts?

Hallo Martin,

dieses spezielle Problem nicht, und auch nicht in InDesign. Ich habe allerdings in FrameMaker Probleme (ist ein FM Bug, aber nur mit bestimmten Schriften) mit der "Helvetica Neue LT Com", die auch bei mir durch den Kunden vorgeschrieben ist. Da diese Probleme in FM zu erheblichen Schwierigkeiten geführt haben, habe ich die Schrift "heimlich" durch die entsprechenden Schnitte aus der "Helvetica Neue LT W1G" ersetzt, was in den resultierenden PDFs zu optisch gleichen und ansonsten technisch funktionierenden Ergebnissen führt.

Ist also schon das zweite Mal, dass die "LT Com" negativ auffällt. Auch wenn ein Zusammenhang für mich nicht nachvollziehbar ist.

Grüße,
Bernd

Ich bedanke mich herzlich für eure grosse Hilfe. Das ist schon mal ein grosser Schritt weiter!

Ich schicke dir – Adelberger – die Dateien auch noch. Falls du noch interesse hast, kannst du gerne auch noch einige Tests durchführen.

Mir bleibt wohl nicht viel anderes übrig, als auf die LT-Std-Version zu wechseln. Die unterscheidet sich, soweit ich das bisher feststellen konnte, ja nicht von der COM-Version. Aber ist halt schon nicht ideal.

Eigentlich sind wir mal auf die COM gegangen, weil wir mit allen anderen Helvetica-Versionen ein Problem hatten; das war aber vor meiner Zeit hier. Daher weiss ich nicht, was genau das Problem war.

Grüsse
Matthias