[Gerbv-devel] File read-in logic changes

[Stuart B. <sd...@cl...>]

Hi Guys,

As promised, I spent some time modifying the code which decides what
file type each layer is.  The purpose of this work was to make gerbv
more robust w.r.t. opening random files, and to make it better at
determining the type of any particular file.  You can check out the
code in gerber.c, drill.c, and in pick-and-place.c.   Here are some
random observations and notes related to my work:

*  Amongst the changes I made was to check each file to verify that it
has no non-printing ASCII chars in it.  (I.e. chars whose decmial 
representation is > 127.)  This helps make gerbv more
robust (i.e. fewer segfaults) when reading in random files.  In
particular, gerbv is now smart enough to not crash when you try to
read in a binary file (like a .pdf).  Instead, it just complains that
it doesn't understand the format, and ignores the file.

There is one wrinkle, however.  The file
example/protel-pnp/Pick_Place_for_SE_SG_IF_V2.csv has a non-printing
ascii character in it!  This char is in this line:

"LED200","LED_3M","1260.008mil","1465.26mil","1259.842mil","1515.748mil",
"1260.008mil","1415.26mil","T","270.00","LED GR N 3MM"

The non-printing ascii char is at the end, between GR and N.  The
ascii char is 220 decimal.

I surmise that this char is a German u-umalut, since this file came
from a German guy.  I imagine that the original file called out a
gruen = green LED.

Question:  Which is preferable:  Reject all files which contain
extended ascii characters, or allow gerbv to segfault if a user tries
to import a binary file?  [1]

Note that this is probably only an issue with pick and place files,
since Gerbers and drill files are more constrained w.r.t. their
contents (except in comment fields).

Comments on this issue?


*  I introduced a check for RS-274D.  When an RS-274D file is found,
gerbv prints out a warning.  The check is pretty robust.


*  I also made the check for pick-and-place verify that the following
are true of any file it reads:

   -- The file must have at least one comma in it.

   -- The file must have at least one resistor, cap, or IC (refdes R,
      C, or U).

   -- The file also has to have at least one instance of the strings
      0201, 0402, 0603, 0805, or 1206, or a string indicative of a
      placement layer instruction.

   -- There are some other negative conditions which you can see in the
      pick-and-place.c.

Since determining if a particular file is a pick-place file is hard, I
figured that mandating these conditions is better than mistakenly
opening up any old text file and then segfaulting.  Note that
pick-place files written by gEDA's PCB will pass the above tests, but
other vendor's files might or might not.  However, most assy houses
seem to want a "XYRS" = "XY, rotation, side" format, they want a CSV file,
and they need the refdes of each part, so the above checks are
probably sensible.

Any comments good/bad on this?


*  In the long term, I agree with Dan's suggestion that gerbv ask you
what type of file you have if gerbv is in doubt.  My thought is that
this should *only* apply to pick-and-place files (since Gerber and
drill are pretty cut-and-dried), and should only happen *if* gerbv 
accumulates enough evidence that a file is a pick-and-place file
(i.e. it meets some minimal set of criteria). After that, it can throw
up a window and ask you.  I don't like to be presented with lots of
windows a la GCPrevue when I am just trying to read in a simple file.

I propose we implement this feature not in the coming, 1.1
release, but perhaps as part of a 1.2 (or 1.1.1) release.


*  FWIW, if somebody has other ways of testing for file type, or
other ideas about how it might be done, please feel free to erase or
build upon my work.  It's not cast in stone.


*  Finally, I have found that if you import a pack-place file next to
the corresponding Gerbers, the pick-place image is well over 10 times
larger than the Gerbers.  It looks like there is some type of problem
with the units used to display the pick-place file.  I did not
investigate this issue since I am not familiar with the pick-place
code.

Any ideas about what is wrong?


Cheers,

Stuart

[1]  A third strategy, I suppose, is to reject a file if the ratio
of non-printing ascii chars to total chars is over some threshold,
3% say.  Is this sensible?  Or should we just be strict about allowing
non-printing chars?