🚀 go-pugleaf

In article <329@nancy.UUCP>, magnani@msudoc.ee.mich-state.edu (Steven Magnani EE) writes:
> (I have added comp.lang.postscript to the discussion to get sone
> feedback on this idea. Note that followups go to sci.electronics --SJM)
> 
> The problem:
> 
> In article <1059@PT.CS.CMU.EDU> phd@SPEECH1.CS.CMU.EDU (Paul Dietz) writes:
> >A recurring problem in this news group [sci.electronics] is the need to post 
> >readable schematics. ASCII circuit representations are just too painful to
> >create, and are quite inflexible.
> >
> >WE NEED A STANDARD FOR EXCHANGE OF SCHEMATICS!!!!!!!!!!!
> >
> >Optimally, any standard would have interfaces on many standard
> >hardware configurations. (Mac, PC's, Xwindows, GKS, UNIX Plot, etc.)
> >Also, for those stuck with standard, non-graphics terminals, a human
> >readable form should be generated as a side effect.
> >


There are three functions to be served by electronic schematic
interchange:

1.  provide distribution of the schematic drawings via e-mail
2.  provide electrical netlist of the circuit via e-mail
3.  provide readily computer-manipulable version of schematic so that
    most anyone can edit the schematic

Items one and two are easily met, but three is not.  First, the most
universal graphics file description capability found on software systems
that edit and generate schematics is HPGL, or Hewlett-Packard Graphics
Language.   I strongly suggest this file format be used for distribution
of schematics.  As I said, most, if not ALL schematics editors already
can generate HPGL files of schematics.  Also, many people have access to
HP pen plotters to plot the files.  Additionally, many software packages
exist which permit plotting HPGL files on laser printers and even the
lowly PC/IBM printer (FPLOT for $64 from Horizon Software) can emulate
an HP pen plotter and plot HPGL files.  The HPGL language description is
simple and well documented, lending itself toward simple manipulation
for scaling, rotation, etc.

I suggest including an ASCII text netlist file to describe the circuit
electrically.  This would be a simple connectivity netlist of the kind
generated by most, if not all schematics editors for wirewrapping,
printing signal connection lists, etc.  There are many formats{, and 
any of them would be fine.  One netlist format should be chosen and
a description/specification of the netlist format should be distributed.

The netlist is useful for wirewrapping, parts lists, and even
automatically reading the circuit into a few "smart" schematics editors
that can process netlists for various things.  PCB layout packages are
also usually driven by a netlist file, too.

I personally think that item three is not worth pursuing at this time
because everyone except those having the ONE schematic capture package
using the chosen format would have to write software conversion routines
to convert from the chosen schematics capture package file format into
their local software format, and in general this is a royal pain, not
the least of which is that most schematic packages do not document
thoroughly (or at all) the file format of schematic files.  Since these
packages do generate HPGL files, this is the way to go.  Most of these
packages DO NOT generate postscript files, though if this were wanted
then the best way to do this would be to write and distribute an
HPGL-to-Postscript translation program!

How about it?  Maybe we can get some netlanders interested in writing
and distributing HPGL emulators like the one I mentioned (HPGL to 
Epson/IBM printers) as well as HPGL-to-Postscript.  Since HPGL is a
vector/line description it is easily scaled and then rasterized.  I
believe the IBM printer will do at least approx. 200 dots/inch, so that
using an IBM printer should still allow scaling down a large (D or E)
schematic onto a wide-carriage printer sheet at very readable
resolution.  The reason most schematic capture packages that print
directly to IBM printers have poor resolution is that dump an internal
PC bitmap (scaled to Hercules or EGA resolution) to the PC printer
and if scaling is done, it is done via bitmap scaling from an already
low bitmap resolution to an even lower resolution.