Jump to content
Ständig interessante neue Typo-Inhalte auf Instagram. Abonniere @typography.guru.

Ich brauche Hilfe bei Problem mit TTF Kerning in Fontlab

Empfohlene Beiträge

Brille

Arno,

wenn ich neue Unicodes generieren lasse, funktioniert irgendwie garnichts mehr richtig. Dann kann ich die Zeichen überhaupt nicht mehr eingeben, so ganz "normal" über die Tastatur (A, B C oder Alt + xxx), weil alle Glyphen neu codiert sind.

 

Seufz. Ich bin kein Fonttechnologie-Fachmann, dem Aufbau und Anwendung von  Unicode in Fleisch und Blut übergegangen ist. Ich habe alles, was ich dazu finden konnte, gelesen, aber ehrlich gesagt finde ich, dass es nicht viel gibt und vieles auch nicht leicht verständlich ist. Wie funktioniert das mit den Encoding-Tabellen? Woher weiß Windows, welches Zeichen meines Fonts gemeint ist, wenn ich z.B. Alt+0158 eingebe? Als Symbolzeichensatz liegen die Zeichen doch irgendwo auf hinteren Unicode-Plätzen.

Fragen über Fragen. Ich kann manchens theoretisch sehr gut nachvollziehen, aber die praktische Umsetzung mit FontLab Studio bleibt mir oft ein Rätsel. Ich habe zu "alten" Vor-Unicode-Zeiten mal Schriften entwickelt (vor 2o Jahren) und da war alles noch schön einfach, jedenfalls verständlicher. (255 Zeichen, die ich definieren konnte und beim Programmieren oder über die Tastatur  aufrufen).

Jetzt ist das wirklich kryptisch geworden und wenn dann noch TypeTool und Studio die Dinge unterschiedlich behandeln, bin ich einfach aufgeschmissen.

Die in Youtube oder Vimeo zu findenden Tutorials zu Fontlab bleiben irgendwie doch sehr an der Oberfläche. Das Handbuch schweigt sich zu vielem aus. Aber ich bin neugierig und will das verstehen! Ich wäre sehr froh, gäbe es mal irgendwo einen Workshop oder ein Seminar oder ähnliches zu Fonttechnologien. Oder wenigstens ein gutes (idealerweise auch noch  deutsches) Fachbuch zu dem Thema.

Der Frust musste mal raus.

 

Bernhard

 

Link zu diesem Kommentar
catfonts

A-ha!

 

U+F07E is not a valid unicode character.

Ändere den Wert bei Unicode mal auf 017E

 

Der Name ist nämlich nur intern, z.B. in der Kerningtabelle oder in OpenType-Features für die Auswahl der Glyphe verantwortlich. Wenn du aber Alt+0158 eintippst, wird das Unicode-Zeichen U+017E (zcaron (ž)) aufgerufen, und das ist ja dann auch nicht vorhanden.

Link zu diesem Kommentar
Brille

Danke, catfonts, dass du dran bleibst :-)

Ich habe den Unicode-Wert dieser Glyphe in den Properties geändert von F09E zu 017E (ehrlich gesagt ohne ganz genau zu verstehen, was ich da tue).

Dann springt diese Glyphe ans Ende der Glyphen-Tabelle und der alte Platz bleibt leer.

Aber wie kann ich denn jetzt diese Unicode-Adresse, diese Glyphe, wieder der "Alt+0158" zuordnen? Wenn ich jetzt im Metrik-Fenster "Alt+0158"eintippe, kommt gar kein Zeichen mehr. Und wenn ich nach dann das Metric-Fenster verlasse, stürzt Fontlab reproduzierbar ab.

 

Interessanterweise funktioniert bei dieser einzelnen Glyphe auch das Auto-Unicode nicht (der kleine Diamant). Wenn ich da drauf klicke, erzeugt er keinen Unicode für dieses Zeichen, die Zeile bleibt leer. Bei allen anderen Glyphen geht das.

 

Link zu diesem Kommentar
Gast Arno Enslin
vor 34 Minuten schrieb catfonts:

U+F07E is not a valid unicode character.

Ändere den Wert bei Unicode mal auf 017E

Das war’s, was ich meinte. Die Zeichen sind alle falsch codiert, also mit einem F statt 0.

 

vor einer Stunde schrieb Brille:

Wie funktioniert das mit den Encoding-Tabellen? Woher weiß Windows, welches Zeichen meines Fonts gemeint ist, wenn ich z.B. Alt+0158 eingebe?

In Bezug auf den ASCII- bzw. ANSI-Code kann ich nur vermuten, dass Windows den Code in den Zeichennamen übersetzt und in dem Font nach dem Zeichen, das diesen Namen trägt, sucht. Ich bin mir da aber keineswegs sicher. Auf dem Mac würdest du mit dem Code 158 ein anderes Zeichen erreichen. Ich habe mich aber nie intensiv mit Zeichensatztabellen beschäftigt. War einfach bisher nicht nötig. Es wäre besser, wenn das jemand erklären würde, der kompetenter auf diesem Gebiet ist als ich.

 

Über Unicode erreicht man aber unter allen Betriebssytemen dieselben Zeichen, sofern die Zeichen richtig kodiert sind.

 

Ich bin selbst eher der Try-and-Error-Typ. Deswegen ist das nicht so einfach für mich, dem Problem auf die Spur zu kommen, ohne Corel Draw X5 und das Notensatzprogramm installiert zu haben.

 

Du könntest mal das FontInfo-Panel aufrufen, unter Supported codepages Latin 1 angeben und das Microsoft Character Set auf Western (Latin 1) CP 1252 / ANSI setzen.

 

Edit: Vor allem solltest du aber mal überprüfen, ob Corel Draw X5 und das Notensatzprogramm mit Kerning überhaupt etwas anzufangen wissen. Macht ja keinen Sinn, Fehler in deinem Font zu suchen, wenn die Programme mit dem Kerning prinzipiell nichts anzufangen wissen.

Link zu diesem Kommentar
Brille

Ich habe die Schrift-Codierung unverändert von der Original-TTF übernommen, da lagen diese schon im Fxxx-Bereich. Soviel ich über Unicode verstanden habe, ist das im Prinzip auch richtig, da Symbol-Zeichensätze im Unicode Fxxx-Bereich liegen sollten.

Wenn ich etwa die WingDings.ttf in Studio 5 lade, liegen die Unicodes auch alle im Fxxx-Bereich.

Auch mein Problem ist im Grunde: ich komme mangels verständlicher Dokumentation auch nur mit Try und Error weiter, aber an der Stelle eben einfach nicht mehr ...

 

 

Link zu diesem Kommentar
Gast Arno Enslin
vor 15 Minuten schrieb Brille:

Wenn ich etwa die WingDings.ttf in Studio 5 lade, liegen die Unicodes auch alle im Fxxx-Bereich.

Aber deine Sonderzeichen tragen ja fast alle die Namen von Zeichen, die keine Symbole, sondern z. B. ASCII-kodiert sind.

 

Wenn sie in der Private Use Area liegen sollen, solltest du nicht die Namen von Zeichen verwenden, die registrierten Unicode haben.

 

Aber wie gesagt: Es kann auch sein, dass weder das Notensatzprogramm noch Corel Draw X5 Kerning interpretieren können. Das Notensatzprogramm nicht, weil es schlichtweg zu alt ist. Und Corel Draw X5 nicht, weil es z. B. einen Bug hat. Deswegen musst du erst mal überprüfen, ob diese beiden Programme mit dem Kerning eines Fonts umgegehen können, der technisch nachweislich in Ordnung ist und Kerning-Informationen enthält, u. z. am Besten in der Kern-Table, falls die Programme auf diese Tabelle zurückgreifen müssen.

Link zu diesem Kommentar
catfonts

und ich würde die Unicodes mal komplett auf die eines Text-Fonts umstellen, und auch die Markierung als Symbolfont aufheben. Wie dann die Glyphen-Namen heißen ist eigentlich ziemlich Egal, Wenn ich ein A "Tirllipflumm" nenne, und es dann über den Alt+xxx Code des A aufrufe, bekomme ich auch ein A.

vor 1 Stunde schrieb Arno Enslin:

In Bezug auf den ASCII- bzw. ANSI-Code kann ich nur vermuten, dass Windows den Code in den Zeichennamen übersetzt und in dem Font nach dem Zeichen, das diesen Namen trägt, sucht.

Das scheint mir Falsch zu sein, es zählt nach außen nur die Codierung. denn vergleicht man hier verschiedene Zeichenfonts unterscheiden sich die Zeichennamen doch erheblich Beispiel: Im Wingdings heißt U+F025 "Bell" und in Webdings "trophy" - was eindeutig bedeutet, das Windows die Zeichen NICHT nach ihrem Namen aufruft. Du kannst sie also durchaus sprechender benennen, wichtig ist NUR der Code

 

Das Problem bei den Dingbat-Fonts: Hier braucht man ja eigentlich kein Kerning, da diese Symbole ohnehin zu 99% einzeln verwendet werden, und eben zumeist auch auf gültigen Codeplätzen liegen, und F07E ist eben ein ungültiger Code, wie auch einige innerhalb des ANSI-Bereichs, die man nicht verwenden darf.

 

Darauf habe ich mir auch angeschaut, welchen Code-Bereich eben dieser Symbolbereich abdeckt, und der reicht eben nur von F021 bis F0FF - alles was da außerhalb liegt, darf nicht einfach logisch erweitert werden F101 liegt also für den Codebereich "Symbol" außerhalb des zulässigen Bereichs

 

Gut möglich, dass Symbolfont und Kerning sich sogar ausschließen, und alle Probleme weg sind, hast du daraus einen normalen Schriftfont gemacht, mit den Unicodes 0xxx statt Fxxx

 

Sehr viele, besonders wenn diese mehr Zeichen als im Bereich F021 - F0FF möglich, nutzen die normale (nicht Private Use-Area) Codierung bei U0021 - U0FF und darüber hinaus, also wirklich auf dem Platz von Buchstaben, Zahlen, Sonderzeichen, Akzenten.

 

Link zu diesem Kommentar
Gast Arno Enslin
vor 2 Stunden schrieb catfonts:

Das scheint mir Falsch zu sein, es zählt nach außen nur die Codierung. denn vergleicht man hier verschiedene Zeichenfonts unterscheiden sich die Zeichennamen doch erheblich Beispiel: Im Wingdings heißt U+F025 "Bell" und in Webdings "trophy" - was eindeutig bedeutet, das Windows die Zeichen NICHT nach ihrem Namen aufruft. Du kannst sie also durchaus sprechender benennen, wichtig ist NUR der Code

Das ist aber Unicode in der Private Use Area. Jedenfalls nicht ANSI. Wenn die Zeichen Unicode haben, können sie, glaub ich, im Prinzip heißen, wie sie wollen. Ich kann mich da aber irren. Müsste man mal ausprobieren. In der Private Use Area sollte der Name aber egal sein. Deswegen heißt sie ja so. Weil der Bereich keinen bestimmten Zeichen zugeordnet ist. Die richtigen Namen sind dennoch nicht ganz unwichtig für Fallbacks oder beim Kopieren von in einem PDF enthaltenen Text. Ist lange her, dass ich mich damit beschäftigt habe. Ich meine mich zu erinnern, dass wegen solcher Kopiervorgängez. B.  ein Kapitälchen-a a.sc heißen sollte. Wichtig sind die richtigen Namen auch, weil FontLab den Unicode aus einer Tabelle heraus generiert, die Namen und Unicode enthält. Ist der Name falsch, kann auch nicht der richtige Unicode generiert werden.

Link zu diesem Kommentar
catfonts
vor 1 Stunde schrieb Arno Enslin:

Ist der Name falsch, kann auch nicht der richtige Unicode generiert werden.

Aber ich kann in dem Fenster Glyph Properties den richtigen Unicode eintragen, sofern der nicht schon mit einer anderen Glyphe belegt ist.

Die Mapping- und Encoding-Datei lässt sich übrigens leicht editieren, ich habe das für Frakturschrifdten gemäß der UNZ1-Codierung auch selbst gemacht, um so den Fraktur-Ligaturen auch den entsprechenden PUA-Code zuzuweisen, das bedeutet natürlich, dass ich in diesen Dateien die hierfür empfohlenen Glyphennamen eingetragen habe.

 

Microsoft mapped einfach die Codes F020 bis F0FF auf die vom Programm gelieferten Codes 0020 bis 00FF, sodass z.B. bei einem Dingbatfont bei Eingabe von A (0041) dann die Glyphe mit dem Code F041 ausgegeben wird. Das ist eine Windows-Funktion die bei Symbolfonts mit einer Codierung von F020 bis F0FF funktioniert, Jenseits von F0FF wird das daher nicht richtig funktionieren.

 

Hier ein kleiner Testfont, mit regulärer Codierung, aber total blödsinnigen Glyphennamen. Wenn eine Software die Zuordnung der Glyphen zu den Tasteneingaben anhand der Glyphennamen macht, dürfte dieser Font nicht funktionieren:

Codiertest.zip

Link zu diesem Kommentar
Gast Arno Enslin
vor 52 Minuten schrieb catfonts:

Hier ein kleiner Testfont, mit regulärer Codierung, aber total blödsinnigen Glyphennamen. Wenn eine Software die Zuordnung der Glyphen zu den Tasteneingaben anhand der Glyphennamen macht, dürfte dieser Font nicht funktionieren:

Wenn die Glyphen aber zum ANSI -Zeichensatz gehören und ihnen kein Unicode zugewiesen wurde, was dann? Dann muss doch zum Beispiel das Zeichen ALt+0158 im Font trotzdem gefunden werden.  Und vor allem: Sowohl unter Mac als auch unter Windows. Wie, wenn nicht über den Namen, soll denn dann die Zuordnung der Zeichen im erweiterten ASCII-Zeichensatz stattfinden? Auf dem Mac ist Alt+0158 ein anderes Zeichen als unter Windows. Mist, ständig ist hier der Cursor weg.

 

In Bezug auf den Rest deines Beitrags: Sehr interessant. Ist mir neu gewesen.

Link zu diesem Kommentar
catfonts

Nun, dazu muss man sich nur mal eine uralte ANSI-Schrift decompilieren, und siehe da, auch diese haben dann an den selben Stellen der Glyphentabelle die nummerischen Codierungen von Hexadezimal #20 bis #FF entsprechend Unicode 0020 bis 00FF

 

Zumindest sagt mir das mein wiedergefundener Type-Designer (erstaunlich wie lange Disketten lesbar sind :-) )

(von DTP-Software, Manfred Albracht, in einer virtuellen Win3.1-Umgebung, die ich für solche Extrmtests auf einem älteren Rechner laufen habe. Das war für damals ne super Software, schade, dass die nicht weiter geführt wurde, und Herr Albracht jetzt Fontlab verkauft)

Hier im Screenshot ist der ANSI-Code dezimal angezeigt, also von 32 = Leerzeichen bis 256 = ÿ.

TypeDesignerCoding.JPG

Link zu diesem Kommentar
Brille

Ich freue mich auf jeden Fall, dass das hier ein rege gelesenes Forum ist. Mit dem TypeDesigner von Manfred Albracht habe ich früher (vor bestimmt rund 20 Jahren) auch gearbeitet, das war alles wunderbar einfach und genau den oder sowas einfaches würde jetzt mein Problem wahrscheinlich gut lösen. Ich habe hier auch noch einen alten Rechner mit Windows 98 rumstehen. Aber ich denke nicht, dass ich noch meine alten TypeDesigner-Programm Disketten finde, ein Disk-Laufwerk habe ich sogar neulich kaufen müssen, um eine andere alte Diskette zu lesen. Mal so blöd gefragt: Catfonts, kannst du mir das mal zur Verfügung stellen? Ich würde es dann damit mal ausprobieren.

 

 

Link zu diesem Kommentar
Brille

Ich habe auch versucht, die Schrift nicht als Symbolfont zu erstellen, sondern als "normale" Schrift. Das Problem ist dann aber, dass im Windows 1250 Central European Encoding einige Lücken auf den vorderen Plätzen von 33 bis 255 sind, die ich dann nicht belegen und auch nicht adressieren kann. Ich brauche aber den Platz vollständig, weil ich über 220 Zeichen unterbringen muss.

Ach, wenn ich die Zusammenhänge nur mal besser verstehen würde ...

Link zu diesem Kommentar
catfonts

Dann geh doch einen ganz anderen Weg und nutze die Fett- und Kursivfunktion:

Teile deine Zeichen auf 4 Fonts auf, und verwende da tatsächlich nur die Zeichen, die sich ohne Codeeingabe direkt über die Tastatur eingeben lassen, dann packe den erste Teil in den normalen Font, den 2. in den kursiven, den dritten in den fetten, unbd den 4. teil in den fett-kursiven Font.

 

Reicht dieser Platz auch noch nicht aus, kannst du deine Tastatur erweitern, und jede Taste mit einer 4-fach Belegung versehen. Hierzu gibt es frei von Microsoft den "Microsoft Keyboard Layout Creator" Hiermit kannst du auf z.B. jede Buchstabentaste, Ziffern und Sonderzeichentaste  bis zu 2 weitere, frei gewählte Unicode-Zeichen belegen, die dann mit AltGr und Umschalt+AltGr aufgerufen werden können.

 

Dein zcaron hochgesetzt auf das PUA ist ja auch schon außerhalb des Bereiches, der als Symbolfont zulässig ist, und auf die Codes der normalen Buchstaben heruntergemappt wird, drum klappt eben auch der Aufruf nicht.

Link zu diesem Kommentar
Brille

Das geht ja nun leider nicht. Meine Schrift soll ein 1:1 Ersatz für einen vorhandenen Font sein. Dieser Font ist ein Symbol-Font und dort sind alle Zeichen auch problemlos aufzurufen. Der Originalfont ist aber nicht gekernt. Das Pogramm selbst kann ich nicht umprogrammieren. Alle genannten Probleme tauchen erst auf, wenn ich Kerning anlege.

Ich habe jetzt mal großzügig meine vorhandenen TT-Symbolschriftsätze (Wingdings, Notensatz und so weiter ...) in FontLab geladen und durchgesehen. Kein einziger Symbol-Font verfügt über ein Kerning, obwohl das in einigen der Zeichensätze durchaus sinnvoll wäre. Ist es womöglich wirklich so, dass bei Schriften mit Windows-Symbol Encoding Kerning garnicht richtig unterstützt wird?

 

Link zu diesem Kommentar
vor 17 Minuten schrieb Brille:

Ist es womöglich wirklich so, dass bei Schriften mit Windows-Symbol Encoding Kerning garnicht richtig unterstützt wird?

Die Frage musst du dem Entwickler eines konkreten Programmes stellen. 

Link zu diesem Kommentar
Brille

@ catfonts: Vor - und Nachbreiten: Das habe ich schon durchgespielt, das geht aber nicht, weil für die Akkordbezeichnungen ziemlich viele Kombinationen notwendig sind und nicht mit allen funktioniert das dann.

 

@ Ralf: die Fragen und Probleme habe ich ja alle schon mit dem FontLab-Support (Alex) sehr ausführlich aber erfolglos diskutiert. Alex hat dabei einen Programmfehler im aktuellen Release festgestellt, der vermutlich den Char158-Fehler verursacht und mir deshalb empfohlen, testweise auf ein älteres Release zurückzugreifen. Ich hatte hier noch ein 5.0, das hat dann aber an der Stelle leider auch nicht besser funktioniert.

Link zu diesem Kommentar
catfonts

Ich glaube, dieser Char158-Fehler hat nichts mit Fontlab, sondern mit Microsofts Umgang mit der Alt+0158-Eingabe zu tun, die dann eben das Zeichen U+017E .

 

Schade eigentlich, dass deine Anwendung keine OpenType-Funktionen kann, dann wär das alles um 100% einfacher. Leider hat sich das in Programmiererkreisen kaum rumgesprochen, und man hackt an Technik aus dem letzten Jahrtausend herum.

Link zu diesem Kommentar
Brille

Naja, das stimmt. Ich habe deshalb schon mit dem Programmierteam in Kanada gemailt. Das Poblem ist, dass der Kern der Software (Band in a Box, übrigens ein geniales Programm) tatsächlich schon 20 Jahre alt ist und sukzessive weiterentwickelt wird. Da nimmt man "radikale" Änderungen in der Programmierumgebung eher ungern in Angriff (never change a running system).

Link zu diesem Kommentar
Gast Arno Enslin

@ Brille

 

1. Falls der original Font kostenlos ist, lade den bitte mal hoch.

 

2. Ich glaube, ich habe mindestens zweimal gefragt, ob das Notensatzprogramm in der Lage ist, das Kerning irgend eines Fonts darzustellen. Falls nämlich nicht, ist es doch völlig müßig, das Problem im Font zu suchen.

 

3. Ich kann mir beim besten Willen nicht vorstellen, dass Zeichen nicht mehr erreicht werden können, nur weil der Font eine Kern-Table enthält. Kern-Table und GPOS-Table sind nicht dasselbe. Die GPOS-Table kann Kerning-Klassen enthalten, die Kern-Table nicht. Die Kern-Table gibt es nicht erst seit OpenType.

 

Du kannst auch mit TTX so eine Tabelle in den Original-Font „hineinmergen”, wenn du ganz sicher gehen willst, dass ansonsten keine Änderungen am Font vorgenommen werden. Jedenfalls kann es durchaus passieren, dass FontLab irgend welche Veränderungen vornimmt, die man nicht beabsichtigt hat. Mit der -t-Option dekompiliert dir TTX die Tabelle deiner Wahl, z. B. die Kern-Table, die das expandierte Kerning des Fonts enthält, den du mit FontLab generiert hast. Wenn die Zeichenbelegung in beiden Fonts gleich ist, und du glaubst, das Problem entstünde durch die Anwesenheit der Kern-Table, kannst du das überprüfen, indem du die Kern-Table von dem mit FontLab generierten Font in den original Font transferierst.

Link zu diesem Kommentar
Brille

Hallo Arno,

 

1) den Originalfont (PGChords.ttf) habe ich hier angehangen, es gibt für diesen Testzweck rechtlich kein Problem (ich stehe mit den Lizenzgeber in direktem Kontakt). Der originale Font beinhaltet keine Kerning-Informationen. Die Zurichtung und das handschriftliche Design der einzelnen Zeichen (gestalterisch alle in nahezu rechteckige Boxen) macht das, anders als in meiner Schrift, nicht nötig.

2) Das Notensatzprogramm selbst übergibt Zeichenketten zur Ausgabe an das Betriebssystem. Ob das Kerning ausgewertet wird, weiß das Entwicklerteam in Kanadea selbst nicht genau (naja, Programmierer haben selten Verständnis für Typographie). Ich habe die aber auf die Spur gesetzt, das zu prüfen und ggf. in das nächste Release einzubauen, soweit möglich. Im Moment sieht es so aus, als ob das Kerning nicht ausgewertet wird, weil auch Überschriften, die aus der Times gesetzt sind, nicht gekernt werden. Ein guter Hinweis von dir, danke!

3) Der Einfluss von "Kerning oder kein Kerning" auf die Anzeige dieses vermaledeiten Zeichens kann ich mir auch nicht erklären. Tatsächlich kann ich diesen eigenartigen Effekt aber reproduzieren. Ich habe dir hier die Truetypeschrift angehangen, die ich mit Typetool aus meiner vfb generiert habe, nachdem ich Opentype- und Kerning-Informationen gelöscht habe (BeStPlainXZ.ttf). Ich kann aus diesem Font alle Zeichen (auch ALT+0158) anzeigen. Wenn du diesen Font in Fontlab lädst und dann ein Kerning anlegst (oder das Kerning aus meiner vfb importierst), schwupp, wird, jedenfalls bei mir, im Quicktest und auch im exportierten TTF-Font das Zeichen 158 nicht mehr ausgegeben, sondern stattdessen die .notdef-Glyphe. Alternativ kannst du auch meine vfb laden und dort alle Kerning-Informationen löschen. Dann funktionert das Zeichen 158 wieder.

 

Herzliche Grüße

Bernhard

 

BeStPlainXZ.ttf

Pgchords.ttf

Link zu diesem Kommentar
Gast Arno Enslin

Ein paar Unterschiede, die über die Outlines hinausgehen, gibt es aber schon. Abgesehen vom Kerning. Braceleft gibt es im original Font nicht. Und im original Font ist keine supported Codepage angegeben. Vielleicht gibt es noch mehr Unterschiede.

 

Ich werde gleich mal beide Fonts dekompilieren und die Zeichen des einen Fonts in den anderen übertragen. Damit sollten unbeabsichtigte Veränderungen ausgeschlossen sein.

 

Link zu diesem Kommentar
Brille

Das stimmt, scharfe Augen: Braceleft habe ich mit einem noch notwendigen Zeichen ergänzt. Ich bekomme beim Öffnen des Originalfonts in Fontlab Studio 5 als Encoding "MS Windows Symbol" angezeigt.

Link zu diesem Kommentar
Gast Arno Enslin

Mit TTX bin ich nur bedingt weitergekommen. Ich habe u. a. den Index geändert. Er entspricht jetzt dem original Font. Bis auf Braceleft (ist am Ende des Index). Das Encoding sollte jetzt auch dem des original Fonts entsprechen. Allerdings bin ich nicht so geordnet vorgegangen, dass ich dir den Arbeitsprozess jetzt genau beschreiben könnte.

 

 

BeStPlainXZ2.ttf

Link zu diesem Kommentar

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Einloggen

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden

Unsere Partner

FDI Type Foundry besuchen
Mit über 130.000 Fonts der größte Schriften-Shop im Internet.
Hier beginnt deine kreative Reise.
Entdecke hunderte Font-Sonderangebote.
Postkarten-ABC zum Sammeln oder Verschenken …
×
×
  • Neu erstellen...

🍪 Hinweis:

Wir benutzen funktionale Cookies.