Bug: Text ausrichten

Am 05.12.2012 17:20, schrieb Patrick Steiner:

Hallo

 

Wenn ich bei einem Text Align center+right wähle bleibt zwischen

Buchstabenende und Origin Luft (ca. 0.8mm). Dasselbe passiert bei align

Das gleiche ist auch bei center+left, da jeder Buchstabe links als

auch rechts einen Freiraum benötigt, man muß ja auch Buchstabe an

Buchstabe setzen können, ohne das die Buchstaben kollidieren, und

dabei muß die Reihenfolge der Buchstaben egal sein.

Sonst bräuchte man ja für jeden Zeichensatz und darin jeden

Buchstaben einen Anfangs- Mittel- und End-Buchstaben (jeweils

mal links mal rechts mal auf beiden Seiten einen Freiraum).

center. Der Mittelpunkt ist nicht in der Mitte des Textes. Die vertikale

Ausrichtung ist jeweils korrekt.

Kann ich nicht nachvollziehen, anbei ein Beispiel.

Man muß auch noch den Zoomfaktor beachten, denn der Grafiktreiber

muß um die Zeichen lesbar darzustellen ja nach Größe den Text

(die Zeichen) entsprechend berechnen, so daß sie mit der

entsprechenden Pixelauflösung lesbar sind. Deshalb springt der Text

bei entsprechender Auflösung etwas.

Das gleiche Verhalten sieht man auch bei Textprogrammen, wenn man

die Skalierung (Vergrößerung) ändert (word.exe), da springt dann die

ganze Zeile.

Mit freundlichen Grüßen / Best regards

Alfred Zaffran

--

______________________________________________________________

Alfred Zaffran              Support

CadSoft Computer GmbH       Hotline:   08635-698930

Pleidolfweg 15              FAX:       08635-698940

84568 Pleiskirchen          eMail: <alf@cadsoft.de>

                             Web:   <www.cadsoft.de>

Registergericht: Amtsgericht Traunstein HRB 5573

Geschäftsführer: Thomas Liratsch

______________________________________________________________

EAGLE V6.3 availabe now!

Am 07.12.2012 10:37, schrieb A. Zaffran:

Am 05.12.2012 17:20, schrieb Patrick Steiner:

>> Hallo

>>

>> Wenn ich bei einem Text Align center+right wähle bleibt zwischen

>> Buchstabenende und Origin Luft (ca. 0.8mm). Dasselbe passiert bei align

 

Das gleiche ist auch bei center+left, da jeder Buchstabe links als

auch rechts einen Freiraum benötigt, man muß ja auch Buchstabe an

Buchstabe setzen können, ohne das die Buchstaben kollidieren, und

dabei muß die Reihenfolge der Buchstaben egal sein.

Sonst bräuchte man ja für jeden Zeichensatz und darin jeden

Buchstaben einen Anfangs- Mittel- und End-Buchstaben (jeweils

mal links mal rechts mal auf beiden Seiten einen Freiraum).

Das wäre doch ein wenig zuviel des Guten.

>

>> center. Der Mittelpunkt ist nicht in der Mitte des Textes. Die vertikale

>> Ausrichtung ist jeweils korrekt.

 

Kann ich nicht nachvollziehen, anbei ein Beispiel.

Sie haben das Problem bereits nachvollzogen. Ich habe ihr Beispiel

vermasst (Siehe mittlere Textzeile im Anhang). Die beiden Zahlen müssen

meines erachtens gleich sein.

Man muß auch noch den Zoomfaktor beachten, denn der Grafiktreiber

muß um die Zeichen lesbar darzustellen ja nach Größe den Text

(die Zeichen) entsprechend berechnen, so daß sie mit der

entsprechenden Pixelauflösung lesbar sind. Deshalb springt der Text

bei entsprechender Auflösung etwas.

Das gleiche Verhalten sieht man auch bei Textprogrammen, wenn man

die Skalierung (Vergrößerung) ändert (word.exe), da springt dann die

ganze Zeile.

Ich habe nicht diesen Effekt angesprochen, wäre mir auch nie aufgefallen.

Im PCB wäre mir diese korrekte Zentrierung sehr wichtig weil wir öfters

Text im Kupfer-Layer oder Silk drucken. Wenn ich den Text dann zentriert

zwischen zwei Löcher setzen möchte ist dieser nicht wirklich zentriert.

Und jeweils von Hand nachrücken finde ich nicht Benutzerfreundlich.

Andere Textverarbeitungsprogramme haben auch vor dem Buchstaben etwas

Luft (gleichviel wie am Ende). Dies führt dann beim Zentrieren zu keinen

Problemen.

Ich bevorzuge den Textorigin (links) wie ihn Eagle jetzt umsetzt. Den

Textorigin rechts bemängle ich.

--

mfg Patrick Steiner

Eagle 6.3.0 Professional

Ich wollte diesen Punkt eigentlich auch schon seit Laengerem bemaengeln,

hab's aber immer wieder vergessen, denn SOOO wichtig finde ich ihn auch

wieder nicht. Aber schoen waer's schon...

Am 07.12.2012 11:28, schrieb Patrick Steiner:

>> Das gleiche ist auch bei center+left, da jeder Buchstabe links als

>> auch rechts einen Freiraum benötigt, man muß ja auch Buchstabe an

>> Buchstabe setzen können, ohne das die Buchstaben kollidieren, und

>> dabei muß die Reihenfolge der Buchstaben egal sein.

>> Sonst bräuchte man ja für jeden Zeichensatz und darin jeden

>> Buchstaben einen Anfangs- Mittel- und End-Buchstaben (jeweils

>> mal links mal rechts mal auf beiden Seiten einen Freiraum).

Nein, wir wollen auch nicht uebertreiben. Ich beziehe mich jetzt

ausschliesslich auf den "Vector Font" von EAGLE, denn alle anderen Fonts

sollte man im Layout sowieso nicht einsetzen: Jeder Buchstabe bei EAGLE

faengt EXAKT links an (es gibt keinen Freiraum links) und hat nur einen

zusaetzlichen Freiraum HINTER dem Buchstaben. Also muss zwischen Anfang

und Mitte NICHT unterschieden werden, sondern nur (Anfang/Mitte) and

(Ende). Siehe unten.

Das wäre doch ein wenig zuviel des Guten.

Ja, aber das ganze Thema ist durchaus NICHT so kompliziert wie

beschrieben...

Aaaaalso: Den Effekt gibt's seit gefuehlten tausend Jahren, und das

Problem ist die interne Darstellung der "stroked fonts", in der jeder

Buchstabe als Strichfolge und der Offset zum naechsten Buchstaben als

"moveto" drinsteht. Es gibt dabei leider keine DIREKTE Information, wie

breit der BUCHSTABE tatsaechlich ist. Dadurch zaehlt in EINER Richtung

der Abstand zum naechsten Buchstaben dazu und in der anderen NICHT.

Das fuehrt zu so merkwuerdigen Dingen wie im angehaengten Bild: Mal

passen die Abstaende, mal nicht (obwohl alles das gleiche Bauteil ist).

Loesung: In den "stroked font" nicht nur den Offset zum naechsten

Buchstaben eincodieren, sondern auch die TATSAECHLICHE Breite des

Buchstabens. Da muss man einfach mal alle Buchstaben des Zeichensatzes

durchgehen und sich die Werte aufschreiben. Dann koennte die ECHTE

Breite eines Textes berechnet werden zu (Breite der LENGTH-1 Buchstaben

wie bisher)+(tatsaechliche Breite des letzten Buchstabens). Alles ganz

einfach. Damit bliebe alles, wie's ist, nur zentrierter und

rechtsbuendiger Text wuerde KORREKT abgearbeitet.

Es ist also durchaus NICHT notwendig, fuer "jeden Zeichensatz" (denn

EAGLE hat nur EINEN Vektorfont) Anfangs-, Mittel- und Endbuchstaben zu

definieren, sondern es braucht nur in EINEM Zeichensatz fuer JEDES

Zeichen (ca. 200) EINE zusaetzliche Integerzahl eingebaut zu werden,

naemlich die tatsaechliche Zeichenbreite. Das ist zwar ein gewisser

Aufwand, aber DEUTLICH weniger als dargestellt.

Andreas Weidner

Eine Editorkoordinate? Du meinst, die kleinste von Eagle darstellbare

Einheit?

Die ist inzwischen soooo klein -- wenn das was ausmacht, dann hast du noch

ganz andere Probleme.

--

Browser-Zugang zu den CadSoft-Support-Foren auf http://www.eaglecentral.ca

Am 15.12.2012 20:29, schrieb Walter.Spermann@cadsoft.de:

OK, ich halte 4b für die erstrebenswerteste Lösung, vielen Dank !

Die Koordinaten-Korrektur kann neben dem aktuellen Alignment und

Orientierung

aber auch noch von dem Spin-Flag und der globalen Einstellung "Vertical

Text" abhängen,

Ja, das ist gar nicht mal so ohne. Deswegen ja auch das "geruettelt

Mass" IF-Abfragen. Da muss man aufpassen wie ein Schiesshund, damit sich

keine Fehler einschleichen.

Es kann uebrigens vermutlich IMMER noch zu Platinenaenderungen kommen,

da die neuen Textpositionen ja auf Editorkoordinaten gerundet werden

muessen. Es KANN sein, dass sich hierdurch die tatsaechlichen

Strichpositionen evtl. um EINE Editorkoordinate aendern, was den

Kupferfluss evtl. wieder stoert (je nachdem, wie der aktuelle

Zeichenalgorithmus gestaltet ist, ist das aber evtl. auch KEIN Problem).

FALLS es ein Problem sein kann, waere es auf alle Faelle sinnvoll,

BETROFFENE Texte in die Kompatibilitaetswarnung beim Einladen mit

aufzunehmen (nur in der Platine, NICHT im Schaltplan).

Andreas Weidner

On 12/12/2012 11:57 AM, Andreas Weidner wrote:

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.

 

Andreas Weidner

OK, ich halte 4b für die erstrebenswerteste Lösung, vielen Dank !

Die Koordinaten-Korrektur kann neben dem aktuellen Alignment und Orientierung

aber auch noch von dem Spin-Flag und der globalen Einstellung "Vertical Text" abhängen,

was aber keinen großen Unterschied in der Implementierung machen sollte.

Gruß,

Walter Spermann

--

-

Walter Spermann

Softwareentwicklung

CadSoft Computer GmbH

Pleidolfweg 15

84568 Pleiskirchen

Tel.: 08635/6989-10

www.cadsoft.de

-

Registergericht: Amtsgericht Traunstein HRB 5573

Geschäftsführer: Thomas Liratsch

-

On 12/12/2012 11:57 AM, Andreas Weidner wrote:

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.

 

Andreas Weidner

OK, ich halte 4b für die erstrebenswerteste Lösung, vielen Dank !

Die Koordinaten-Korrektur kann neben dem aktuellen Alignment und Orientierung

aber auch noch von dem Spin-Flag und der globalen Einstellung "Vertical Text" abhängen,

was aber keinen großen Unterschied in der Implementierung machen sollte.

Gruß,

Walter Spermann

--

-

Walter Spermann

Softwareentwicklung

CadSoft Computer GmbH

Pleidolfweg 15

84568 Pleiskirchen

Tel.: 08635/6989-10

www.cadsoft.de

-

Registergericht: Amtsgericht Traunstein HRB 5573

Geschäftsführer: Thomas Liratsch

-

Eine Editorkoordinate? Du meinst, die kleinste von Eagle darstellbare

Einheit?

Die ist inzwischen soooo klein -- wenn das was ausmacht, dann hast du noch

ganz andere Probleme.

--

Browser-Zugang zu den CadSoft-Support-Foren auf http://www.eaglecentral.ca

Am 15.12.2012 20:29, schrieb Walter.Spermann@cadsoft.de:

OK, ich halte 4b für die erstrebenswerteste Lösung, vielen Dank !

Die Koordinaten-Korrektur kann neben dem aktuellen Alignment und

Orientierung

aber auch noch von dem Spin-Flag und der globalen Einstellung "Vertical

Text" abhängen,

Ja, das ist gar nicht mal so ohne. Deswegen ja auch das "geruettelt

Mass" IF-Abfragen. Da muss man aufpassen wie ein Schiesshund, damit sich

keine Fehler einschleichen.

Es kann uebrigens vermutlich IMMER noch zu Platinenaenderungen kommen,

da die neuen Textpositionen ja auf Editorkoordinaten gerundet werden

muessen. Es KANN sein, dass sich hierdurch die tatsaechlichen

Strichpositionen evtl. um EINE Editorkoordinate aendern, was den

Kupferfluss evtl. wieder stoert (je nachdem, wie der aktuelle

Zeichenalgorithmus gestaltet ist, ist das aber evtl. auch KEIN Problem).

FALLS es ein Problem sein kann, waere es auf alle Faelle sinnvoll,

BETROFFENE Texte in die Kompatibilitaetswarnung beim Einladen mit

aufzunehmen (nur in der Platine, NICHT im Schaltplan).

Andreas Weidner