Probleme mit Kernings bei diversen Sonderzeichen in Word 2003

[catfonts]

Richtig, Wobei die Vorbreite hier so eng ist, weil da nur die eine Serife ist, Hätte ich hier eine serifenlose, wäre die Nachbreite bei den Bögen kleiner als die Vorbreite wo der senkrechte Stamm steht.

[ww_wupp]

@catfonts: Vielen Dank!

Ich bin einen deutlichen Schritt weiter mit folgender Entwicklung und folgenden Einschränkungen: - Die von Dir empfohlene Download-Seite für FontForge brachte eine Quelldatei, die mein Virenschutzprogramm nicht mag, während der Installation ging wohl so ziemlich alles kaputt, und ein leider erst danach gemachter Scan brachte das Ergebnis, dass die Quelldatei 109 mal den Trojaner "TR/Crypt.XPACK.Gen2" enthielt. Ich musste also diese Datei schreddern und das Programm, was davon angekommen war.

- Weitere Quelldateien waren in gleicher Weise "verseucht". Klar, das kann auch ein Fehler des Virenschutzprogramms sein, aber wenn ich permanent den Virenschutz ausschalten muss, ist mir auch nicht wohl dabei.

- Eine Quelldatei von Chip "FontForgePortable_2014-11-26.paf.exe" enthielt hingegen keine Trojaner oder Viren, und die hat meiner Beobachtung nach nur den "Nachteil", dass sie sich nicht fürs Deinstallieren zeigt, das Programm bleibt anscheinend mit allen Komponenten auf dem Stick, und von dort konnte ich nach weit mehr Herumexperimentieren, als ich mir eigentlich Zeit nehmen wollte, letztendlich ein recht gutes Ergebnis hinbekommenen, wo vermutlich wirklich nur noch wenige Unterschneidungspaare notwendig werden dürften.

- Allerdings war es völlig unmöglich, die zusammengesetzten Glyphen "sauber" zu behalten, da war immer z. B. der "Macron"-Strich voll verrutscht, oder eben die Dieresis.

- Klar, meine "Spezialmacken" muss ich mir erst selbst wieder nachbauen, verkleinerte Blanks auf Sonderzeichen, ein voller Block ohne Seitenabstände und derlei Sachen. Aber damit kann ich leben.

- Allerdings bleibt es dabei: Ich habe probeweise ein einziges Unterschneidungspaar eingerichtet

! gefolgt von U+263B

, und da ändert sich definitiv nichts, der Unterschneidungswert kommt nicht zur Wirkung.

 

Ich werde mit diesem Ergebnis natürlich jetzt nicht meine mühsam aufgebaute Buch-Datei auseinanderfetzen, aber fürs weitere Entwickeln dieser Schrift und für meine weiteren mit ähnlichen Anfängerfehlern belasteten Schriftarten ist das ganz bestimmt ein guter Weg, sofern ich die zusammengesetzten Glyphen erstmal leer mache oder in einfache Glyphen umwandle.

 

Vielen Dank also!

 

Gruß und Dank

 

ww_wupp

[catfonts]

Nur mal zu dem von mir gegebenen Link zum Fontforge-Download:

 

Da muss wohl schon was krumm auf deinem Rechner sein, denn ich habe die Datei bei "Virus Total" durchscannen lassen, und bis auf Rising, das einen Trojaner vermutet, wird es bei allen führenden Anti-Viren-Programmen als Sauber angesehen:

 

https://www.virustotal.com/de/file/be6a69213585c5e0811feb9507e35d8d14ff1eef4224ba1c67a9d538a868c8bd/analysis/1434721111/

 

Ich vermute, das die eine Meldung ein falsch positives Ergebnis ist.

[Phoibos]

"FontForgePortable_2014-11-26.paf.exe" enthielt hingegen keine Trojaner oder Viren, und die hat meiner Beobachtung nach nur den "Nachteil", dass sie sich nicht fürs Deinstallieren zeigt, das Programm bleibt anscheinend mit allen Komponenten auf dem Stick, und von dort konnte ich nach weit mehr Herumexperimentieren, als ich mir eigentlich Zeit nehmen wollte, letztendlich ein recht gutes Ergebnis hinbekommenen, wo vermutlich wirklich nur noch wenige Unterschneidungspaare notwendig werden dürften.

 

Das Programm heißt "portable", weil es ohne Installation läuft und jenseits des eigenen Programmordners, den Du entpackt hast, Dein System nicht vollmüllt, ergo keine Einträge in der Registry, wo die Deinstallationsinformationen gespeichert werden, hinterlässt. Einfach den Ordner löschen und Du bist das Programm inklusive aller Abhängigkeiten los. Für weitere Informationen hier das Projekt, dass *.paf entwickelt hat: http://portableapps.com/

[ww_wupp]

@catfonts: Danke für Deine Rückmeldung, ich habe mich bewusst behutsam ausgedrückt, so ähnlich hatte ich es ja auch vermutet, wohl ein ähnliches Problem wie jahrelang bei GIMP, aber: Ich habe nunmal kein anderes Virenschutzprogramm und kann mir ohne online zu gehen kein anderes holen, und so bin ich froh, dass ich für meine spezielle Lage die portable Version von FontForge gefunden habe.

 

@Phoibos: Vielen Dank, so würde ich das gemacht haben, wenn ich mit dem Programm nicht doch noch etliche weitere meiner Schriftarten revidieren wollte.

Ich bin mir nur unsicher, ob das auch noch funzen würde, wenn ich es vom Stick z. B. auf externe Festplatte verschieben würde, aber das ist dann bestimmt kein Problem, entweder, es funzt, oder, ich muss es eben nochmals installieren.

Etwas irritiert war ich allerdings immer bei den Meldungen, dass eine mit FontForge (portabel) gemachte, aber dann von mir bewusst gelöschte Datei jedes Mal neu beim wiederholten Programmstart gesucht wurde. Da muss also doch irgendwo was in der Registry gelandet sein...

 

Gruß und Dank

 

ww_wupp

[Phoibos]

Ich bin mir nur unsicher, ob das auch noch funzen würde, wenn ich es vom Stick z. B. auf externe Festplatte verschieben würde

 

Wenn Du den ganzen Ordner verschiebst, funktioniert alles weiterhin.

 

 

 

Etwas irritiert war ich allerdings immer bei den Meldungen, dass eine mit FontForge (portabel) gemachte, aber dann von mir bewusst gelöschte Datei jedes Mal neu beim wiederholten Programmstart gesucht wurde. Da muss also doch irgendwo was in der Registry gelandet sein...

 

PortableApps speichert so etwas in .ini-Dateien im Ordner.

[ww_wupp]

@Phoibos: Danke für Deine Erläuterung! Ich habe daraufhin alle .ini-Dateien mit Notepad++ angeschaut, aber der Name der gelöschten und bei jedem Start wieder angefragten Datei ist so nicht darin zu finden.

 

Gruß und Dank

 

ww_wupp

[Phoibos]

*Kopfklatsch* Windows MRU-Listen sind natürlich unberührt, da die vom Betriebssystem angelegt und verwaltet werden. Kann es sein, dass Fontforge auf dieses Windows-Feature zurückgreift? Dann sind die Daten in der Registry.

[catfonts]

Nun ja, Es ist ja wohl auch sehr wenig sinnvoll, wenn sich Fontforge auf dem Stick merkt, welche Datei da zuletzt geöffnet war, denn die kann es gar nicht finden, startet man die portable Version auf einem anderen Rechner.

 

Was für portable Programme jedoch Tabu ist, ist die Windows-Registry, dort sind solche Informationen auch gar nicht versteckt.

 

Untergebracht werden derartige lokale Programmeinstellungen jedoch im Benutzerverzeichnis, und da im vor dem Benutzer wohl ausgeblendeten und zugriffsgesperrten (was hier Windows macht)  c:\Users (Benutzer - Windoof übersetzt das für die Anzeige)\{du}\Anwendungsdateien\FontForge   Darin ist eine Datei "prefs" - und da ans ende sammelt FontForge die Liste der zuletzt geöffneten Dateien

[ww_wupp]

@Phoibos und @Catfonts: Danke für Eure Antworten. Soweit ich das jetzt nach einigem Suchen beurteilen kann, können beide Vermutungen nicht stimmen, sondern dürfte das portable FontForge diese Daten verschlüsselt speichern. Es gibt jedenfalls keinen Ordner c/[user]/Anwendungsdaten/FontForge. In c/windows/prefetch gibt es einige .pf-Dateien, aber die beinhalten auch alle nicht den Text des reklamierten Namens der gelöschten Datei, und auch in der .log-Datei im Ordner c/[user]/lokale einstellungen/Temp/FontForgePortableTemp kann ich diesen Namen nicht finden.

 

Vermutlich muss ich entweder damit leben, oder alles löschen und FontForgePortable komplett neu aus der Quelldatei initiieren / installieren oder wie das korrekt heißen mag.

 

Gruß und Dank

 

ww_wupp

[catfonts]

Hast du bei dir die ausgeblendeten Ordner auch sichtbar gemacht?  C:\Users\[benutzername]\Anwendungsdaten/... ist normalerweise ein versteckter Ordner.

 

 

Versteckte Ordner sichtbar machen:

 

Windows+E  >  Kurz Alt drücken  >  Extras - Ordneroptionen. Hier im Fenster Ansicht kannst du versteckte Ordner und ausgeblendete Systemdateien sichtbar machen, Ebenso empfielt sich, die Ausblendung von Erweiterungen bei bekannten Dateitypen aufzuheben.

 

 

 

[ww_wupp]

@Catfonts: Danke für Deine Rückfrage, ich lasse die versteckten und ausgeblendeten Dateien stets sichtbar werden. Ansonsten hätte ich die erwähnten Dateien gar nicht gesehen.

 

Gruß und Dank

 

ww_wupp

[ww_wupp]

Da mir catfonts freundlicherweise in diesem Thema FontForge empfohlen hat, schreibe ich hier ein Problem hinein, dass vor allem mit fontforge und nur noch randlich mit dem ursprünglichen Thema zu tun hat, aber schon auch noch: Ich habe diese Autometrics-Prozedur noch bei anderen meiner Schriftarten ausprobiert - und stehe plötzlich eigentlich zufällig vor dem Problem, dass FontForge beim Exportieren ja die Glyphenfelder so automatisch sortiert, dass dabei - wenn ich das richtig beobachte - ausschließlich die Unicode-Codes, nicht aber die Macintosh Roman Codes verwendet werden.

 

Dadurch ist nun folgendes passiert:

 

Ich hatte im FontCreator weil leicht machbar auf Glyphenfeld Nr. $0099 mit den Codes

Macintosh Roman / Byte encoding table $00B9

Microsoft Unicode BMP only / Segment mapping to delta values 0 (ja: Null, also kein Wert)

Unicode 2.0 and onwards semantics, BMP / Segment mapping to delta values 0 (nochmals kein Wert)

ein kleines griechisches Pi gelegt und das Glyphenfeld nicht benannt.

 

In der Output-Datei von FontForge war dieser Glyph an die letzte Position verschoben worden mit dem Glyphenfeld-Namen "glyph153", deutlich erkennbar als nicht codiertes Glyphenfeld und ohne jegliche Code-Werte, wobei mir für Macintosh Roman zunächst das Format "Trimmed table mapping" angeboten wird, das ich bisher nicht verwendet habe oder kenne, und wo über "Select" die - meiner bisherigen Annahme nach für Macintosh Roman unbrauchbaren - Unicode-Tabellen aufgerufen werden. Natürlich ist es kein Problem, für die beiden anderen Platforms die geeigneten Unicode-Werte einzugeben, aber genauso natürlich bekomme ich, wenn ich dort, auf Glyphenfeld $0194 für die Platform Macintosh Roman über Format Byte endoding table den für dieses kleine Pi üblichen Codewert $00B9 auswählen möchte die Warnmeldung:

 

The "Byte encoding table" mappings con not be assigned to glyphs with inexes higher than 255.

 

Dieses "255" scheint dem Glyphenfeld $00FF zu entsprechen, wo ich zwar das lslash habe, das keinen Code unter Platform Macintosh Roman mit Format Byte encoding table hat, aber ein Versuch, anstelle des auch dort defaultmäßig angezeigten Format table trimming das Format Byte encoding table zu wählen und darüber irgendeinen auf Glyphenfeld $0000 liegenden Code auszuwählen gibt die dafür übliche Warnung, und nicht die obige.

 

Gehe ich auch nur zum nächsten Glyphenfeld und versuche dasselbe, bekomme ich wieder die genannte Warnung, dass das für dieses Glyphenfeld nicht geht.

 

Nun ist aber durch dieses Sortieren durch FontForge jede Menge von Zeichen, die auf Plattform Macintosh Roman mit Format Byte encoding table einen Code-Wert haben, auf Positionen mit einer höheren Glyphenfeld-Nummer als $0100 verschoben, und ich bin unsicher, ob ich mir jetzt die Mühe machen sollte, diese mehrere Dutzend Glyphen so zu verschieben, dass sie wieder hinsichtlich der Position der Glyphenfelder im Bereich gültiger Macintosh Roman - Codierung liegen, oder ob ich mir diese Mühe sparen kann.

 

Ich habe gerade mal ausprobiert, ob sich das hinsichtlich des Unterschneidens auf "ellipsis" auswirkt, das ist ein Zeichen mit Macintosh Roman Code-Wert, es liegt auf Glyphenfeld $0163 und ich habe es gerade ausprobiert: W-ellipsis hat kein Problem, den mittlerweile eingegebenen Unterschneidungswert umzusetzen.

 

Soeben habe ich noch versucht, das große scharfe S mit beiden Codierungen als Kerningpaare auszuprobieren, also sowohl mit Code $1E9E als auch $EBE4, der Einfachheit halber mit dem Ausrufezeichen, und beide Paare wurden mir in XP in Word auch bei Einschalten der Unterschneidungen so angezeigt, als bestünden diese Unterschneidungspaare nicht. Die weiter bearbeitete Schriftart hat - ohne diese Unterschneidungspaare auf dem großen scharfen S - derzeit 444 Unterschneidungspaare, allerdings fehlt noch die Analyse ausgedruckter Probe-Bögen, und danach sollen erst irgendwann die Unterschneidungspaare für den Großteil der Composed Glyphs folgen.

 

Ich MUSS also bestimmt weiterhin zumindest für meine Verwendung etliche Sonderzeichen auf unüblichen Plätzen haben, ansonsten könnte ich sie nicht in Unterschneidungspaaren verwenden.

 

Bitte um Rückmeldungen zu der Frage nach "verrutschten Macintosh Roman Codewerten".

 

Gruß und Dank

 

ww_wupp

 

PS noch: Ich kann im FontCreator beim Auswählen von Codes folgende Formate nützen, in der Reihenfolge, wie sie in der Auswahl-Liste stehen:

 

Byte encoding table (greift auf Mac Characters Tabelle zu)

High-byte mapping through table (greift auf Unicode-Tabellen zu)

Segment mapping to delta values (greift auf Unicode-Tabellen zu)

Trimmed table mapping (greift auf Unicode-Tabellen zu)

Segmented coverage (greift auf Unicode-Tabellen zu)

 

Noch ein PS:

Falls keine weiteren Macintosh Codes verloren gegangen sein sollten, sind 35 Glyphenfelder davon betroffen, dass ein dort nicht mehr gültiger Wert steht.

[catfonts]

Das liegt einfach faran,dass eben bei den 8bit-Code nur entweder das eine oder das andere geht, weil eben beide nur die Codeplätze 0x20 - 0xFF verwenden, und für diese Codepages eben alles was darüber liegt, außen vor lassen. Das war ja ewig das Problem beim Daqtenaustausch zwischen Windows und Mac.

 

Und das war ja gerade der Hauptgrund für Ünicode, hier eben genug platz für alle Zeichen zu haben. Man müsste dann eben einen Font mit der Windows-Codepage, und einem für den Mac erzeugen.