Ich habe ein seltsames Problem:

 

Ich habe für ein Programm zur Erstellung von Schul-Arbeitsblättern einige Schriftarten angefertigt, darunter auch Druckschrift und hier habe ich ein seltsames Problem. Der Satz für eine Familie besteht hier immer aus 2 Schritten, der normalen (Regular) und einer fetten Schrift (Bold).

 

Unter Windows, im Zielprogramm und in dem leider etwas hakeligen und nicht wirklich perfekten PDF-Export, der abere zumindestennd einige OpenType-Funktionen unterstützt, funktioniert alles wie gewünscht. Egal ob die Fonts jetzt lokal ins Font-Verzeichnis der Anwendung kopiert sind, oder ob sie regulär im System installiert wurden. Ebenso funktioniert die schriftart auch richtig, ist sie in Windows installiert in anderen Anwendungen.

 

Anders auf dem Mac, hier steht in der Schriftensammlung der schon richtig als Familie aufgenommenen Fonts mit einmal die Bold-Variante VOR der normalen, und weist man einem Text in irgend einem Textprogramm die Schriftart zu, wechselt der Text automatisch in die fette Schrift, ein abschalten der Fett-Auszeichnung ist dann nicht möglich. Leider besitze ich selbst keinen Mac, das Problem tritt auf dem Rechner meines Kunden auf. und zwar auch auf einem 2. Macbook, auf dem die Schrift zuvor noch nie installiert war.

 

Ich habe in Fontlab alle Einträge mit denen einer anderen, normal funktionierenden Schriftart verglichen, und ich konnte hier keine Abweichung finden. Ich frage mich jetzt, woran kann das liegen?

Nur, weil ich auch oft den Wald vor Bäumen nicht sehe …

 

Antialiasing-Probleme (der normale Schnitt wird verwendet, sieht aber fett aus) konntest du ausschließen?

Ja,

 

1. springt die Auszeichnung auf Fett, lässt sich nach Aussage meines Kunden aber nicht auf normal setzen,

 

2 ist die Fette um hinter den Fehler zu kommen, mit markierten Glyphen ausgestasttet, um eine künstliche Fettung durch die Software erkennen zu können.

 

3. in der Schriftensammlung steht,  anders als bei allen anderen Schriften, auch den anderen von mir, die Fette vor der Normalen.

 

4. deinstalliert man die Fette, wird auch brav die normale verwendet. Auf die Fette zu verzichten,  und das dann künstlich machen zu lassen ist keine Option, weil der PDF-Export dass dann "Sonne Farbe (china)" aussehen läss, da das da drin durch doppelt setzten der Schrift mit leichtem Seitenversatz geschieht,

Kannst mir die Schrift ja mal schicken und ich prüfe sie am Mac. 

Stille-Post-Fehlermeldungen sind ja immer recht schwierig. 

Danke, ich habe die Fonts auf meinen Server gepackt, Link hast Du als PN. Wer sonst noch ne Idee hat, bekommt den Link natürlich auch, da stgeht auch mein Auftraggeber dahinter, nur ganz öffentlich möchte ich die Schrift eben nicht stellen

Probieren schadet nicht, kannst du mir gern ebenfalls schicken.

Aber klar, Link ist als PN unterwegs.

Spooky … unter welchem OS X hast du das probiert? Bei mir (10.10.3) stellt es sich leider genauso dar wie bei dir, ohne dass ich wüsste, woran das liegen mag.

 

Mir ist aber noch etwas aufgefallen:

Ich aktiviere nur den Regular-Schnitt in FEX. Wenn ich in TextEdit etwas schreibe und deine Schrift zuweise, wird sie logischerweise als Regular dargestellt und benannt. Wenn ich jetzt aber den Text markiere und eine andere Schrift auswähle (z.B. Helvetiva, Times), springt der jeweilige Schnitt ebenfalls auf fett!

 

Kann es sein, dass OS X hier der Übeltäter ist und das gar nichts mit deinem Font zu tun hat?

 

Edit: Irgendwas wird es doch (auch?) mit deinem Font zu tun haben, weil TextEdit immer dann auf "Fett" springt, wenn man von deinem Regular-Font in einen anderen wechselt. Aus einem anderen Regular-Font kommend bleibt auch der neue bei Regular.

Welches OS-X mein Auftraggeber hat, weiß ich leider nicht, ich selbst habe nur Windoof (ach so, kein Wort gegen Kleinweich) - Windows. Und da funktioniert es, dank des unbestritten hohwertigeren Betriebssystems eben prima.

Ich hab’s jetzt mal in Windows 7 ausprobiert, da funktioniert der Font aber auch nicht!

 

Im "Editor" einen Text geschrieben, deinen Regular-Schnitt zugewiesen (es werden alle 4 Optionen Standard, Fett, Schräg und Fett Schräg angezeigt) und danach nochmal auf "Schriftart" gegangen, schon wird nur noch "Fett" als einziger Schnitt angezeigt – obwohl der Text in "Regular" dargestellt wird. Liegt also leider doch irgendwo an deinem Font. Screenshots schick ich dir …

Markwürdich! Bei mitr unter Win7 funktioniert sie???

 

OK, eine große Bitte an die Apple-Tester:

 

Ich habe die Glyphen, auch die OpenType-Funktionen und Klassen in einen komplett neuen Font herüber kopiert, und alle Einstellungen entsprechend eines Fonts gemacht, der sauber funktioniert.

 

Dieses neue Font-Duo steht auf der gleichen URL, nur eben .../Norddruck2.zip - es wäre sehr lieb, die beiden auch noch mal auf dem Apple zu testen, ob das auch hier wieder Unfug macht.

 

Ein kleiner Hinweis zu der Schrift: als Besonderheit ist eine recht einfache Umsetzung typografischer Anführungsstriche mit drin, also " vor Buchstaben ergibt „ und nach Buchstaben “. Das ist zwar nicht 100% sicher, funktioniert aber für die Anwendung hinreichend gut, auch mit einfachen Anführungszeichen, wobei das ' zwischen Buchstaben zum Apostroph wird. #schoolcraft und #wsc zeigen die Logos

Mysteriös! Sag Bescheid, solltest du an einem Test mit einem Linux-System interessiert sein.

Ich kann’s mit momentan noch nicht erklären, aber Apple mag den Namen der Schrift irgendwie nicht. Solange da das »NxxxDxxxx« drin ist, tritt das besagte Problem auf. Nenne ich den Familie »Hausschrift« oder irgendwie anders verschwindet es.

 

Reagiert Apple da auf irgendein Keyword?

Hmm, muss ixch testen,

 

Dagegen spricht allerdings, dass ich noch ne Schreibschrift hab, die "WsC SwissBasis1.ttf" heißt, also auch diesen CamelCase-Namen hat und in Sachen OpenType-Funktionen noch derber ausgestattet ist, und die zickt nicht rum.

Ich meinte nicht die CamelCase-Schreibweise und auch nicht den Präfix, sondern das konkrete Wort. Hab sogar versucht die Wortteile rumzudrehen – das Problem bestand weiter. 

Wir haben auch grad vieles herumprobiert, das Problem scheint am Wortteil "Nord" zu liegen, als wenn Apple da im String nach "Nor" fahndet, und das dann als "Normal" wertet. Ich werde dann wohl nie wieder einen Fontnamen mit "Nord" bauen.

 

Wir haben sie dann eben nur WsC Druckschrift / WsC Fibelschrift genannt, und das klappt, wenn dann die Süd-Variante noch gebraucht wird, müssen wir uns was einfallen lassen.

 

Erst mal allen einen ganz großen Dank, hinter dieses Geheimnis zu kommen. (jetzt steht n älterer Mac, nur für solche Tests auf meuiner "Irgendwann mal besorgen" Liste.)

als wenn Apple da im String nach "Nor" fahndet, und das dann als "Normal" wertet.

 

Jawoll, das wird es sein. Mir fiel kein entsprechendes Wort ein – aber ich bin in Srabble auch eine Niete. 

Dann müssten aber Schriften wie "Isonorm" oder "Antique Olive Nord" auch Probleme bereiten – tun sie aber nicht … 

Ich hab mal die großen Fontanbieter Frei/Kommerziell nach Nord durchsucht, das ist wirklich nicht viel. Was mich jetzt interessieren würde, wie ist es mit Elsner+Flakes TF Nord EF bei Bold und Regular. Ich kann mir jedenfalls vorstellen, dass diese NDR-Hausschrift, die ja eine Überarbeitung der NDR Sans ist, und die ja zudem noch gut ausgebaut ist, auch auf Macs laufen muss.

Dann müssten aber Schriften wie "Isonorm" oder "Antique Olive Nord" auch Probleme bereiten – tun sie aber nicht … 

 

Fontnamen sind eine hochkomplexe Sache. Da spielen über ein Dutzend Felder zusammen. Ich würde nicht behaupten wollen, dass kein Font jemals »Nord« enthalten darf, aber im konkreten Fall scheint es der Auslöser zu sein. Die Chance stehen sicher nicht schlecht, dass man einen Workaround bei Beibehaltung des alten Namen finden kann – wenn man Zeit und Nerven hat, alle Möglichkeiten durchzutesten. 

bei MyFonts herunterladen

Fontnamen sind eine hochkomplexe Sache. Da spielen über ein Dutzend Felder zusammen. Ich würde nicht behaupten wollen, dass kein Font jemals »Nord« enthalten darf, aber im konkreten Fall scheint es der Auslöser zu sein. Die Chance stehen sicher nicht schlecht, dass man einen Workaround bei Beibehaltung des alten Namen finden kann – wenn man Zeit und Nerven hat, alle Möglichkeiten durchzutesten. 

Ja, das befürchte ich auch. Müsste catfonts die Schrift mal unter einem komplett anderen Namen rauslassen …

Müsste catfonts die Schrift mal unter einem komplett anderen Namen rauslassen …

 

Ich hab das hier ja lang und breit getestet (also Export aus FontLab in verschiedensten Varianten) und nur dadurch konnte ich ja herausfinden, dass der Fontfamilienname den Fehler auslöst oder zumindest Teil des Problems ist. Könnt ihr mir schon glauben. 

Das glaub ich dir, sicherlich. War auch an catfonts als Hinweis gedacht, dass ich dann gern noch mal mit einem anderen Familiennamen teste.

Nun, wenn das mit der Nordvermeidung klappt, und mein Auftraggeber da mitzieht, bin ich ja zufrieden, da mache ich mir dann nicht mehr den Ärger, da mühevoll nach einem Nord-Workaround suchen, obwohl mich das mit der E+F-Schrift schon interessieren würde... Aber gut, man kann nicht alles haben.

 

Ich werde morgen mich an die Umbenennung machen, die pack ich dann auch in die schon genannte Zip-Datei, wenn man mir die noch mal unabhängig testet, wär das schon, ich sag dann hier bescheid, wenns hochgeladen ist. Für heute wünsch ich ne gute Nacht.