Re: Need a Way to Get Rid of CAM .GPI Files

James Morrison wrote on Tue, 18 January 2011 16:48

I know this has come up before but I'm having to delete a lot of these

lately and it is annoying.

They are generally small, so what's the big deal just leaving them there?

My automated script that makes the ZIP file for board fab includes the GPI

file, although I don't know if any board house has ever looked at it.  I

figure if it resolved even one confusion once it will have been worth it.

It really takes no extra time to deal with since it's all automated.  The

README file that the automated script creates lists the GPI file as "Human

readable photoplotter information", so it can be easily ignored by anyone

that doesn't care.

--

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

On 1/18/2011 2:56 PM, Olin Lathrop wrote:

James Morrison wrote on Tue, 18 January 2011 16:48

>> I know this has come up before but I'm having to delete a lot of these

>> lately and it is annoying.

 

They are generally small, so what's the big deal just leaving them

there? My automated script that makes the ZIP file for board fab

includes the GPI

file, although I don't know if any board house has ever looked at it. I

figure if it resolved even one confusion once it will have been worth

it. It really takes no extra time to deal with since it's all automated.

The

README file that the automated script creates lists the GPI file as "Human

readable photoplotter information", so it can be easily ignored by anyone

that doesn't care.

 

iirc, they only show the last section of the job processed, rather than

the parameters for each file. that could be misleading. the information

in there is of questionable value. probably more useful would be a file

that listed all the extensions and the title that went with that job

section that produced them. A boilerplate addendum of whatever options

may have been in effect could be added, if EAGLE indeed uses anything

that's not standard.

I can easily see how they would be confusing to a manufacturer, seeming

by their inclusion, to require a special setup. Yet giving no clear

information what that setup might be. They are certainly not organized

with the board house in mind, having lots of extraneous info like file

dates. imo, they are only barely human readable.

On 1/18/2011 2:56 PM, Olin Lathrop wrote:

James Morrison wrote on Tue, 18 January 2011 16:48

>> I know this has come up before but I'm having to delete a lot of these

>> lately and it is annoying.

 

They are generally small, so what's the big deal just leaving them

there? My automated script that makes the ZIP file for board fab

includes the GPI

file, although I don't know if any board house has ever looked at it. I

figure if it resolved even one confusion once it will have been worth

it. It really takes no extra time to deal with since it's all automated.

The

README file that the automated script creates lists the GPI file as "Human

readable photoplotter information", so it can be easily ignored by anyone

that doesn't care.

 

iirc, they only show the last section of the job processed, rather than

the parameters for each file. that could be misleading. the information

in there is of questionable value. probably more useful would be a file

that listed all the extensions and the title that went with that job

section that produced them. A boilerplate addendum of whatever options

may have been in effect could be added, if EAGLE indeed uses anything

that's not standard.

I can easily see how they would be confusing to a manufacturer, seeming

by their inclusion, to require a special setup. Yet giving no clear

information what that setup might be. They are certainly not organized

with the board house in mind, having lots of extraneous info like file

dates. imo, they are only barely human readable.