Fontlab - Erste Schrift, erste Fragen

[Ralf Herrmann]

Wenn du die Ebene FontAudit anschaltest, werden bestimmte Probleme die FontLab erkennt markiert.

 

Außerdem gibt es im Contour-Menü verschiedene automatische Korrekturfunktionen. Die können bei so einer Schrift ganz praktisch sein.

 

[Obelix]

Das ist ja wirklich super für so eine Schrift! Vielen Dank

[Obelix]

Wie verfahre ich denn im Metric Mode mit Satzzeichen wie:

 

. , ; : ! ? ( ) usw.

 

Genauso wie bei den Buchstaben? nnn!nnn?nnn;nnn

Und das genauso wenn Zahlen auf Buchstaben treffen? nnnn1nnn2nnn3nn4

[Sebastian Nagel]

Satzzeichen gleiche ich mit Buchstaben und Zahlen aus.

 

Bei Zahlen mittle ich in der Regel normalerweise die "0" zwischen "oooooo" aus, und nehme diese dann als Maßstab für die anderen Zahlen, also dann weiter mit 0000000010000000   000002000000 ... (Es sei denn es sind Tabellenziffern, die alle die gleiche Breite und kein Kerning haben (dürfen).

 

Inwieweit du dann die Zahlen noch auf die Buchstaben feinabstimmst, kommt auf die Schrift an ... an der Stelle stellt sich die Frage ob alles mit allem getestet und gekernt werden soll (viel "Mist" mit dabei, aufwendig), oder selektiert wird, was wirklich gebraucht wird (schwer den Überblick zu wahren und an alle Anwendungsfälle zu denken).

 

Inzwischen ist es auch wichtiger, z.b. Kombinationen wie ".w" zu kernen, da sowas ja durchaus in www-Adressen etc. vorkommen kann. "Früher" war das eine eher seltene Kombination, da nach einem Punkt meist ein Leerzeichen stand.

Auch Kleinbuchstaben-Großbuchstaben-Kombinationen wie "oT" waren früher kaum "nötig", wenn heute aber Markennamen mit Gemischtschreibweise geschrieben werden, kann es unter Umständen wichtiger sein.

[Obelix]

Vielen Dank für deine Antwort!

 

Mal eine allgemeine Frage: Wie lange braucht ihr um eine Schrift fertig zu stellen (ohne Schriftentwicklung, nur Metric, Kerning etc. in Fontlab).

Bei einem "normalen" Zeichensatz, generelle Sonderzeichen, eben Standard.

Natürlich hängt's auch vom Schrifttyp ab, aber mal so eine allgemeine Einschätzung von eurem Zeitrahmen.

 

Und noch etwas: Die erstell ich eine Kerningklasse mit Zahlen und Satzzeichen?

Eine Klasse mit bspw:

 

kern1: a' b c d

 

klappt super, aber wenn ich bspw. eingebe:

 

kern1: 1' 2 3 4 oder kern1: ,';:

 

und "accept" drücke, passiert nichts

[Sebastian Nagel]

Der Zeitaufwand ist für mich und meine Arbeitsweise nicht wirklich schätzbar, da ich das ganze nebenher betreibe ... Jemand der das Vollzeit betreibt, hat vielleicht eine bessere Methodik und Arbeitsmoral und vor allem mehr Überblick über die aufgewendete Zeit.

Metrik und Kerning für ein Alphabet (das wäre z.B. a-z oder A-Z oder Kapitälchen-A-Z) schaffe ich konzentriert an einem weit ausgedehnten Abend.

Dann fängt's aber an kompliziert zu werden, denn es geht ja dann auch um Kerning zwischen Groß- und Kleinbuchstaben, Groß- und Kapitälchen, Satzzeichen, Ziffern, ... Da geht für mich fast schon mehr Zeit drauf, insbesondere auch beim »Überblick wahren«.

Für eine Fette kann (und sollte) dann viel von der Metrik und Kerning von der Roman übernommen werden ... wenig neuer Aufwand, mehr Kontrollaufwand.

Die Kursive schenkt hingegen nochmal besonders ein, weil deren Metrik auch wieder gut zur Roman passen muss, damit kursive Auszeichnungen innerhalb eines normalen Textes auch funktionieren.

 

 

Zweite Frage ist einfacher ...

du musst bei der Nennung der Zeichen immer den Glyphennamen anführen, nicht das, was du auf der Tastatur eingeben würdest. Für die normalen Buchstaben ist das identisch (a=a, b=b, ...), für Sonderzeichen, Ziffern etc. hingegen nicht, dort ist es z.b. 1=one, 2=two, 3=three, ...

Den Namen der Glyphe findest du im Properties-Panel (Glyhenübersicht --> Glyphe markieren --> Alt+Enter drücken) im Feld "Name", oder in der Glyphenpalette wenn du als Anzeige "Name" auswählst oberhalb der Glyphenform.

Du kannst aber auch die Glyphen aus der Übersicht einfach ins Kern-Fenster rein ziehen, dann werden sie automatisch mit ihrem Namen eingetragen.

[Obelix]

Yeah! Vielen Dank! :)

 

Dirket die nächste Frage ;)

 

Wenn ich eine Kerningklasse erstellt habe und daraus ein OT Feature machen möchte und "Compile" drücke, kommt diese Warnung:

 

"Feature block seen before any language system statement.  You should place languagesystem statements before any feature definition"

 

Habe dazu etwas im Fontlab Forum gefunden http://forum.fontlab.com/index.php?topic=8278.0;prev_next=next#new

 

Jedoch verstehe ich nicht, wie ich diesen Fehler beheben soll.

 

Achja, ich benutze einen Mac OS X 10.6.8 und Fontlab 5.1.2 Mac

[Obelix]

ich glaube, ich habs...wenn das jetzt alles war, dann heul ich -.-'

 

[Sebastian Nagel]

:) ich glaub das war's, wobei du die beiden Zeilen nicht in ein Feature "xxxx" einbauen solltest (das es nicht gibt), sondern besser in das gelbe Feld unterhalb in deinem Screenshot.

Dieses gelbe Feld ist der "allgemeine" Teil der Opentype-Befehle die du dem Font mitgibst und steht vor den spezifischen Features wie liga, kern, etc.  Das kommt in Fontlab allerdings überhaupt nicht so rüber, somit nicht ohne Hinweis ergründbar ...

 

Die Reihenfolge in der die Opentype-Befehle interpretiert werden ist also:

1. Gelbes Feld (für globale Einstellungen wie Sprachen etc.)

2. das oberste Feature in deiner Liste (das wäre bei dir jetzt das "xxxx")

3. das nächste Feature in deiner Liste

4. ...

 

"kern" sollte dabei immer ganz am Ende stehen.

 

Was du auch machen solltest, ist ein "liga" feature anlegen und vor das kern-Feature reihen. In dieses Liga-Feature solltest du dann zumindest die beiden Standard-Ligaturen "fi" und "fl" eintragen, also

 

feature liga {

sub f i by fi;

sub f l by fl;
} liga;

 

und natürlich die beiden Glyphen "fi" und "fl" anlegen (und seien es nur Alibi-Glyphen) damit sie auch ersetzt werden können.

 

Das Ganze hat damit zu tun, dass entweder Fontlab oder Indesign (weiß nicht mehr wer "schuld" ist) Positionierungsfeatures wie das kern-feature eines ist einfach so lange ignorieren, bis ein Ersetzungsfeature wie das "liga" aufgerufen wurde.  D.h. deine Kerning-Anweisungen sind in der Anwendung unwirksam, wenn du nicht in der Reihenfolge vorher ein alibimäßiges "sub" provoziert hast.

 

 

 

Innerhalb der Features wird übrigens auch von oben nach unten abgearbeitet, d.h. wenn du z.B. eine fi und eine ffi-Glyphe hast, und zum Einsetzen dieser Ligaturen Folgendes schreibst:

feature liga {

sub f i by fi;

sub f f i by ffi;
} liga;

 

wird erst die jede Fundstelle der Glyphenfolge "f i" durch die Glyphe "fi" ersetzt (z.B. wird aus dem Wort "griffin" -->  g r i f fi n).

Danach erst wird nachgesehen, ob es im Text eine Glyphenfolge "f f i" gibt ... die gibt es aber nicht mehr, denn zuvor wurde das "f i" schon durch "fi" ausgetauscht. Somit wirst du mit diesen Befehlen die "ffi"-Glyphe nie zu sehen bekommen  (außer du würdest noch ein "sub f fi by ffi;" hinten dran hängen).

 

Deshalb ist es besser, erst lange Ketten zu suchen und danch die kürzeren:

 

feature liga {

sub f f i by ffi;

sub f i by fi;

} liga;

 

ersetzt erst alle Fundstellen von "f f i" durch "ffi", und wenn danach noch irgendwo "f i" auftauchen sollte, setzt es dort dafür "fi" ein.

[Obelix]

Cool, vielen Dank! :)

Hab den Code jetzt in das gelbe Feld geschrieben.

Bei der Schrift werden keine Ligaturen benötigt, aber gut zu wissen! :)

 

Nächstes Problemchen:

 

Ich habe eine Kerningklasse generiert und ein OT Feature daraus erstellt. Wenn ich nun eine zweite Kerningklasse generiere und ein OT Feature erstellen möchte, kommt immer die Meldung, ob ich die erste Klasse überschreiben möchte. Ich klicke "No", aber die zweite Klasse wird nicht als OT Feature erstellt.

Ich habe die erste Klasse auch nicht angeklickt oder sonstiges... hm...

 

Edit:

 

Ok, jetzt hab ichs -.-'

Auf -Yes- klicken und die zweite Kerningklasse wird unter die erste eingefügt. Es kommen also alle Kerningklassen in das eine OT Feature "Kern".

 

Schon krass, dass alles autodidaktisch hin zu bekommen, so Kleinigkeiten, die einen total aufhalten, findet man nicht in den Büchern oder im 1000seitigen Handbuch^^

bearbeitet April 22, 2013 von Obelix

[Obelix]

Ich habe nun die Metric fertig und bin beim Kerning (Kerningklassen erstellen und daraus OT Features). Klappt bisher auch ganz gut.

Habe die Minuskeln in verschiedene Gruppen aufgeteilt und diese mit dem großen "T" -gekernt-.

 

Im Metrics Mode habe ich die Versalien sehr schmal zusammen geschoben, sodass es ein harmonisches Bild ergibt, wenn Großbuchstabe auf Kleinbuchstabe trifft. Problem ist nur: Die Versalien überschneiden sich gegenseitig etwas. Dies wollte ich mittels einer Kerningklasse beheben.

Die Versalien sollen einfach einen generellen festen Abstand bekommen. Nur wie definiere ich diesen in einer Kerningklasse, auf einen Schlag quasi, ohne jeden Buchstaben mit jedem zu kernen?

[Obelix]

So...sind mal meine bisherigen Kerningklassen (für das große "T" zu den Minuskeln) und der OT Code.

Echt schwierig, wenn man die OT Programmierung noch lernen muss oO

Für Kritik und Tipps am Code wäre ich sehr dankbar!

 

[Sebastian Nagel]

Das ist ein spannender Ansatz – aber ich glaube von hinten auf aufgezäumt ...

Es ist leider ziemlich aufwendig, das in einem Forum kurz und knapp zu erklären und wesentliches nicht zu vergessen ... Fontlab bietet eine Halbautomatik für das Erstellen des KERN-features, das muss also nicht "in Code" gemacht werden, sondern in Form von Klassen und optischem Ausrichten:

 

Erst erstellt man Kerning-Klassen für halbseitig formverwandte Buchstaben. z.B. kannst du in die Klasse "LinksRund" die Glyphen c d e o q und alle Diakritika (ö, é, ...) rein packen. In die Gruppe "RechtsRund" kannst du b e o p reinnehmen.  Weitere Gruppen wären z.B. "LinksHochGerade" mit den Glyphen b h k l.    Welche Gruppen sinnvoll sind, hängt von der jeweiligen Schrift ab. Packe alle rein die *wirklich* gemeinsam behandelt werden können, und lass die "Fragwürdigen" besser raus und gib ihnen eine eigene Gruppe (die im schlimmsten Fall nur 1 Mitglied besitzt).

Ein Mitglied jeder Gruppe kannst du mit ' kennzeichnen, also z.B. c d e o' q. Das ist der Leithammel, mit dem du danach arbeiten musst, während die anderen Mitglieder den Regeln für dieses Zeichen folgen (außer wenn Ausnahmen).

Die Häkchen neben der Gruppe sagen Fontlab, für welche Seite eines Paares die Klasse überhaupt gelten soll. Die Gruppe "LinksRund" sollte natürlich ein Häkchen nur auf der rechten Seite bekommen, denn die Formen sind nur gleich zu behandeln, wenn die Zeichen rechts in einem Paar stehen (Tc Td, Te, To, Tq).  Im Idealfall ist jedes Zeichen in den Klassen so vertreten, dass es insgesamt genau ein Häkchen links und eines rechts hat (b ist z.B. in der Klasse "LinksGeradeHoch - Haken rechts" und in der Klasse "RechtsRund - Haken links" vertreten)! Mehrfachnennungen resultieren in grausigen Fehlermeldungen und Nicht-Generieren des Kern-Features (zwei Anweisungen für eine Zeichenseite, nicht eindeutig). Fehlende Nennungen tun nicht weh (dann gilt das ganze als Einzelzeichen ohne Gruppenzugehörigkeit), vermindern aber die Übersichtlichkeit für dich.

 

Wenn du die Gruppen erstellt hast, wechselst du ins Metrik-Fenster, und dort in den Kerning-Modus.

Dort schreibst du z.B. "nnnnonnnaannnnonnn".   Die "nnnonnnn" sollten aus der Metrik heraus gut aussehen und dienen zum Vergleich wo du mit dem Kerning hin willst. Dann markierst du das zweite "a" und schiebst es mit den Pfeiltasten nach links oder rechts. Dadurch wird eine Unterschneidung für die Kombination "aa" angelegt. Dann blätterst du mit Strg+Mausrad ein Zeichen weiter zu "ab" und regelst dort das nächste Paar. Wenn nun das "b" in der Klasse "LinksGeradeHoch" steht und nicht der Leithammel ist, ist das Zeichen im Metrikfenster dunkelblau statt schwarz. Du kannst das "b" dann einfach auslassen und eventuell nötiges Kerning zwischen a und b beim Klassen-Hammel (z.B. "l") erledigen, was sich dann auch auf das "b" auswirkt. Dadurch kannst du ziemlich viele Kombinationen überspringen bzw. gemeinsam regeln.

So gehts dann weiter bis "az". Danach folgt "ba", "bb", ...  wobei dein "b" vermutlich über den prädestinierten Leithammel "o" abgedeckt wird, d.h. du kannst vermutlich geich zu "ca", "cb", ... springen bis du dann bei "zz" angelangt bist.  Dann geht's weiter mit "Aa" ... "Zz" ... "AA" ... "ZZ" ...

Sei sparsam mit dem Kerning und überlege was wirklich gebraucht wird, was auch ohne Kerning akzeptabel ist, und was nicht ... Auch das hängt von der Schrift ab. Wenn du extrem viele Klassen-Kerningpaare definierst (5000+) rennst du in diverse Fontlab-Bugs rein die sich nur über Umwege umgehen lassen ... soviele solltest du aber nicht brauchen.

 

Bis dahin hast du die Kerning-Angaben nur in Fontlab in der Arbeitsdatei (vfb) gespeichert. Über Tools > Kerning-Assistance > Update KERN feature kannst du dann deine Angaben in das KERN-Feature schreiben lassen (Achtung, ersetzt dein bisheriges Kern-Feature komplett!).

Wenn du dann im Opentype-Panel die Features kompilieren lässt, kannst du die Umsetzung im Preview-Panel im Opentype-Modus auch an und ausschalten und testen.  Das selbe passiert, wenn du eine Font-Datei generierst ... davor immer das Kern-Feature updaten, dann wird beim Font-erstellen automatisch kompiliert und die Kerning-Anweisungen sind so mit enthalten.

 

Dann spielt noch dein Betriebssystem Caching-Spiele mit dir, und du wirst in deinen Anwendungsprogrammen unter Umständen alte Font-Daten bekommen statt deiner eben neu erstellten, ohne es zu merken. Das Einzige was sich bei mir hier bisher in der Praxis bewährt hat, ist immer vor dem Generieren des Fonts über File > Font info > Names and Copyright > Stylename ... im Style einen neuen Namen anzugeben (z.B. Schriftname2 ... 3 ... 4) und dann unten auf das "Build names" sowie im unterpunkt "Opentype specific names" ebenfalls auf "Build opentype names" zu klicken.

So bekommst du eine Fontdatei mit eindeutig neuem Namen, und das System kann dir keine alten Daten unterjubeln.

 

 

(kurz noch zu den Ligaturen von weiter oben: selbst wenn du keine Ligaturen in der Schrift hast oder brauchst, solltest du zumindest eine Pseudo-Ersetzung einbauen, damit die POS-Features wie Kerning greifen können ... Bug sei Dank.)

[Obelix]

Vielen Dank für den ausführlichen Text! :)

 

Hätte nicht gedacht, dass so viel Arbeit dahinter steckt. Zudem ist die Schrift sehr tricki, eben keine geraden Formen...

 

Weiter geht's ;)

[Obelix]

Das sind jetzt meine Klassen:

 

 

Wenn ich die Minuskeln miteinander gekernt habe, erstelle ich dann Klassen für die Versalien (genau wie bei den Kleinbuchstaben, RechtsRund etc...) und dann kommt das Kerning zwischen Versalien und Minuskeln, und danach Versalien mit Versalien?

 

Und die verfahre ich dann mit Satzzeichen, wie: , . : ; € - + usw.? Dafür auch Klassen erstellen und nnna-nn nnnnb-nnn?

Und das ganze dann nochmal bei Zahlen...

[Obelix]

öhm... wenn ich jetzt schreibe: nnnaannn nnnabnnn usw. dann sind immer die rechten Buchstaben blau, bei allen... also irgendwas mache ich noch falsch...

[Sebastian Nagel]

Die Klassen sehen schon mal (fast) richtig angelegt aus:

 

– hast du alle 26 Buchstaben 2x untergebracht? Das ist nicht zwingend, aber erleichtert die Übersicht.

In einer "klassischen" Textschrift müssten da potentiell Klassen fürs a <>  cRechts <  (für die "Spezialform" des c auf seiner rechten Seite), g <>   s <>, eine Sammelklasse für vwy <>   x <> (oder xk <   und x > ?)  und für z <> angelegt werden.  Das kann aber je nach Schrift erforderlich sein oder nicht, kommt auf die Formen an. Die Klassen sind im Grunde schlichtweg "Formsammlungen", alles was ausreichend ähnlich ist, kann gesammelt und gemeinsam behandelt werden. Gleichzeitig kann man die Phase auch als Prüfstein verwenden um Form-Inkonsistenzen zu finden und ggf. zu korrigieren.

 

– Für die Klasse "RechtsRund" würde ich das o als Hauptzeichen festlegen (also o'  statt  c') und das selbe auch für "LinksRund" (auch das o').  Mit dem Kerning des o kannst du dann praktisch alle runden Formen gleichzeitig erschlagen – wenn's später wo Probleme mit was rundem gibt, ist das o die erste Adresse bei der nachgsehen werden muss.   Auch bei anderen Formen gibt es praktische und unpraktische Leitzeichen. Bei den Versalien ist das "H" perfekt für alles was gerade ist (links und rechts).

 

Und richtig: hast du die Minuskeln durch, brauchst du neue Klassen für die Versalien. Diesen "Formkatalog" kannst du dann in sich wieder abstimmen (Versal-Versal) und mit den Minuskeln (Versal-Minuskel und wenn du fleißig bist auch anders rum Minuskel-Versal).

Für Satzzeichen kannst du auch Formverwandtes zusammenfassen, wobei da die Klassen recht klein bleiben, z.b. gehen  (. , ...)  (:;)  ( - – — ·•) zusammen.

Bei den Zahlen wirst du vermutlich feststellen, dass ich kaum gemeinsame Formen finden (0 6 9 haben Ähnlichkeit, 8 und 3 unter Umständen). Hier macht es meist wenig Sinn Klassen anzulegen, wenn man am ende immer nur ein Zeichen drin hat und es somit sowieso eine Einzelbehandlung gibt.

 

 

Zum Problem, dass alles blau ist:

Probiere mal zwei Leithammel nebeneinander zu stellen (und testweise keine nnnnnonnnnn davor und danach). Das wäre z.B. o und l (ol) wenn die beiden in den Klassen RechtsRund, LinksRund, RechtsGeradeOben, LinksGeradeOben als o' und l' markiert sind. Wenn die beiden dann Schwarz sind (oder zumindest das l!), ist mal alles "ok" – es sind beides Master-Zeichen die für andere Zeichen das Kerning mitregeln.

Wenn du dann das l gegen ein h tauschst (oh) (das in der Klasse LinksGeradeOben eingetragen sein sollte?), müsste das h blau werden, als Signal, dass du hier kein Masterzeichen vor dir hast sondern eines, das Kerningwerte vom Master (l') erbt. Du kannst dann *trotzdem* eine Kerning-Angabe machen, die dann als Ausnahme vom Master registriert wird – das solltest du aber möglichst vermeiden, da du damit den eigentlichen Sinn des Klassenkerings unterwanderst.

 

 

Zur Metrik / Kerning von Versalien:

 

Diese werden dir vermutlich zu eng aneinander stehen (oder kollidieren), wenn du die Metrik auf die Minuskeln abgestimmt hast.  Du könntest das jetzt natürlich übers Versal-Versal-Kerning korrigieren ... Bedenke aber, dass es Programme gibt, die kein Kerning anwenden, dann hast du weiterhin Kollisionen. Da hilft dann nur, entweder die Formen dezent anzupassen, oder die Metrik des betroffenen Versals so anzupassen dass es akzeptabel ist, und dafür dann den zu weiten Abstand zu Minuskeln übers Kerning zu justieren. Für mich selbst habe ich entschieden: wenn kein Kerning angewendet wird, dann ist es mir wichtiger dass nach Möglichkeit nichts kollidiert, und dafür nehme ich größere Löcher unter Umständen in Kauf.

 

 

Für Opentype-fähige Programme gibt es noch das CPSP-Feature, das hier weiterhelfen kann:

Es ist dafür gedacht, Versalien zu sperren (oder ausgeklügelter umzupositionieren) wenn der Benutzer den Schalter Versalsatz aktiviert hat (es hilft aber nicht, wenn er einfach nur VERSAL SCHREIBT).

 

Das Feature sieht in der einfachsten Form so aus:

feature cpsp {
  pos @cpsp <0 0 50 0>;
} cpsp;

 

Und gibt allen Zeichen, die sich in der (von dir angelegten!) Opentype-Klasse @cpsp befinden (in der Regel alle Versalien) zusätzlich eine Nachbreite von 50 Einheiten mit. D.h. wenn es aktiv ist, werden alle Versalien etwas gesperrt. Hier könnte man natürlich auch statt pauschal alle jedes Zeichen für sich behandeln, wenn es die Formen erfordern.

Damit bekommst du indirekt beides: Versalien, die gut zu den Minuskeln passen, und brauchbaren Versalsatz.

[Obelix]

Vielen Dank! :)

 

Ja, alle 26 Buchstaben kommen jeweils zweimal in den Klassen vor (bspw. a=LinksRund a=RechtsGerade).

 

Zum zum alles Blau:

Achso, also sollte der Hammel auch immer zweimal gleich gewählt sein?

 

Hammel:

 

LinksRund = a

RechtsGerade = a

 

LinksRund = e

RechtsRund = e

 

LinksObenGerade = l

RechtsObenGerade = l

 

usw. ?

[Obelix]

habe es jetzt so gemacht, wie oben von mir beschrieben.

ich habe zudem "nur" die hammel miteinander gekernt, weil die anderen buchstaben richten sich ja nur nach den hammeln.

 

das ergebnis gefällt mir auch ganz gut.

[Obelix]

so,...

 

Klassen angelegt, gekernt und mittels dem Kerning Assistance die OT Codes geschrieben, bzw. schreiben lassen ;)

Die Regular wäre somit von den Abständen her fertig.

 

Wenn ich die Metric und das Kerning von der Regular in den Boldschnitt importiere, kann ich irgendwo eingeben, dass die Metric und das Kerning sich bspw. um 20% erweitern sollen, oder muss ich alle Werte einzeln bearbeiten?

[Obelix]

Ok, habs schon selber gefunden unter: Action -> Adjust Metrics ;)

 

Alle meine Buchstaben und Zeichen sind ja in Klassen verteilt und damit gekernt.

Wenn ich jetzt -Ausnahmen- kernen möchte, z. B. ist das O und Q in einer Gruppe, beim Q möchte ich aber einen anderen Abstand zum e haben, wie geschieht das? Muss ich dafür einen separaten OT Code anlegen und wenn ja, welchen?

[Sebastian Nagel]

Einfach im Metrics/Kerning-Fenster Qe eingeben. Wenn du dann das e markierst und verschiebst, müsstest du einen kleinen roten Balken zwischen den Zeichen sehen, und in der Kerning-Tabelle rechts wird ein Paar mit roten Ziffern definiert. Das zeigt an, dass das Kerning für dieses Paar festgelegt wurde, *obwohl* das Q kein Master in seiner Klasse ist (das wäre das O').

 

Diese Ausnahme gilt dann aber auch nur für "Qe", also nicht für "Qé, Qè, ...".

 

Wenn du dann noch das KERN-Feature neu generierst, wirkt die Ausnahme auch.

 

Im von Fontlab erstellten Kern-Feature-Code passiert Folgendes: Die Ausnahme wird einfach hinter die Klassenregel gereiht – da Opentype-Befehle von oben nach unten ausgeführt werden, überschreibt die Ausnahmeregel "pos Q e -10;" einfach eine zuvor vielleicht vermerkte "pos @VersalRundRechts @RundLinks -20;"-Regel, in denen Q und e pauschal über die Master O' und o' mitbehandelt worden wären.

[Obelix]

Vielen Dank! :)

 

Jetzt ist der Boldschnitt quasi auch fertig.

 

Kann man ausgesuchten Buchstaben oder Zeichen in Fontlab Tastenkombis zuordnen?

Bspw. drücke ich Apfel+o und ein anderes o erscheint in InDesign.

[Ralf Herrmann]

Nein, Tastaturkürzel sind eine Funktion der Anwendungssoftware, nicht des Fonts. 

[Obelix]

hmm... also muss man dann "special-glyphen" anlegen und diese dann "per Hand" über das Glyphenmenü in ID einfügen?