OT: Ghostscript, won't install

"Jim Thompson" <To-Email-Use-The-Envelope-Icon_at_On-My-Web-Site.com> wrote in
message news:rcqq76pjop5qed6f8klvdc8cmn491ft0bk_at_4ax.com...
HyperLynx displays coupling and signal interaction between PCB traces
just like you can simulate in PSpice, or any other Spice for that
matter.

Yes, although hasn't the Achille's heal for PSpice has always trying to get
*lossy* coupled lines to simulate properly? I seem to recall that many models
turn lossy coupled lines into a cascade of a fixed loss and lossless coupled
lines, which is only approximately correct, getting worse as the lines become
longer.

That being said, I suspect the main "value add" of HyperLynx is that it knows
how to import all the common PCB file formats and check constraints (such as
"no more than xx mV far-end corsstalk") whereas SPICE can't import PCB layouts
and requires you to provide macros or similar to check for violations.

(?) They evaded addressing how you model a board.

There seems to be a perception in this world that utlizing EM simulation tools
means, "someone lays out a board, and then you feed it to your fancy tool and
tell me how everything interacts, right?" -- when in actuality, except for
small boards, doing so is just way too time-consuming. All the microwave
design tools I'm familiar with (stuff like Microwave Office, Agilent's ADS,
etc.) start with the opposite approach: You lay down your transmission lines,
your discontinuities, etc. -- sometimes using coupled elements that are
behaviorally defined or EM simulated with *small* chunks of bare copper if
you need to -- and once you're all done, THAT defines what the layout looks
like.

In researching for a recent IBIS modeling job, I believe that AMS
modeling is the wave of the future.

I suspect you're correct -- particularly for anyone doing IC design.

I do think IBIS will stick around for awhile for digital guys doing
board-level design, though.

---Joel

I don't know the answer to that. What few simulations I've done
seemed to work AOK.

Probably. I actually got argument from the end-customer wanting me to
PROVE that the IBIS simulation would match the Spice simulation. Even
AFTER I showed that the data points in the IBIS model came from a
simple old-fashioned Spice .PRINT statement... list voltage data
points every specified time step... how could it NOT match

"Jim Thompson" <To-Email-Use-The-Envelope-Icon_at_On-My-Web-Site.com> wrote in
message news:0dsq761craad7qmv8vm9pk0hj4vgocjb8s_at_4ax.com...
I don't know the answer to that. What few simulations I've done
seemed to work AOK.

That idea ("SPICE isn't that good at simulating lossless coupled lines") came
from a college class I took on interconnects. The guy teaching it hadn't ever
worked in industry, though, so there wasn't necessarily always a lot of
correlation between what he thought were challenging problems in industry vs.
reality. (...but he is a nice guy and a good teacher... and he does
attend IEEE-type conferences, and thereby had some contacts with industry
folks...)

Probably. I actually got argument from the end-customer wanting me to
PROVE that the IBIS simulation would match the Spice simulation. Even
AFTER I showed that the data points in the IBIS model came from a
simple old-fashioned Spice .PRINT statement... list voltage data
points every specified time step... how could it NOT match :-(

Maybe he's really just trying to get the real SPICE model out of you! My
understanding is that, other than performance considerations, the main driving
force behind IBIS was that IC manufacturers wouldn't have to publish some of
their "tricks" used in I/O rings (...that giving out the actual SPICE file
would tend to reveal...).

---Joel

"krw_at_att.bizzzzzzzzzzzz" wrote:

On Mon, 30 Aug 2010 16:48:58 -0400, "Michael A. Terrell"
mike.terrell_at_earthlink.net> wrote:


Joerg wrote:

Jim Thompson wrote:
On Mon, 30 Aug 2010 14:46:00 -0400, "Michael A. Terrell"
mike.terrell_at_earthlink.net> wrote:

Joerg wrote:
Michael A. Terrell wrote:
Jim Thompson wrote:
On Sun, 29 Aug 2010 13:44:16 -0700, Joerg ?invalid_at_invalid.invalid?
wrote:

[snip]
?
?It would be very simple if many of the popular tools could at least
?import it. But PS must have fallen from grace, almost none do. However,
?Jim said Paint Shop does and that may be the ticket here because I am
?sure it has a more professional frontend than what I've got now.

PS hasn't fallen from grace... it's very much alive in the fancy
graphical and printing worlds.

Jeorge just doesn't want to take the time to lern how to use it.

Why learn how to drive and maintain a Stanley Steamer when you can buy a
nice gasoline-engine car everywhere?

You seem to be the only one around here with problems with PS. That
doesn't make PS the problem.


Nope, not the only one. Actually, at one client an engineer calls PS
"piece of s..t". He became a lot more fed up with it than I did.

Joerg seems to have problems with just about every software there is.

Maybe he has trouble with RTFM :-)

I also think he needs to run a reputable clean-up tool on his system.
He claims crashes on products I've never had issues with. I think
he's drifted off into DLL-conflict land, due to going "cheap".

Maybe he also needs to read-up on "compatibility" set-ups.


Again, it's only Acrobat that crashes all the time. Now how do you
explain that all other programs including some with a whole lot more
complexity never crash on this here computation machine?

Also, it's machine independent. On the other PCs Acrobat crashes all the
time and nothing else does. Same at clients. To me it is rather clear
what that means.


That their IT department is incompetent?

Aren't they all?


Every one I've dealt with. Secretaries get new computers with all
the RAM and a fast CPU, while engineering gets the outdated junk.
Failing hardware, slow hard drives and 90% misconfigured software that
barely functions. Een worse is when they attempt to repair the
hardware. I have a used outlet strip that came from a local company,
where the IT department wrapped a paper clip around the switch
terminals.

You can describe PS as not contemporary all you want, but you're
wrong. It's the root of PDF creation and virtually ALL high-end
publication products.


Probably so. But I don't want to publish a fancy magazine with it. And
there has got to be a reason why contemporary word processors either
have trouble or flat-out refuse to import it.

On Tue, 31 Aug 2010 14:27:08 -0700, Joerg wrote:

You can describe PS as not contemporary all you want, but you're
wrong. It's the root of PDF creation and virtually ALL high-end
publication products.

Probably so. But I don't want to publish a fancy magazine with it. And
there has got to be a reason why contemporary word processors either
have trouble or flat-out refuse to import it.

Because it wasn't designed to be imported. Programs import data;
PostScript is *code*. It's a full-featured programming language with
conditionals, loops, procedures, arrays, dictionaries, etc. It also
happens to have a very powerful (i.e. not "dumbed down") graphics API.

A PostScript file is just a program which does:

draw stuff
draw more stuff
emit page
draw yet more stuff
emit page
...

Because of this, importing PostScript is a much harder task than importing
a raster image or even a vector format such as SVG (WMF gets a free pass
on Windows because it's just a serialisation of the Windows GDI API).
Consequently, many programs won't even try (on Unix, any program which
imports PostScript will invariably invoke Ghostscript to do the heavy
lifting).

Programs which attempt to import PostScript often fall down trying
to import it in terms of high-level structures like sentences and
paragraphs. Sometimes it works, sometimes it doesn't.

If you use Ghostscript to convert PS to another vector format such as PDF
or SVG, it executes the file with an output driver which outputs
shapes/text/images by emitting PDF/SVG/etc primitives rather than
rastering them to pixels.

This is reliable, but you tend to get very "flat" output, with no
structure. E.g. if you import a schematic which has been converted to PS,
nets will be composed of many individual lines, each symbol will be
composed of lines, areas, and text rather than a monolithic entity, etc.

In fact, many programs output text by printing each character
individually (this allows the program to exert complete control over
kerning, etc); if you import this, you end up with hundreds or even
thousands of single-letter "text objects" rather than lines or paragraphs.

OTOH, even the "flat" output generated by Ghostscript is higher-level than
the grid of pixels in a raster format such as PNG/GIF/etc.

Sometimes I wonder why that was done, placing all the programming power
into the file that finally goes to the printer.

Michael A. Terrell wrote:

"krw_at_att.bizzzzzzzzzzzz" wrote:

Michael A. Terrell wrote:

That their IT department is incompetent?

Aren't they all?

Every one I've dealt with. Secretaries get new computers with all
the RAM and a fast CPU, while engineering gets the outdated junk.
Failing hardware, slow hard drives and 90% misconfigured software that
barely functions. Even worse is when they attempt to repair the
hardware. I have a used outlet strip that came from a local company,
where the IT department wrapped a paper clip around the switch
terminals.

That's about right. The "assistants" do the boss' work. They *need* the
hottest machines. Engineers are on salary. They're only paid to get the job
done.

"Joerg" <invalid_at_invalid.invalid> wrote in message
news:8e5ptpFn4pU1_at_mid.individual.net...
Sometimes I wonder why that was done, placing all the programming power
into the file that finally goes to the printer.

I expect others will have better answers to that question than me, but
recall that variants of PostScript were proposed (and used) as the
desktop GUI API as well: In the late '80s the NeXT computer used
so-called "Display Postscript," which was based on Sun's NeWS ("Network
extensible Window System"). See:
http://en.wikipedia.org/wiki/Display_PostScript If you were already
using Display PostScript for your GUI, it would have been utterly
trivial to support PostScript printers, you know? :-)

I imagine that folks programming the NeXT 30 years ago rightly
considered Windows to be a toy OS, even if it did have decent
desktop-publishing software (indeed, Aldus PageMaker was *the reason*
many people even purchased Windows in the first place) -- to this day
I'm sure many of them are shocked that Windows has come to dominate the
desktop OS arena rather the then-clearly-technologically-superior
NeXTStep, the Amiga OS, or perhaps even the Mac OS.

Sometimes I wonder why that was done, placing all the programming power
into the file that finally goes to the printer. I mean, even in the
early 90's we had rather powerful programs that they called "desktop
publishing software" back then. Expensive, but good. Maybe that was a
reason why people other than myself also abandoned PS, and not just
engineers.

On Tue, 31 Aug 2010 18:51:47 -0700, Joerg wrote:

Sometimes I wonder why that was done, placing all the programming power
into the file that finally goes to the printer. I mean, even in the
early 90's we had rather powerful programs that they called "desktop
publishing software" back then. Expensive, but good. Maybe that was a
reason why people other than myself also abandoned PS, and not just
engineers.

PostScript was an integral part of the "Desktop Publishing" revolution. At
that time, Apple Macs (running either Quark XPress or whatever Adobe's
product was called back then) had the lion's share of the DTP market, and
the LaserWriter was the only printer anyone would consider for serious DTP
work.

The main reason for offloading to the printer was simply performance.
Printing via a lower-level format such as HPGL would require the Mac to
"flatten" the output, plotting individual characters. This would result in
a good chunk of your salary budget being spent on having people watch
"Printing ..." progress bars.

The other reason for using PostScript was that the competitors (mostly
PCL) didn't have the necessary flexibility for professional pre-press
work, e.g. being able to specify halftone patterns, colour spaces, etc. A
lot of the layout work went digital before the print shops did, so the
output from the LaserWriter wasn't just a preview, it was often
"camera-ready artwork" from which the plates would be made.

In the world of Unix isn't PostScript always the printer format of
choice?

"Jim Thompson" <To-Email-Use-The-Envelope-Icon_at_On-My-Web-Site.com> wrote in
message news:j5us76l8b75vooc52jllvp59m5h1f5al1o_at_4ax.com...
In the world of Unix isn't PostScript always the printer format of
choice?

It sure was early-on.

These days most non-"Windows only" printers can be used; the main package that
supports this is called CUPS (Common Unix Printing System).

Like you, I have an HP K850 -- it's supported. But I also have a Canon
multi-function printer... that isn't. :-(

---Joel

I vaguely remember that and IIRC that was often considered hardcore
nerdware.

Most of the non-engineers needed tools that are not
too challenging when it comes to computer skills. They'd totally freak
out if you presented them with this:
http://partners.adobe.com/public/developer/en/ps/sdk/DPS.refmanuals.PSW.pdf

This way it was doomed to fail. Just as Linux was and to some extent
still is. You can't tell a non-tech person "Oh, just get the sources, do
this, that and the other thing, and do another build"

I'm sure many of them are shocked that Windows has come to dominate the
desktop OS arena rather the then-clearly-technologically-superior
NeXTStep, the Amiga OS, or perhaps even the Mac OS.
It was predictable though. Users go the route that's easiest and
affordable, and that was DOS and later Windows.

I know this hurts Linux fans or users but it's the way it is, the way> most
people are. Just like I don't think automatic transmissions are all
that great but the learning curve is short, so most drivers prefer them.

In the world of Unix isn't PostScript always the printer format of
choice?

It sure was early-on.

These days most non-"Windows only" printers can be used; the main package
that supports this is called CUPS (Common Unix Printing System).