> Oh for a pdf -> library converter that'd get the pin types, names
> and numbers right!

One solution may be to look at ClientBasic as Sch:PlacePin has some
parameters that govern Name,Number,X,Y, etc. etc.  but ClientBasic (VB for
all intents and purposes) is a super major pain in the ass to do any string
manipulation (compared to perl ;-))....

I am also sure a server could be written using the Protel API, but (as in
all cases herein) a very specific (say for example) data file (or
spreadsheet) format would have to be defined....  but a database file might
be better (in that the format does not matter, rather the field names and
types do).....

for example, to get an Excel spreadsheet of pin data, one only has to copy
and paste from PDF to Excel (usually through MS-Word, to get the tables
correct)....  This will work if the PDF datasheet is not pages of embedded
images and actually contains real text.

some PDFs are locked which is where ghostview came in (a free'er PDF type
viewer which can do a text extract of pages specified in a range).
passwords were usually ignored in ghostview....

As another solution attempt, I did try to do a database import in a schlib,
but it does not seem to work (even though a lot of the server processes in
schlib are really sch processes, hence Sch:ImportSchematicFromDatabase
doesn't work even though Sch:PlacePin does (in theory))!!!!!  if they could
at least add that feature like how they have it on regular sch's then this
could work very well from the excel/access/export_to->DB4 then import pin
database lists into protel approach...

I used to have an automatic Excel sheet to schematic part generator!!!!!!!!
it was a web automated and COM/OLE Automating perl script (perl is free and
open to everyone) but it was tailored to Cadence unfortunately.... because
cadence's files are all OPEN and TEXT based and NOT ENCAPSULATED in a
DATABASE (and NOT BINARY), it was a matter of my perl script just parsing
Excel sheets of pin data (automatically saved as text files over the web)
and generating the concept/cadence schematic part as the appropriate TEXT
files.  It was then a matter of "pushing pins" around in the cadence
graphical editing environment as the perl script instantiated the pins all
in separate columns based upon pin type (power and ground pins were in two
rows on the top and bottom of the schematic/library graphics page
respectively).  This was a very easy solution to typing in 1200 pins (and
pin names in three different (3 * 1200 = 3600??yikes!) text files
w/different formats as required by some of the processes of the day in
cadence land).... Oh the savings in part-debug time when human fat fingering
of the keyboard is eliminated.

I wish that I could get into protel without any specific requirements on
which language to use (like, for example, by using COM/OLE Automation... I
use it in Perl, C++, C++ Builder and any other language du jour) instead of
*HAVING* to use extremely painful Delphi (C++ Builder would be a good
compromise, because then I would write an OLE Automation wrapper (language
independent) using RAD around protel's EXE/DLLs once the NDA is lifted heh
heh heh....)... sorry, my personal bias.....  I digress...


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*                      - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
* Contact the list manager:
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to