Ich wundere mich - die anderen Fonts sind (für mich) weitgehend nutzlos, und ausgerechnet der Vector-Font scheint einige wichtige Glyphen nicht implementiert zu haben...
Ist es tatsächlich so, dass das 
fehlt? Wenn ja: Wird das mal nachgereicht?
Ich wundere mich - die anderen Fonts sind (für mich) weitgehend nutzlos, und ausgerechnet der Vector-Font scheint einige wichtige Glyphen nicht implementiert zu haben...
Ist es tatsächlich so, dass das fehlt? Wenn ja: Wird das mal nachgereicht?
Hi Giorgio,
gerne.
Jo, manchmal muss man leider "zu Fuß gehen".
Ist wohl die einfachste Art, sich fortzubewegen. 
Ähnlich ist wohl EAGLE:
"EINFACH ANZUWENDENDER GRAPHISCHER LAYOUT EDITOR"
Gerald
---
Am 15.12.2016 um 18:01 schrieb Giorgio Avanti:
In jeder Hinsicht die Bedienung und damit das Rad neu erfunden.
Nicht »neu erfunden« — vorher schon da gewesen.
Eagle ist älter als Windows; zu DOS-Zeiten mussten alle grafischen
Programme ihre GUI und Konventionen selber machen. Und davon waren
manche super bedienbar, Eagle ganz ordentlich, AutoCAD aber war IMHO
damals grausig, als das schlimmste ist mir Bartels in Erinnerung.
Würde Eagle hart auf heutige Konventionen umgestellt, würden alle
alterfahrenen Anwender aufschreien. Mir sind ja schon all diese
unidentifizierbaren Icons zu doof, zum Glück gibts noch die alphabetisch
sortierten Textmenüs.
Allerdings, Fonts und Zeichensätze… die könnten wirklich mal dem
aktuellen Jahrtausend angepasst werden! (Aber als Entwickler nicht
vergessen: Leiterplatten-Belichter und Truetype-Fonts spielen noch
keineswegs immer problemlos zusammen, der Vektorfont hat sehr wohl seine
Berechtigung. und 
und Ω etc. vermisse ich darin auch sehr.)
Liebe Grüße, Hans
Mea Culpa, da hast du natürlich auch recht, was die Historie angeht. Bloß:
Ganz gelten lassen mag ich's aber nicht. Es ist ja nicht nur so, dass vieles jedweder heute sonst so geläufigen Arbeitsweise zuwider läuft, es sind auch einfach Funktionen, ohne die ich als Anwender nicht mag. Vernünftige Gruppen fallen mir da ein. Rotationen, Translationen etc mit wechselnden Points of Interest. Verschiedene Farben für verschiedene Netze. Ansichtsmodi. ... Ich hab zum ersten Mal vor ca 10 Jahren mit der Software gearbeitet, und bin erschrocken, dass die Bedienung noch gleich ist. Altanwender muss man nicht vergraulen: CAD- und 3D-Software hat des öfteren mehrere parallele Bedienkonzepte, ja sogar die Möglichkeit zu den bekannten aus anderen Programmen zu wechseln.
Wie dem auch sei: Ich möchte da ganz egoistisch etwas in Händen halten, bald, das schnelleres, präziseres, zeitgemäßeres Arbeiten ermöglicht, Änderungen nicht unkalkulierbar macht und na-das-wär-doch-was auch noch nett aussieht vielleicht. Dabei geht's mir nicht um das Alter: Mach 3 ist auch ne Omma unter den Programmen, aber logisch, übersichtlich, bedienbar. Was älteres fällt mir grad nicht ein, das auf dem Stand verharrte. 
Von TTF war übrigens nie die Rede. Im Gegenteil bin ich absoluter Fan eines einzelnen, funktionierenden Vektorfonts. Nochmal lesen was ich schrieb.
Danke jedenfalls für euren Trost. Ich warte, weiter.
Hans Lederer wrote:
Am 15.12.2016 um 18:01 schrieb Giorgio Avanti:
In jeder Hinsicht die Bedienung und damit das Rad neu erfunden.
Nicht »neu erfunden« — vorher schon da gewesen.
Eagle ist älter als Windows; zu DOS-Zeiten mussten alle grafischen
Programme ihre GUI und Konventionen selber machen. Und davon waren
manche super bedienbar, Eagle ganz ordentlich, AutoCAD aber war IMHO
damals grausig, als das schlimmste ist mir Bartels in Erinnerung.
Würde Eagle hart auf heutige Konventionen umgestellt, würden alle
alterfahrenen Anwender aufschreien. Mir sind ja schon all diese
unidentifizierbaren Icons zu doof, zum Glück gibts noch die alphabetisch
sortierten Textmenüs.
Allerdings, Fonts und Zeichensätze… die könnten wirklich mal dem
aktuellen Jahrtausend angepasst werden! (Aber als Entwickler nicht
vergessen: Leiterplatten-Belichter und Truetype-Fonts spielen noch
keineswegs immer problemlos zusammen, der Vektorfont hat sehr wohl seine
Berechtigung.
Die Glyphen im Font sind das eine, ihre Codierung kann aber auch
Probleme verursachen. Bei Unicode gibt es z.B. für 'Ω' zwei ver-
schiedene Codepoints, die beide äquivalent sind - aber eben ver-
schieden codiert. Für Umlaute gibt es einzelne Codepoints und
Codepoint-Sequenzen die Unicode als äquivalent definiert.
Beispiele: ä, ä, Ω, Ω
Insbesondere bei Bezeichnern wie Bauteilnamen muss man da aufpassen
bzw. kann auf die Schnauze fallen.
Hans Lederer wrote:
Am 15.12.2016 um 18:01 schrieb Giorgio Avanti:
In jeder Hinsicht die Bedienung und damit das Rad neu erfunden.
Nicht »neu erfunden« — vorher schon da gewesen.
Eagle ist älter als Windows; zu DOS-Zeiten mussten alle grafischen
Programme ihre GUI und Konventionen selber machen. Und davon waren
manche super bedienbar, Eagle ganz ordentlich, AutoCAD aber war IMHO
damals grausig, als das schlimmste ist mir Bartels in Erinnerung.
Würde Eagle hart auf heutige Konventionen umgestellt, würden alle
alterfahrenen Anwender aufschreien. Mir sind ja schon all diese
unidentifizierbaren Icons zu doof, zum Glück gibts noch die alphabetisch
sortierten Textmenüs.
Allerdings, Fonts und Zeichensätze… die könnten wirklich mal dem
aktuellen Jahrtausend angepasst werden! (Aber als Entwickler nicht
vergessen: Leiterplatten-Belichter und Truetype-Fonts spielen noch
keineswegs immer problemlos zusammen, der Vektorfont hat sehr wohl seine
Berechtigung.
Die Glyphen im Font sind das eine, ihre Codierung kann aber auch
Probleme verursachen. Bei Unicode gibt es z.B. für 'Ω' zwei ver-
schiedene Codepoints, die beide äquivalent sind - aber eben ver-
schieden codiert. Für Umlaute gibt es einzelne Codepoints und
Codepoint-Sequenzen die Unicode als äquivalent definiert.
Beispiele: ä, ä, Ω, Ω
Insbesondere bei Bezeichnern wie Bauteilnamen muss man da aufpassen
bzw. kann auf die Schnauze fallen.
Am 16.12.2016 um 15:38 schrieb Michael Bäuerle:
Hans Lederer wrote:
Die Glyphen im Font sind das eine, ihre Codierung kann aber auch
Probleme verursachen. Bei Unicode gibt es z.B. für 'Ω' zwei ver-
schiedene Codepoints, die beide äquivalent sind - aber eben ver-
schieden codiert. Für Umlaute gibt es einzelne Codepoints und
Codepoint-Sequenzen die Unicode als äquivalent definiert.
Beispiele: ä, ä, Ω, Ω
Insbesondere bei Bezeichnern wie Bauteilnamen muss man da aufpassen
bzw. kann auf die Schnauze fallen.
Nun ja, in Unicode gibt es soo viele Zeichen, da kann schon Verwirrung
auftreten. Da meine ich, wer »exotische« Zeichen benutzen will, der
muss halt auch selber wissen, was er tιρρτ.
Aber ganz bin ich mit deinen Beispielen nicht einig, Michael: dein
zweites ä sind eigentlich zwei Zeichen, ein normales a plus ein ̈
U+0308 Trema bzw. combining diaeresis. Da wüsste ich nicht, wie man das
„versehentlich“ erzeugen sollte, das wird doch sicher bei der Eingabe in
ein anständiges ä U+00E4 gewandelt. Hoffe ich mal.
Das große griechische Ω U3FF und das Ohm-Zeichen Ω U2126 sind
definitiv zweierlei Unicode-Zeichen. Sie sind nur in vielen Fonts mit
derselben Glyphe gezeichnet, ist ja ok, oder es gibt fürs Ohm gar keine,
so dass man notdürftig aufs große Omega ausweicht.
Ähnlich das „echte“ Durchmesser-Zeichen ⌀ U+2300, das es in vielen Fonts
leider auch nicht gibt, so dass man halt in der Not oder aus
Unwissenheit das kleine ø U00F8 oder große Ø U00D8 missbraucht.
Wie gesagt, wer die nutzen will, muss auch selber Bescheid wissen. Aber
geben sollte es sie! In Bezeichnern würde ich auf Sonderzeichen
vorsichtshalber verzichten — aber Kleinbuchstaben möchte ich dort schon
endlich mal haben!
Hans
Hans Lederer wrote:
Am 16.12.2016 um 15:38 schrieb Michael Bäuerle:
Hans Lederer wrote:
Die Glyphen im Font sind das eine, ihre Codierung kann aber auch
Probleme verursachen. Bei Unicode gibt es z.B. für 'Ω' zwei ver-
schiedene Codepoints, die beide äquivalent sind - aber eben ver-
schieden codiert. Für Umlaute gibt es einzelne Codepoints und
Codepoint-Sequenzen die Unicode als äquivalent definiert.
Beispiele: ä, ä, Ω, Ω
Die sollten nun nicht mehr verschieden sein, da mein Newsreader den Text
vor dem Versand gemäß RFC 5198 normalisiert. Das ist jetzt Unicode
Normal Form C.
Insbesondere bei Bezeichnern wie Bauteilnamen muss man da aufpassen
bzw. kann auf die Schnauze fallen.
Nun ja, in Unicode gibt es soo viele Zeichen, da kann schon Verwirrung
auftreten. Da meine ich, wer »exotische« Zeichen benutzen will, der
muss halt auch selber wissen, was er tιρρτ.
Das Problem ist, dass in der Elektronik gebräuchlichen Zeichen wie
'Ω' oder 'µ' in Unicode unintuitiv behandelt werden. So sind im Gegen-
satz zu den Beispielen oben die Zeichen µ (U+00B5 'MICRO SIGN') und
μ (U+03BC 'GREEK SMALL LETTER MU') nicht als äquivalent definiert.
Man muss also nicht nur wissen was man tippt (was für Codepoints das
ergibt), sondern auch wie sich diese bei Unicode verhalten.
Aber ganz bin ich mit deinen Beispielen nicht einig, Michael: dein
zweites ä sind eigentlich zwei Zeichen, ein normales a plus ein ̈
U+0308 Trema bzw. combining diaeresis. Da wüsste ich nicht, wie man das
„versehentlich“ erzeugen sollte,
Unicode erlaubt diverse Zeichen deren Glyphe nicht mit einem Codepoint
darstellbar ist. So einen Zusammenhang zu unterstellen ist bei Unicode
per Definition nicht zulässig. Man muss immer damit rechnen, dass eine
Sequenz von Codepoints nur eine einzelne Glyphe ergibt.
Insbesondere auf Apple-Systemen ist die zerlegte Variante auch nicht
exotisch (wird dort z.B. im Dateisystem für Namen verwendet).
das wird doch sicher bei der Eingabe in
ein anständiges ä U+00E4 gewandelt. Hoffe ich mal.
Es gibt da kein "anständig". Unicode definiert beides als "canonically
equivalent", d.h. man darf beides verwenden, muss beim Empfang mit
beidem rechnen und in jedem Fall sollte beides gleich angezeigt werden
und sich auch sonst gleich verhalten (z.B. beim suchen, vergleichen,
etc.).
Das große griechische Ω U3FF und das Ohm-Zeichen Ω U2126 sind
definitiv zweierlei Unicode-Zeichen. Sie sind nur in vielen Fonts mit
derselben Glyphe gezeichnet, ist ja ok, oder es gibt fürs Ohm gar keine,
so dass man notdürftig aufs große Omega ausweicht.
Nein, es sind eben nicht wirklich verschiedene Zeichen, sondern nur
verscheidene Codepoints. Einer ist hier eine "singleton decomposition"
des anderen Codepoints.
Unicode möchte dafür auch explizit die gleiche Glyphe haben:
|
| Canonical equivalence is a fundamental equivalency between characters
| or sequences of characters which represent the same abstract
| character, and which when correctly displayed should always have the
| same visual appearance and behavior.
^^^^^^^^^^^^^^^^^^^^^^
Siehe hierzu auch Unicode Annex 15:
<http://www.unicode.org/reports/tr15/>
Ähnlich das „echte“ Durchmesser-Zeichen ⌀ U+2300, das es in vielen Fonts
leider auch nicht gibt, so dass man halt in der Not oder aus
Unwissenheit das kleine ø U00F8 oder große Ø U00D8 missbraucht.
Wie gesagt, wer die nutzen will, muss auch selber Bescheid wissen. Aber
geben sollte es sie! In Bezeichnern würde ich auf Sonderzeichen
vorsichtshalber verzichten — aber Kleinbuchstaben möchte ich dort schon
endlich mal haben!
Ja, die wären in dieser Hinsicht auch nicht problematisch.
