Posts by sebi

Zudem sind die Benutzerebenen eine Geos-Besonderheit und können daher ruhig erhalten bleiben. Auch wenn sie evtl. wenig genutzt werden, besteht ja keine Not, sie abzuschaffen.

Ich habe soeben auch noch eines der begehrten Mühlenzimmer ergattert

Na dann sind ja die (meisten) Entscheidungen gefallen :).

Der Menüpunkt „Write Source Code“ ist ebenfalls ohne Bindestrich.

Ja, die richtigen Namen zu finden, dauert manchmal länger als die Programmierung

Feinsemantischen Gedanken über die Stärke der Verbindungen bei Set und Group würde ich mich nicht hingeben, beide sind sich so ähnlich, daß es für eine UI genügt, ist ja keine philosophische Hausarbeit.

Ich würde dann schon eher überlegen, ob auch einem englischen Muttersprachler die möglichen Begriffe als verschieden bzw. gleich gut geeignet erscheinen. Es werden ja nicht alle Begriffe, auch wenn sie ähnlich sind, in jedem Kontext verwendet. Frag doch einfach mal die englischen Leute in der Discord-Gruppe und stell die Alternativen zu Abstimmung :-). Die könnten dann auch abstimmen, ob mit oder ohne Bindestrich.

Quote from MeyerK

Wenn ich es mir jetzt noch mal so betrachte (die Bindestriche machen mich wahnsinnig, vor allem im Englischen)... warum nicht eigentlich nur "Set" oder "Group" oder sowas? Dass es um Icons geht, ist ja klar...

Die Bindestriche hatten mich auch gepiekst, wollte aber nicht so kleinlich sein

Im Englischen würde ich die Striche auch nicht setzen, im Deutschen schon.
Da hast du recht, es liest sich schwerfällig, wäre leichter mit nur einem Wort. Dafür ist es exakt! Einen Tod muß man …

Ich würde versuchen, Begriffe zu finden, die die hierarchische Beziehung abbilden. So versteht man das Ganze sofort.

Also etwa „Icon-Gruppe“ oder „Icon-Set“ (was jetzt Icon ist) und einfach Icon, für was jetzt „Format“ ist.

Quote from Wilfried

Emulator: DosBox unter W10

Code

double round(double zahl1,byte zahl2)
{
  double zahl3;
  FloatIEEE64ToGeos80(&zahl1);
  FloatRound(zahl2);
  FloatGeos80ToIEEE64(&zahl3);
  return(zahl3);
}

round(3.86,1) ergibt 3.9
round(3.86,0) ergibt 3
round(-3.86,1) ergint -4
round(3.86,0) ergibt -3

Mit Watcom compiliert

Display More

Das schweift zwar ab, aber ich hätte trotzdem eine Verständnisfrage zu diesem Code: Macht der überhaupt irgendwas?

Die Variable zahl3, die von der Funktion zurückgegeben wird, wird ja nirgends (explizit) belegt.

Oder passiert das alles indirekt?

• FloatIEEE64ToGeos80() speichert zahl1 irgendwo
• FloatRound() rundet zahl1 auf die mit zahl2 angegebene Zahl von Nachkommastellen
• FloatGeos80ToIEEE64() fischt die gerundete zahl1 aus den nebulösen Speicheruntiefen heraus und gibt sie als zahl3 zurück

Sieht so native Geos-Programmierung aus?

Quote from Mütze

Bei mir tritt der Effekt (ich schreibe jetzt mal nicht "Fehler" ;-)) unter BBX 410, BBX 413 und PC/GEOS6 auf.

Interessant. Meinen Beitrag hatte ich mit Rainers Hinweis im Kopf, daß der Effekt (sic!) nur unter Geos 6 auftrete, verfaßt.

Wenn er bei dir immer auftritt, dann … klingt es ja noch komplizierter. Wird Zeit, daß sich Falk mal einschaltet

Aber wenn das Verhalten unter BBX 4 und Geos 6 verschieden ist, dann kann ein fehlerhafter Irrtum nicht ausgeschlossen werden und es sollte idealiter nach den Ursachen gegründelt werden.

Rainer,

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.

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.

Quote from Jirka Kunze

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.

Quote from Jirka Kunze

Hallo Sebastian,

deine Ausführungen sind korrekt. Ab da du es sicher ganz genau wissen willst hier noch zwei Ergänzungen:

Unbedingt

Quote from Achim

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.

Quote from Bario

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.