Ich brauche Hilfe bei Problem mit TTF Kerning in Fontlab

[[Mitglied Bril…]]

Hallo Arno. Danke für deinen Einsatz. Wenn ich jetzt deinen Font in Studio 5 öffne, gibts den gleichen Effekt mit dem Zeichen Alt+0158 im Quicktest. Da kommt dann die .notdef-Glyphe. Auch wenn ich den Font als Truetype schreibe bleibt es dabei: das Zeichen spinnt.

 

[[Mitglied 6813…]]

Das Problem mit der .notdef-Glyphe habe ich in FontLab Studio 5.04 nicht. Weder mit dem von mir generierten, noch mit deinen Fonts.

[[Mitglied Bril…]]

Das ist interessant.

Ich habe es auf meine PC (Win10/64) mit 5.02 und 5.2.1 probiert, das Ergebnis stets: siehe Screenshot, kein Char 158 im Quicktest.

Könnte es sein, dass du eine andere OS-Umgebung hast?

Der Fontlab Support hatte mich ja schon darauf hingewiesen, dass es da irgendwei ein Problem gibt und mich deshalb gebeten, das mit einem ältere Fontlab-Release zu probieren. ein 5.04 habe ich aber nicht, nur ein 5.02 . Es reicht wohl nur die exe-Datei aus, vielleicht kannst du mir die ja mal als privat-Mail rübergeben?

 

[[Mitglied 6813…]]

Ich habe Windows 7 installiert. Windows 10 vertrag ich gesundheitlich nicht.

 

vor 21 Minuten schrieb Brille:

Es reicht wohl nur die exe-Datei aus, vielleicht kannst du mir die ja mal als privat-Mail rübergeben?

Das darf ich leider nicht. Aber deswegen kannst du dich ja direkt an FontLab wenden.

[[Mitglied catf…]]

Mich wundert es überhaupt nicht, das dein  "c158" benanntes Zeichen sich mit Eingabe von Alt+0158 nicht aufrufen lässt, denn es ist Codiert auf F09E.

Dieser Symbolfont wird ja, damit eine Tastatureingabe dieser im PUA angesiedelten Codierung überhaupt möglich ist vom Unicode-Bereich F020 - F0FF auf 0020 - 00FF herunter gemapped, und daher gelten hier eben leider auch die in diesem Bereich gesperrten Codeplätze, die dich ja davon abhalten, den Font eben als nicht-Symbolfont zu codieren.

Siehe hier:

Das du im PUA dann auch jeden Platz belegen kannst, hat da leider nichts mit zu tun. Du kannst diese Zeichen ja dann über ihren Unicode aufrufen, wenn man sich z.B. über das Keyboard-Layout-Creator-Programm diese Codepunkte auf die Tastatur packt. Alt+0158 funktioniert eben definitiv nicht, und ruft dann eben tatsächlich U+007E auf - und das ist im Font nicht drin, also .notdef!

 

Ich hab dein c158 mal auf "zcaron" (also U+007E) - das rutscht dann ans Ende der im Fontlab angezeigten Glyphen, aber na und?  Die angezeigte Reihe ist ja total uninteressant für die Nutzung des Fonts.

 

 

BeStPlainXZ2c.ttf

[[Mitglied 6813…]]

vor 21 Minuten schrieb catfonts:

Mich wundert es überhaupt nicht, das dein  "c158" benanntes Zeichen sich mit Eingabe von Alt+0158 nicht aufrufen lässt

Bei mir lässt es sich aber mit Alt+0158 aufrufen. Sowohl in FontLab selbst, als auch in Word 2010. Und soweit ich verstanden habe, kann Brille das im original Font enthaltene Zeichen ebenfalls mit der Eingabe Alt+0158 aufrufen. Nur nicht mit dem modifizierten Font.

[[Mitglied Bril…]]

@ catfonts : Wie genau hast Du das gemacht? Eine neue Glyphe als Kopie des c158 angelegt und die dann über die Properties mit zcaron benannt  und auf U+017E gelegt?

Ich habe dann mit deiner Schrift den merkwürdigen Effekt (den ich zumindest nicht verstehe), dass ich, wenn ich deine TTF in Studio öffne, zunächst beim Eintippen von ALT+0158 im Metricfenster immer das "alte" Zeichen (also meines ohne den Punkt) zu sehen ist, sobald ich dort aber einmal /zcaron eintippe, fortan immer das neue Zeichen (also deines zur Unterscheidung mit Punkt) angezeigt wird, auch wenn ich ALT+0158 eintippe. Warum ist das so?

 

[[Mitglied catf…]]

Im Grunde habe ich das ganz einfach gemacht, eigentlich um zu sehen, wohin deine Alt+0158-Eingabe dich schickt, bekommst du das .notdef zu Gesicht.

 

Ich bin im Menü auf  Glyph gegangen, dort dann "Generate Glyph" (alternativ geht auch Strg+G) und in das Fenster zu generierenden Glyphen einfach nur "zcaron" eingetragen. Damit erschien eine neue Glyphe im Font-Fenster, diese zeigt dann erst einmal nur ein z, da dieser Buchstabe vorhanden ist, ein Caron jedoch nicht.

 

Dann habe ich mir deine Glyphe "c158" gesucht, und an Stelle des z(caron) eingefügt, und zum Erkennen, welches Zeichen ich bekomme, dieses durch den Punkt gekennzeichnet, aber auch das Doppelkreuz etwas bearbeitet (das war meine erste Idee zur Kennzeichnung, fand das aber nicht deutlich genug, darum zusätzlich der Punkt.)

 

Auf diese Art kannst du dann testen, welche Glyphe in deiner Anwendung dann tatsächlich verwendet wird.

 

[[Mitglied Bril…]]

Vielen Dank für deine hilfreichen Erklärungen. Ich werde von mal zu mal schlauer

Und hast du eine Erklärung, warum mit ALT+0158 im Metric Window zunächst das "alte" Zeichen c158 angezeigt wird und erst dann, wenn einmal "/zcaron" eingegeben wurde, das neue? Wo kann ich denn sozusagen erkennen, welches Zeichen des angewählten Encodings jeweils mit welchem ALT-Code unter Windows "verknüpft" wird, hier scheinen ja auf wunderliche Weise beide Glyphen mit dem Tastencode verbunden zu sein.

[[Mitglied catf…]]

tja, und da weiß ich jetzt auch nicht weiter, Allerdings hab ich da schon so manche unerklärliche Sonderbarkeit erlebt, siehe

 

[[Mitglied Bril…]]

Das "Nor"-Problem klingt ja wirklich schräg ...

Kannst du mir noch einen Tip geben zum zweiten Teile meiner Frage: Woran kann ich erkennen welcher Tastencode welches Zeichen aufruft, gibt es da in Fontlab Studio vielleicht ein Art Tabelle? Es scheint ja zum Beispiel zumindest auch so, dass Zeichen die in "hinteren" Unicode-Rängen liegen (wie eben Symbolschriften bei F...), trozdem über die gleichen ALT-Kombinationen aufgerufen werden können, wie Standardschriften wo die entsprechenden Glyphen gleich "vorn" liegen.

[[Mitglied catf…]]

Hier kann ich eigentlich nur Mutmaßen.

 

Ich nehme mal nur an, dass bei der Alt+XXXX Eingabe dieser Wert schlicht in einen 16Bit Hexadezimalcode übersetzt wird, also in 2 Byte, mit einem höherwertigen und einem niederwertigen Byte.

 

Jetzt hast du deinen Font als Adobe/Microsoft-Symbolkodierung markiert, und diese liegt eben auf der alten 8bit ANSI-Codierung, mit dem höhewertigen Byte F0 nur als Marker für den Symbolfont, also wird bei einen normgecht codierten Symbolfont das höherwertige Byte einfach ignoriert. Findenm sich dann aber im Font Zeichen, über die Standardcodierung hinaus, erkennt das System den endlich als OpenType-Schriftart und schaltet auf ein direktes Erkennen des Unicodes bei der Alt+0xxx Eingabe.

 

Aber generell, gibst du auch andere, normalerweise im Ur-Font enthaltene Zeichen über [Alt]0xxx ein?

 

Generell wird dein Zeichen aber bei dieser Alt-Eingabe nicht über den Glyphennamen ausgewählt. Wenn du das nicht c158 sondern c159 nennen würdest, würde es dann auch nicht über Alt0159 aufgerufen.

[[Mitglied Bril…]]

Am 2.12.2016 um 13:36 schrieb Arno Enslin:

Das Problem mit der .notdef-Glyphe habe ich in FontLab Studio 5.04 nicht. Weder mit dem von mir generierten, noch mit deinen Fonts.

Ich habe mir von Fontlab die Version 5.04 mailen lassen. Leider tritt das Problem mit dem Char 158 im Quicktest auch dort auf.

Ich werde das Ganze jetzt umgehen und versuchen den Programmierer auf Unicode-Adressierung umzustimmen. Dann dürfte das alles nicht mehr problematisch sein. Es gibt ohnehin Gründe, das zu tun (es sind künfitg mehr Zeichen notwendig, als sich in ANSI codieren lassen), also ist das ein guter Anlass.

Bisweilen erstmal vielen Dank an alle, die mitgeforscht haben. Ich habe bei allem erfolglosen Aufwand doch einiges dazugelernt.