ja, die Änderungen sollten auch dort nachvollzogen werden, damit alles schön synchron bleibt.
Da bin ich bereits dran, sind ja auch noch ein paar andere Punkte von damals 
offen. Schicke ich dir dann alles zu, brauch aber noch etwas.
Posts by sebi
-
-
Hallo,
vor einer kleinen Weile wurde hier im Forum ja über die Zeichenbelegung der Geos-Schrift SymbolPS diskutiert, wozu ich eine Liste mit den passenden Unicode-Zeichen beisteuerte.Diese Liste hatte ich vor über drei Jahren (!) nach bestem Wissen und Gewissen selbst zusammengestellt, indem ich die Unicode-Verzeichnisse nach passenden Zeichen abklapperte.
Angefeuert durch das Déjà vu habe ich diese Zuordnung noch einmal überprüft. Diesmal stand mehr Material zur Unterstützung bereit: Kodierungslisten von Adobe und Apple sowie die Adobe-PostScript-Dokumentation.Dabei ergab sich zum Einen, daß sensationelle 96,5 % der Zeichen korrekt den Unicode-Codepoints zugeordnet sind
. Lediglich bei neun Zeichen ergab sich eine Änderung der Unicode-Codepoints. Diese Anpassungen und weitere Informationen sind in der anhängten HTML-Datei beschrieben.(Diese Datei hatte ich urspr. nur erstellt, um mir die verschiedenen Zeichen anzeigen zu lassen und Infos festzuhalten. Ist daher wieder eher funktional statt schön.)
Am überraschendsten waren Ascii-Zeichen, die in Wirklichkeit ähnlich aussehende mathematische Operatoren (*, Minus, ~) sind, und die Wurzelzeichenverlängerung, die ich als das häufig vorkommende diakritische Zeichen Makron mißdeutete. Hier gibt es auch keine gute Lösung, da das Verlängerungszeichen in Unicode nicht existiert.
Leider habe ich diese Berichtigungen erst jetzt nachträglich gefunden. Vielleicht ist es ja trotz des Zusatzaufwandes möglich, diese Änderungen zu übernehmen, damit auch bei den neuen Schriften die bestmögliche Qualität erreicht wird.
Da ich die bisherige SymbolPS-Diskussion nicht mehr gefunden habe, eröffne ich ein neues Thema.
Schöne Grüße!
PS: Die angehängte Datei SymbolPS.txt bitte in SymbolPS.html umbenennen. Die Änderung war zum Hochladen nötig.
-
Bei Bedarf kann ich darüber auch auf den nächsten GEOS-Treffen referieren:-)
Unbedingt
Ich fände es sowieso interessant, neben den allgemeinen Vorträgen auch spezifischere, die (etwas) tiefer in bestimmte technische Themen eintauchen, anzubieten. Die wären dann wsl. nicht mehr für jeden interessant, aber würden auch einen Wissensaustausch ermöglichen und so die Geos-Treffen um einen Aspekt erweitern.
Allerdings könnte es schwierig werden, mehr Vorträge zeitlich unterzubringen. Und die entsprechende Zeit fehlt dann beim (gemeinsamen) Arbeiten. Muß man vielleicht vor Ort operativ entscheiden.
-
Hallo Sebastian,
deine Ausführungen sind korrekt. Ab da du es sicher ganz genau wissen willst hier noch zwei Ergänzungen:
Unbedingt
-
Was heißt das genau, die Darstellung mit Bitmaps zu verbessern? Was wäre da zu tun? Ich kann mich dunkel erinnern, das davon schon einmal die Rede war.
Vom Hörensagen gefüttert würde ich es so beschreiben (bitte korrigieren, falls fehlerhaft):
- Die Schrift selbst ist in Form von Vektordaten beschrieben, kann also gut über viele Größen skaliert werden.
- Für die Darstellung auf dem Bildschirm muß die Vektorbeschreibung eines Buchstaben bzw. Zeichens in Bildschirm-Pixel umgerechnet werden (Rasterisierung).
- Insbesondere bei kleinen Schriftgrößen, wenn jedes Zeichen nur wenige Pixel umfaßt, ist es schwierig, eine automatische Lösung zu konstruieren, die (schnell) gut lesbare Ergebnisse liefert. Soll nun das Pixel links oder rechts der Linie ausgefüllt werden?
- Für bessere Ergebnisse hat wohl GeoWorks damals für ihre Systemschriften für kleine Größen Bitmap-Schriften erstellt, bei denen also die Aufteilung der Zeichen auf Pixel schon erfolgt ist. Die Pixel-Darstellung wurde wohl handoptimiert, das hilft ungemein bei komplexeren Zeichen oder Buchstaben mit Akzenten: ä, á, à, å.
- Ein Nebeneffekt könnte gewesen sein, daß Bitmap-Schriften (potentiell) auch schneller dargestellt werden können, da die Rasterisierung entfällt (was aber evtl. wegen Caching u.ä. kein besonders starker Effekt war).
-
Spannende Seite! Da gibt’s z.B. Verlinkungen zu einigen recht exotischen Zeichensätzen, wie dem DEC Technical Character Set. Wieder neues Lesefutter gefunden :). Besten Dank!
Auf der Seite ist ja der Symbol-Zeichensatz dargestellt mit direkter Verlinkung der Zeichen zu ihren Wikipedia-Artikeln. Bei den eckigen Klammern steht zu der angesprochenen Verwirrung:
„The angle brackets or chevrons U+27E8 ⟨ MATHEMATICAL LEFT ANGLE BRACKET and U+27E9 ⟩ MATHEMATICAL RIGHT ANGLE BRACKET are for mathematical use and Western languages, whereas U+3008 〈 LEFT ANGLE BRACKET and U+3009 〉 RIGHT ANGLE BRACKET are for East Asian languages. The chevrons at U+2329 and U+232A are deprecated in favour of the U+3008 and U+3009 East Asian angle brackets. Unicode discourages their use for mathematics and in Western texts,[15] because they are canonically equivalent to the CJK code points U+300n and thus likely to render as double-width symbols.“
Ich verstehe das so:
- 2329 und 232A soll man nicht mehr verwenden
- 3008 und 3009 sind für ostasiatische Sprachen
- 27E8 und 27E9 sind für Mathematik und westliche Sprachen einzusetzen
-
Der gute, alte Norton Commander
-
Aber wenn Thomas mit seinem Hinweis recht hat – woran es keinerlei Zweifel gibt und worauf jeder ordentliche Pirat sein Holzbein verwetten würde – dann ist SymbolPS keine 08/15-Symbolschrift, sondern die PostScript-Standard-Symbolschrift, also quasi selbst ein historischer Standard. Gerade diese Schrift würde ich nun nicht verändern, sondern eher bei Bedarf eine neue erstellen. Und solange niemand konkrete Zeichen nennt, die ihm fehlen, ist das ja eh eine theoretische Diskussion.
-
Wenn ich Rainers Frage richtig verstanden habe ging es ja nicht darum, dass ihm bestimmte Zeichen fehlen, sondern das ungenutzter Platz vorhanden ist und ob dort etwas hin könnte.
Soweit muss es aus meiner Sicht mit der Kompatibilität nicht gehen, dass ein neu eingeführtes Symbol im Symbolfont des neuen FreeGEOS rückwärts auch in Geos 2.0 verfügbar sein muß. Solche Vorbehalte würden ja jegliche Weiterentwicklung verbieten.
Platznutzung ist klar, ich hatte nur konkret gefragt, denn falls niemandem ein Zeichen fehlt, das man dort einfügen könnte, dann hätte sich die Fragestellung schon einfach erledigt
Kommt halt darauf an, was man für Zeichen einfügen will (da sind wir wieder bei der Frage). Sind es mathematische Zeichen, dann würden sie in den SymbolPS passen, aber wenn z.B. um Emojis oder Altjapanisch geht, dann wäre vielleicht eine komplett neue Schriftart passender. Solange es nicht ganz dringend ist, würde ich dafür plädieren, die Rückwärtskompatibilität möglichst zu wahren.
-
Was Bernd sagt!
Und konkret: Welches mathematische Zeichen braucht ihr denn unbedingt für die Weltformel, welches in SymbolPS derzeit fehlt?
-
Schön, daß ihr die fragliche Stelle gefunden habt! Irgendwas mußte ja faul sein.
Aber das interessiert mich jetzt doch mal: Was fehlte da? Auf den Screenshots sah die A-Reihe ja immer vollständig aus, mit dem Punkt auf Position A0.
-
Hallo Jirka!
Die technischen Details sind doch das Spannendste, das Salz in der Suppe, die Kirsche in der Sahne :).
Da hätte ich noch ein paar kleine Fragen:
- Der 16-Bit-Code, in den der Geos-Char-Code gewandelt wird, wäre dann zufällig UTF-16?
- Dann erwartet dein TrueType-Subsystem also nicht, daß die TTF-Schriften genauso wie die bisherigen Geos-Schriften aufgebaut sind (also 256 festgelegte Zeichen), sondern es sucht sich die passenden selber aus der (u.U. viel größeren oder auch kleineren?) TTF-Datei?
- In der CMAP-Tabelle steht also, welchem Unicode-Zeichen jedes Schriftzeichen der Schriftdatei entspricht? Was ist, wenn die CMAP fehlt? Haben denn auch uralte TTF-Schriften schon die Unicode-Zuordnung?
Besten Dank für eventuelle (technische) Antworten
-
Den Satz mit C3 und D5 verstehe ich leider nicht.
Würde Rainer beipflichten, daß der Punkt in CA zu viel ist und sich dadurch die Folgezeichen verschieben. Außerdem scheinen noch an anderen Stellen Zeichen zu fehlen.
Wenn ich einfach nur Rainers und deinen Screenshot rein optisch (!) vergleiche, fallen mir diese Unterschiede auf: (Hoffe, ich habe mich bei den Positionen nicht verzählt. Dies sind die Positionen auf deinem Bild.)
- Position 4F: Fehlt eine Art Unterstrich?
- Position B5: die teilweise Unendlichkeit fehlt.
- Position CA: Der Punkt kommt weg.
- Positionen CB bis FF: müßten alle eine Position nach links rücken (da der Punkt in CA wegfällt).
- Position F0 (eig. EF): da fehlt eine Klammer
- Position F6 (eig. F5): da fehlt der untere Teil des Integrals
- Position F7 (eig. F6): da fehlt eine Klammer
Grüße!
-
habt ihr euch bei der Gelegenheit auch mal den Symbol-Font angesehen?
Ja, für unsere Exporte hatte ich damals auch Übersetzungstabellen von Symbol PS zu UTF-8 erstellt. War ganz schön fummlig.
Hier die Exportdatei. Nochmal ein Stückchen unübersichtlicher, da etliche Zeichen im Zeichensatz mehrfach vorkommen, das steht dann als Meldung da. Außerdem sind die Zeichen aus dem Ascii-Bereich, die den Ascii-Zeichen entsprechen, nicht aufgeführt (es stehen also nur die Ascii-Ausnahmen drin).
Vielleicht hilft es ja trotzdem.
-
Eine Zeichentabelle GEOS UNICODE wäre hilfreich hat jemand sowas ?
Ja, habe ich, aber leider nicht in schön
.Habe mal die Textdatei angehängt, die ich für unsere Konvertierungsarbeiten mit Rainer benutzt habe. Sieht vielleicht erstmal verwirrend aus, aber für dich wären nur wenige Spalten interessant.
Einige Anmerkungen dazu:
- Ist eine Textdatei im UTF-8-Format.
- Spalte "Quelle": der Hex-Code des Geos-Zeichens
- Spalte "Quelle UTF-8": der Hex-UTF-8-Code des Geos-Zeichens
- Spalte "Z": Darstellung des Zeichens
- Spalte "Beschreibung": Name des Zeichens
Alternativ kannst du auch die Zeichenpalette MacRoman https://de.wikipedia.org/wiki/Macintosh_Roman nutzen. Die bietet auch gleichzeitig eine schöne Übersicht und man kommt schnell an den Hex-Code jedes Zeichens.
Geos hat den Zeichensatz vom Mac fast identisch übernommen. Die Ausnahmen:- Zeichen DE und DF: sind in Geos y´ und Y´ (die lassen sich hier nicht korrekt eingeben?!), auf dem Mac die Ligaturen fi und fl
- Zeichen F0: in Geos nicht definiert, auf dem Mac der Apfel
Viel Erfolg
! -
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
-
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.
-
Bei den Textexporten, die ich mal in Bernds Editor eingebaut hatte, begann ich damals auch mit einem PDF-Export. Es wurden dann valide PDFs mit ein paar Textzeilen erstellt
.Die PDF-Grundstruktur geht eigentlich, aber die Formatspezifikation ist einfach so umfangreich, daß es a) einfach unglaublich viel Arbeit ist und b) es zahllose Details gibt, hinter denen die Teufelchen hocken.
Ein großes Problem ist die Wysiwig-Darstellung. Dazu müßten nämlich die in Geos verwendeten Schriften im PDF eingebettet werden. Was inzwischen eh zum guten Ton gehört. Das könnte einfacher werden, falls es mit Geos und den TTF-Schriften klappt. Damals hatte ich einfach die Basisfunktionalität genutzt und im PDF definiert: Serifen-Schrift, 12 pt. Da sucht sich das PDF-Anzeigeprogramm dann eine vorhandene Schrift aus.
-
Das phantastische Bildinfos bietet – natürlich – beide Möglichkeiten. Es erlaubt sogar, die Transparenzschwelle zu wählen.
-
So habe ich das bei Bildinfos auch umgesetzt, wenn Bilder mit 8-Bit-Transparenz importiert werden, aber Geos nur 1-Bit-Transparenz beherrscht.
Im Prinzip legt man die Hintergrundfarbe fest. Je transparenter ein Pixel ist, um so stärker scheint der Hintergrund durch. Die passende Hintergrundfarbe hängt vom Bildinhalt ab – Weiß paßt oft, beim MeyerK-Beispielbild wäre Schwarz besser, aber auch jede andere Farbe ist (theoretisch) möglich.
