An image problem and a big fat bug

Amid the deep gloom of the Sunday Times jumping the Apple ship and sundry corporate share price swoops up and down, there’s FrameMaker. FrameMaker? you ask. Surely most designers use Quark for publishing? Yes, most UK magazine publishers do. But quite a lot of catalogue and book designers opt for FrameMaker. It has serious limitations but, for those publishers, its simplicity of book page layout and its wonderful ability to create indexes, cross-references, contents lists and tables of illustrations in the areas of text and document handling makes all its image handling hassle worthwhile.

Image handling hassle? Yes. You can’t for example, as you can with Quark, simply import an image into a picture box and start grabbing handles and playing around with it. In FrameMaker you have to put images into special boxes for cropping and sizing, and when you resize an image you do so at the expense of resolution.

And it doesn’t remember the original resolution, so you’re stuffed if you haven’t written it down. So, because that’s hopeless for print production, you have to go into Photoshop, prepare your image at the exact size, export it to FrameMaker and, if you make a tiny error, back into Photoshop. And back again. What a pain.

Some publishers simply forget the abysmal image handling, don’t use it and get outsiders to drop in the pics after everything else is done. This had been a notable failing of FrameMaker since at least version 3, and I can only think Adobe persists in keeping the application thus crippled because of the need to differentiate Frame-Maker from its own PageMaker, the sort-of Quark rival. It’s true version 5.5 offers new Quark-like colour handling, but since an illustrated book designer won’t want to use the image stuff, that’s a bit irrelevant.

One big, good difference is in the new version’s integration of SGML (structured generic markup language) of which HTML is a kind of sub-set. You create a document in Frame-Maker and write an SGML instruction to arrange the contents to suit different publications, including the Web. It’s very powerful.

A lot of what FrameMaker does can be done in PageMaker and Quark. But in FrameMaker it’s all built-in. And it has great flexibility. If a publisher of illustrated guide books has all its information in a database, it can pick and choose material and publish it in a variety of forms and books. A dream for catalogue publishers.

At the input end, you give authors a Word or WordPerfect template, and when you open their files in FrameMaker, 80 per cent of the typesetting is already done. Like the subsequent cross referencing and indexing, it works and it’s stable. And it has multi-lingual dictionaries for which you would have to pay Quark squillions. So the new version is even better at prosaic book-style tasks.

But it has a major bug. In FrameMaker you glue together a series of files and let it get on with page numbering, cross-referencing, contents listing and so on. But I couldn’t get the new version to work. Some seasoned Frame-Maker users I know followed the instructions to convert existing version 4 files into MIF files – like all publishers they have a lot of material they use on a continuing basis, so being able to use old files is essential. After using a file for a while it accumulates grot so when you upgrade you write it to an MIF interchange file where it’s cleaned up. You then import the cleaned-up file into the new version of FrameMaker.

Trouble is, this doesn’t work from 4 to 5.5. Adobe knows it has problems – it even has a CD ready to resolve them. But, in time-honoured fashion, the CD doesn’t fix all of them. Complaints to Adobe met with silence. Finally, it turned out, there’s a well-staffed British technical service, and it responded almost by return. Pity Adobe didn’t mention it sooner.

Except it didn’t exactly sort out the problem. “Sorting out” meant spending four or five hours per file work-around. Though the CD does sort out rotated text, never a strong point with FrameMaker.

Anyway, if the bug was fixed and a designer-friendly mode of image control instituted, this could be a brilliant program. As it is, buy it if you dare.

Designer’s dictionary

PNG (portable network graphics)

Ping, which is the way to pronounce PNG, is a little program you use to see if you’re firing straight on the Internet. The acronym PNG is actually the suffix for a new graphics file format which has developed partly as a result of Unisys and Compu-serve suddenly remembering a couple of years ago that they owned copyright in the universally-used GIF format and started asking around for royalties. PNG is the direct response to this nonsense and it stands for portable network graphics specification – and it is in the public domain. It compresses better than GIF, it has lossless compression, full alpha blending in 8- and 16-bit modes, full Y2K (year 2000) support, 1-, 2-, 4- and 8-bit palette support plus 16-bit grayscale support. There is 24- and 48-bit truecolour support, and other nice friendly things. But will it prevail? As a replacement for GIF, almost certainly. But equally, it will continue to co-exist with JPEG, TIFF, EPS and all the other favourite formats, including those deploying future-technology wavelets and trixels. Maybe.