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,
du kannst es als Bild einfügen.
Eine eigene lib mit Sonderzeichen basteln.
Es gibt schon Anfragen hierin, - vor einigen Monaten wurde mal was dahingehend gepostet.
Hinweis aus dem Manual, Kap. 5.5:
---
Verbotene Zeichen und Sonderzeichen
Leerzeichen, Strichpunkt und Umlaute sind in allen Namen verboten.
Hochkommas und andere (exotische) Zeichen, die einen ASCIICode über
127 haben, sollten möglichst vermieden werden.
In DeviceNamen sollte kein Fragezeichen bzw. Stern vorkommen, da diese
Zeichen als Platzhalter für PackageVariante (?)und Technology (*)stehen.
In PadNamen sind Kommas zu vermeiden.
TeilBusNamen dürfen keine Doppelpunkte, Kommas und eckige Klammern
enthalten.
Das Ausrufezeichen hat in Texten eine Sonderfunktion. Es startet und
beendet überstrichenen Text. Beispiele dazu finden Sie in der Hilfefunktion
zum TEXTBefehl.
Soll das Ausrufezeichen im Text erscheinen, muss ein
Backslash ( \ ) vorangestellt werden.
Wenn der Backslash in einem Namen oder Text dargestellt werden soll,
müssen Sie diesen, zum Beispiel beim NAMEoder
TEXTBefehl, zweimal hintereinander eintippen.
---
Grüße
Gerald
---
Danke Gerald, das bestätigt allerdings nur meine Befürchtungen.
Ich meine: Wir haben 2016. Nicht 1986.
"Einfach" könnte man auch durch "Eigentlich unmöglich" ersetzen. In jeder Hinsicht die Bedienung und damit das Rad neu erfunden. Ich hoffe, Autodesk hat diesbezüglich positiven Einfluss. Servus.
"Einfach" könnte man auch durch "Eigentlich unmöglich" ersetzen. In jeder Hinsicht die Bedienung und damit das Rad neu erfunden. Ich hoffe, Autodesk hat diesbezüglich positiven Einfluss. Servus.
Ja, mal sehen..... Ich harre auch schon der Dinge, die auf uns zukommen.
Allerdings, wenn vergleichend man die Webseite aktuell anschaut.... hm, könnte vielleicht....".."
Grüße
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. 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: ä, ä, Ω, Ω
Insbesondere bei Bezeichnern wie Bauteilnamen muss man da aufpassen
bzw. kann auf die Schnauze fallen.
Hi,
was hältst von HPGL?
Das würde ich nehmen für Spezialzeichen, bzw. Charakter.
Grüße
Gerald
---
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: ä, ä, Ω, Ω
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:
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