Spezielle Probleme mit der Schriftart Hussar Milosc

[ww_wupp]

Hallo in die Runde,

nach längerer Zeit melde ich mich mit sehr speziellen Problemen, die ich auf einem älteren Windows Betriebssystem mit der Schriftart Hussar Milosc habe.

Vor einigen Wochen habe ich auf myfont.de nach Schriftarten gesucht für ein kleineres eigenes Projekt und mich dann für Hussar Milosc entschieden.

Im Release-Ordner sind die SIL OFL Lizenz und 2 otf-Dateien. Leider sind beide als kursiv programmiert, sodass ich nur eine der beiden Dateien installieren konnte. Ich layoute meine Sachen immer wieder in einem älteren Word und exportiere von dort mit dopdf in einer 11-12 Jahre alten Version. Dabei bekam ich das Problem, dass die komplette Schriftart in der pdf-Ausgabe decodiert war, d.h. anstelle von blank bekam ich exclamation mark, anstelle von zero (0) die one (eins) etc. etc..

Gestern habe ich mal versuchsweise eine Korrektur angewendet, deren Ergebnis das Decodieren beendet hat: Die Schriftart hat recht viele Mapping Ebenen, und beim blank war mir aufgefallen, dass einige dieser Ebenen ohne Code sind. Ich habe also teilweise den Code dort in meinem FontCreator nachgetragen,

[Ralf Herrmann]

Da fehlt wohl ein Stück vom Text. 

[ww_wupp]

vor 19 Minuten schrieb Ralf Herrmann:

Da fehlt wohl ein Stück vom Text. 

Ja, das stimmt, der komplette Text sollte lauten:

Hallo in die Runde,

nach längerer Zeit melde ich mich mit sehr speziellen Problemen, die ich auf einem älteren Windows Betriebssystem mit der Schriftart Hussar Milosc habe.

Vor einigen Wochen habe ich auf myfont.de nach Schriftarten gesucht für ein kleineres eigenes Projekt und mich dann für Hussar Milosc entschieden.

Im Release-Ordner sind die SIL OFL Lizenz und 2 otf-Dateien. Leider sind beide als kursiv programmiert, sodass ich nur eine der beiden Dateien installieren konnte. Ich layoute meine Sachen immer wieder in einem älteren Word und exportiere von dort mit dopdf in einer 11-12 Jahre alten Version. Dabei bekam ich das Problem, dass die komplette Schriftart in der pdf-Ausgabe decodiert war, d.h. anstelle von blank bekam ich exclamation mark, anstelle von zero (0) die one (eins) etc. etc..

Gestern habe ich mal versuchsweise eine Korrektur angewendet, deren Ergebnis das Decodieren beendet hat: Die Schriftart hat recht viele Mapping Ebenen, und beim blank war mir aufgefallen, dass einige dieser Ebenen ohne Code sind. Ich habe also teilweise den Code dort in meinem FontCreator nachgetragen, erstmal nur unter neuem Dateiversionsnamen für mich abgespeichert, anstelle der Originalversion installiert, und die Fehlcodierung war beendet. Ich habe zwar inzwischen eine nicht ganz aktuelle Version von Fontlab, habe aber derzeit nicht die Zeit und Kraft, mich darin einzuarbeiten. Und unter Linux habe ich auch fontforge zur Verfügung, aber auch keine Zeit und Kraft, mich damit zeitnah anzufreunden.

Da ich auf dem blank gern auch das nobreakspace habe, habe ich (weiter in FontCreator) auch versucht, das auch noch dort einzucodieren, das ging aber nicht: Ich bekam auf der Mapping Ebene Macintosh Roman die Mitteilung, dass der Code $00A0 für nobreakspace bereits vergeben wäre. Ich hab mir das angegebene Glyphenfeld angeschaut, und es ist der dagger. Also habe ich mir dort den Code auf der Mapping Ebene Macintosh Roman angeschaut: Dort ist der Code $00A0 zwar tatsächlich vergeben, aber für dagger.

Bevor ich die Bestandsaufnahme abschließe und zu meinen eigentlichen Fragen übergehe, vielleicht noch der Hinweis, dass der Copyright-Verweis in der otf-Datei insofern fehlerhaft ist, als dort steht "all rights reserved", und dazu hat mich SIL OFL Community bereits vor Jahren bezüglich meiner eigenen Schriftarten darüber informiert, dass diese Worte nicht mit der SIL OFL vereinbar sind und weg sollen.

Nun meine Fragen:

Laut SIL OFL Bedingungen wäre ich verpflichtet, jede Änderung mit einem neuen Schriftartnamen zu speichern. Das kommt mir aber bei dieser geringen Korrektur (derzeit: fehlende Codes auf dem blank ergänzt, und sonst nichts) für meine sehr speziellen Bedürfnisse und Bedingungen irgendwie übertrieben vor. Ich weiß im Moment auch noch nicht, welches Maß von Verbreitung mein gegenständliches Projekt (ein selbst geschriebener und grafisch gestalteter Text) letztendlich haben wird... Sollte ich die veränderte Schriftart unter neuem Schriftarnamen veröffentlichen müssen, müsste ich den Umfang sowohl der Glyphenzahl als auch die Zahl der Mapping Ebenen erheblich verringern, zumal ich z.B. im Chinesischen überhaupt nicht wüsste, was da anstelle des jetzt dort für kursiv stehenden Wortes hin müsste etc. etc.. Bitte um Ideen und Vorschläge hierzu.

Ich wäre darüber hinaus dankbar für Hinweise, wie ich den beschriebenen unterschiedlichen Gebrauch des Codes für nobreakspace verstehen kann und ob ich da im FontCreator doch noch was machen könnte/sollte.

Ich hoffe auf Rückmeldungen.

VG ww_wupp

[Diwarnai]

Grad mal nachgestellt und den "Windows Font" runtergeladen (zip). Darin sind 

– HussarMilosc.otf

– HussarMiloscObl.otf

– SIL Open Font License.txt

 

Augenscheinlich eine aufrechte und eine kursive Version der Schrift. 

Die beiden otf lassen sich fehlerfrei in FEX importieren und aktivieren:

Auch hier die eine aufrecht, die andere kursiv.

 

Im aktuellen Word angewendet …

… und als pdf ausgegeben, völlig fehlerfrei.

 

vor 39 Minuten schrieb ww_wupp:

… auf einem älteren Windows Betriebssystem … Ich layoute meine Sachen immer wieder in einem älteren Word und exportiere von dort mit dopdf in einer 11-12 Jahre alten Version. …

Das ist die wahrscheinlichste Fehlerursache.

[ww_wupp]

vor 5 Minuten schrieb Diwarnai:

Das ist die wahrscheinlichste Fehlerursache.

Diese Aussage kann ich durchaus verstehen - vielen Dank hierfür! -, teile sie aber nicht:

Unter diesen Umständen funktionieren bei mir die meisten anderen Schriftarten, nur mit Tudor Rose hatte ich vor etlichen Jahren mal ein ähnliches Problem.

Es ist tatsächlich so, dass in der nicht-kursiven otf-Datei in den Eigenschaften überall kursiv steht, soweit ich die Sprachen kenne. Und obwohl ich die nicht-kursive otf-Datei in Windows/fonts installiert habe, wird mir die Schriftart dort nur als kursiv angezeigt.

Somit hoffe ich weiter auf Antworten zu meinen am Ende meines Themas genannten Fragen.

Vielen Dank und VG ww_wupp

[ww_wupp]

Ich habe mir die beiden Dateien soeben noch in fontforge angeschaut, da kann ich die Einträge für kursiv in beiden Dateien nicht in der Form finden, wie in FontCreator. In fontforge wird mir vielmehr die kursive Version als "oblique" angezeigt. Aber ich habe mit fontforge fast keine Erfahrung, sodass ich da keine abschließende Aussage treffen kann. Es ist mir aber auch in Linux nicht möglich, beide Dateien zu installieren, und die nicht kursive Version wird mir als "fett" angezeigt.

[Ralf Herrmann]

Im Zweifel gib den Schriften unterschiedliche Familiennamen. Das wäre die einfachste Lösung. Eine perfekt stilverlinkte Familie ist eine komplexe Sache. Da muss man in unzähligen Feldern exakt die richtigen Dinge einstellen. 

Zu den Kodierungsfragen kann ich nicht viel sagen. Da müsste man man erstmal die Problemstelle eingrenzen. Ist der benutzte Workflow mit den alten Programmen denn überhaupt komplett Unicode-basiert? Es klingt fast so, als wäre das nicht der Fall und dies führt dann zu den fehlerhaften Zeichen. In diesem Fall wäre wirklich die Änderung des Workflows anzuraten, nicht die Änderung der Fonts.  

[Ralf Herrmann]

Du musst abgeänderte OFL-Schriften übrigens nicht veröffentlichen, nur weil sie abgeändert wurden. Nur wenn sie veröffentlicht werden, dann muss man sich an die Regeln der Lizenz halten. 

[ww_wupp]

@RalfHerrmann: Danke für Deine drei  Antworten.

vor einer Stunde schrieb Ralf Herrmann:

Im Zweifel gib den Schriften unterschiedliche Familiennamen. Das wäre die einfachste Lösung.

Leider wäre das für mich im Font Creator garnicht einfach, aufgrund der vielen mir nicht verfügbaren Sprachen in dieser Schriftart. Ich müsste dann trotzdem alle mir nicht greifbaren Bereiche löschen.

vor einer Stunde schrieb Ralf Herrmann:

Eine perfekt stilverlinkte Familie ist eine komplexe Sache. Da muss man in unzähligen Feldern exakt die richtigen Dinge einstellen. 

Es geht mir ja für mein kleines Projekt nicht um eine perfekt stilverlinkte Familie, ich habe kein Kursiv und Fett drin. Ich möchte nur keine Rechtsfehler riskieren, sollte mein Projekt doch noch bei einem Verlag als kleines Buch erscheinen.

vor einer Stunde schrieb Ralf Herrmann:

Zu den Kodierungsfragen kann ich nicht viel sagen. Da müsste man man erstmal die Problemstelle eingrenzen.

Wenn möglich, würde ich dazu ja gern beitragen.

Ich weiß von meiner jahrelangen Arbeit mit dem FontCreator, dass 2 der 3 von mir stets verwendeten Mapping Ebenen identische Codes haben, während die Codes bei der 3. Mapping Ebene ab einer gewissen Stelle enorm differieren und dann ab einer bestimmten Stelle der Glyphenfeld-Nummern nicht mehr möglich sind. Das gilt allerdings nur für "normale" Schriftarten, für Symbolschriftarten nicht, da zeigt mir FontCreator Codes an, die nicht den Unicodes entsprechen.

vor einer Stunde schrieb Ralf Herrmann:

Ist der benutzte Workflow mit den alten Programmen denn überhaupt komplett Unicode-basiert? Es klingt fast so, als wäre das nicht der Fall und dies führt dann zu den fehlerhaften Zeichen. In diesem Fall wäre wirklich die Änderung des Workflows anzuraten, nicht die Änderung der Fonts.

Da Hussar Milosc keine Symbolschriftart ist, bin ich sehr sicher, dass das alte Word mir z.B. bei "einfügen->Sonderzeichen" die Unicodes anzeigt, wie auch die "Zeichentabelle" des entsprechenden alten Windows. Beim dopdf vermute ich mal, dass einer oder mehrere der in der Original-Schriftarten-Datei fehlenden Codes für das Blank zu einer Verrutschung beim Importieren der Schriftart geführt hat. Nach meinen Ergänzungen an dieser Stelle scheint DAS Problem ja behoben zu sein, ich habs allerdings bisher nur mit einer kleinen Probedatei ausprobiert, nicht z.B. mit meinem bisherigen Gesamttext.

vor 1 Stunde schrieb Ralf Herrmann:

In diesem Fall wäre wirklich die Änderung des Workflows anzuraten, nicht die Änderung der Fonts.  

Ich gehe davon aus, dass Du damit meinst, ich sollte mich vom alten Windows, vom alten Word, vom alten FontCreator und vom alten Photoshop Elements (in dem es dann irgendwann weitergeht) verabschieden und stattdessen entweder ein aktuelles Windows oder ein aktuelles Linux-Betriebssystem mit dazu passenden Programmen sowie entweder FontLab oder FontForge verwenden. Das wäre für mich extrem viel zeitlicher Aufwand, der bedeuten würde, dass ich das kleine Projekt ganz aufgeben müsste, weil familiär und gesundheitlich einfach nur recht wenig Zeit bei mir für sowas bleibt. Klar, ich kann auch in LibreOffice Writer oder in OpenOffice Writer layouten, aber da gibts halt einige für mich recht nervige Features, die sich bei jedem Update mitunter neu einstellen etc. etc.. Und mein ja absolut aktuelles Linux erlaubt ja z.B. auch nur die Installation einer der beiden otf-Dateien von Hussar Milosc...

vor 1 Stunde schrieb Ralf Herrmann:

Du musst abgeänderte OFL-Schriften übrigens nicht veröffentlichen, nur weil sie abgeändert wurden. Nur wenn sie veröffentlicht werden, dann muss man sich an die Regeln der Lizenz halten. 

Danke auch hierfür: Ich frage mich halt, wie ich das mache im Fall, dass das ein kleines von einem Verlag veröffentlichtes Buch werden sollte. Dann sollte ich ja fairerweise angeben, dass ich die Schriftart Hussar Milosc etc. verwendet habe. Und da ich sie ja jetzt geringfügig verändert verwende, müsste ich doch wohl auch dies mitteilen, oder sehe ich das zu streng?

VG ww_wupp

[ww_wupp]

Nun bin ich einiges weiter gekommen:

Die von mir geringfügig ergänzte Schriftart ist mit der von mir verwendeten dopdf-Version tatsächlich kompatibel.

Die von mir im FontCreator bei "normalen" Schriftarten verwendeten 3 Mapping Ebenen sind Macintosh Roman, Microsoft Unicode Bitmap only und Unicode 2.0 and onwards semantics, BMP. Alle 3 stehen in mehreren auswählbaren Optionen zur Verfügung, wobei ich bei Macintosh Roman bisher immer "Byte encoding table" verwendet habe, bei den beiden anderen "Segment mapping to delta values".

Mit diesen Einstellungen hat dagger in Macintosh Roman den Code $00A0, die beiden anderen $2020.

Wende ich hingegen bei Macintosh Roman "trimmed table mapping" an, haben alle 3 den Code $2020. Diese Einstellung habe ich auch in der originalen Schriftart Hussar Milosc vorgefunden und hatte nur bisher nicht darauf geachtet, dass dort Macintosh Roman mit "trimmed table mapping" angewendet ist.

Da mir mittlerweile doch noch einige Korrekturwünsche aufgefallen sind, werde ich wohl in den nächsten Tagen tatsächlich eine neue SIL OFL Schriftart aus Hussar Milosc mit erheblich verringertem Umfang machen. Aufgefallen ist mir konkret, dass das Blank mir viel zu schmal ist und dass die Unterlänge des small letter g ein wenig zu dick ist. Möglicherweise möchte ich auch noch die Größenverhältnisse der Anführungszeichen ein wenig homogener machen.

Ich bleibe natürlich gespannt auf weitere Rückmeldungen, vermute aber, dass das Problem dank Eurer Hilfe geklärt sein dürfte.

Danke also und VG ww_wupp

[ww_wupp]

Eine kurze, vielleicht wichtigere Rückfrage im Anschluss an diese Erfahrungen wäre für mich noch: Sollte ich mir für die Schriftarten von mir, von denen ich weiß, dass sie mehr in Verwendung sind, noch irgendwann mal die Zeit nehmen, in FontCreator bei der Mapping Ebene Macintosh Roman einen neuen release auf "trimmed table mapping" umzustellen? (Das hieße vermutlich: Erstmal die Mapping Ebene komplett zu löschen und dann mit Option, die Codes von einer anderen Mapping Ebene zu übernehmen, die Mapping Ebene neu einzubauen; ich hoffe, dass würde so funktionieren, und somit nur wenig Zeit brauchen...)

Danke nochmals und VG ww_wupp

[Ralf Herrmann]

Ich kann den Erklärungen nicht folgen, aber ich benutzte diesen Fonteditor auch nicht. Ich kann nicht nachvollziehen, was diese Mapping-Ebenen sein sollen. Heutige Fonts sind halt einfach Unicode-kodiert. Da gibt’s dann auch keine Probleme, weil die Unicodes eindeutig sind. Sowas wie »Mac Roman« benutze ich nur noch zur Zeichenbelegung, nicht aber als Zeichencodierung.  

[ww_wupp]

@Ralf Herrmann: Herzlichen Dank für Deine erneute Antwort.

Angesichts dessen, dass ich von anderswo weiß, wie viele Leute noch mit weit älterer Technik ausgerüstet sind, bin ich am überlegen, ob ich mir doch noch die Zeit nehmen sollte, Screenshots aus dem FontCreator zu machen und hochzuladen, oder ob das hier doch nichts brächte.

Ich selbst kann mit Deiner nachfolgenden Aussage vorerst garnichts anfangen:

vor 20 Stunden schrieb Ralf Herrmann:

Sowas wie »Mac Roman« benutze ich nur noch zur Zeichenbelegung, nicht aber als Zeichencodierung.

So viel vielleicht aber jetzt doch noch, erstmal: Beim Öffnen von Hussar Milosc habe ich im Font Creator im Vergleich zu meinen bisherigen Erfahrungen mit Schriftarten von anderen ziemlich viele Mapping Ebenen vorgefunden. Ich habe mich zu Beginn meiner Arbeit mit Schriftartengestaltung im FontCreator (2006) bei der Auswahl der Mapping Ebenen an dem orientiert, was ich in anderen Schriftarten gesehen habe, und das waren immer wieder die letzthin von mir genannten 3 (manchmal waren es sogar nur 2 davon, als Macintosh Roman und Microsoft Unicode Bitmap only). Und in diesen von mir angeschauten anderen Schriftarten war eben auch für Macintosh Roman die von mir bisher gewählte Einstellung, und diese Einstellung war hier auch die Default-Einstellung von FontCreator, wobei es mich natürlich schon immer wieder gestört hat, dass diese Einstellung dazu führte, dass z.T. mehr als die Hälfte meiner Glyphenfelder an dieser Mapping Ebene keinen Code mehr hatte - wie das allerdings auch bei den von mir zuvor angeschauten Schriftarten damals der Fall war. Allerdings habe ich beim Anlegen meiner Schriftarten stets ziemlich viele Mapping Ebenen von vornherein gelöscht, um nicht beim Hinzufügen weiterer Glyphenfelder alle diese Mapping Ebenen codieren zu müssen.

Mir hat jedenfalls meine Ausgabe des FontCreator bei der Lösung des Problems geholfen, dass ich nun durch die Ergänzung einiger nicht eingetragener Codes am blank es geschafft habe, dass ich Hussar Milosc nach dieser Ergänzung mit meinen gewohnten Programmen problemlos verwenden kann.

Ich hoffe, das hilft ein wenig zum besseren Verstehen.

VG und vielen Dank - ich bleibe natürlich interessiert an und dankbar für weitereN Rückmeldungen -

ww_wupp

[Ralf Herrmann]

Es wäre vermutlich besser, die Fragen ins FontCreator-Forum einzustellen:

https://forum.high-logic.com

[ww_wupp]

Am 8.12.2022 um 13:41 schrieb Ralf Herrmann:

Es wäre vermutlich besser, die Fragen ins FontCreator-Forum einzustellen:

https://forum.high-logic.com

Lieben Dank für Deinen Rat. Das werde ich mir demnächst anschauen.

Ich bin gestern so weit gekommen, dass ich 2 fertig verwendbare Schriftartendateien habe, die unter meinen Arbeitsbedingungen das können, was ich brauche (abgesehen vielleicht von den Kernings).

Mir ist durch Checken etlicher kostenloser Schriftarten-Ausgaben von myfont.de klar geworden, was ich in meinem FontCreator in den üblicherweise vorhandenen Codebereichen unter Format->Namings schreiben muss, damit regular und oblique gemeinsam in meinem Windows installiert werden können. (Für Macintosh Chinesisch und Macintosh Russisch und die nicht-englischen Unicode Fremdsprachenbereiche habe ich hingegen keine Vorbilder gefunden, sodass ich diese Codebereiche, die in den Hussar Milosc .otf-Dateien ohnedies keine für mich sichtbaren Codes haben, einfach gelöscht habe.

Mir ist dabei auch klar geworden, dass die Macintosh Roman Codes in keiner dieser Ausgaben identisch sind mit den Windows Codes (welche letztere offensichtlich Unicode Codes sind). Mir ist nur noch nicht klar, ob die Ausgabe dieser meiner neuen Schriftarten besser funzen würde, wenn ich die Macintosh Roman Codes unverändert ließe, also von Hussar Milosc übernähme, oder wenn ich die Werte nehme, die dort üblich sind, s.

https://de.wikipedia.org/wiki/Macintosh_Roman

Die in den .otf-Dateien von Hussar Milosc verwendeten Macintosh Roman Codes konnte ich trotz ziemlich langer Recherchen mit 3 Suchmaschinen nirgendwo im Internet finden.

Ich habe halt keinen Mac PC, auf dem ich das ausprobieren könnte.

Natürlich werde ich nicht die Fehler hinsichtlich der SIL OFL von Hussar Milosc übernehmen, wenn ich dann meinen Release online gehen lasse.

Tja, so weit mit einem herzlichen Danke meine bisherigen Erfahrungen.

VG und natürlich bleibe ich für weitere Rückfragen und Rückmeldungen interessiert

ww_wupp

bearbeitet Dezember 9, 2022 von ww_wupp
wichtiges Wort vergessen gehabt

[Phoibos]

Vielleicht helfen Dir die Links in diesem Artikel weiter: https://en.wikipedia.org/wiki/Code_page

 

Da es sich um freie Schriften handelt, erstelle doch eine modern aufgebaute Fontdatei mit aktuell üblichen technischen Vorgaben. Die Pfade kannst Du dann von den Originalen da reinkopieren.

Im Übrigen war es früher schon immer extremes pita, sich mit über die verschiedene Plattformen und Programmversionen mit Fonts herumzuschlagen, etwas, was seit .ttf schon viel besser geworden ist, aber erst durch Unicode fast komplett geklärt wurde (utf-8 vs utf-16 vs utf-32,, big/little endian, UCS -- ist aber alles für den Alltagsgebrauch europäisch-stämmiger Schriftsysteme irrelevant).
 

[ww_wupp]

Am 8.12.2022 um 13:41 schrieb Ralf Herrmann:

https://forum.high-logic.com

... da habe ich mich gestern noch umgeschaut, also: Die Suche nach "trimmed table mapping" führte mich zu 5 Ergebnissen, das älteste wohl von 2015, und alle anscheinend ohne Lösung des Problems.

Darüber hinaus habe ich mir die Mitgliedsbedingungen dort angeschaut, und daraus entnommen, dass Mitglieder, die sich von unterschiedlichen IP-Adressen anmelden, sehr bald gekündigt würden. Da ich aber meine Sachen an mehreren PCs im Wechsel mache, vermute ich, dass ich dort nicht willkommen wäre - oder würdet Ihr das anders verstehen?

@Phoibos: Danke für Deinen freundlichen Hinweis, ich habe mir soeben

vor 4 Stunden schrieb Phoibos:

https://en.wikipedia.org/wiki/Code_page

und die darauf verlinkte englische Fassung des Wikipedia Artikels zu Macintosh Roman angeschaut: Auf beiden Seiten kann ich keinen Hinweis auf "trimmed table mapping" finden.

Konkret sieht das beim Arbeiten mit meinem FontCreator an diesen Schriftarten so aus: Die - anscheinend nirgendwo veröffentlichte - Code page von Macintosh Roman trimmed table mapping ist anscheinend im recht großen Anfangsbereich identisch zu Macintosh Roman und - ich vermute mal ganz stark - auch zu Unicode. Wenn ich mir darüber hinaus die Macintosh Roman Codes in den Hussar Milosc .otf-Dateien entweder über Format -> Mappings oder über Glyphenfeld->Properties ansehe, bekomme ich andere Code-Eintragungen in Verbindung mit der zu den anderen Code tables identischen Glyphenbezeichnung zu sehen. Markiere ich diesen Eintrag jedoch und drücke "select", bekomme ich die Liste angezeigt für Macintosh Roman byte encoding table, wo der jeweilige Code mit einer anderen Glyphenbezeichnung verknüpft ist. Lösche ich nun den bisherigen Codeeintrag für Macintosch Roman für dieses Glyphenfeld, so kann ich das in meinem FontCreator, sobald ich die Änderung durch OK und schließen des Dialogfelds bestätigt habe, nicht mehr rückgängig machen. Ordne ich danach dem Glyphenfeld die bisherige Codeeintragung zu, wird sie mit der dafür in Macintosh Roman byte encoding table vorgesehenen Glyphenbezeichnung verknüpft. Ordne ich dem Glyphenfeld nun aber hier statt dessen die passende Glyphenbezeichnung zu, so bekommt das Glyphenfeld einen anderen Code-Eintrag, nämlich den hier bei Macintosh Roman byte encoding table vorgesehenen.

Übrigens muss ich noch korrigieren: Der Terminus "Mapping Ebene" kommt im FontCreator so nicht vor, das war eine mehrmals wiederholte Schlamperei von mir, für die ich um Nachsicht bitte. Ich kann - auf die ganze Schriftart bezogen - über die im Programm oben stehenden Einträge "Format" auswählen, und im dabei in Listenform aufgehenden Dialogfeld sind die obersten Einträge:

"Platform Manager" (hier kann ich auswählen, welche Code page Einträge ich aktivieren und deaktivieren will - ich hoffe, Code page stimmt an dieser Stelle, ich sehe diesen Begriff dort nicht wirklich, sondern eben die unterschiedlichen Bezeichnungen; das gilt auch im folgenden).

"Naming": Hier ist für die oben ausgewählten Bereiche der jeweilige Eintrag des Namens der Schriftart zu sehen oder zu ändern, aber auch ob die Schriftartdatei "kursiv" oder "regular" etc. gemeint ist, die Urheberrechtseinträge, und für zumindest einen der Unicode-Einträge können auch Sprach-Bereiche gewählt oder gelöscht werden, wobei das Löschen dort aber endgültig ist, wenn die OK-Taste mal gedrückt wurde.

"Mapping": Hier kann ich oben auswählen, welchen Code page Bereich ich sehen oder bearbeiten will, und links auswählen, welches Glyphenfeld ich sehen oder bearbeiten will und ggf. Codes löschen oder hinzufügen.

Unabhängig davon kann ich die Codes aber auch für jedes Glyphenfeld einzeln ändern, indem ich das Glyphenfeld rechtsklicke. Auf dem vorderen Tab des Dialogfelds kann ich insbesondere die Laufweite und den Glyphennamen eingeben, wenn einer am oberen Rand des Glyphenfelds stehen soll, und im hinteren Tab dieses Dialogfelds für die vorhandenen Code page Bereiche die Codes ändern.

Im Moment herrscht bei beiden von mir angelegten Schriftarten-Dateien im Bereich Macintosh Roman noch Chaos: Z.T. habe ich bisherige Codeeinträge ersatzlos entfernt, z.T. habe ich neue Codeeinträge durchgeführt, z.T. bisherige Codeeinträge unverändert gelassen.

Ich vermute jetzt, dass ich erstmal in einem nächsten Antwort-Beitrag eine wohl zunächst als Tabelle von mir zu erstellende und dann hier als jpg-Bild einzustellende Wiedergabe der Codierung in Macintosh Roman trimmed table mapping machen werde müssen.

Und dann werde ich wohl einerseits die beiden bereits erstellten Schriftartendateien komplett im Code page Bereich auf Macintosh Roman byte ecoding table umstellen müssen, und andrerseits 2 weitere Schriftartendateien erstellen müssen, bei denen ich die Macintosh Roman trimmed table mapping Codierung unverändert lasse. Ob ich dann bei diesen beiden letztgenannten auch wieder die Glyphenauswahl auf die mir gewohnte Auswahl reduzieren, oder doch gleich lassen soll, ist mir noch etwas unklar. Natürlich muss ich auch dort die Code page Einträge löschen, auf denen ich keine Code-Einträge gefunden habe und für die ich nicht weiß, wie ich sie korrekt in Format->Namings als für mich brauchbares "regular" bzw. "kursiv" beschriften kann. Allerdings werde ich bei diesen beiden letzteren wohl auch darauf verzichten müssen, beim Hinzufügen des nobreakspace auf das blank den Code auf Macintosh Roman trimmed table mapping dort einzutragen, weil ich wie beschrieben mit meinem FontCreator das so nicht kann.

Im Moment bin ich noch unsicher, ob ich angesichts der dargestellten Beobachtungen doch noch versuchen will, meine Frage im High Logic Forum zu posten, zunächst jedenfalls gefühlsmäßig eher nicht.

Ich bleibe interessiert an weiteren Rückmeldungen und werde die genannten Schritte so bald wie mir möglich durchführen.

VG ww_wupp

bearbeitet Dezember 10, 2022 von ww_wupp
da waren einige Flüchtigkeitsfehler

[ww_wupp]

Sorry, da hab ich doch noch einen Fehler übersehen:

vor 1 Stunde schrieb ww_wupp:

Die Suche nach "trimmed table mapping" führte mich zu 5 Ergebnissen, das älteste wohl von 2015, und alle anscheinend ohne Lösung des Problems.

2015 ist falsch, da sollte 2005 stehen, tut mir echt leid!

VG ww_wupp

[ww_wupp]

Peinlich, aber erstmal nicht zu ändern: Kurze Zwischenmeldung: Ich habe keine Unterschiede zwischen der Wikipedia-Tabelle für Macintosh Roman und den entsprechenden Codes in der .otf-Datei von Hussar Milosc gefunden. Es scheint aber etliche Schreibfehler in der zugehörigen Auswahltabelle in der von mir verwendeten Version von FontCreator ab Code $0080 zu geben. Das konnte ich heute aber noch nicht zuende durchchecken.

VG ww_wupp

[Phoibos]

vor 1 Stunde schrieb ww_wupp:

aber etliche Schreibfehler in der zugehörigen Auswahltabelle in der von mir verwendeten Version von FontCreator ab Code $0080 zu geben.

Hast Du mal ein Tool wie Font Doctor (ich hoffe, dass das der ist, der früher mit Suitcase gebundelt kam) oder so probiert?

[Phoibos]

Und auch wenn Du mit veralteter Technik unterwegs bist und der Künstler schon länger nichts mehr gepostet hat, vielleicht kann Dir Robert Jablonski vielleicht helfen?

[ww_wupp]

vor 46 Minuten schrieb Phoibos:

Hast Du mal ein Tool wie Font Doctor (ich hoffe, dass das der ist, der früher mit Suitcase gebundelt kam) oder so probiert?

 

vor 18 Minuten schrieb Phoibos:

vielleicht kann Dir Robert Jablonski vielleicht helfen?

Danke für Deine beiden Hinweise.

Anscheinend habe ich mich nicht deutlich genug ausgedrückt.

Zu den Schreibfehlern im FontCreator: Ich habe da allerdings auch nicht die jüngste Ausgabe, und offensichtlich hat das Programm an dieser Stelle irgendeinen bug, vielleicht Schwierigkeiten mit dem Modus des Macintosh Roman code table Bereichs, aber: Ich konnte trotzdem herausfinden, dass die Schriftarten DORT fehlerfrei sind, ich muss dort also - trotz bisheriger von mir falsch interpretierter Beobachtungen - gar nicht dran, abgesehen vom Ergänzen fehlender Codes für blank. (Die weiteren Korrekturen betreffen ja nicht Macintosh Roman.)

Bezüglich Robert Jablonski wäre das bestimmt ein gangbarer Weg, wenn ich nicht auch noch den Wunsch hätte, seine Schriftart mit ein bisschen schmalerer Unterlänge beim small latin letter g zu verwenden (und vielleicht auch noch ein großes SZ einzubauen). In der vorliegenden Form hat mein Text bei jedem kleinen g in makroskopischer Sicht einen deutlichen dunklen Fleck. Diese Änderungen bedeuten ja trotzdem, dass ich eine neue Schriftart machen muss, aber nach den bisherigen Erkenntnissen ist das - abgesehen von einigen Korrekturen bei den Kernings - alles mittlerweile sehr überschaubar geworden, ich muss zwar leider meine bisherigen Schriftart-Weiterentwicklungs-Ergebnisse "einstampfen" und von vorn beginnen, kann aber die gewonnenen Erkenntnisse dann umso rascher anwenden.

Vielen Dank und VG ww_wupp

bearbeitet Dezember 10, 2022 von ww_wupp
Die Antwort war noch nicht fertig gewesen...

[ww_wupp]

@Phoibos: Natürlich werde ich mir sobald ich Luft dazu finde den Font Doctor mal anschauen und, sobald ich mit den beiden Schriftart-Dateien fertig bin, also die Ausgabe online stehen wird, Robert Jablonsky zu kontaktieren versuchen. Die Tage ist bei mir aber leider dermaßen viel anderes vorrangig, dass ich diesbezüglich noch zu nichts gekommen bin...

Vielen Dank und VG ww_wupp

[ww_wupp]

Soeben mahnt mich das typografie.info-System per eMail, hier die beste Antwort zu markieren.

Das kann ich leider nicht, da ich einige Hinweise im selben Maß als sehr hilfreich erlebt habe.

Und, so leid es mir tut, ich habe es noch immer nicht geschafft, die Sache endlich zum Abschluss zu bringen, dann werde ich gern nochmals berichten.

Meine Beobachtungen bei der Suche im Forum für den FontCreator lassen mich derzeit vermuten, dass der von mir beobachtete Fehler in meiner Ausgabe des FontCreator in von mir nicht gekauften Updates inzwischen behoben wurde, da meine Ausgabe nur wenig jünger ist, als die von mir gefundenen Einträge dort in diesem Forum.

Ich erwäge trotzdem, die fehlerhafte Auswahl-Liste in meinem FontCreator hier noch zu posten, sobald ich dazu komme, bin aber noch unschlüssig, ob als zusammengesetzten und kommentierten "Screenshot" oder als Tabelle. Beides wäre etwa gleich zeitaufwändig, könnte aber vielleicht anderen bei vergleichbarer Problemlage hier noch helfen.

(Nochmals möglichst kurz erklärt: Wenn ich in meinem FontCreator einem Glyphenfeld in Hussar Milosc einen Macintosh Roman Code zuordnen will, muss ich auf  "select" klicken. Und da werden mir für die Codes von $0080 bis $00FF so gut wie ausschließlich falsche Code-Zuordnungen gezeigt. So z.B. für $0080 "<control>" anstelle von latin capital letter a with dieresis. Wähle ich hier aber trotzdem $0080 aus, wird mir dann in den Properties des Glyphenfelds die richtige Angabe gezeigt.)

Also: Bis hoffentlich bald und sicherheitshalber mal Euch allen gute Feiertage!

VG und vielen Dank ww_wupp

[ww_wupp]

Nun habe ich mir endlich die Zeit nehmen können, die wiederholt angedeutete Liste der fehlerhaften Auswahltabelle in meinem FontCreator für Macintosh Roman zu erstellen.

Ich habe die Tabelle in pdf und davon in jpg umgewandelt und dann etwas runterskaliert, ich hoffe, es ist alles gut lesbar.

Den oberen Teil konnte ich ja weglassen, weil fehlerfrei, von $0080 bis $009F sind es ausschließlich <control>-Einträge, für die ich zusätzliche Tabellenzeilen einfügen musste, weil nach "<control>" fast überall noch etwas in eckigen Klammern steht. Die roten Einträge entsprechen den Einträgen in der Auswahltabelle, die von den Angaben in der entsprechenden Tabelle auf Wikipedia abweichen. An den seltenen Stellen, wo die Angabe nicht abweicht, ist der Eintrag jeweils schwarz. Es erschien mir übersichtlicher, die Zeichen einzutragen, obwohl in der Auswahltabelle die Wortformen stehen. Also z.B. Latin capital letter a with dieresis anstelle von Ä.

Falls es wo unklar sein sollte oder die Grafik doch zu klein sein sollte, bitte gern rückmelden.

VG und gute Feiertage ww_wupp