Soweit ich weiß, wird die "Version.txt" nicht automatisch angelegt. Da kann man also reinschreiben, was man für gut und richtig hält. Aber vielleicht kann man eine automatische Erstellung implementieren?
Oder bin ich auf dem Holzweg?
Da müsste man Falk fragen , ob da was möglich ist mit Github ?
Gruss von Nico
Hallo zusammen.
Ich finde, mit den Fonts, die wir zur Zeit haben, sind wir ganz gut aufgestellt. Für Schriftverkehr, Tabellenkalkulation und andere Anwendungen sind diese Fonts meiner Ansicht nach vollkommen ausreichend. Wir sollten uns besser darauf konzentrieren, Fehler in den Zeichensätzen, wie sie jetzt kürzlich aufgetaucht sind, zu finden und zu beseitigen.
Ein anderes Thema ist die Darstellung auf dem Bildschirm. Dort ist meines Erachtens noch Luft nach oben. Wenn ich die Darstellung der Fonts in PC/GEOS 6 mit denen in Breadbox Ensemble 4.x vergleiche, gibt es da noch Unterschiede.
Die Darstellung auf dem Bildschirm ist in den Nimbusfonts in den originalen Fonts mit Bitmap bei kleiner Darstellung verbessert worden die fehlen natürlich in TTF das wäre eine mega Arbeit !
Sogar habe ich Test mit Umwandlung in FNT (Nimbus) mit MoreTools gemacht , finde in mehreren Punkten TTF besser , Jirka hat tolle Arbeit geleistet !!
Leider Fehlen in einigen Fonts Einige Zeichen die sind in den originalen Fonts nicht enthalten das ist aber ein Deseigner Job , da kenne ich mich nicht aus , meine Augen sind auch nicht die besten mehr!
Die Nimbus Fonts sind nun komplett da bin ich froh , nun haben wir die Geostabelle komplett in dem Hintingprogramm.
Gruss von Nico
Die Fonts Besley und Bodoni sollen nicht ins Build sollten nur nach github , aber mal sehen was Falk meint.
hanslse "Font Converter", that adapts the TTF fonts to Geos , no chance too complicate.
I have to copy characters and rename the character IDs manually.
@Jirka Font NYTFranklin in der Distribution ist noch unvollständig , ich bin leider kein Font designer !
Alle Zeichen sind im Font nur nicht gezeichnet !
10 Fonts im Build reichen !
Die Auswahl hat glaube ich Falk gemacht !
Copperplate CC Bold geht ohne Bearbeitung !
Gruss von Nico
Display MoreIch habe heute ein bißchen mit GEOS 6 und PS-Druck getestet. Für 3 der Schriften fehlt noch das ID-Mapping in der GEOS.INI:
---%<--------
[FontMapping]
;FID_PS_BOOKMAN - Bookman-Light
URWBoolman = 20504
;FID_PS_AVANTE_GARDE - AvanteGarde-Book
URWGothic = 21004
;FID_PS_PALATINO - Palatino-Roman
URWPalladio = 20490
---------------@Nico die Macher von Cooper*Black haben auch noch weitere tolle Fonts. Vielleicht magst Du die auch konvertieren:
;FID_PS_CLARENDON - Clarendon
Besley* = 20513
;FID_PS_BODONI - Bodoni-Book 16 points
Bodoni* = 20482Jost* als Futura-Ersatz ist wohl nicht free. Unter den Cowboy Fonts gibt es mit Copperplate CC auch einen schönen Copperplateverschnitt unter SIL lizensiert.
Fonts Besley* und Bodoni 16pt in Github hinzugefügt , aber noch nicht in FreeGeos hinzugefügt.
Mapping habe ich als getrennten PR erstellt.
Z003 FontID (ZapfChancery Z003) ???
Gruss von Nico
Ich habe ein original ZIP hatte die aus den Disketten erstellt.
Von Nico
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
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 
Jirka brachte die Lösung des geheimnisvollen Punkts : 00A0 fehlte im Font !
Da hätte ich noch lange suchen können ! UFF Danke !
Ich war echt am Aufgeben !
Gruss von Nico
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!
Positionen CB bis FF: müßten alle eine Position nach links rücken (da der Punkt in CA wegfällt)
Durch das verschieben des Symbols "Seite liegende U mit dem Unterstrich* an freie Position rücken die restlichen Zeichen an die richtige Position.
Position F7 (eig. F6): da fehlt eine Klammer
Gruss von Nico
Dieser Punkt CAhex verschiebt die restlichen Zeichen der Punkt ist aber nicht im Program mit dem ich den Font bearbeite :
Das einzige was noch hift ist dieses Zeichen zu versetzen damit die restlichen Zeichen nach vorne rücken.
Klammern klappt:
Gruss von Nico
nschu Sehr cool! Allerdings sind die Zeichen in den letzten drei Zeilen noch eine Position zu weit rechts. Ursache ist das als Punkt dargestellte Zeichen auf Position 0xCA. Dort gehört das auf der Seite liegende U mit dem Unterstrich hin, das jetzt rechts davon ist. Dann rutschen die anderen Zeichen (Hoffentlich) nach.
Ich halte die Kompatibilität der Zeichensätze zu älteren Dokumenten für extrem wichtig. Deswegen bin ich dir wirklich dankbar Nico, dass du dich da so reinhängst! Ich würde es echt blöd finden, wenn ich mir die Arbeit gemacht hätte, eine Formel mit dem Symbol-Font zusetzen und dann meinen Schülern sagen müsste (nur als symbolischen Beispiel) "Stellt euch vor, diese Blume hier ist jetzt ein Pfeil nach rechts".
Unter URW Symbol gehören immer 3 nebeneinander stehende Zeichen zusammen (hier in einem GeoWrite Dokument). Der scheinbar zusätzliche Strich auf 0xEF dient dazu, die geschweiften Klammern zu verlängern.
Die Datei dazu hängt dran.
LG
Rainer
Leider hast du recht die Adressen scheinen anders zu sein.
Mit URW Symbols gespeichert und in FreeGeos bringt es Zeichen 00C3 anstatt 00D5 dies liegt ein Platz davor !
Weiss nicht weiter , es gibt 2 Fehler Adresse CAhex (312okt) und F0hex (360okt)
Deshalb verschieben sich die Plätze wahrscheinlich!
Könnte das ein Problem des Treibers sein @Jirka ?
Gruss von Nico
Alle Zeichen im Font , nur 2 Punkte kann ich nicht lösen.
Gruss von Nico
Gruss von Nico
Hier nun der Nimbus Sans überarbeitet mit Fix von Jirka !
Habe nun doch mit Autohint wie vorher gemacht , das sieht besser aus !
Gruss von Nico
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
Die sind aber richtig in den originalen Fonts , und ist eine manuelle Bearbeitung die sehr kompliziert ist und auch noch Fehleranfällig !
Ich werde mal den Font Nimbus Sans anpassen !
Gruss von Nico
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
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
Also, ich finde die ausführliche Abfrage schon in Ordnung. Und das "wirklich" nehme ich raus. Kann aber auch derjenige machen, der es nach github hochlädt.
Ich habe das "wirklich" entfernt und nach github hochgeladen , PR erstellt.
Gruss von Nico
Der Wechselkurs ist Teil der Berechnung das kann ich nicht so einfach ändern. Das Update gilt dem DynamicList !
Es sollte anders werden es gibt aber ein Bug im DynamicList sagt Falk deshalb testete ich dieses , von der Bedienung denke ich ist es einfacher ! In der Liste kann man auch mit Rauf und Runter wählen.
Gruss von Nico
