Kleinbuchstaben in Libaries

Holger Drempel schrieb:

Früher konnte man in Libaries Kleinbuchstaben verwenden, z.B. für 10pF. In

den neuen Versionen werden alle zu Grossbuchstaben konvertiert.

Kann man dieses Verhalten wieder abstellen?

Das ist so nicht korrekt.

Es wird unterschieden zwischen NAME und VALUE. Namen (egal ob Netznamen

oder Bauteilnamen) enthalten nur Großbuchstaben und werden schon bei der

Eingabe nur in Blockschrift angezeigt. Values dagegen dürfen auch

Kleinbuchstaben (und sogar Leerzeichen) enthalten.

10pF halte ich eindeutig für einen Value, der auch genau so eingegeben

werden kann - aber was hat das in einer Bibliothek verloren?

Tilmann

"Tilmann Reh" <usenet2007nospam@autometer.de> wrote in message

news:hkjp3v$4ue$1@cheetah.cadsoft.de...

Holger Drempel schrieb:

Schnipp:

10pF halte ich eindeutig für einen Value, der auch genau so eingegeben

werden kann - aber was hat das in einer Bibliothek verloren?

Tilmann

Schnapp:

Hi!

Also ich habe fertige Bibliotheken von passiven und aktiven Bauteilen mit

Werten aus der E-Reihe, so auch 10pF für einen Kondensator. Der hat dann

auch noch einen Schwung andere Attribute. Das erspart mir z.B. beim

Generieren der BOM das Suchen einer Bestellnummer. Der Vorteil ist unter

anderem. daß man weiß, was man für Bauteilwerte regelmäßig verwendet.

Bei 100n habe ich verschiedene Bauformen 0603,.. 1208 und diverse

bedrahtete. Die haben dann gleich die richtige Spannung, Material und

Toleranz mit im Schlepptau.

Gruß

Carsten

Carsten schrieb:

"Tilmann Reh" <usenet2007nospam@autometer.de> wrote in message

news:hkjp3v$4ue$1@cheetah.cadsoft.de...

Holger Drempel schrieb:

 

Schnipp:

 

10pF halte ich eindeutig für einen Value, der auch genau so eingegeben

werden kann - aber was hat das in einer Bibliothek verloren?

 

Tilmann

 

Schnapp:

 

Hi!

 

Also ich habe fertige Bibliotheken von passiven und aktiven Bauteilen mit

Werten aus der E-Reihe, so auch 10pF für einen Kondensator. Der hat dann

auch noch einen Schwung andere Attribute. Das erspart mir z.B. beim

Generieren der BOM das Suchen einer Bestellnummer. Der Vorteil ist unter

anderem. daß man weiß, was man für Bauteilwerte regelmäßig verwendet.

Bei 100n habe ich verschiedene Bauformen 0603,.. 1208 und diverse

bedrahtete. Die haben dann gleich die richtige Spannung, Material und

Toleranz mit im Schlepptau.

 

Gruß

Carsten

 

 

Hallo,

genau so nutzen wir die lib auch. Aber seit 5.0 sind auch Sonderzeichen

wie µ für lib Namen nicht mehr erlaubt. Mit Version 4.x ging das noch

ohne Probleme.

Gruß ggcode

Alles schön und gut, gibt es jetzt aber eine Trick die Sonderzeichen bzw.

Kleinbuchstaben wieder zu aktivieren?

Ich bin immer fasziniert, wenn ich sehe, welche kleinen Hacks man in Eagle

eingeben kann und was sonst alles möglich ist.

Oder gibt es einen besonderen Grund, warum die Eingabe der Kleinbuchstaben

nicht mehr funktioniert?

Holger

Holger Drempel schrieb:

Alles schön und gut, gibt es jetzt aber eine Trick die Sonderzeichen bzw.

Kleinbuchstaben wieder zu aktivieren?

 

Ich bin immer fasziniert, wenn ich sehe, welche kleinen Hacks man in Eagle

eingeben kann und was sonst alles möglich ist.

 

Oder gibt es einen besonderen Grund, warum die Eingabe der Kleinbuchstaben

nicht mehr funktioniert?

 

Holger

 

 

Hallo Holger,

mit 4.x funktioniert das noch. Also dort die Lib erstellen. Hast dann

aber keine features von 5.x :-(.

Laut Support Kompatibilitäts Gründe zu anderen Sprachen die diese

Sonderzeichen nicht haben. Bei der Groß und Kleinschreibung ---> keine

Ahnung.

Gruß ggcode

Am 06.02.2010 13:59, schrieb Tilmann Reh:

Holger Drempel schrieb:

 

Früher konnte man in Libaries Kleinbuchstaben verwenden, z.B. für 10pF. In

den neuen Versionen werden alle zu Grossbuchstaben konvertiert.

Kann man dieses Verhalten wieder abstellen?

 

Das ist so nicht korrekt.

 

Es wird unterschieden zwischen NAME und VALUE. Namen (egal ob Netznamen

oder Bauteilnamen) enthalten nur Großbuchstaben und werden schon bei der

Eingabe nur in Blockschrift angezeigt. Values dagegen dürfen auch

Kleinbuchstaben (und sogar Leerzeichen) enthalten.

Ich wäre sehr dafür,  alle Beschränkungen bezüglich Kleinbuchstaben und

Sonderzeichen überall möglichst vollständig aufzuheben.  Ich kann keinen

ernsthaften Grund sehen,  warum der Zeichenumfang für zB Namen überhaupt

eingeschränkt werden sollte.  Es liegt in der Verantwortung des Nutzers,

  seine Sachen vernünftig lesbar zu gestalten,  und es wird immer mal

exotische Fälle geben (die kann man sich vorher gar nicht ausdenken),

wo irgendein Sonderzeichen nützlich ist.

Und bei dieser Gelegenheit wäre es höchste Zeit,  Texte Unicode-fähig zu

machen (UTF8)!  Das kann doch nicht sooo schwierig sein,  oder?  Bei den

meisten Büroprogrammen und Betriebssystem ist das mittlerweile

selbstverständlich,  selbst Programmier-Editoren übernehmen das nun.

Die Welt ist groß,  und Eagle wird schon lang nicht mehr nur von

Deutschen benutzt.

Ebenso wäre es allerhöchste Zeit,  Eagle für die System-Fonts fit zu

machen!  Mir fällt eigentlich kein heutiges Programm mehr ein,  das noch

so auf eigene Schriften eingesperrt ist.

Nur auf den Boards wird man sich als sorgfältiger User wohl noch einige

Zeit auf den Vektorfont beschränken müssen,  bis auch die Filmbelichter

verlässlich soweit sind,  mit Fonts richtig umgehen zu können.

Das heißt auf Obiges bezogen,  dass sich jemand eine Weile hinsetzen

sollte,  um Eagles noch unentbehrlichen Vektor-Font kräftig um etliche

Unicode-Zeichen zu erweitern!  Obwohl ich selber weder Kyrillisch noch

Katakana brauche,  habe ich da schon öfters manche (technische)

Sonderzeichen vermisst...  OK,  das ist vielleicht nicht der

interessanteste Job für euch Programmierer,  aber in der Font-Szene wird

sich doch sicher jemand finden lassen,  der das günstig machen kann.

Grüße,  Hans Lederer

Am 11.02.2010 09:07, schrieb Hans Lederer:

Das heißt auf Obiges bezogen, dass sich jemand eine Weile hinsetzen

sollte, um Eagles noch unentbehrlichen Vektor-Font kräftig um etliche

Unicode-Zeichen zu erweitern!

Und ihn bei der Gelegenheit auch der ISO 3098 annähern !

Grüße, Hans Lederer

Hans Lederer wrote:

 

Und bei dieser Gelegenheit wäre es höchste Zeit,  Texte Unicode-fähig zu

machen (UTF8)!  Das kann doch nicht sooo schwierig sein,  oder?

Unterschaetze das mal nicht. Spaetestens wenn die Unicode-Namen auch

gleichzeitig Dateinamen sein koennen, dann stehst du vor der Tuer der

Hoelle:

- Es gibt illegale UTF8-Codes die erkannt werden muessen

  (sonst kann der Decoder mitsamt dem ganzen Programm abstuerzen)

- Ein einzelnes Unicode-Zeichen kann zusammengesetzt sein (aus

  mehreren Codes bestehen)

- Precomposed oder Decomposed Darstellung bei UTF8

- Verschiedene Dateien im gleichen Verzeichnis koennen den gleichen

  Name haben (verschieden codiert)

- Konvertierung der Namen je nach Dateisystem noetig (Im Dateisystem

  ist der Dateiname ggf. anders codiert als im Programm)

- ...

Der Aufwand kann schon erheblich sein und es koennen trotz korrekter

Implementierung nachher diffuse Probleme auftreten weil die Codierung

nicht mehr eindeutig ist.

Micha

Am 11.02.2010 11:45, schrieb Michael Baeuerle:

Hans Lederer wrote:

 

Und bei dieser Gelegenheit wäre es höchste Zeit,  Texte Unicode-fähig zu

machen (UTF8)!  Das kann doch nicht sooo schwierig sein,  oder?

 

Unterschaetze das mal nicht. Spaetestens wenn die Unicode-Namen auch

gleichzeitig Dateinamen sein koennen, dann stehst du vor der Tuer der

Hoelle:

- Es gibt illegale UTF8-Codes die erkannt werden muessen

   (sonst kann der Decoder mitsamt dem ganzen Programm abstuerzen)

- Ein einzelnes Unicode-Zeichen kann zusammengesetzt sein (aus

   mehreren Codes bestehen)

- Precomposed oder Decomposed Darstellung bei UTF8

- Verschiedene Dateien im gleichen Verzeichnis koennen den gleichen

   Name haben (verschieden codiert)

- Konvertierung der Namen je nach Dateisystem noetig (Im Dateisystem

   ist der Dateiname ggf. anders codiert als im Programm)

- ...

 

Der Aufwand kann schon erheblich sein und es koennen trotz korrekter

Implementierung nachher diffuse Probleme auftreten weil die Codierung

nicht mehr eindeutig ist.

 

 

Micha

Ja,  ok,  bei Dateinamen wäre ich vorläufig auch noch zaghaft (da

vermeide ich vorzugsweise auch jetzt sogar noch Umlaute.  {aber in

Texten traue ich mich schon lange, sie zu verwenden! }).

Obwohl das hier mit Windows und einem Samba-Server unter Linux schon

lange eigentlich problemlos geht.  Neulich aber musste ich ein

Безымянный.TIF erst umbenennen,  bevor Irfanview es anfassen konnte.

Grüße,  Hans Lederer

Hans Lederer wrote:

 

Ja,  ok,  bei Dateinamen wäre ich vorläufig auch noch zaghaft (da

vermeide ich vorzugsweise auch jetzt sogar noch Umlaute.

Das ist auch sinnvoll, zumindest wenn man nicht auschliessen kann, dass

die Datei mal den lokalen Rechner verlassen soll.

{aber in

Texten traue ich mich schon lange, sie zu verwenden! }).

Ja, intern in Programmen sollte es keine (bzw. weniger) Probleme geben.

Obwohl das hier mit Windows und einem Samba-Server unter Linux schon

lange eigentlich problemlos geht.

Dann haenge mal noch zusaetzlich einen Mac per NFS an diesen Server ...

Die Unicode-Probleme sind oft subtil und nicht offensichtlich. Man merkt

es z.B. nicht unbedingt gleich, wenn man eine Datei ueberschreiben

wollte (z.B. beim Einspielen eines Backups) und es ist in Wirklichkeit

eine zweite gleichen Namens entstanden - es gab ja keine Fehlermeldung.

Je nachdem wie man dann auf die Datei zugreift bekommt man im worst case

mal die eine und mal die andere. Da gehen dann schonmal unbemerkt Daten

verloren obwohl es "so aussieht als waere alles OK" (und eigentlich auch

nichts kaputt ist).

Andersrum ist auch interessant: Sichert das Backup-Programm wirklich

beide Dateien wenn sie den gleichen Namen haben? Und wenn ja, was

passiert beim Restore wenn das Zieldateisystem eine bestimmte Codierung

vorschreibt? Das gibt dann eine Fehlermeldung obwohl Backup und

Zieldateisystem voellig intakt sind - wird der Admin verstehen warum es

nicht funktioniert?

Micha