OT: Ghostscript, won't install

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. ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |

          Democrats are best served up prepared as a hash
                Otherwise the dog won't eat it :-)
Reply to
Jim Thompson
Loading thread data ...

"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...

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.

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.

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

Reply to
Joel Koltner

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. The old ones in the early

90's still did but even then with rather mixed success. Back then I (and a lot of others) switched to HPGL, problem solved. Nowadays we just switch to PNG, GIF or similar.
--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Reply to
Joerg

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

That's certainly the way I'd do it. If you're doing a fast LVDS link you'd better know how to lay it out.

My end of the schtick was writing an IBIS model for a chip. Gruesome grunt work. I was hoping for some insight from the seminar... all I got was an advertising spiel :-(

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

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |

          Democrats are best served up prepared as a hash
                Otherwise the dog won't eat it :-)
Reply to
Jim Thompson

"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...

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...)

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

Reply to
Joel Koltner

There was no chance of that. I worked, under NDA, for the chip manufacturer, to make an IBIS model for exactly that reason.

I personally didn't even have schematics, just netlists :-) ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |

          Democrats are best served up prepared as a hash
                Otherwise the dog won't eat it :-)
Reply to
Jim Thompson

However,

am

a

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.

Reply to
krw

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.

Reply to
Nobody

Yes, that's what I began to realize in this thread. PS is not just a storage or print format like pretty much all the others.

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.

The print shops in those days generally wanted an output file that was HP LaserJet compatible. So when we needed some fancy print we printed to file, stored on a floppy and brought that into town. I could actually walk. Data communication by hoofing it :-)

So far I got no output at all. The dark gray lines one can see in GSView simply vanish when writing to a PDF file and even when sending it to a HP Laser. But I don't need to get it going anymore, we've switched to another file format that works.

That was the same with HPGL. You could zoom it up to wazoo and round was still round. But, in most cases PNG or GIF is good enough. Schematics tend not to contain many curve things except lettering and logic gates.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Reply to
Joerg

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:

formatting link
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.

---Joel

Reply to
Joel Koltner

And production gets what the engineers no longer use. :(

I had a good laugh when they hired a new head IT geek at my last job. He had just got the company to buy two new servers and to expand the network from just engineering, to the entire complex. I almost bust my gut trying not to tell him what an idiot he was, when he told me that every computer in the plant would be replaced in the next six months. They bought six new computers a month, to replace what died of old age. He never did get all new computers.

Another IT geek was hired for Y2K compliance. He was upset that one computer only had a 5.25" floppy drive and his diagnostic disk was

3.5". He was complaining about converting it, then gave me a really stupid look when I told him that it didn't matter for two reasons. It wasn't networked, and it didn't have a real time clock. Then I told him it was Heath/Zenith XT computer. I don't think that kid had ever saw anything that old. Then he found that engineering still had about a dozen XT & 286 computers for testbeds. :)

You should have seen what I went through to get a dual printer card for my bench computer. I had three programmers that needed a parallel port. Their idea of constantly swapping the plugs didn't fly. The only place for the computer was up on a shelf, and it took five minutes to change cables for a two minute job. When management ask what the problem was, I told them that a third of my day was wasted, because IT wouldn't spend $20 for a part. An hour later it were ordered along with one for every computer on that product line, and a spare. :)

--
Politicians should only get paid if the budget is balanced, and there is
enough left over to pay them.
Reply to
Michael A. Terrell

I vaguely remember that and IIRC that was often considered hardcore nerdware. Back in those days fancy brochures and documents were completely written or at least finalized by secretaries. Heck, we as engineers didn't even have computers other than the CAD stations and the SW guys' machines. 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:

formatting link

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" :-)

The way to go was this: You started out with all-in-one suites. For me that was MS-Works, best thing since sliced bread because it could handle just about anything a newly self-employed needs. And all that including database for a whopping $109. Learning curve half a day, at the most. Then as the business and its needs grew MS-Word was brought in. Ok, one full day of learning curve but now I had full TOC, indexing and rather unfettered graphics import. The fancy guys then went on to PageMaker and programs like that but I never felt the urge.

It was predictable though. Users go the route that's easiest and affordable, and that was DOS and later Windows. Only Apple could have pushed all this over but their pricing policies were such that IMHO they priced themselves out of most of the market. From an ease-of-use point of view I have to hand it to them, I am not a computer specialist at all yet was able to fix a rather broken Apple computer for an older lady who could not find the manual. I'd attribute that completely to the user friendliness of their machine and software.

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.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Reply to
Joerg

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.

Reply to
Nobody

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

Joerg reminds me of one of my grandfathers... obstinate for the fun of it :-) ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |

          Democrats are best served up prepared as a hash
               Otherwise the dogs won't eat them :-)
Reply to
Jim Thompson

"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...

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

Reply to
Joel Koltner

My HP P2015dn has PostScript support. I've never used it, guess I should try it sometime :-)

When PostScript comes in I usually just run it thru Adobe and take a look.

If there's a scale issue, as there often used to be but rarely anymore, I run it thru Ghostscript to "tile" it. ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |

          Democrats are best served up prepared as a hash
               Otherwise the dogs won't eat them :-)
Reply to
Jim Thompson

The computer nerds had UNIX, the hardware nerds had transistors... :-)

That sort of documentation is meant for programmers, though -- a hardware engineer wouldn't be looking at it.

Agreed, that's a non-starter that obviously fails the "grandma test."

This is true, but you might be underestimating how important marketing was to it as well. Steve Ballmer is a *very* good salesman -- Commodore couldn't begin to compete, and it was only after a decade or two of missteps (including the NeXT!) that Steve Jobs has finally managed to get Apple back to being a real threat to Microsoft.

Here 'ya go, Steve Jobs telling you how great the NeXT is:

formatting link
(click around some... it's certainly not worth watching all 35 minutes of it).

(You're right about Apple's main problem initially being how overpriced they were. These days, while they're not as cheap as PCs, they definitely pay a lot more attention to that...)

Only the Linux fans who won't be satisfied until it takes over the world... which it won't in our lifetimes.

---Joel

Reply to
Joel Koltner

And CUPS usually works by accepting PostScript, and (unless the printer supports PS natively) using Ghostscript to convert it to whatever the printer understands.

It can also accept raster data, but unless that's the original format of the data, client-side rasterisation will usually produce worse results than generating PS.

From the application's perspective, CUPS printing boils down to: find a "destination" (i.e. printer), open a stream for it, write PostScript to the stream.

Reply to
Nobody

Nah, we had tubes :-)

Well, so does PS. You have to install this and that, know command line syntax, certainly not granny-proof. And I knew a lot of secretaries who'd have freaked out over that.

Yes, you had to be good at sales. But in the PC world it mattered less, people who needed PCs (at least back then) were technically and financially savvy. Here the PC archtecture had a major advantage: Clones. In Europe IBM charged very high prices but clone assemblers sprung up everywhere like wildflowers. Not with Apple, you either had to plunk down the dough or you couldn't have one. So, mostly journalists and some other trades with cushy expense accounts bought. Engineers always had PCs.

And he wears a tie!

It sort of does in the embedded world and servers, but that's it. PC? Not a chance.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Reply to
Joerg

Yeah, I remember that. Pre progress bar times, all we had was a command line and the PC would be sitting there. So, most of us did the print job as a batch file and started that at the end of the day. For me that was when my wife called for dinner.

In Europe it was a bit different. Print shops wanted PCL, "printed" to a diskette handed over to the clerk. Super high end I don't know, all I ever did was presentation material. Same for all my business friends. I didn't know anyone other than university folks who stuck with PS.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Reply to
Joerg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.