
WebMagick
-
-
Ich könnte mir eher vorstellen, dass das auf Unterschiede in der Font-Darstellung zurückzuführen ist... Jirka Kunze , was meinst Du?
-
Ein anderer Font würde den anderen Kuller erklären, aber nicht, warum der Kuller und das Leerzeichen danach jetzt auch unterstrichen sind.
-
Stimmt. Wir hatten an der Bullet-Point Geschichte auch was geändert, weil es da Bugs gab.... vielleicht hat mgroeber eine Idee....?
-
-
Hallo
Die Antwort ist ebenso simpel wie unangenehm. Das Zeichen gibt es im Nimbus Sans Font nicht.
BBX 4.01 - URW Sans / Cranbrook vs GEOS 6 Nimbus Sans / Century 59 (gleiche Datei, nur unter GEOS 6 geöffnet)
Da gleiche trifft auch für das µ (Zeichen darunter) Langer und kurzer Strich sind vertauscht (links, 3. Zeile von unten), das Dach ^ und evtl. noch ein paar Zeichen mehr zu. Dafür gibt es in den neuen Fonts ein paar Zeichen, die in den alten nicht vorkommen.
Das ist ziemlich doof, was die Dokumentenkompatibilität angeht.
Ich mach mal ein Issue.
Rainer
-
Shit.
-
Hallo,
ich habe mal eine frühere Alpha Version von Ensemble 6 gegen die PC/GEOS Live Demo verglichen.
Frühe Alpha Version mit Nimbus Sans:
Live Demo:
Der Punkt (nicht der Satzpunkt) und das µ ist in der älteren Version vorhanden. Der Unterschied beim Punkt zum Satzpunkt ist nur schwer zu erkennen, er liegt etwas näher dem Zentrum des Kästchen.
Die beiden Striche sind in beiden Fällen vertauscht, ich vermute das liegt am Mapping des GEOS Zeichens auf den Unicode. Das prüfe ich gleich. Auch sieht es so aus als ob das kleine Pi in den Zeichensatz gehört und nicht das große Pi. Das prüfe ich auch.
Hintergrund:
Für PC/GEOS haben wir die Font ein wenig abgespeckt, was einen deutlichen Performancegewinn und einen geringeren Speicherbedarf brachte. Das bedeutet dass diese nur die Zeichen des GEOS-Zeichensatzes enthalten sollen. Offensichtlich wurden in neuere Versionen einige Zeichen entfernt die eigentlich im Font hätte verbleiben müssen. @Nico kannst du hierzu etwas sagen?
Vielleicht ist es ja eine gute Idee die GEOS Zeichen und das Mapping auf die Unicodes zu dokumentieren. Hier habe ich schon mal angefangen die Fonts zu dokumentieren und für weitere Infos ist noch genug Platz: https://github.com/jirkakunze/pcg…ont_overview.md
Einen Issue auf github gibt es ja bereits.
Jirka
-
Vielleicht ist es ja eine gute Idee die GEOS Zeichen und das Mapping auf die Unicodes zu dokumentieren.
Das wäre hilfreich, das mal an einer Stelle zentral festzuhalten.
Mit Rainer haben wir ja auch schon so eine Mapping-Tabelle für die String-Wandlung nach UTF-8 in R-Basic erstellt.
-
Hallo,
bezüglich der Unterstreichung des Punktes habe ich noch eine Idee. Wir haben ja die Styles der Listendarstellung überarbeitet, für bessere Darstellung der Fehlerseiten. Vielleicht hat dieser Fix eine Nebenwirkung?
Viele Grüße,
Falk \\ blueway.Softworks
-
Ich habe jetzt mal den Nimbus-Q Fonttreiber und einige Fonts aus BBX 4 nach PC/GEOS beta kopiert. Der Punkt ist dann wieder da, allerdings plus Unterstrich. Bei meinem nicht ganz HTML-konformen Gebrauch bei den oberen Links entsteht dadurch der Eindruck, als wenn der Link bis zum Punkt reicht.
Bei HTML-konformen Gebrauch (Links unten im Screenshot) ist der falsche Unterstrich unter dem Punkt gut erkennen. Das Leerfeld zwischen Punkt und Link erscheint mir etwas zu weit - jedenfalls im Vergleich zu Firefox und Safari.
Da haben sich vielleicht zwei Fehler ergeben: Vertauschte Zeichen im Font und irgendwas im HTML-Renderer?
-
Die Überprüfung der genannten Probleme hat folgendes ergeben:
Zeichenmapping im TTF-Treiber:
- die Zeichen C_EM_DASH und C_EN_DASH (die beiden waagerechten Striche) sind in ihrer Position vertauscht
Zeichensatz im Font (Nimbus Sans Regular):
- Bullet Operator (Code 0x2219) fehlt im Font
- µ (Code 0x00b5) fehlt im Font
- kleines Pi (Code 0x03c0) fehlt im Font
Die anderen Fonts müssen noch geprüft werden.
Alles in allem sind das lösbare Probleme. Danke an den Finder.
Jirka
-
So als Font-Laie denke ich: Kann man die fehlenden Zeichen nicht händisch aus einem anderen, ähnlichen Font übertragen? µ und pi sind aus meiner (leicht wissenschaftlich geprägten) Sicht schon recht wichtige Zeichen.
Rainer
-
Ein Übertragen der Zeichen ist nicht notwendig. Die Fonts die der Distribution beiliegen sind für PC/GEOS angepasste Fonts. Diese Anpassungen umfassen je nach Font 2 bis 3 Schritte:
- Je nach Font Anpassung des Font Familiy Names (das ist der Name der dann auch in der Fontauswahl in GEOS angezeigt wird), bzw. der Subfamily.
- Alle Zeichen die nicht zum GEOS Zeichensatz gehören aus dem Font entfernen.
- Bytecode mit einem Autohinting Tool erzeugen.
Die originalen Nimbus TrueType Fonts haben die notwendigen Zeichen alle. Diese haben nur den 2. Schritt nicht 'überstanden'. Nico hat sich für uns die Arbeit gemacht für jedes Fontfile die o.g. Schritte durchzuführen. An dieser Stelle vielen Dank dafür.
Der 2. Schritt muss nur noch Korrigiert werden dann ist alles i.o.
Jirka
-
Ein Übertragen der Zeichen ist nicht notwendig. Die Fonts die der Distribution beiliegen sind für PC/GEOS angepasste Fonts. Diese Anpassungen umfassen je nach Font 2 bis 3 Schritte:
- Je nach Font Anpassung des Font Familiy Names (das ist der Name der dann auch in der Fontauswahl in GEOS angezeigt wird), bzw. der Subfamily.
- Alle Zeichen die nicht zum GEOS Zeichensatz gehören aus dem Font entfernen.
- Bytecode mit einem Autohinting Tool erzeugen.
Die originalen Nimbus TrueType Fonts haben die notwendigen Zeichen alle. Diese haben nur den 2. Schritt nicht 'überstanden'. Nico hat sich für uns die Arbeit gemacht für jedes Fontfile die o.g. Schritte durchzuführen. An dieser Stelle vielen Dank dafür.
Der 2. Schritt muss nur noch Korrigiert werden dann ist alles i.o.
Jirka
Das ist nicht so einfach uni00B5 ; uni03A9 ; uni0394 ; uni2219 und uni2215 haben keine Namen könnte das der Fehler sein !
Den Pi könnte ich anstelle des Grossen eventuell ersetzen (nicht getestet) !
Du hast geschrieben in einem alten Alpha Font wären die Zeichen , sind da alle Zeichen die Fehlen enthalten dann schicke mir den Font damit ich meine Geoscodetabelle erneuern kann und werde ein Test machen den Font neu zu erstellen !
Ideal wäre ein Font TTF mit allen im Geos enthaltenen Zeichen in dem Programm das ich benutze kann ich dann den Encoding exportieren , hatte hier ein font aus Geos FNT zu TTF konvertiert da fehlten dann diese Zeichen wurde aber nicht bemerkt.
Ich werde das mal mit URW SANS testen.
Nur wenn alles klappt werde ich die Fonts nochmal neu machen das dauert mindestens 1 bis 2 Wochen !
Gruss von Nico
-
Großes Dank an alle, die sich um die Fonts kümmern!
-
Ich habe nun folgendes geschafft :
die Zeichen C_EM_DASH und C_EN_DASH (die beiden waagerechten Striche) sind in ihrer Position vertauscht hier müsste ich dann die Zeichen austauschen.
Dafür muss ich dann die Nummer # tauchen oder reicht es die Zeichen nur zu kopieren ?
/endash #2013 –
/emdash #2014 —Das geht . Hoffe das ist dann OK
Leider muss 4 Sachen manuell bearbeitet werden pro Schrift und pro Style !
Eine Zeichentabelle GEOS UNICODE wäre hilfreich hat jemand sowas ?
Von Nico
-
Hallo Nico,
du musst keine Zeichen tauschen. EM_DASH und EN_DASH werden im Mapping des Treibers korrigiert. Den PR dafür habe ich bereits eingereicht.
Bei der Kontrolle des Mappings im Treiber ist ein weiterer kleiner Fehler aufgefallen der Aufzählungspunkt war auf das Unicode Zeichen BULLET_OPERATOR gemappt. Richtig ist dieses Zeichen auf BULLET zu mappen. Im o.g. PR ist diese Korrektur ebenfalls enthalten.
In den Fonts müssen nur noch folgende Unicodes hinzugefügt werden:
- BULLET (0x2022)
- µ (0x00b5)
- das kleine pi (0x03c0)
Jirka
-
Ja, Sebi und ich (vor allem Sebi) hatten so etwas mal für R-BASIC gebaut. Ich komme aber in den nächsten tagen nicht dazu, das (d.h. die Tabellen dazu) rauszusuchen. Vielleicht ist Sebi ja schneller
Ansonsten kann man versuchen, dass mit R-BASIC selbst zu programmieren. Die Funktion Convert$ unterstützt die Modi UTF8_TO_GEOS und GEOS_TO_UTF8.Rainer
-
du musst keine Zeichen tauschen. EM_DASH und EN_DASH werden im Mapping des Treibers korrigiert. Den PR dafür habe ich bereits eingereicht.
Wo sind denn die Zeichen irrtümlich vertauscht? In der Schriftdatei oder im Treiber-Code?
Es wäre ja vermutlich besser, die Schriftdatei korrekt aufzubauen anstatt Korrekturen in den Treiber einzubauen
-