Hallo
Wenn ich bei einem Text Align center+right wähle bleibt zwischen
Buchstabenende und Origin Luft (ca. 0.8mm). Dasselbe passiert bei align
center. Der Mittelpunkt ist nicht in der Mitte des Textes. Die vertikale
Ausrichtung ist jeweils korrekt.
--
mfg Patrick Steiner
Eagle 6.3.0 Professional
Am 12.12.2012 11:57, schrieb Andreas Weidner:
Am 12.12.2012 11:25, schrieb Walter Spermann:
>> ich kann Ihre Kritik/Vorschläge und die anderer Kunden gut
>> nachvollziehen. Eine wichtige Frage,
>> die sich (wie bei so vielen Änderungen) aber stellt, ist die
>> Veränderung bestehender Daten:
>> Ein Kunde hat sein Board mit V6.3 fertig (DRC-fehlerfrei) und schickt
>> es zur Fertigung,
>> wo EAGLE 6.x (x>3) verwendet wird mit einer optimaleren Behandlung von
>> Vektorfont.
>> Der LP-Hersteller bekommt jetzt möglicherweise DRC-Fehler, die es
>> vorher noch nicht gab.
>> Oder er macht gar keinen DRC und gibt direkt Gerber aus.
>> Die Buchstaben können nun verschoben sein (je nach Orientierung und
>> Alignment),
>> so dass der Output auch abweichen kann (z.B. Orphans in 6.3 sind in
>> 6.x verbunden so dass
>> mehr Kupfer entsteht). Es ist abzuwägen, ob man das in Kauf nehmen soll.
Aaaaaalso:
1. Solche Aenderungen sollte man natuerlich nicht machen beim Uebergang
von Version 6.5.1 auf 6.5.1a oder so, sondern z.B. von 6.x auf 7.
2. Solche Aenderungen WURDEN bereits durchgefuehrt beim Uebergang von
5.x auf 6. Obwohl ich unserem Platinenhersteller explizit die
Versionsnummer mitgeteilt hatte, wurde dadurch eine Charge Platinen
FALSCH hergestellt (Version-5-Kupferaussparungen aus einer Innenlage
wurden beim Laden mit Version 6 NICHT mehr ausgespart). Kurze Zeit
spaeter wurde ein neues Feld des Platinenherstellers zur Eingabe der
EAGLE-Versionsnummer eingefuehrt. Die fehlende Unterstuetzung alter
Signallagen hat viele Platinen DEUTLICH geaendert.
3. Wenn es solche Aenderungen gibt, sollte der Benutzer natuerlich
darauf hingewiesen werden. Das wird bei ehemaligen Signallagen ja
mittlerweile auch durchgefuehrt. Ist zwar nicht besonders schoen,
aber immerhin.
4. Weitaus schoener waere es natuerlich, das geladene alte Design
gleich so zu verarbeiten, dass alles UNVERAENDERT bleibt.
Dafuer gibt es mindestens ZWEI Moeglichkeiten:
a) Es wird ein INTERNES Flag angelegt, das mitteilt, ob sich
Texte wie in Version 6.x verhalten oder neu korrigiert. Alte
Texte verhalten sich dann so wie frueher, neue Texte auf die
korrigierte Weise. Einfach zu programmieren, braucht aber ein
zusaetzliches Flag und ist nicht so schoen fuer den Nutzer.
b) Beim Laden eines alten Projekts werden die Urspruenge der
BETROFFENEN Texte so verschoben, dass sich die Textposition
nicht aendert (bis auf eventuelle Rundungsfehler, da ja auf
Editorkoordinaten positioniert werden muss). Das ist
natuerlich programmiertechnisch etwas aufwendiger, aber mehr
als ein geruettelt Mass an IF-Abfragen und etwas Pythagoras
ist dafuer nicht noetig. Dann kann der Nutzer jedoch auch
alte Projekte mit der neuen huebschen Funktionalitaet nutzen.
Warum einfach wenn es auch kompliziert geht.
Meiner Ansicht nach ist die BRD-Datei sowieso die FALCHE
Fabrikationsgrundlage.Das obige Beispiel zeigt warum. Ich dachte bis
anhin das machen nur Hobby-Anwender oder diejenigen die noch
Word-Rechnugnen an ihre Kunden per E-Mail versenden. 
--
mfg Patrick Steiner
Eagle 6.3.0 Professional
Patrick Steiner schrieb:
Am 12.12.2012 11:57, schrieb Andreas Weidner:
>> 4. Weitaus schoener waere es natuerlich, das geladene alte Design
>> gleich so zu verarbeiten, dass alles UNVERAENDERT bleibt.
>> Dafuer gibt es mindestens ZWEI Moeglichkeiten:
>> a) Es wird ein INTERNES Flag angelegt, das mitteilt, ob sich
>> Texte wie in Version 6.x verhalten oder neu korrigiert. Alte
>> Texte verhalten sich dann so wie frueher, neue Texte auf die
>> korrigierte Weise. Einfach zu programmieren, braucht aber ein
>> zusaetzliches Flag und ist nicht so schoen fuer den Nutzer.
>> b) Beim Laden eines alten Projekts werden die Urspruenge der
>> BETROFFENEN Texte so verschoben, dass sich die Textposition
>> nicht aendert (bis auf eventuelle Rundungsfehler, da ja auf
>> Editorkoordinaten positioniert werden muss). Das ist
>> natuerlich programmiertechnisch etwas aufwendiger, aber mehr
>> als ein geruettelt Mass an IF-Abfragen und etwas Pythagoras
>> ist dafuer nicht noetig. Dann kann der Nutzer jedoch auch
>> alte Projekte mit der neuen huebschen Funktionalitaet nutzen.
Warum einfach wenn es auch kompliziert geht.
Meiner Ansicht nach ist die BRD-Datei sowieso die FALCHE
Fabrikationsgrundlage.Das obige Beispiel zeigt warum. Ich dachte bis
anhin das machen nur Hobby-Anwender oder diejenigen die noch
Word-Rechnugnen an ihre Kunden per E-Mail versenden.
Abgesehen davon, daß ich noch nie eine BRD-Datei an einen LPH gegeben
habe und auch meine Gerber-Daten vor dem Verschicken immer nochmal
prüfe: Es ist trotzdem dringend ratsam, ein bestehendes Design beim
Einlesen in einer neueren Programmversion nicht zu verändern!
Ich halte das von Andreas unter 4b beschriebene Verfahren für den
sinnvollsten und naheliegendsten Weg, den Fehler zu beheben, ohne
gleichzeitig alte Designs unbrauchbar zu machen. Genau auf diese Weise
würde ich es jedenfalls bei einer eigenen Software machen.
Diese Methode hat im Gegensatz zu 4a den Vorteil, keine zusätzliche
Markierung zu benötigen (die bisherige Version ist ja sowieso im BRD
gespeichert), damit reichen im Programm zwei IF-Abfragen und ein
winziges bißchen Arithmetik.
Tilmann
Patrick Steiner schrieb:
Am 12.12.2012 11:57, schrieb Andreas Weidner:
>> 4. Weitaus schoener waere es natuerlich, das geladene alte Design
>> gleich so zu verarbeiten, dass alles UNVERAENDERT bleibt.
>> Dafuer gibt es mindestens ZWEI Moeglichkeiten:
>> a) Es wird ein INTERNES Flag angelegt, das mitteilt, ob sich
>> Texte wie in Version 6.x verhalten oder neu korrigiert. Alte
>> Texte verhalten sich dann so wie frueher, neue Texte auf die
>> korrigierte Weise. Einfach zu programmieren, braucht aber ein
>> zusaetzliches Flag und ist nicht so schoen fuer den Nutzer.
>> b) Beim Laden eines alten Projekts werden die Urspruenge der
>> BETROFFENEN Texte so verschoben, dass sich die Textposition
>> nicht aendert (bis auf eventuelle Rundungsfehler, da ja auf
>> Editorkoordinaten positioniert werden muss). Das ist
>> natuerlich programmiertechnisch etwas aufwendiger, aber mehr
>> als ein geruettelt Mass an IF-Abfragen und etwas Pythagoras
>> ist dafuer nicht noetig. Dann kann der Nutzer jedoch auch
>> alte Projekte mit der neuen huebschen Funktionalitaet nutzen.
Warum einfach wenn es auch kompliziert geht.
Meiner Ansicht nach ist die BRD-Datei sowieso die FALCHE
Fabrikationsgrundlage.Das obige Beispiel zeigt warum. Ich dachte bis
anhin das machen nur Hobby-Anwender oder diejenigen die noch
Word-Rechnugnen an ihre Kunden per E-Mail versenden.
Abgesehen davon, daß ich noch nie eine BRD-Datei an einen LPH gegeben
habe und auch meine Gerber-Daten vor dem Verschicken immer nochmal
prüfe: Es ist trotzdem dringend ratsam, ein bestehendes Design beim
Einlesen in einer neueren Programmversion nicht zu verändern!
Ich halte das von Andreas unter 4b beschriebene Verfahren für den
sinnvollsten und naheliegendsten Weg, den Fehler zu beheben, ohne
gleichzeitig alte Designs unbrauchbar zu machen. Genau auf diese Weise
würde ich es jedenfalls bei einer eigenen Software machen.
Diese Methode hat im Gegensatz zu 4a den Vorteil, keine zusätzliche
Markierung zu benötigen (die bisherige Version ist ja sowieso im BRD
gespeichert), damit reichen im Programm zwei IF-Abfragen und ein
winziges bißchen Arithmetik.
Tilmann
