How to create library part with thermal pad?

Well Mr Pearce,

as much as I thank you for your help, I must admit that I am not as

knowledgeable using Eagle as you might have thought I was. That is why I

didn't understand (and still don't) why there are supposed to be holes in

the tStop layer, what they do, nor how come it is one of the only two

layers that are generated automaticall for a SMD pad. there might be

something (or more than one thing) that I don't understand, that's obvious,

but if I did know, then I obviously wouldn't be posting on this forum, eh?

So, no need to insinuate something by saying that I need less syllables in

order to understand, or telling me to read the help file when I don't even

know specifically what to look for... It is hard to know what to look for

when you think you've looked at everything you could think of, and then

there's the things one doesn't think of...

In any case your explanation did help me out. I shall try this polygon

perimeter-delimitation method with the tRestrict layer.

sincerely,

Redcutlass

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Redcutlass wrote on Wed, 30 March 2011 12:29

That is why I didn't understand (and still don't) why there are

supposed to be holes in the tStop layer, what they do, nor how come it is

one of the only two layers that are generated automaticall for a SMD pad.

It seems now the real problem is not as much your understanding of Eagle,

but that you don't understand how PC boards work and how they are made.  If

you did, it would be intuitive how some of the Eagle layers map to layers

of a PCB.

Briefly, a PCB can the thought of as a sandwich of layers.  For simple

double sided boards from top to bottom these are the top silkscreen, top

soldermask, top copper, the PCB material itself (usually FR4 fiberglass),

bottom copper, and bottom soldermask.  You might also have a bottom

silkscreen for a more complicated board.

Go read up on PCB construction, then how the Eagle layers map to that will

make sense.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Olin wrote on Thu, 31 March 2011 07:27

It seems now the real problem is not as much your understanding of

Eagle, but that you don't understand how PC boards work and how they are

made.  If you did, it would be intuitive how some of the Eagle layers map

to layers of a PCB.

 

Briefly, a PCB can the thought of as a sandwich of layers.  For simple

double sided boards from top to bottom these are the top silkscreen, top

soldermask, top copper, the PCB material itself (usually FR4 fiberglass),

bottom copper, and bottom soldermask.  You might also have a bottom

silkscreen for a more complicated board.

 

Go read up on PCB construction, then how the Eagle layers map to that

will make sense.

euh, no. I am quite aware of how a PC board is made, be it single

double-sided, or multi-layered. I know what the solder mask does and what

delimitation it is supposed to have around the components. This is not my

first succesfully-manufactured board I've designed...

Funny enough,I asked a co-worker if he would refer to the Stop layer (he

doesn't use Eagle) as having "holes" in it, and he looked at me with

question marks in his eyes..

He then suggested that maybe the person who said that meant "openings"...

Then suddenly it all made sense.

You see, it isn't a question of my lack of knowledge, it is a question

using the correct word to describe the Stop layer. when I read holes I

thought to myself: round small openings. That's a hole. Not, "a perimetric

delimitation around an area", which opening would have suggested.

I was hoping not to have to defend myself in such a manner but it seems as

though people would rather assume that I lack knowledge.

anyway, another reader on another related topic has found a solution. I

shall go try that out now.

anyways, thanks for your replies, I hope I don't come off as too defensive.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote in message

news:inch25$8ic$1@cheetah.cadsoft.de...

 

"Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> wrote in message

news:inbvt9$fuu$1@cheetah.cadsoft.de...

Sorry for the left overs..

I could add that there should be a syncronized area clone/copy mode, where

you select a group window on both the sch and brd, and where clone/copy

checks if they contain the same parts and nets, and works on the selected

data in a wysiwyg way.

It should give error if nothing is common, or warning if one selection

contains other nets/parts than the other.

"Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> wrote in message

news:inbvt9$fuu$1@cheetah.cadsoft.de...

The CUT word is a real world reference to cutting something from a

sheet of paper, or an old newspaper editing desk. If you cut something

, it is either deleted or moved+pasted somewhere else. The problem with

this reference to Eagle is that brd and sch works "in parallel", so if you

cut in either the traditional way, you have not defined what is going to

happen to the other part of the project.

Maybe the function CUT should be renamed. (how about "CLONE" or

"DUPLICATE"?). To make both this and the copy functions more usable I would

also add more to it, like different options to what happens to the

copied/cloned netnames when you paste it. This could have been done after

copying as a separate function (edit paste buffer nets), or when pasting. It

is very intuitive to say how this is going to happen GUI wise, but in

command space it may be more difficult to visualize. Maybe the paste buffer

should get its own project.pastebuffer(index).sch and/or

project.pastebuffer(index).brd reference and work much like the main

structure, while commands could get a netname prefix to work in the

pastebuffer, so that a net named "net" would be referred to as

"$paste(1).net" after a copy or clone to buffer 1. (I've assumed there will

be multiple paste buffers here).

The Eagle window could even have a "edit pastebuffer" mode, where the stuff

in the pastebuffer can be opened and edited.

Am 04.04.2011 10:35, schrieb Klaus Schmidinger:

On 04/01/11 14:58, Olin Lathrop wrote:

>> ...

>> It is pretty universally understood that CUT does a copy and delete. This

>> was well established before Eagle was written. It is totally beyond me

>> what Klaus and company were thinking when they named the copy command

>> "cut".

 

The user interface of EAGLE was inspired by the "Valid GED", a graphical

editor I was working with during my time at Siemens. In that editor the

COPY command worked in such a way that you select the command and then

click on the object you want to copy. Then you move the copy to the

desired target location and click again to place it.

 

The CUT command in the GED did only copy the selected group into

the "cutting" buffer for later use with PASTE. It did not delete

the group from the original drawing.

 

Well, I'm sorry I got into contact with the GED before I was "contaminated"

with Windows, but that's the reason why COPY and CUT behave as they do

in EAGLE.

 

To get this recurring discussion over with once and for all I suggest

the following changes for version 6:

 

- The COPY command, when activated, just copies the group into

the buffer and terminates immediately. It will no longer be able to

select individual objects for copying. To copy individual objects

you will have to draw a group around each object, do a COPY and then

a PASTE. Unlike the former CUT command, which allowed the user to

define a reference point to "cut" the group at a particular location,

at which it will be attached to the mouse cursor when doing a later

PASTE, there will be no such reference point in the COPY command

(as usual under Windows, the group will be selected at its center).

 

- The CUT command becomes a combination of COPY, followed by a DELETE

of the group. Since board and schematic

are connected via forward&backannotation, some limitations apply

to the DELETE command (as is already the case now). Therefore it

may not be possible to actually delete the entire group. In such a case,

the group that has been copied into the buffer may contain objects

that have not been deleted from the drawing. Also, when doing a CUT

in the schematic, the group that gets copied into the buffer will

contain only the objects from the schematic, while the DELETE will

also delete the related objects from the board.

Alternatively (and since it most likely would cause quite some

confusion in boards and schematics) the CUT command could be

removed entirely.

 

- The PASTE command remains unchanged.

 

These changes should make EAGLE's COPY/CUT mechanism as "Windows like"

as possible. Whether this behavior is actually useful, is another

question...

 

Klaus Schmidinger

Well, I think this is going to be a very bad idea. Apart from the fact

that some people think that they are the nabel of the world does not

mean that they are allways right.

You can bet that your suggested change will not close the subject "once

an for all".(Unfortunately)

Eagle is also not written for windows alone but also for linux etc.

But mostly window users go up the wall if something is not windows like.

(I shall not start a discussion about all the windows problems now, but

I am a windows user too).

So some people stumble over "cut" and they have not, and did not want,

learn that in over twenty years.

I bet that if the word "salary" wold be exchanged to "deptor" they would

accept that in 10 seconds

I use the "copy" very often in creating schematics und it would be worse

now allways first painting a group around a device just to copy it.

Why not just simply rename the "cut" into "groupcopy" or whatever you

like and leave the funktions as they are.

A far better idea is to have the complainers come up with a suitable name.

--

Mit freundlichen Grüßen / With best regards

Joern Paschedag

Klaus Schmidinger schrieb:

To get this recurring discussion over with once and for all I suggest

the following changes for version 6:

 

- The COPY command, when activated, just copies the group into

   the buffer and terminates immediately. It will no longer be able to

   select individual objects for copying.

That would be a great disadvantage. I often use COPY on single objects.

It wouldn't be any problem to keep that (with use of the LMB), IMHO -

even if the function for dealing with groups was changed as described above.

   To copy individual objects

   you will have to draw a group around each object, do a COPY and then

   a PASTE.

Horrible.

   Unlike the former CUT command, which allowed the user to

   define a reference point to "cut" the group at a particular location,

   at which it will be attached to the mouse cursor when doing a later

   PASTE, there will be no such reference point in the COPY command

   (as usual under Windows, the group will be selected at its center).

...so you'll run into many grid problems. Selecting the reference point

is a very essential feature of the (current) CUT command.

These changes should make EAGLE's COPY/CUT mechanism as "Windows like"

as possible. Whether this behavior is actually useful, is another

question...

Exactly. I hereby request YAES (yet another eaglerc.usr switch) to

restore the current behaviour.

(Additionally, what about scripts that use the old command syntax?)

Tilmann

P.S. Yes, you have to learn the different command behaviour compared to

windows standard. Yes, you also need to get used to it. But after all,

EAGLE is a complex and powerful design tool - and in the current

implementation, you get the maximum /working efficiency/, and that's

what counts. The need to learn the tools is common for all complex ones.

Perhaps you just need to /rename/ the existing commands to avoid (or

reduce) the windows users confusion? (Script handling should still be

considered, however.)

On 04/01/11 14:58, Olin Lathrop wrote:

...

It is pretty universally understood that CUT does a copy and delete.  This

was well established before Eagle was written.  It is totally beyond me

what Klaus and company were thinking when they named the copy command

"cut".

The user interface of EAGLE was inspired by the "Valid GED", a graphical

editor I was working with during my time at Siemens. In that editor the

COPY command worked in such a way that you select the command and then

click on the object you want to copy. Then you move the copy to the

desired target location and click again to place it.

The CUT command in the GED did only copy the selected group into

the "cutting" buffer for later use with PASTE. It did not delete

the group from the original drawing.

Well, I'm sorry I got into contact with the GED before I was "contaminated"

with Windows, but that's the reason why COPY and CUT behave as they do

in EAGLE.

To get this recurring discussion over with once and for all I suggest

the following changes for version 6:

- The COPY command, when activated, just copies the group into

   the buffer and terminates immediately. It will no longer be able to

   select individual objects for copying. To copy individual objects

   you will have to draw a group around each object, do a COPY and then

   a PASTE. Unlike the former CUT command, which allowed the user to

   define a reference point to "cut" the group at a particular location,

   at which it will be attached to the mouse cursor when doing a later

   PASTE, there will be no such reference point in the COPY command

   (as usual under Windows, the group will be selected at its center).

- The CUT command becomes a combination of COPY, followed by a DELETE

   of the group. Since board and schematic

   are connected via forward&backannotation, some limitations apply

   to the DELETE command (as is already the case now). Therefore it

   may not be possible to actually delete the entire group. In such a case,

   the group that has been copied into the buffer may contain objects

   that have not been deleted from the drawing. Also, when doing a CUT

   in the schematic, the group that gets copied into the buffer will

   contain only the objects from the schematic, while the DELETE will

   also delete the related objects from the board.

   Alternatively (and since it most likely would cause quite some

   confusion in boards and schematics) the CUT command could be

   removed entirely.

- The PASTE command remains unchanged.

These changes should make EAGLE's COPY/CUT mechanism as "Windows like"

as possible. Whether this behavior is actually useful, is another

question...

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

warrenbrayshaw wrote on Fri, 01 April 2011 15:46

Are you saying the North American convention is to read a document from

the bottom or the left.

I don't think of it as reading a document from a particular side.  However,

pretty universally when you see vertical text here it is written going

down, not up.  This applies to signs, the spines of books, and just about

everything else.  Vertical text going up looks stupid, at least here.

For example, if you look at a german bookcase the titles will read up, but

here they will read down.

All this has been pointed out to Cadsoft before.  They don't seem to care.

They really should enhance text placement in general.  Eagle is workable

but very primitive in that regard.  Most software that lets you graphically

place text allows you to chose the anchor from one of the 9 corners, center

of edges, and center.  After that should be choice of direction, with

something better than the rather awkward "spin" flag to fix things.

I actually wrote a ULP that looks for vertical text strings.  It sets the

spin flag, orientation, and moves the origin around so that the text reads

down instead of up in the same place.  It mostly works, but it does move

the text around a little bit.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Olin Lathrop wrote:

Another annoying "feature" that is due to Eagle's origin is that

vertical text reads up not down.  That is the german convention.

However, I am using the english language version, and judging from

the number of downloads and the activity in this forum, the english

language version is much more popular.  Is this ever going to get

fixed?  It's been reported as a problem long ago.  At the very least

there should be a setting for default vertical text direction.

Currently this is a outright bug in the english language version, but

Cadsoft doesn't seem to take is seriously because it looks right in

the version they use.

Off subject apologies.

I had not previously known of this  'text reads down' preferrence and agree

that if a significant portion of the market desires it then it should be

catered for.

I don't see the default as a German convention. 'text reads up' is my

preferrence as rotating the document clockwise (right) is my preference.

Are you saying the North American convention is to read a document from the

bottom or the left.

Cheers

Warren

ain't that true. I'm not surprised to see that other (non-german) members

find this weird. But once you know it... lol

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

I did not think about that... the famous language barrier. However the

level of english spoken on the forum, I find, is of higher quality than

other forums I visit.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Gary Gofstein wrote on Thu, 31 March 2011 16:19

There are a lot of cases where you have to be flexible in your

interpretation of EAGLE's terms.  For backward compatibility with

scripts and ULP's, the historic, perhaps misleading, terms are here to

stay.

When I first started learning Eagle the poor choice of command names caused

considerable confusion.  For example, CUT does a COPY, and COPY never seems

to do what you want.  WIRE draws lines except when they represent wires,

then you use NET.

It is pretty universally understood that CUT does a copy and delete.  This

was well established before Eagle was written.  It is totally beyond me

what Klaus and company were thinking when they named the copy command

"cut".

Another annoying "feature" that is due to Eagle's origin is that vertical

text reads up not down.  That is the german convention.  However, I am

using the english language version, and judging from the number of

downloads and the activity in this forum, the english language version is

much more popular.  Is this ever going to get fixed?  It's been reported

as a problem long ago.  At the very least there should be a setting for

default vertical text direction.  Currently this is a outright bug in the

english language version, but Cadsoft doesn't seem to take is seriously

because it looks right in the version they use.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Gary Gofstein wrote on Thu, 31 March 2011 16:19

There are a lot of cases where you have to be flexible in your

interpretation of EAGLE's terms.  For backward compatibility with

scripts and ULP's, the historic, perhaps misleading, terms are here to

stay.

When I first started learning Eagle the poor choice of command names caused

considerable confusion.  For example, CUT does a COPY, and COPY never seems

to do what you want.  WIRE draws lines except when they represent wires,

then you use NET.

It is pretty universally understood that CUT does a copy and delete.  This

was well established before Eagle was written.  It is totally beyond me

what Klaus and company were thinking when they named the copy command

"cut".

Another annoying "feature" that is due to Eagle's origin is that vertical

text reads up not down.  That is the german convention.  However, I am

using the english language version, and judging from the number of

downloads and the activity in this forum, the english language version is

much more popular.  Is this ever going to get fixed?  It's been reported

as a problem long ago.  At the very least there should be a setting for

default vertical text direction.  Currently this is a outright bug in the

english language version, but Cadsoft doesn't seem to take is seriously

because it looks right in the version they use.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

On 9/27/2011 12:16 AM, Klaus Schmidinger wrote:

On 09/27/11 01:42, Olin Lathrop wrote:

>> warrenbrayshaw wrote on Mon, 26 September 2011 18:20

>>> I too would have guessed there were a large number US resident Eagle

>>> users

>>> but alas not one has responded to confirm your assertions.

>>

>> I don't think many people watch these forums, particularly in the US

>> where

>> they are not well known. Haven't you noticed that particularly the NNTP

>> users are disproportionately European? Also note that nobody from the US

>> has disagreed with me either. Most people don't want to use NNTP,

>> Element14 is widely disliked, and few people know about Eagle Central.

>>

>> I can tell you that I've mentioned this to others and have pointed people

>> to my TEXTFLIP ULP that tries to fix vertical text after the fact.

 

And I am still waiting for you to provide a

concrete example of a diagram, data sheet

or whatever (preferably, of course, a schematic diagram)

that has vertical text reading downwards (or "from the left

side"). Since this is, according to you, what everybody

does in the US, it shouldn't be hard to come up with something.

 

Klaus Schmidinger

I (in the US)  Like NNTP. Clear Concise, no frills and searchable.

On 09/27/11 01:42, Olin Lathrop wrote:

warrenbrayshaw wrote on Mon, 26 September 2011 18:20

>> I too would have guessed there were a large number US resident Eagle

>> users

>> but alas not one has responded to confirm your assertions.

 

I don't think many people watch these forums, particularly in the US where

they are not well known.  Haven't you noticed that particularly the NNTP

users are disproportionately European?  Also note that nobody from the US

has disagreed with me either.  Most people don't want to use NNTP,

Element14 is widely disliked, and few people know about Eagle Central.

 

I can tell you that I've mentioned this to others and have pointed people

to my TEXTFLIP ULP that tries to fix vertical text after the fact.

And I am still waiting for you to provide a

concrete example of a diagram, data sheet

or whatever (preferably, of course, a schematic diagram)

that has vertical text reading downwards (or "from the left

side"). Since this is, according to you, what everybody

does in the US, it shouldn't be hard to come up with something.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

warrenbrayshaw wrote on Mon, 26 September 2011 18:20

I too would have guessed there were a large number US resident Eagle

users

but alas not one has responded to confirm your assertions.

I don't think many people watch these forums, particularly in the US where

they are not well known.  Haven't you noticed that particularly the NNTP

users are disproportionately European?  Also note that nobody from the US

has disagreed with me either.  Most people don't want to use NNTP,

Element14 is widely disliked, and few people know about Eagle Central.

I can tell you that I've mentioned this to others and have pointed people

to my TEXTFLIP ULP that tries to fix vertical text after the fact.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Olin Lathrop wrote:

warrenbrayshaw wrote on Mon, 26 September 2011 16:48

>> The request is for documentation and CAD drawings practices  and not

>> the spines of books,

 

As I said before, down-reading vertical text is a strong convention

here. The book spines are merely a way to illustrate this and point

out that there really is a difference.

 

You're not going to find a standard document, but the fact that's how

it's done here should be good enough.  I don't know what fraction of

Eagle users are in the US, but that's got to be a significant number.

 

--

I too would have guessed there were a large number US resident Eagle users

but alas not one has responded to confirm your assertions.

I was only curious. I went looking for an example and found none. I was not

asking for a standard document, just a link to a document or attachment that

provides anecdotal evidence that the convention exists beyond individuals

choosing to use that practice. You are requesting the feature and have not

in the interrum provided examples.

To me it seems that Cadsoft would be justified in not catering for it as the

business case has not been made.

Warren

Viewed / responded via the newsgroup at

news.cadsoft.de

warrenbrayshaw wrote on Mon, 26 September 2011 16:48

The request is for documentation and CAD drawings practices  and not

the spines of books,

As I said before, down-reading vertical text is a strong convention here.

The book spines are merely a way to illustrate this and point out that

there really is a difference.

You're not going to find a standard document, but the fact that's how it's

done here should be good enough.  I don't know what fraction of Eagle users

are in the US, but that's got to be a significant number.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Andreas Weidner wrote:

Am 23.09.2011 23:13, schrieb Warren Brayshaw:

>> Can soemone, a US resident I suspect, post some document links that

>> show down reading text is a common convention somewhere.

 

In my office and our institute's library, we have several hundreds of

English books, mainly from American publishers. Of this awful number

of books, not more than about a handful have their titles printed

upwards. Therefore, downward printing seems to be QUITE common in the

US.

 

Even quite OLD German books have their title pointing downwards, and

only the 'younger' ones (from the 70s and later) seem to have adopted

upwards printing. I myself prefer upwards, of course, because I only

learned reading in the 70s (yes, of the LAST century, and NOT the one

before that)...

 

Andreas Weidner

The request is for documentation and CAD drawings practices  and not the

spines of books, which has derailed the discussion. Interesting though.

Warren

--

Viewed / responded via the newsgroup at

news.cadsoft.de

Am 23.09.2011 23:13, schrieb Warren Brayshaw:

Can soemone, a US resident I suspect, post some document links that show

down reading text is a common convention somewhere.

In my office and our institute's library, we have several hundreds of

English books, mainly from American publishers. Of this awful number of

books, not more than about a handful have their titles printed upwards.

Therefore, downward printing seems to be QUITE common in the US.

Even quite OLD German books have their title pointing downwards, and

only the 'younger' ones (from the 70s and later) seem to have adopted

upwards printing. I myself prefer upwards, of course, because I only

learned reading in the 70s (yes, of the LAST century, and NOT the one

before that)...

Andreas Weidner

Klaus Schmidinger wrote:

On 24.09.2011 00:51, Olin Lathrop wrote:

>> Robert Pearce wrote on Fri, 23 September 2011 12:55

>>> A bookshelf is a very poor model to use as referent.

>>

>> It was merely a example.  How is the text on the spine of german

>> books oriented?

 

German books usually have the text reading upwards.

 

Book titling is irrelevant but the following from Wikipedia  completes our

education.

QUOTE

Spine titling.......

......Early books did not have titles on their spines; rather they were

shelved flat with their spines inward, and titles written with ink along

their fore edges. Modern books display their titles on their spines.

In languages with Chinese-influenced writing systems, the title is written

top-to-bottom, as is the language in general. In languages written

horizontally, conventions differ about the direction in which the title on

the spine is rotated:

• In the United States, the Commonwealth and in Scandinavia, titles are

usually written top-to-bottom on the spine. This means that when the book is

placed on a table with the front cover upwards, the title is correctly

oriented left-to-right on the spine. This practice is reflected in the

industry standards ANSI/NISO Z39.41[22] and ISO 6357.[23]

• In most of continental Europe, titles are conventionally printed

bottom-to-top on the spine so, when the books are placed vertically on

shelves, the title can be read by tilting the head to the left.[24]

END QUOTE

Latin America publications are not mentioned  but a quick search reveals

they mainly follow Europe.

Warren

--

Viewed / responded via the newsgroup at

news.cadsoft.de

Klaus Schmidinger wrote on Sat, 24 September 2011 04:59

German books usually have the text reading upwards.

That's what I thought but wasn't sure.  Here in the US the spine of books

when in a bookcase read down.  This means there definitely are different

regional conventions.

Again, the books are only one indication of the general preference.  The Y

axis label is a special case because the Y axis "flows" upwards and the

text is just going along with that.  Other than in such cases, upwards

vertical text just looks strange or wrong.

Quote:

Imagine a symbol with two pins, one extending to the right

and one to the left (i.e. rotated by 180 degrees). Would you

really want the pin and pad names of the left pin be written

upside down?

No I wouldn't, but this particular case is a lot easier because there are

only 4 possible pin orientations so it's easy to say up front what the text

orientation for each case should be.  In the two vertical cases I want the

text reading down, not up as now.  This should probably be based on a

global vertical text orientation switch.

What I was thinking about more was arbitrary graphical text created with

the TEXT command, like in the silkscreen layer coming from package

definitions.  Those end up in arbitrary locations and orientations anyway,

so I don't care how Eagle originally writes them as long as it's easy for

me to move around and reorient.  Note that easy doesn't include having to

set the spin flag.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

On 23.09.2011 23:13, Warren Brayshaw wrote:

Olin Lathrop wrote:

 

>>

>> One way or another, vertically oriented text needs to read down, not

>> up. If you look at a bookshelf here in the US, the titles on the

>> bindings all read down, for example.

>>

>>

>

I have watched with interest Olin's request for down reading verticle text.

Living in New Zealand, a country with British roots, it maybe understandable

that up reading text is normal. Due to our geograhic location and import /

export habits we are equally exposed to the standards of the US and so

become 'aware' of the many differences. That said, I have never come across

down reading text on a document  or plan.

 

So I searched some US companies for product pdfs to see if I could observe

this down reading text and found none that qualify as Olin describes for a

page that is to be read without rotating it.

 

I've read a lot of datasheets and all graphs have the Y-axis reading up.

 

The only time there was down reading  text, as the page was arrived at, was

a page that had been rotated landscape to portrate clockwise. This is not

normal if the documant is never expected to be bound into a book but happens

when this page would be the left page of an open book

 

Can soemone, a US resident I suspect, post some document links that show

down reading text is a common convention somewhere.

That's a good point, Warren.

So before we continue this thread, I'd like Olin to come

forward with a concrete example of a diagram, data sheet

or whatever (preferably, of course, a schematic diagram)

that has vertical text reading downwards (or "from the left

side"). Maybe I was a little too hasty spending all the

time and effort in implementing this feature, while in

real life nobody actually uses it...

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________