Ich habe nach der Info von Jirka die Position 00A0 mit dem Zeichen "Obermenge von oder gleich" hinzugefügt dann war der Punkt verschwunden !
So einfach wenn man es weiss ! Danke nochmal an Jirka (00A0) und an Sebi (symbolps-zu-utf8.txt) für eure Hilfe ohne euch hätte ich das nicht geschafft !!
Ich hatte diese Woche Urlaub , deshalb bin ich froh dass das erledigt ist !
Neue Schriften sind gemergt !
Gruss von Nico
PS : Es ist auch dein FreeGEOS ! von Jika 
Ich stelle jetzt mal ne nur halb ernste gemeinte Frage: Was machen wir mir den leere Zeilen? Kann man die gewinnbringend nutzen und wenn ja, wie? Oder ist das Aufwand/Nutzen Verhältnis einfach nicht angemessen?
Rainer
Ich stelle jetzt mal ne nur halb ernste gemeinte Frage: Was machen wir mir den leere Zeilen? Kann man die gewinnbringend nutzen und wenn ja, wie? Oder ist das Aufwand/Nutzen Verhältnis einfach nicht angemessen?
Rainer
Die leeren Zeilen sind auch im originalen Font nur eben verstreut ! Die Fonts sollten möglichst original bleiben !
Nico
Die leeren Zeilen sind auch im originalen Font nur eben verstreut ! Die Fonts sollten möglichst original bleiben !
Das macht für vorhandene Zeichen und Rückwärts-Kompatibilität auch Sinn. Aber "leere" Zeichen sind ja in der Vergangenheit mit großer Wahrscheinlichkeit nicht genutzt worden und da könnte man ja jetzt nützliche Dinge unterbringen, oder?
Das macht für vorhandene Zeichen und Rückwärts-Kompatibilität auch Sinn. Aber "leere" Zeichen sind ja in der Vergangenheit mit großer Wahrscheinlichkeit nicht genutzt worden und da könnte man ja jetzt nützliche Dinge unterbringen, oder?
Hmm, das klingt verlockend, führt meiner Meinung nach aber trotzdem zu Inkompatibilität. Wenn du mit GeoWrite unter PC/GEOS 6 die ultimative Weltformel beschreibst, ist sie unter GEOS 2/3/4 nicht lesbar, falls du dafür die bisher leeren Zeichen mit verwendet hast.
Jedenfalls sollte man das Für und Wider genau abwägen, bevor solch eine tiefgreifende Änderung vorgenommen wird.
Was Bernd sagt!
Und konkret: Welches mathematische Zeichen braucht ihr denn unbedingt für die Weltformel, welches in SymbolPS derzeit fehlt?
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.
Ich glaube, wir sind uns alle einig, dass die Weiterentwicklung unseres kleinen PC/GEOS ne sehr sinnvolle Sache ist. 
Meiner Meinung nach ist aber die Dokument-Kompatibilität einer der "sensiblen Bereiche", bei denen man lieber zweimal überlegen sollte, welche Auswirkungen die Änderungen dort haben können.
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.
Die Inkompatibilitäten würden auch den Druck betreffen, denn es handelt sich ja nicht um einen beliebigen sondern den Symbolfont aus den 35 PostScript Standardschriften. Das heißt, dieser Font wird nicht auf den Drucker downgeloaded, weil er dort bereits im PS-ROM vorliegt.
Das heißt, dieser Font wird nicht auf den Drucker downgeloaded, weil er dort bereits im PS-ROM vorliegt.
Gäbe es dann nicht prinzipiell Probleme, wenn ein Zeichen in einem speziellen Symbol-Font (z.B. Windows) auf einer andere Stelle liegt, als in einem anderen (z.B. GEOS)? Also genau das Problem, was wir jetzt hatten?
Rainer
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 ein Zeichen in einem speziellen Symbol-Font (z.B. Windows) auf einer andere Stelle liegt, als in einem anderen (z.B. GEOS)? Also
Vielleicht sollte man in dieser Diskussion noch erwähnen, dass die fraglichen Symbole im original Type-1 (PS) Font schon an der selben Position liegen, wie sie in der GEOS-Zeichentabelle angezeigt werden. Erst bei der Konvertierung nach TrueType (oder auch Nimbus-Q) in FontMonger wird da was „verwürfelt“.
Bei Versuchen der Umwandlung in FontForge ist mir auch aufgefallen, dass dort als Export-Ziel explizit TrueType (Symbol) angeboten wird. Probiert man das aus, wird man gewarnt, weil Symbol-Fonts nur 1-Byte Indizes unterstützen würden. Das deutet möglicherweise darauf hin, dass diese in der Anwendung (GEOS/Windows) anders als von Jirka beschrieben zu behandeln wären. Das würde aus meiner Sicht auch Sinn machen, weil „allgemeine“ Symbole ja kaum eindeutige Bezeichner haben können.
Ich habe auch mal ausprobiert ein paar Formel mit Matrix, Integral und Schnickschnack in GEOS zu setzten. Das ist SEHR mühsam, weil man den Text ja über mehrere Zeilen verteilen muss und ggf. Tabs für eine exakte Ausrichtung (Matrix) braucht. Praktische Relevanz der ganzen Thematik ist für mich da eher fraglich.
PS: warum verwendet GEOS6 in der GEOS.INI eigentlich dezimale Werte für das Font-ID-Mapping, wo die Konstanten im Code doch im hexadezimal (FID_PS_<name>) definiert werden? Die Umrechnerei ist doch nur fehleranfällig.
Ich habe auch mal ausprobiert ein paar Formel mit Matrix, Integral und Schnickschnack in GEOS zu setzten. Das ist SEHR mühsam, weil man den Text ja über mehrere Zeilen verteilen muss und ggf. Tabs für eine exakte Ausrichtung (Matrix) braucht. Praktische Relevanz der ganzen Thematik ist für mich da eher fraglich.
So habe ich es aber gemacht, wen ich mal ne Formel innerhalb einer Zeile brauchte. Mit GeoDraw erstellte Formeln (das ist etwas weniger aufwändig) werden eben nicht zeilenmittig angezeigt. Deswegen steht ein Formeleditor schon seit ewigen Zeiten auf meiner Wunschliste ...
PS: warum verwendet GEOS6 in der GEOS.INI eigentlich dezimale Werte für das Font-ID-Mapping, wo die Konstanten im Code doch im hexadezimal (FID_PS_<name>) definiert werden? Die Umrechnerei ist doch nur fehleranfällig.
Wahrscheinlich ist es so: Das muss ja nur einmal gemacht werden, beim Erstellen der Mapping-Tabelle. Es gibt eine GEOS Funktion InitFilereadInteger(), die in der GEOS.INI eine dezimale Zahl erwartet, keine Hex-Zahlen. Hex-Zahlen würden also mehr Aufwand machen - Zeit, die der Treiber nicht hat.
dann ist SymbolPS keine 08/15-Symbolschrift, sondern die PostScript-Standard-Symbolschrift, also quasi selbst ein historischer Standard.
Ich bin bisher davon ausgegangen, dass die Schrift eingebettet wird. Dann wäre es wurscht. Aber nix genaues weiß ich nicht.
Rainer
Hi!
Bei „Symbol“ scheint es sowieso einige Merkwürdigkeiten zu geben: „Mapping of the angle bracket characters at 0xE1 and 0xF1 can vary. Adobe uses code points U+2329 and U+232A (〈 and 〉), whereas Apple uses U+3008 and U+3009 (〈 and 〉).“
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:
