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?
Hans Lederer wrote:
Am 16.12.2016 um 15:38 schrieb Michael Bäuerle:
Hans Lederer wrote:
und und Ω etc. vermisse ich darin auch sehr.)
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.
Hi,
ein Gedanken wollte ich noch hinzufügen.
Man sollte trennen, bzw. unterscheiden, ob die Beschriftung
auf der Platine, oder im Schaltplan gemacht wird.
Auf der Platine, "worum geht es normaler Weise?" - eben, um Leiterbahnen
und Bauteilbestückung. Hier braucht man ja normal keine Sonderzeichen,
nicht mal das Ohm-Zeichen.
Anders ist es sicherlich im Schaltplan, bzw. gesamten Dokumentation.
Hier wäre im Prinzip eine Vektorschrift nicht notwendig.
Vektorschrift wäre nur auf der Platine wichtig, für den HPGL-Plotter, weil es besser ist zu flashen.
Also, einfach einen heutig üblichen, oder schönen Zeichensatz im S-Plan verwenden, wo auch diese griechischen
bzw. technischen Zeichen vorhanden sind.
Dann sollten eigentlich alle glücklich sein.
Also, seit den 198x er Jahren war es in meiner Umgebung schon recht egal, wie die Beschriftung aussah, -sieht.
Hauptsache das Werkl werkelt.
"Normgerechte Beschriftung" - uff,,,uff,,,, ist es denn nicht Wurst, ob Kapitälchen im Schriftzug sind, oder nicht?
So mal meine Maunze, - Erfahrung; "miau.."
... ich vermisse im Eagle ganz andere Dinge... - eher auch, was es schon aus den DOS-Zeiten gab, Eagle aber immer noch nicht hat.
Die Sonderzeichen-Diskussion kenne ich auch schon seit der DOS-Zeit; u.A. mit PCAD (von dieser Ecke komme ich), AUTOCAD, ORCAD, etc...
Dahingehend, auch unter Autodesk, vermute ich ganz andere Spielereien... -"hat denn Eagle noch eine Chance heutzutage?""
Autodesk ist auch so eine Riesen-Fa, wie Altium. Ich denke nicht wirklich, dass Eagle Autodesk echt interessiert, weil sie ja seit jeher
in ganz anderen Sparten ihre CAD-Programme anbieten; ist Eagle doch ein reines "Mikro-Modulchen".
Grüße
Gerald