ERROR Font Validation | Schwerwiegender Fehler | Schrift nicht verwenden | Überprüfung des Systems | Schriftsammlung

[[Mitglied Manu…]]

Guten Tag,

 

bin gerade in der Testphase meiner Schrift. Das Programm »Schriftsammlung« (Mac), gibt diese Fehlermeldung:
»Überprüfung des Systems – Schwerwiegender Fehler gefunden. Diese Schrift nicht verwenden.«.

Dies kommt nur bei der .oft und im bold-Schnitt.
Regular und .ttf (auch von der bold) laufen fehlerfrei.

 

jemand einen tipp wie ich den fehler erstmal finden und dann ggf. beheben kann?

wie testet ihr schriften? gibt es hierfür extra programme?

 

Als Anhang die Fehlermeldung + alle Schriftschnitte zum testen.
Fehler kommt bei nur bei:

HandStampPlayRoughSerif-Bol.oft

 

Hand Stamp Play Rough Serif_all.zip

[[Mitglied 3a6c…]]

Für Windows gibt es den FontValidator.

 

Auf Apple-Computern mit Intel-Prozessor lässt sich doch Windows parallel installieren, oder?

 

Ohne deinen Font jetzt mit dem FontValidator getestet zu haben:

 

Ich habe mir HandStampPlayRoughSerif-Bol.otf in FontLab angeschaut und mit TTX dekompiliert. Dabei ist mir Folgendes aufgefallen:

 

1. In der CFF-Table fehlt der FamilyName.

 

2. Mal davon abgesehen, dass man in FontLab vor lauter roten Warnpfeilen die Outlines kaum sehen kann – jedes kleinste Stempelfleckchen ist gehintet. Das muss wirklich nicht sein. Entweder nur die Outlines der eigentlichen Lettern hinten oder alle Hints löschen.

 

3. In der OS/2-Table ist mir der fsSelection-Wert aufgefallen:

 

   <fsSelection value="00000000 01000000"/>

 

Ich kommentierebestimmte Stellen in dekompilierten Fonts mit Hilfe eines Batch-Scripts. Und der Kommentar lautet:

 

<!-- fsSelection value="00000000 00000000"/ for Upright -->
<!-- fsSelection value="00000000 00000001"/ for Italic -->
<!-- fsSelection value="00000000 00100000"/ for Bold -->
<!-- fsSelection value="00000000 00100001" for Bold Italic/ -->
 

Mit anderen Worten: Ich weiß nicht, was die 1 an der Stelle zu suchen hat, an der sie sich in deinem Font befindet. Im Zweifelsfall würde ich sagen: Gar nichts.

 

    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>

 

Das ist der Short-Style-Name für Windows. Also ist nicht beabsichtigt, dass der Font mit dem regulären Schnitt verlinkt werden soll.

 

Deswegen wäre der richtige Wert für fsSelection:

 

<fsSelection value="00000000 00000000"/>

 

 

[[Mitglied catf…]]

Und ich habe den Font-Validator, und deine Fonts da mal durch gejagt.

 

Erstaunlicherweise hat der in HandStampPlayRoughSerif-Bol.oft nur das gleiche zu meckern wie in HandStampPlayRoughSerif-Reg.otf, das sind aber eigentlich unwichtige Fehler, die bei nahezu allen meinen Fonts, die ich prima auf Windows-Linux und Mac nutzen kann auch habe, und die nie gestört haben.

 

Also habe ich mir die Fonts in Fontlab angesehen, und da folgendes gefunden:

 

 

 

Hier geht es schon mit dem Family Name los, der sollte bei beiden ohnev das Reg und Bol sein, damit die Schriften auch als Familie durchgehen.

 

Bei der Bold muss das nicht nur bei Weight stehen, sondern es muss dann auch der Bold-Flag gesetzt sein, und der Style-name muss auch Bold heißen

 

daraus folgt der nächste Fehler:

 

 

Hier wirds für den Mac vollends unverständlich. Zwar ist hier der OT Family Name richtig gesetzt, aber dafür ist der Style hier mit dem unverständlichen Bolb statt Bold benannt, und für den Mac ist der Font Namenslos. Da sollte noch mal der Family Name stehen.

 

 

 

Daher wird der hier dann auch zu einem Font mit unterschiedlichen Familiennamen, in "Bol" und doch ist der Font Regular?

 

Also diese Sachen noch mal bei allen 4 Fonts überprüfen.

 

 

 

 

[[Mitglied catf…]]

Ich hab das Benennungs-Wirrwarr mal gerichtet, so sollte es klappen. Deinstalliere die Reg auch wieder.

 

HandStampPlayRoughSerif.zip

[[Mitglied 3a6c…]]

@ Manuel V.

 

Dieser Beitrag betrifft dein Problem mit dem Font nicht direkt. Kannst du ignorieren. Es sei denn, du hast Lust, dich mit dem AFDKO bzw. TTX vertraut zu machen und die Namen deiner Fonts zukünftig nicht mehr mit Hilfe eines Font-Editors wie FontLab zu vergeben, sondern mit Makeotf (enthalten im AFDKO) oder TTX und einem Text-Editor. Voraussetzung ist außerdem die Bereitschaft, sich mit der OpenType-Spezifikation zu befassen.

 

@ catfonts

 

Nicht die schlechteste Gelegenheit, nochmal Werbung für das AFDKO bzw. die FontTools/TTX zu machen. Kommentiert von mir, übereinstimmend mit der alten Adobe-Konvention für die Namensvergabe. Aber auch mit der neuen Konvention wären die folgenden Namerecords überflüssig. Der Punkt an der Sache ist, dass man damit unabhängig von den Fehlern wird, die Font-Editoren wie FontLab machen.

 

Wenn du in FontLab die volle Kontrolle über die Namensvergabe haben willst, musst du die Option »Export only OpenType name records - ignore default names« wählen und die Felder unter »Additional OpenType names« manuell füllen. Oder alternativ deinen Font mit FontLab so wie gewohnt generieren, ihn mit eingeschalteter Option »Read all OpenType name records« wieder in FontLab öffnen und die Seite »Additional OpenType names« vom generierten und wieder geöffneten Font in den Quellfont kopieren.

 

Das Basic set of font names ist aber noch wichtig für die CFF-Table und muss bis auf die letzten beiden Felder (Menu Name und FOND Name) ausgefüllt werden.

 

Die Namensvergabe mit FontLab ist desaströs. Das fängt schon damit an, dass das blöde FontInfo-Panel viel zu klein ist.

 

Und Adam Twardochs Tutorial für die Namensvergabe (zu finden auf dem FontLab-Forum) macht die Sache auch nicht besser. Denn sich da durchzuarbeiten ist auch nicht aufwändiger, als sich mit der OpenType-Spezifikation und TTX zu befassen. Außerdem nützt Adams Tutorial wenig, wenn man andere Font-Editoren nutzt.

 

Zitat

 

und für den Mac ist der Font Namenslos.

 

Das Feld »Mac name« ist nur für die Name ID 18, platformID 1.  Und im Fall dieses Fonts (der fette Schnitt) überflüssig.

 

<!-- MAC-16 is useless -->

    <namerecord nameID="16" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Hand Stamp Play Rough Serif
    </namerecord>

 

<!-- MAC-17 is useless -->
    <namerecord nameID="17" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Bold
    </namerecord>

 

<!-- MAC-18 / Compatible Full Name, if you want the name of the font to appear differently than the Full Name (MAC-4) -->
    <namerecord nameID="18" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Hand Stamp Play Rough Serif Bold
    </namerecord>

 

<!-- MS-16-(!!!) / Preferred Family / Omitted, if identical to MS-1 (MS Sub Family). -->

    <namerecord nameID="16" platformID="3" platEncID="1" langID="0x409">
      Hand Stamp Play Rough Serif
    </namerecord>

 

<!-- MS-17-(!!!) / Preferred Sub Family (Long Style) / Omitted, if identical to MS-2 (Short Style, member of MS Sub Family). -->
    <namerecord nameID="17" platformID="3" platEncID="1" langID="0x409">
      Bold
    </namerecord>

[[Mitglied catf…]]

Offensichtlich hast du ja richtig gute Erfahrungen mit AFDKO bzw. TTX. Ich hab mir das grad auch installiert, aber so richtig Peilung hab ich da leider noch nicht. Vielleicht könntest du mich und andere, wie den Threadersteller ja mal mit einem übersichtlichen Tutorial beglücken?

 

Aber anscheinend ist das mit den Font-Namen auch für manchen Softwarehersteller ein Buch mit mindestens 7 Siegeln. Mein Schul-Aerbeitsblätter-Software-Hersteller benutzt eine PDF-Bibliothek, die die Stichworte Bold oder Regular an einer Stelle, wo Fontlab sebn Copyright-String einträgt. Und für mich ist das dann immer ein Rätselraten, damit es sowohl im Hauptprogramm als auch bei der PDF-Ausgabe richtig funktioniert und nicht nach einem fett geschriebenen Buchstaben der Rest dann fett bleibt.

 

Aber zurüch zu ADFKO und Co.

Ich bin zwar nicht so der Kommandozeilen-Crack, aber immerhin hab ich ja mit MS-DOS-4.1 das noch gelernt, und bin froh, so manchen DOS-Befehl noch zu kennen, der dann auch in der aktuellen Eingabeaufforderung funktioniert, in so fern würde ich da gern auch richtig mit klar kommen - allerdings werde ich wohl kaum die Outlines von Buchstaben per Koordinaten eingeben.

[[Mitglied 3a6c…]]

Ich steuere das AFDKO mit Hilfe von Batch-Scripts. Müsste ich die Befehle direkt in die Kommando-Zeile eingeben, würde ich schnell den Überblick verlieren. Außerdem machen die Batch-Scripts eine Installation überflüssig. Ich muss Python nicht der Umgebungsvariablen hinzufügen. Das wäre bei direkten Befehlen über die Kommandozeile notwendig, um die Befehle kurz zu halten. Sich da einzuarbeiten, ist zugegebenermaßen zeitaufwendig. Aber, um auf die Schnelle ein Beispiel zu nennen, wie man sich die Arbeit mit TTX bezüglich der Namensgebung erleichtern kann:

 

TTX kann Tabellen einzeln dekompilieren, z. B. die name-Table. Um einen Font intern zu benennen, die Style-Links und die Werte für die Gewichte richtig zu setzen, müssen drei bis vier Tabellen dekompiliert werden. Und die Name-Table ist die einzige, aus der man ein Template machen kann. Alle anderen in Bezug auf die Namensgebung und die Style-Links relevanten Tabellen enthalten Informationen über Fonts, die viel spezifischer sind, z. B. die CFF-Table. Die ist als Template insofern untauglich, weil darin auch die Outlines beschrieben werden. Aber in den ersten paar Zeilen der CFF-Table stehen eben auch Family-Name, Font-Name und Full-Name.

 

Für die Style-Links sind drei Werte relevant, nämlich der

 

macStyle value in der head-Table

 

und der

 

fsSelection value

 

und der

 

usWeightClass value

 

in der OS_2-Table.

 

Letzterer ist wichtig, weil Folgendes gilt:

 

Allowed Style Links between weight classes:

 

Even not to equal, do not use:

100-200

 

To greater and equal:
250 to 600-1000
300 to 600-950
350 to 600-900
400 to 600-850
450 to 600-800
500 to 650-750
550 to 600-800

 

To less and equal:
600 to 250-450 and to 550
650 to 250-550
700 to 250-550
750 to 250-550
800 to 250-450 and to 550
850 to 250-400
900 to 250-350
950 to 250-300
1000 to 250

 

-----------------------------------------------

 

Man kann also nicht jedes Gewicht mit jedem verknüpfen. Und ich selbst setze Style-Links bei Font-Familien, die viele Mitglieder haben, nur zwischen aufrechten und kursiven Schnitten gleichen Gewichts. Weil es meiner Meinung nach verwirrend ist, wenn z. B.  bei einer Großfamilie, die die Gewichte Normal, Semibold und Bold enthält, Normal mit Semibold verknüpft sind, denn üblicherweise ist Semibold der Schnitt, mit dem im Fließtext fett ausgezeichnet wird. Der fette Schnitt (Bold) würde also bei einer Verknüpfung von Normal und Semibold im Menu von Office-Programmen wie Word angezeigt werden, der halbfette Schnitt wäre hingegen über den Bold-Button erreichbar und nicht im Menü sichtbar.

 

-----------------------------------------------

 

Tatsächlich sind mir schon viele Fonts namhafter Typedesigner untergekommen, die intern nicht korrekt benannt waren, und zwar weder korrekt nach der alten Adobe-Konvention, noch nach der neuen (die sich eng/enger an der Spezifikation orientiert).

 

Du hast also recht, wenn du von einem Buch mit sieben Siegeln sprichst. Andererseits müssen sich Typedesigner auch noch mit vielen anderen technischen Aspekten ihrer Fonts befassen, die sie ja erfolgreich lösen. Deswegen vermute ich, dass der Grund dafür, dass die Vergabe der internen Namen manchen von ihnen so große Probleme bereitet (oder ihren Kunden), dass sie das Buch mit den sieben Siegeln schlichtweg langweilig finden. Denn es ist eine rein technische Angelegenheit, die viel mehr mit Software-Entwicklung als mit künstlerisch-kreativer Gestaltung zu tun hat.

 

Viele deiner Beiträge zeugen aber von einem großen technischen Verständnis. D. h. der Eindruck, den ich von dir gewonnen habe, ist der eines sehr vielseitigen Menschen, der sowohl Probleme, die sich bei der künstlerisch-kreativen Gestaltung ergeben, als auch Probleme, die eher technischer Natur sind, lösen kann. (Das sind Qualitäten, die dich zu einem guten Vermittler zwischen Grafikern und Programmierern machen. Zwischen diesen beiden Gruppen gibt es recht oft Kommunikationsprobleme.)

[[Mitglied Manu…]]

VIELEN DANK für eure Antworten! WOW

Stimmt – der größte Fehler war wohl das fehlende setzten der Checkbox »bold« und somit der chaotische Family Name.
Das konnte ich nachvollziehen und schon korregieren.

 

vor 12 Stunden schrieb catfonts:

Ich hab das Benennungs-Wirrwarr mal gerichtet, so sollte es klappen. Deinstalliere die Reg auch wieder.

 

HandStampPlayRoughSerif.zip

WOW – Danke
Habs gleich mal getestet. Leider gibt er auch bei dieser Datei noch die Fehlermeldung (siehe Screen).
Leider gibt es in der Mac-Hilfe zur Schriftsammlung auch keine Info was mit der Fehlermeldung genau gemeint ist.

 

 

 

@Arno Enslin

vor 14 Stunden schrieb Arno Enslin:

…

 

3. In der OS/2-Table ist mir der fsSelection-Wert aufgefallen:

 

   <fsSelection value="00000000 01000000"/>

 

Ich kommentierebestimmte Stellen in dekompilierten Fonts mit Hilfe eines Batch-Scripts. Und der Kommentar lautet:

 

<!-- fsSelection value="00000000 00000000"/ for Upright -->
<!-- fsSelection value="00000000 00000001"/ for Italic -->
<!-- fsSelection value="00000000 00100000"/ for Bold -->
<!-- fsSelection value="00000000 00100001" for Bold Italic/ -->
 

Mit anderen Worten: Ich weiß nicht, was die 1 an der Stelle zu suchen hat, an der sie sich in deinem Font befindet. Im Zweifelsfall würde ich sagen: Gar nichts.

 

    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>

 

Das ist der Short-Style-Name für Windows. Also ist nicht beabsichtigt, dass der Font mit dem regulären Schnitt verlinkt werden soll.

 

Deswegen wäre der richtige Wert für fsSelection:

 

<fsSelection value="00000000 00000000"/>

…

wo finde ich den Bereich OS/2-Table mit fsSelection-Wert ?
Ist das in der Font-Info hier:

steht komischerweise bei mir schon alles auf »0«.

 

Ich werde jetzt nochmals alles Schnitt-für-Schnitt nachlesen und auch die Autohints deaktivieren.

Ziel ist die Fehlermeldung zu beheben :D

[[Mitglied 3a6c…]]

In FontLab sind dafür die beiden  Checkboxen Bold und Italic zuständig, u. z. sowohl für den fsSelection-Wert als auch für den macStyle-Wert. Und der Style-Name im Basic set of font names muss damit korrespondieren und kann nur vier Namen annehmen, nämlich Regular, Italic, Bold oder Bold Italic. Eine Font-Familie kann in Office-Programmen wie Word maximal vier Familienmitglieder haben.

 

Es macht Sinn, sich Fonts in Bezug auf die Namensvergabe als Clans vorzustellen. Und die kleinste Familienstruktur, die in der OT-Spezifikation »Subfamily« genannt wird, besteht aus einem bis vier Mitgliedern.

 

Bei deiner aus zwei Mitgliedern bestehenden Font-Familie musst du dich zuerst entscheiden, ob du möchtest, dass beide Mitglieder namentlich in Programmen wie Word (unter Windows) aufgelistet werden, oder ob der fette Schnitt nur über den Bold-Button erreichbar sein soll. Falls sie beide namentlich aufgelistet werden sollen, muss sich der Name für die NameID 1, Platform ID 3 (Microsoft) unterscheiden. Falls nicht, darf er sich nicht unterscheiden.

 

So. Der Softwarehersteller Adobe ist der Spezifikation mit seiner alten, eigenen Konvention zur Namensvergabe absichtlich nicht vollständig gefolgt. D. h. die NameIDs 1 und 2 für die Platform ID 1 (Mac) wurden nach der alten Konvention nicht gemäß der Spezifikation gesetzt. Aber das braucht dich erst mal nicht zu interessieren.

 

Lernen lässt sich das Ganze aber am Besten, wenn man eine der Adobe-Font-Großfamilien wie die Minion dekompiliert und sich die Name-Table anschaut. Soweit ich mich gerade erinnere hat Adobe die Namen ab etwa 2010 (eher 2012, da bin ich mir gerade nicht sicher.) nach einer hauseigenen neuen Konvention gesetzt. Und das spiegelt sich auch im AFDKO wider. Jedenfalls macht es Sinn, die alte Version der Minion und die neue bezüglich der Namen zu vergleichen.

 

Im Wesentlichen halte ich mich an Adobes Konventionen zur Namensvergabe, u. z. derzeit noch an die alte Konvention.

 

Edit: Und der Teil der Spezifikation, der die Namen abhandelt, ist hier zu finden: microsoft.com/typography/otspec/name.htm.

 

Edit 2: Es gibt außerdem bezüglich der Länge von Namen Beschränkungen, die sich aus verschiedenen alten Spezifikationen / Technical Notes ergeben:

 

PDF "Font Naming Issues", Adobe Technical Note #5088, Section 2.2

 

PDF "OTFname_Tutorial", contained in the AFDKO, Adobe Technical Note #5149, Section 1.6.1

PDF "The Compact Font Format Specification", Adobe Technical Note #5176, Section 7

 

Aber fürs Erste reicht es bezüglich der Länge der Namen aus, sich daran zu halten, was Adam Twardoch in seinem Tutorial über die Namensvergabe auf dem FontLab-Forum schreibt.

 

Ärgerlicherweise hat Adam das ursprüngliche Tutorial editiert, anstatt das Update in einem neuen Beitrag zu posten. Deswegen könnte die dem Tutorial folgende Diskussion noch verwirrender sein, als sie ohnehin schon ist. Für Leute, die gerade erst anfangen, die sieben Siegel des Buches zu öffnen, meine ich.

[[Mitglied catf…]]

Ich muss zugeben, dass ich wohl ein wenig nachlässig war, und die Fonts dann nicht noch auf dem Mac getestet hatte. Ärgert mich ein wenig, schließlich hab ich genau dafür Mac und PC nebeneinander auf meinem Schreibtisch. Aber da ich auch schon ähnliche Rätsel hab lösen müssen, werde ich das auch noch mal nachholen.

 

Eines dieser noch immer ungelösten Rätsel, das ich damals noch nicht auf dem Mac selbst untersuchen konnte, war dieses:

 

Letztlich war die einzige Lösung, aus dem Schriftnamen das Wort Nord heraus zu nehmen, ohne sonst etwas am Font zu ändern. Der Name konnte auch gern gleich lang bleiben, und da ganz etwas anderes stehen, nur Namen, die irgendwie Nord enthielten erbrachten das fehlerhafte Ergebnis.

 

Daher vermute ich mal, dass es auch bei dir irgendetwas mit dem Namen selbst zu tun hat, und irgendwie weiß niemand so genau, wie auf dem Mac diese Namen interpretiert werden, jedenfalls wohl mehr, als nur irgendein Text der Menschen sagt, wie diese Schrift heißt, damit man sie in seiner Schriftensammlung findet.

 

Versuch doch mal, die Schrift "RoughStampSerif" zu nennen, oder PlaystampSerif? Dein Name ist jedenfalöls schon zu lang für das Schriften-Auswahlfeld mancher Programme, besonders wenn der dann auch noch in deiner ja einigermaßen breit laufenden Schrift angezeigt wird. 

 

Soll es davon übrigens auch eine Sans geben? Sonst würde ich auch auf das Serif im Namen verzichten.

[[Mitglied catf…]]

vor 12 Stunden schrieb Arno Enslin:

Ich steuere das AFDKO mit Hilfe von Batch-Scripts. ...

Danke, diesem Beitrag würde ich am liebsten gleich 5 mal mit Gefällt mir markieren

 

Da muss ich mich wohl doch mal sehr über die Siegel her machen, und ja, Du hast recht, diese nerdige Programmiererei ist so ganz nicht meine Welt, obwohl ich da eben auch nicht so unbeleckt bin, wo mein digitales Leben eben mit Basic und Fortran begann und zig MS-DOS-Batch-Dateien um so manches DOS-Programm überhaupt mit all seinen nötigen Startoptionen zum Laufen zu bringen.

 

Zumindest gibt es ja auch spannende Aspekte, die manchmal zu einem Detektiv-Spiel ausarten.

[[Mitglied Manu…]]

vor 5 Stunden schrieb Arno Enslin:

…

Edit 2: Es gibt außerdem bezüglich der Länge von Namen Beschränkungen, die sich aus verschiedenen alten Spezifikationen / Technical Notes ergeben:

 

PDF "Font Naming Issues", Adobe Technical Note #5088, Section 2.2

 

PDF "OTFname_Tutorial", contained in the AFDKO, Adobe Technical Note #5149, Section 1.6.1

PDF "The Compact Font Format Specification", Adobe Technical Note #5176, Section 7

 

Aber fürs Erste reicht es bezüglich der Länge der Namen aus, sich daran zu halten, was Adam Twardoch in seinem Tutorial über die Namensvergabe auf dem FontLab-Forum schreibt.

also kleiner als 30 zeichen, richtig? Komplett mit Style Name?

Dazu habe ich noch was gefunden aus »Learn FontLab Fast«:

 

 

@catfonts

 

vor 2 Stunden schrieb catfonts:

 

 

Letztlich war die einzige Lösung, aus dem Schriftnamen das Wort Nord heraus zu nehmen, ohne sonst etwas am Font zu ändern. Der Name konnte auch gern gleich lang bleiben, und da ganz etwas anderes stehen, nur Namen, die irgendwie Nord enthielten erbrachten das fehlerhafte Ergebnis.

 

hmmm … regular.otf + regular.ttf + bold.ttf funktionieren ohne Fehlermeldung
Verzwickt. Ich teste mal weiter :D

[[Mitglied catf…]]

Schon mal folgenden Test gemacht: Bei den OTF-Schriften erst einmal alles vom Rechner gelöscht, und dann die fette zuerst versucht zu installieren?  Möglicherweise meckert der ja dann beim Versuch die normale zu installieren? Dann kommt es möglicherweise bei den Postscript-OTF-Fonts intern zu einer Kürzung des Font-Namens, und beide beanspruchen dann den selben Platz in der Schriftensammlung, werden aber trotzdem als unterschiedlich erkannt.

[[Mitglied 3a6c…]]

vor 3 Stunden schrieb Manuel V.:

also kleiner als 30 zeichen, richtig? Komplett mit Style Name?

Der PS-Font-Name darf maximal 29 Zeichen enthalten. Bei PostScript-flavored OpenType-Fonts muss der Full Name für die PlatformID 3 (Microsoft) in der Name-Table außerdem dem PS Font Name entsprechen.

 

Der Family Name (nameID1, platformID 3) darf maximal 30 Zeichen enthalten.

 

Alle anderen Namen in der Name-Table dürfen, soweit ich ermitteln konnte, 63 Zeichen enthalten.

 

Vor allem aber darf im Feld »Style Name« nicht Light Italic stehen, denn da sind, wie gesagt, nur vier Namen erlaubt, nämlich Regular, Italic, Bold und Bold Italic.

 

Aber wie catfonts schon ganz richtig sagte: Die Namen sollten aus Gründen der besseren Übersicht in den Menüs kurz gehalten werden.

[[Mitglied catf…]]

So, ich habe an der Schrift heute mal Detektivarbeit getrieben. Das Endergebnis:

Aber jetzt im Einzelnen:

Erste Idee: Mit dem Namen stimmt was nicht, daher Namen drastisch gekürzt auf RoughStamp - Jetzt meckert der Mac an beiden Fonts!

 

Zweite Idee: Jetzut öffne die Dinger doch mal mit Fontforge. - das schien eine blendende Idee zu sein, denn hier gibt es unter dem Menüpunkt "Element" den Menüpunkt Validation. Zuerst stürzte mir das Programm gleich beim Auftrag den Font zu validieren ab.

 

Also zurück mach Fontlab, und hier mittels Tools - Action - CleenUp die Konturen vereinfacht. dann noch mal in FontForge geöffnet und erneut Element - Validate. Jetzt ballerte mich Fontforge von Fehlermeldungen nur so voll.

Also bin ich eines der Probleme nach dem anderen angegangen. Offensichtlich hatte dein Autotracer da so einiges an Mist angestellt, mir sich überlappenden Konturen, offenen Vektoren, selbst überlappenden Konturen usw.

 

Also immer wieder den Font generiert, und dann versucht, das auf dem Mac zu installieren - immer wuieder mit der gleichen Fehlermeldung: Schwerwiegender Fehler.

 

Je mehr Fehler ich beseitigte, um so mehr entdeckte dann FontForge mit seiner Validierung. Offensichtlich hatte das allein schon bei den offenen Konturen die jewilige Glyphe abgehakt. ZTuletzt meldete Fontforge "too many hints" und  "overlapping hints" bei etlichen Glyphen. Also sagte ich mir: So ein Font mit diesen fusseligen Stempelabdrucken ist ohnehin kein Bildschirmfont, also mit FintForge die Hints komplett gelöscht, und alle Autohint-Funktionen abgestellt. Das brachte dann das Ergebnis, dass ich die Fonts auf dem Mac installiert bekommen habe.

 

Hier jetzt meine Endversionen:  RoughStamp.zip

 

 

 

[[Mitglied 3a6c…]]

vor 26 Minuten schrieb catfonts:

also mit FintForge die Hints komplett gelöscht, und alle Autohint-Funktionen abgestellt.

Das mit den Hints schrieb ich am Anfang. Die eigentlichen Glyphen dürften ruhig gehintet sein. Aber nicht jedes kleine Stempelfleckchen. Und mit sich überlappenden Hints ist das schon bei Fonts mit sauberen Outlines so eine Sache. Die führen nicht immer zu einer besseren Darstellung. Wenn ich Fonts mit Autohint.py (im AFDKO enthalten) hinte, dann mache ich immer zwei Versionen, nämlich eine mit einfachen, sich nicht überlappenden Hints (Option -ns [no subsititution]), und eine mit Hint Substitution. Und dann teste ich jeden einzelnen Schnitt und nehme jeweils die Version, die am Besten auf dem Bildschirm aussieht. Manchmal setze ich auch nur die Standard Stems, also die horizontalen und vertikalen Strich-Breitenwerte ohne individuelle Hints.

[[Mitglied catf…]]

Sicher dürften die Hauptglyphen gehintet sein, nur macht sich das eben nicht so einfach über eine Autohint-Funktion, die zumeist wohl nicht weiß, wo sie anfangen soll, und wo nicht. Möglicherweise gint esc da ja eine Einstellung, wie klein die Fitzelchen sein dürfen, um sinnvoll gehintet zu werden. Also muss man sich hier, will man nur den sinnvollen Teil gehintet haben muss man sich wohl auch noch in VTT* einarbeiten. Und leider muss ich sagen, diese Software hängt für mich schon wieder voller Siegel

 

*) https://www.microsoft.com/en-us/Typography/vtt.aspx

 

Aber möglicherweise wäre diese Software hier auch nützlich gewesen, obwohl so ein Streusel-Font sicher auch hier problematisch ist.

 

 

[[Mitglied 3a6c…]]

vor 54 Minuten schrieb catfonts:

Und leider muss ich sagen, diese Software hängt für mich schon wieder voller Siegel

Für mich auch. Mit TrueType-Hinting habe ich mich noch gar nicht beschäftigt.

 

In Bezug auf die Hints der Stempelfleckchen: Die hätte ich  manuell gelöscht. Oder ich hätte den Font manuell gehintet. Wobei das länger gedauert hätte. Jedenfalls gibt es da ein wirklich gutes Tutorial über Type-1-Hinting von David Lemon.

 

Und Adam Twardoch hat auch ein Tutorial über Hinting geschrieben. Das habe ich aber noch nicht gelesen.

[[Mitglied catf…]]

vor 3 Minuten schrieb Arno Enslin:

In Bezug auf die Hints der Stempelfleckchen: Die hätte ich  manuell gelöscht.

Oh, wenn die Stempelflecken aus hunderten Fitzelchen bestehen? Sicher über dein AFD-KO - Äh - Wundertool?

 

(warum muss ich da blos an so ne Partei denken, bei der ein führendes Mitglied auch noch Gau-Land heißt? - (und da muss ich dann irgendwie an einen Gau-Leiter denken, warum nur))

[[Mitglied 3a6c…]]

Einen Befehl zum Ausknocken der AFD hat das AFDKO leider nicht.

 

Ich glaub, ich würde die Glyphen in FontLab in die Maske kopieren. Dann zwischen Maske und Outline wechseln. Und dann aus FontLab heraus mit dem FontLab-Autohint-Python-Script hinten. Das greift ebenfalls auf das im AFDKO enthaltene Autohint-Programm zurück.

 

Edit:

 

Die FontLab-Scripts, die auf das AFDKO zugreifen, sind übrigens ausgelagert und hier zu finden.

 

Da habe ich übrigens trotz fehlender Python-Kenntnisse etwas dran herumgebastelt. Und zwar, nachdem ich die Entwickler erfolgreich darum angefleht habe, sie wieder funktionsfähig zu machen. Sie funktionierten nämlich lange Zeit nicht mehr wegen Änderungen am AFDKO. Und das war niemandem sonst aufgefallen, obwohl gerade das Autohinting-Script extrem nützlich ist.

[[Mitglied catf…]]

Aber dann schau dir die Glyphen mal genau an, und erkläre mir, was du an diesen bewusst krumpeligen Konturen überhaupt sinnvoll hinten möchtest, und wo das dann überhaupt etwas verbessert, oder möglicherweise eher verschlimmbessert?

[[Mitglied 3a6c…]]

Ohne es ausprobiert zu haben, kann ich nicht sagen, ob sich mit Hints eine Verbesserung erzielen ließe. Aber es geht ja beim Hinting auch nicht nur um die Kontrolle der Strichbreiten, sondern auch um die vertikale Ausrichtung. Ich vermute, da ließe sich schon was machen. Allerdings ist das eh kein Font für kleine Schriftgrade. Und kein Hinting ist besser als schlechtes Hinting. Mir wäre es die Mühe nicht wert, daran herumzufrickeln.

 

Übrigens sind in dem fetten Schnitt gar keine Standard Stems angegeben. Insofern macht das mit den Hints eh keinen Sinn. Höchstens in Bezug auf die vertikale Ausrichtung. Wobei ich noch nie ausprobiert habe, ob die Ausrichtung funktioniert, wenn keine Standard Stems angegeben sind.

[[Mitglied catf…]]

Und so wie ich die Idee hinter diesem Font sehe, ist auch die vertikale Ausrichtung ziemlich wurscht (wie bei meinem Erikas Farbband dem ja eine entfernt ähnliche Idee (Wackeliges Schriftbild aus angefressenen, manchmal nur noch aus vielen Einzelfitzelchen bestehenden Buchstaben, die auf der Schreiblinie auch etwas hüpfen). Daher wär hier ein nachbessern der vertikalen Ausrichtung wohl ein Kampf gegen den Geist dieser Schrift, die ja eben auch das unegale einer mit Spiel-Stempeln gestempelten Schrift imitieren soll.

 

Allerdings würde ich mir denken, dass dieser Schrift etwas ganz anders gut täte: Mehr Glyphen für die Buchstaben, die dann wie bei meiner "Erikas Farbband" einen Ringelreihen vollführen damit nicht immer der gleicher Buchstabe angenagt, schief oder oder zu tief durchgedrückt, sodass das Fleisch mit druckt ist. Dann wäre dieser Handgestempelt-Effekt noch einmal sehr gesteigert.

 

Wahrscheinlich hat das wirklich tolle TTFautohint genau für Fonts dieser Art ja auch die Funktion Dehint? ( https://www.freetype.org/ttfautohint/  )

[[Mitglied Manu…]]

@catfonts deine Datei funktioniert 1A – DANKE

@Arno Enslin bin gerade dabei mir alle links nach und nach anzuschauen, DANKE

Die Lösung war einerseits der Name bzw. die setzen auf »bold« und das Hinting (Danke Arno).
Dann funktioniert sogar der lange Name ;)

[[Mitglied 3a6c…]]

vor 42 Minuten schrieb Manuel V.:

Dann funktioniert sogar der lange Name

Ich weiß jetzt nicht, auf welchen internen Namen du dich beziehst, aber ein automatischer Check durch eine Software wie die Schriftensammlung garantiert nicht, dass der Font in allen gängigen Anwendungen und unter allen gängigen Betriebssystemen funktioniert. D. h. du solltest auch dann die Maximallängen der internen Namen nicht überschreiten, wenn die Schriftensammlung nichts zu beanstanden hat.

 

Z. B. ist der usWeightClass value nicht bei allen Anwendungen gleichermaßen problematisch. Und Ähnliches gilt auch für die internen Namen. Wenn du keine Möglichkeit hast, Fonts unter verschiedenen Betriebssystemen und Programmen zu testen, dann halt dich am Besten an die Spezifikationen bzw. an die Adobe-Konventionen.