I'm sure they've been using Xyvision for a very very long time. Intertia (a.k.a. switching costs) is probably a big part of it.

It's also very possible that Xyvision has some particular features for scientific/technical stuff that they can't get (or that require expensive add-ons) in QuarkXPress and InDesign.

Regards,

T

I have never used Xyvision, but I can empathize with you for I myself have been around a number of proprietary software applications that are cumbersome at best to use. One of them being Preps, which is a pagination application for production folk. It doesn't even run in OSX, and the software is free, lol, but the silly little key that you have to have costs about $5k I was told. It's horribly confusing, and anyone who does not already know how to use it is better off staying away from it, otherwise, you could really mess up and cost your printer a lot of money.

Automation is generally the biggest reason to still use batch systems like XyVision. Although batch systems are actually capable of a high degree of typographic control (at least the systems that are holdovers from the early days of electronic typesetting, I'm not so sure about some of the newer ones), the features that keep them in the running these days are their ability to handle huge amounts of work in a small amount of time -- as long as things are set up well. They're not designer-friendly software, but awfully useful for companies that produce a lot of material without a lot of custom layouts.

Inertia is a problem with companies that have never stopped using these systems as galley composers, since they're often left with tons of data that can't be converted to other software without effectively starting from scratch. These big systems really come into their own, though, when you use them to process text with standard markup languages (like SGML or XML), rather than their own proprietary coding.

The learning curve for building formats and workflows is awful (which is why they work better in places that don't need a lot of design customization or manual intervention), but once you've built your typographic and pagination specs, things can go very fast.

For instance, I work on a similar system (Miles 33) that has a terrible user interface, its own proprietary command language, and an endless list of maddening quirks, but we can bury all that underneath a workflow that lets us take a dump of marked-up text from a database and spit out hundreds of pages of tables, math, text and artwork with little need for the person processing the books to know how it's all put together.

That set-up might require a huge amount of work for someone else ahead of time, but then formatting and laying out the books themselves is pretty straightforward for everyone else, and the marked-up data can be more easily used for other purposes.