Silbentrennung mit Arial Unicode MS
Markus Wiedenmaier
ich verzweifle gerade an einem Problem mit der Silbentrennung und
vielleicht kann mir jemand auf die Sprünge helfen:
Ich verwende in einigen Dokumenten den Font Arial Unicode MS in
Verbindung mit FM9 strukturiert auf Windows XP SP3.
Soweit ich nun herausgefunden habe, funktioniert die Silbentrennung
einwandfrei, wenn ich
a) Statt Arial Unicode MS den Font Arial verwende
b) oder keine Umlaute im jeweiligen Wort vorkommen.
Weise ich also dem Absatzformat Arial zu, gibt es keine Probleme.
Wenn ich dann im Absatzformatdesigner wieder auf Arial Unicode MS
zurückstelle, stellt sich die Sprache automatisch auf Simplyfied
Chinese um.
Eine Änderung der Sprache zurück hat aber auch keine Auswirkungen.
Konkret geht es um das finnische Wort „Verkkoliitäntätiedot“. Entferne
ich bei „ä“s wird getrennt.
Irgendwelche Ideen? Kann ich da in FM irgendwas einstellen, damit sich
FM auch bei diesem Font korrekt verhält?
Danke schon mal im Voraus.
Markus Wiedenmaier
Johannes Graubner (Transcom)
hast Du sichergestellt, dass sowohl im Absatz- als auch im
Zeichenformat für die zu trennenden Wörter die richtige
Sprache eingestellt ist?
(Dass sich die Spracheinstellung mit einer Font-Änderung
automatisch verändert, scheint mir Ursachen abseits vom Font
zu haben.)
Viele Grüße
Johannes
-----Ursprüngliche Nachricht-----
Von: frameu...@googlegroups.com
[mailto:frameu...@googlegroups.com] Im Auftrag von
Markus Wiedenmaier
Gesendet: Mittwoch, 31. August 2011 17:15
An: frameusers-de
Betreff: [frameusers-de] Silbentrennung mit Arial Unicode MS
Hallo zusammen,
--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google
Groups-Gruppe "frameusers-de" sind.
Für das Erstellen von Beiträgen in dieser Gruppe senden Sie
eine E-Mail an
frameu...@googlegroups.com
Um sich von dieser Gruppe abzumelden, senden Sie eine E-Mail
an
frameusers-d...@googlegroups.com
Für Nachrichten an den »Eigentümer« der Gruppe, senden Sie
eine E-Mail an
frameuser...@googlegroups.com
Weitere Optionen finden Sie in dieser Gruppe unter
http://groups.google.com/group/frameusers-de?hl=de
Thomas Böttiger
;-)
Ist aber nur so eine Idee.
>
>
> Irgendwelche Ideen? Kann ich da in FM irgendwas einstellen,
> damit sich
> FM auch bei diesem Font korrekt verhält?
> Danke schon mal im Voraus.
> Markus Wiedenmaier
>
Thomas Böttiger
Stephan Will
Am Wed Aug 31 2011 17:15:02 GMT+0200 schrieb Markus Wiedenmaier
<in...@practice-innovation.de>:
> Soweit ich nun herausgefunden habe, funktioniert die Silbentrennung
> einwandfrei, wenn ich
> a) Statt Arial Unicode MS den Font Arial verwende
> b) oder keine Umlaute im jeweiligen Wort vorkommen.
Arial Unicode ist lediglich eine Machbarkeitsstudie und keine produktiv
einsetzbare Schrift.
MS wollte halt mal eine Schrift mit (zum damaligen Zeitpunkt) *allen* in
Unicode definierten Zeichen/Glyphen erstellen.
Nicht umsonst ist die Datei 25 MB schwer.
Gru�
Stephan Will
practice innovation
> hast Du sichergestellt, dass sowohl im Absatz- als auch im Zeichenformat
für die zu trennenden Wörter die richtige Sprache eingestellt ist?
Absatz nicht vor).
Die Templates wurden für FM9 von Grund auf neu erstellt. Die Sprachzuweisung
wird durch die EDD überschrieben. Das Dokument wird über einen XML-Import
immer neu auf Basis dieses Templates aufgebaut, so dass ich Altlasten
ausschließen möchte.
Allerdings bekomme ich das Ganze auch einfach reproduziert, in dem ich ein
neues Dokument über "Datei > Neu" anlegen, den Text Verkkoliitäntätiedot
als Unicode-Text über Einfügen>Special einfüge.
Mit Arial und Times New Roman wird das Wort getrennt; mit Arial Unicode MS
nicht. Entferne ich die Umlaute, habe ich auch das gleiche Verhalten.
Auch die Sprachumstellung wenn ich zurück auf Arial Unicode MS wechsle
verhält sich identisch.
Deshalb wage ich es mal mein Template auszuschließen. Zudem ist das Problem
auf verschiedenen Rechnern (XP) reproduzierbar.
Zur Vollständigkeit der Font im Fonts-Ordner heißt "Arial Unicode MS
Standard (TrueType)", hat den Dateinamen ArialUni.ttf, ist vom 24.09.2010
und hat eine Dateigröße von 22731kb.
Was mir auch noch auffällt, vielleicht hängt das damit zusammen, in der
Strukturansicht, werden die Zeichen der Textknoten nicht mit Arial (wie in
der StructureView Section konfiguriert) dargestellt.
Eher sieht es so aus, als ob hier irgendein Ostasiatischer Font, oder
vielleicht Combined Font verwendet wird, was dann auch wieder Simplyfied
Chinese in der Sprachauswahl erklären würde.
Lässt sich daraus schließen, dass FM Arial Unicode MS als Combined Font
interpretiert?
Wenn ja müsste das ja hart in FM implementiert sein, denn ich habe keine
Combined Fonts im Template angeleg; der CombinedFontCatalog im MIF ist auch
leer. Ein Mif-Wash brachte auch keinen Unterschied.
Konfigurationseinstellung habe ich keine finden können, die das Verhalten
beeinflussen können. Auch die Einstellung der beiden Fonts Arial und Arial
Unicode MS sehen für mich bis auf die Anzahl unterstützter Zeichen gleich
aus.
Schöne Grüße
Markus Wiedenmaier
practice innovation
> Früher hätte ich das auf eine Umstellung des Druckertreibers geschoben,
Änderung auf Adobe PDF hat aber nichts gebracht.
Trotzdem Danke für den Tipp.
Markus Wiedenmaier
practice innovation
> Arial Unicode ist lediglich eine Machbarkeitsstudie und keine produktiv
einsetzbare Schrift.
> Nicht umsonst ist die Datei 25 MB schwer
Danke für die Info.
Es war eine bewusste Entscheidung für den Font; auch hinsichtlich der Größe,
des Fonts.
Sicherlich kann ich jetzt die Entscheidung kippen und zurück auf Arial
gehen, für Ostasiatisch andere Fonts einsetzen etc.
Die Entscheidung werde ich auch in Frage stellen, wenn
- das Trennproblem nicht anders gelöst werden kann
- und mit dem Problem ansonsten nicht gelebt werden kann.
Was sind die Gründe, den Font nicht produktiv einzusetzen? Alleine die
Größe?
Gruß
Markus
Stephan Will
Am Wed Aug 31 2011 18:32:31 GMT+0200 schrieb practice innovation
<in...@practice-innovation.de>:
> Was sind die Gr�nde, den Font nicht produktiv einzusetzen? Alleine die
> Gr��e?
Gr��e, fehlende Bold-, Italic-, BoldItalic-Varianten, Trennprobleme,
fehlende Kerning- & Hinting-Informationen, entspricht nicht dem
OpenType-Standard, ...
Gru�
Stephan
practice innovation
> Größe, fehlende Bold-, Italic-, BoldItalic-Varianten, Trennprobleme,
fehlende Kerning- & Hinting-Informationen, entspricht nicht dem
OpenType-Standard, ...
danke für die Info. Werde das bei den weiteren Überlegungen berücksichtigen.
Trennprobleme sind m.E. nicht auf einen Font zurückzuführen, sondern eine
Sache des Editors. Wie und ob getrennt wird entscheidet die Anwendung.
In Wörd wird der Text ordnungsgemäß getrennt.
FrameMaker trägt im MIF für den Font Arial Unicode MS das Enconding
"GB2312-80.EUC", also das Encoding für Ostasiatische Schriften. Wird das
manuell auf FrameRoman geändert, ändert FM das beim nächsten Speichern
wieder.
Auf Grund dieses Encodings werden die Zeichen nicht getrennt.
Das Problem tritt auch bei Fonts wie Batang, SimSun auf.
Deshalb vermute ich, dass FM Fonts auf Zeichencodes im Asiatischen Unicode
Range analysiert. Sind ostasiatische Schriftzeichen enthalten, wird
automatisch das Encoding eingestellt und die Silbentrennung ist für Zeichen
>127 nicht mehr möglich.
Kann man dieses Verhalten irgendwo ändern?
Schöne Grüße
Markus Wiedenmaier
Johannes Graubner (Transcom)
ohne das nachgestellt zu haben: Bist Du Dir sicher, dass die
Umlaute die korrekten aus dem jeweiligen Alphabet sind? Es
gibt etliche Zeichen, die sehen einander ähnlich aus,
stammen aber aus einer anderen Schrift (z.B. kyrillisches
"s" und lateinisches "c"). (Zugegeben, ich wüsste nicht, aus
welchem anderen Alphabet ein "ä" stammen sollte.)
Viele Grüße
Johannes
-----Ursprüngliche Nachricht-----
Von: frameu...@googlegroups.com
[mailto:frameu...@googlegroups.com] Im Auftrag von
practice innovation
Gesendet: Mittwoch, 31. August 2011 18:23
An: frameu...@googlegroups.com
Betreff: AW: [frameusers-de] Silbentrennung mit Arial
Unicode MS
Hallo Johannes,
Stephan Will
Am Wed Aug 31 2011 19:20:10 GMT+0200 schrieb practice innovation
<in...@practice-innovation.de>:
> Trennprobleme sind m.E. nicht auf einen Font zur�ckzuf�hren, sondern eine
> Sache des Editors. Wie und ob getrennt wird entscheidet die Anwendung.
das Problem ist auch Sache des Fonts, n�mlich dann, wenn die Schrift
"suboptimal" produziert wurde.
Und Arial Unicode ist nicht "zu Ende" produziert worden.
Gru�
Stephan Will
practice innovation
bin mir da schon sicher, zumal ich die "ä"s nochmals von Hand in "ä"s
geändert habe.
Gruß
Markus
-----Ursprüngliche Nachricht-----
Von: frameu...@googlegroups.com [mailto:frameu...@googlegroups.com]
Im Auftrag von Johannes Graubner (Transcom)
Gesendet: Mittwoch, 31. August 2011 19:55
An: frameu...@googlegroups.com
Betreff: AW: [frameusers-de] Silbentrennung mit Arial Unicode MS
Hallo Markus,
ohne das nachgestellt zu haben: Bist Du Dir sicher, dass die Umlaute die
korrekten aus dem jeweiligen Alphabet sind? Es gibt etliche Zeichen, die
sehen einander ähnlich aus, stammen aber aus einer anderen Schrift (z.B.
kyrillisches "s" und lateinisches "c"). (Zugegeben, ich wüsste nicht, aus
welchem anderen Alphabet ein "ä" stammen sollte.)
Viele Grüße
Johannes
-----Ursprüngliche Nachricht-----
Von: frameu...@googlegroups.com
[mailto:frameu...@googlegroups.com] Im Auftrag von practice innovation
Gesendet: Mittwoch, 31. August 2011 18:23
An: frameu...@googlegroups.com
Betreff: AW: [frameusers-de] Silbentrennung mit Arial Unicode MS
Hallo Johannes,
> hast Du sichergestellt, dass sowohl im Absatz- als auch im
Zeichenformat
für die zu trennenden Wörter die richtige Sprache eingestellt ist?
Ja die Sprachzuweisungen (i.d.F. Suomi) passen (Zeichenformate kommen in dem
Absatz nicht vor).
practice innovation
>das Problem ist auch Sache des Fonts, nämlich dann, wenn die Schrift
"suboptimal" produziert wurde.
>Und Arial Unicode ist nicht "zu Ende" produziert worden.
Wie gesagt auch Fonts wie Batang, SimHei haben Probleme mit der
Silbentrennung. Auch bei diesen beiden Beispielen funktioniert die
Silbentrennung nicht. Hier gehe ich mal davon aus, dass sie "zu Ende"
produziert sind.
Gibt es denn einen alternativen Unicode Font, der (analog zu Arial Unicode
MS) einen weiten Range an Unicode-Zeichen abdeckt und bei dem die
Silbentrennung mit FM funktioniert.
Schöne Grüße
Markus Wiedenmaier
kdaube
> >das Problem ist auch Sache des Fonts, nämlich dann, wenn die Schrift
> "suboptimal" produziert wurde.
> >Und Arial Unicode ist nicht "zu Ende" produziert worden.
gemacht in FM9:
absatz format ist in font Lucida Sans Unicode (nicht gratis)
sprache = suomi
Durch variieren des wortes vorher stelle ich fest: etliche
trennstellen:
http://daube.ch/anything_for_all/upload/fm-9-trennung.png
practice innovation
vielen Dank für die Information.
Lucida Sans Unicode unterstützt aber gerade die Unicode Ranges für den
Ostasiatischen Sprachraum nicht
(http://www.microsoft.com/typography/fonts/font.aspx?fmid=160).
Alle Fonts, die ich bislang untersucht habe, die die Ostasiatischen Sprachen
unterstützen, haben das gleiche Problem bei der Silbentrennung. Enthält ein
Wort Zeichen oberhalb des ASCII-Bereichs, trennt FM nicht. Das Problem
existiert somit auch im deutschen, wenn Umlaute im Wort enthalten sind.
Fonts die diesen Bereich nicht unterstützen, trennen korrekt, wie in Ihrem
Beispiel.
Dass FM den Font als "Simplyfied Chinese" Font interpretiert, zeigt die
Darstellung der Textknoten in der Strukturansicht. Dort wird der Font
"System" angezeigt, der standardmäßig in der maker.ini für Simplyfied
Chinese konfiguriert ist.
Ändere ich folgende Konfigurationseintrag in der maker.ini
DefaultSimplifiedChineseFamily=Arial Unicode MS
Wird auch in der Strukturansicht der Font wie erwartet angezeigt.
In der maker.ini bin ich zudem auf folgenden Eintrag gestoßen:
RomanRanges=0000-024F, 0400-052F, 0370-03FF, 2000-206F
Eine Änderung auf
RomanRanges=0000-FFFF
hatte allerdings, entgegen meiner Hoffnung, keine Auswirkungen auf das
Verhalten.
Schöne Grüße
Markus Wiedenmaier
Michael Müller-Hillebrand
> Es war eine bewusste Entscheidung für den Font; auch hinsichtlich der Größe,
> des Fonts.
Das war eine suboptimale Entscheidung. Dass zum Beispiel eine Firma wie Siemens in bestimmten Bereichen auch diese Schrift als scheinbar eierlegende Wollmilchsau einsetzt, hilft auch nicht weiter. Neben den von Stephan Will genannten Faktoren gilt gerade für den fernöstlichen Bereich zu bedenken, dass die Glyphen dieser Schrift nach chinesischem Still gezeichnet sind, was in Japan als respektlos empfunden wird.
> Sicherlich kann ich jetzt die Entscheidung kippen und zurück auf Arial
> gehen, für Ostasiatisch andere Fonts einsetzen etc.
Ja, und zwar separat für Chinesisch, Japanisch und Koreanisch!
> Die Entscheidung werde ich auch in Frage stellen, wenn
> - das Trennproblem nicht anders gelöst werden kann
> - und mit dem Problem ansonsten nicht gelebt werden kann.
Das Konzept »Global Font« ist rein theoretisch, ein gemeinsamer Unicode Codepoint für ein Zeichen bedeutet nicht, dass es eine gemeinsame Darstellung des Zeichens in allen Kulturen dieser Welt geben kann. Wer dies glaubt, würde wohl auch in einer deutschen Bedienungsanleitung bedenkenlos Fraktur verwenden... ich habe mehrfach zu diesem Thema gesprochen, zuletzt 2009 auf der tekom-Tagung:
http://cap-studio.de/wp/wp-content/uploads/2009/11/VISU5_Typographie_CJK.pdf
Schöne Grüße,
- Michael
--
_____________________________________________________________
Michael Müller-Hillebrand -- http://cap-studio.de/
Adobe Certified Expert, FrameMaker
Lösungen und Training, FrameScript, XML/XSL, Unicode
~
~ Auf der tekom-Tagung in Wiesbaden 18.-20.10.2011
~ Messestand 412 in Halle 4 ~ Vortrag am Mi 19.10.:
~ 11:15h Raum 6.2 »XPath in FrameMaker praktisch nutzen«
~
Mueller, Klaus
Markus W. schrieb:
> Wenn ich dann im Absatzformatdesigner wieder auf Arial Unicode MS
> zurückstelle, stellt sich die Sprache automatisch auf Simplified Chinese um.
> Eine Änderung der Sprache zurück hat aber auch keine Auswirkungen.
Ich beschäftige mich momentan ebenfalls mit diesem Problem.
Es wird zwar nicht Arial Unicode MS eingesetzt, aber ein von URW für den
Kunden erstellter "Global Font" mit Unterstützung u.a. für Chinesisch, Japanisch,
Koreanisch und Arabisch.
Manche nachvollziehbare Argumente gegen Arial Unicode MS im Speziellen
(fehlendes Kerning, kein eigener Fettschnitt, kein produktiv einsetzbarer Font,
nicht professionell erstellt oder nicht zu Ende produziert) als auch gegen Global
Fonts im Allgemeinen greifen bei diesem Font nicht. Tatsächlich wird zwar für
Japanisch (aus den von MMH genannten Gründen) ein eigener Font verwendet,
für alle anderen Sprachen wird der Font sowohl mit InDesign als auch mit einem
speziellen XML-Publishing-Prozess erfolgreich eingesetzt.
Im bisherigen FrameMaker-Prozess mit FM7 wurden bisher andere Fonts
verwendet; für den geplanten Umstieg auf FrameMaker 10 prüfe ich nun aber,
ob der Global Font eingesetzt werden kann.
In der aktuellen Diskussion m.E. vernachlässigt wurde das ursprüngliche Problem
des Fragestellers:
. Warum überlässt oder erlaubt FrameMaker es nicht dem Anwender, zu entscheiden,
welche Sprache ein Text haben soll, sobald der verwendete Font asiatische
Sprachen unterstützt? Und:
. Warum funktionieren diese Global Fonts in anderen Applikationen in allen Sprachen,
nicht aber in FrameMaker?
Johannes G. schrieb:
> (Dass sich die Spracheinstellung mit einer Font-Änderung automatisch
> verändert, scheint mir Ursachen abseits vom Font zu haben.)
Doch, genauso ist es.
Der Hintergrund für diese "Bevormundung" liegt an den im Font angegebenen
unterstützten Codepages (nicht: den unterstützten Unicode-Ranges).
Diese Angaben sind m.W. grundsätzlich erst mal nur Flags, die mit der
tatsächlichen Zeichenbelegung eines Fonts nur bedingt in Zusammenhang stehen.
Wenn ein Font die Codepage 936 unterstützt, wird die Sprache "Vereinfachtes
Chinesisch" zugewiesen. Wenn der Font CP 936 nicht unterstützt (aber alle
anderen asiatischen Codepages), wird "Koreanisch" zugewiesen, usw.
(Simpl. Chinese -> Korean -> Trad. Chinese -> Nihongo).
Wie von Markus W. festgestellt, ändert die nachträgliche Zuweisung einer
anderen Sprache daran nichts: Der interne "FontEncodingName" eines Absatzes
bleibt dennoch z.B. "GB2312-80.EUC", was u.a. eine korrekte Silbentrennung
in nicht-asiatischen Sprachen verhindert.
Diese Funktionalität wurde m.E. bereits mit FrameMaker 6 eingeführt.
Mit einem Global Font, bei dem die Codepage-Unterstützung für asiatische
Sprachen entfernt wurde, bleibt der FontEncodingName auf FrameRoman.
Ich versuche momentan zu prüfen, wo im Unicode-Umfeld ab FM8 ein
Problem mit einem entsprechend modifizierten Global Font entstehen könnte.
. Die Zuweisung des Fonts gegenüber eines 'expliziten' asiatischen Fonts
(z.B. SimHei) zeigt keine Fehler in der Anzeige der belegten Zeichen.
. Die Kodierung der Zeichen in der exportierten MIF zeigen keinen Unterschied.
. Der erste sichtbare Nachteil eines solchen Fonts ist, dass dieser bei der
Definition von Kombinierten Schriften nicht mehr für die Auswahl der asiatischen
Schrift zur Verfügung steht, d.h. für Kombinierte Fonts ist dieser Font nicht
geeignet. (Andererseits ist ein Kombinierter Font bei Verwendung eines Global
Fonts im Grunde auch nicht notwendig, da dieser ja bereits die gewünschten
lateinischen Zeichen enthält.)
. Kann die "Silbentrennung" asiatischer Sprachen bzw. die Kumihan-Einstellungen
durch die geänderte Encoding-Angabe des Fonts beeinflusst werden?
(Wobei: Benutzerspezifische Kumihan-Tabellen habe ich nie verwendet, weil
sie schlicht viel zu instabil waren ...) -> check
. Möglicherweise gibt es durch das Fehlen des asiatischen Encodings Probleme
mit Scripts oder Plug-Ins, die das Encoding eines Absatzes auswerten?
Ich erinnere mich da an unterschiedliche Rückgabewerte für TextRanges oder
TextLocs in FrameScript, die dann mit eSys.GetDefFontEncoding bzw.
eSys.SetDefFontEncoding umgangen werden konnten/mussten. -> check
. Bei der Erstellung unterschiedlicher Testfonts (mit entferntem Codepage-Support
für asiatische Sprachen) ergaben sich zu 100% reproduzierbare Distillerfehler,
welche bei anderen Varianten mit denselben Einstellungen offenbar nicht auftraten.
%%[ Error: invalidfont; OffendingCommand: definefont; ErrorInfo: .notdef --nostringval-- ]%%
Wodurch dies konkret verursacht wird, hat sich mir bislang noch nicht eröffnet ...
Dieser Fehler tritt übrigens auch bei einer "Pro"-Variante des von URW erstellten
Fonts auf - auch hier allerdings ausschließlich bei Verwendung mit FrameMaker ...
Schöne Grüße,
Klaus Müller, itl AG
Michael Müller-Hillebrand
Ich beschäftige mich momentan ebenfalls mit diesem Problem.
Es wird zwar nicht Arial Unicode MS eingesetzt, aber ein von URW für den
Kunden erstellter "Global Font" mit Unterstützung u.a. für Chinesisch, Japanisch,
Koreanisch und Arabisch.
In der aktuellen Diskussion m.E. vernachlässigt wurde das ursprüngliche Problem
des Fragestellers:
. Warum überlässt oder erlaubt FrameMaker es nicht dem Anwender, zu entscheiden,
welche Sprache ein Text haben soll, sobald der verwendete Font asiatische
Sprachen unterstützt? Und:
. Warum funktionieren diese Global Fonts in anderen Applikationen in allen Sprachen,
nicht aber in FrameMaker?