The Best of both Worlds
T.O.M.S.
In the final part of the series of articles on PC Survival & Maintenance, we mentioned the most satisfying, 'Best of Both Worlds' experience afforded by the combination of a PC running both Windows and RISC OS (under VirtualRPC) and offered to lead on to an article on this topic.
The response was not exactly overwhelming (!); however, the mixed feedback we did receive included a number of fiendishly good ideas, some of which were new to us, so this was the trigger to go ahead. Although we'll deal primarily with the Windows + VirtualRPC combo, some of the topics can apply equally in principle to other combinations such as VirtualRPC running on a Mac, an ARM-powered machine networked with a PC or Mac, or to two networked, ARM-powered machines.
Performance and compatibility
We purposely won't discuss RISC OS performance and software compatibility under VirtualRPC in any detail as these topics have been covered at length elsewhere. Suffice to say that comparative performance tests of typical VirtualRPC installations demonstrate that they show ARM-powered machines a very clean pair of heels in almost every respect. This is especially the case if the host PC is running a recommended Intel Core 2 Duo processor (e.g. the 2.2GHz E4500) and even more so with the faster variants. (Should you require a comparative performance report, please email us for a copy). With the exception of those RISC OS application software titles which specifically require proprietary hardware such as a podule or dongle, virtually all others will run under VirtualRPC, and via the ultra-fast HostFS disc filing system.
Some may require to be installed on the ADFS partition provided, but they're limited typically to "ye olde" software which, say, has anti-piracy protection. Other dated titles may object to running in 32K or 16M screen modes, and/or handling deep sprites, but dropping into a 256-colour screen mode may well resolve that. Display performance has also greatly improved, with VirtualRPC now running at up to 1600×1200 pixels in 16M colours without hesitation and, if you need even more, the ARM7500 option within the StrongARM variants will support screen modes up to 2048×1536 pixels, again in 16M colours. (Note: In this ARM7500 configuration, 'SA-compatible' software will still run, but the very few titles which specifically require StrongARM emulation will not).
File and document exchange
A significant advantage of having both operating systems running 'under the same bonnet' (and generally displayed on the same monitor) is the ease and speed with which files and documents can be moved between the two, in either direction; we'll put this facility to good use later on. However, the topic comes up regularly and, although it's very easy to set up, nevertheless seems to cause some problems, so let's first have a look at this basic feature.
We used to use and advocate TempDir for RISC OS but, having heard of the occasional problem with that arrangement from other users (which we've seen ourselves but only very rarely), we've since opted to use the simplest possible solution, i.e. a standard directory folder which can be 'seen' by both operating systems and into which you can drop files etc for ease of access from both ends.
To organise that, firstly, under RISC OS, generate a standard directory with a suitable name and decide on a convenient place to put it on a HostFS hard disc (not the ADFS partition). We opted to name ours 'Exchange' ™ sounds logical ™ and put it as a sub-directory in the Support folder on all our machines. (It may be safer not to put it within the main !Boot folder as we suspect this might be at the root of at least some of the reported hiccups.) That's the RISC OS side sorted. Now nip across to Windows and track down this newly-generated 'Exchange' directory which, as far as Windows is concerned, is just a standard folder (as indeed are all directories within the RISC OS installation, including '!' applications etc, so there's no need to press <Shift> to open the latter). To find the Exchange folder, open My Computer and keep double-clicking in turn on HDD (C:), Program Files, VirtualAcorn, VirtualRPC-xxx (for the version you have installed) and HardDisc4. You'll now see the familiar contents of your main RISC OS hard disc 'drive' (!Boot, Apps, etc) so, from there, keep double-clicking down the directory tree to locate the new Exchange folder.
Next, right-click over its icon and select the Create Shortcut option; this will generate a duplicate folder, called 'Shortcut to Exchange'. Drag-and-drop (i.e. move) the shortcut folder onto the Windows desktop (leaving the original in the HardDisc4 folder) and, if you wish, rename it, e.g. 'Exchange'.
Now when you open the 'Exchange' directory(ies), via the Windows desktop shortcut and/or on HardDisc4 within VirtualRPC, the related contents should be identical and you can access them directly, under either operating system.
Retaining filetypes
In principle, if you drop an object into the Windows Exchange folder, and then view it in the RISC OS folder, it should have retained its associated RISC OS filetype (assuming there is one) and the object icon will appear as normal; e.g. a JPEG. Very occasionally this doesn't work, but using TypeFind should quickly restore it. If it's a repetitive hiccup however, you'll need to check the relevant filetype is included in the Tools™Options™Hostfs Extensions list, or add the requisite data (see the user guide).
Going from RISC OS to Windows, again in principle the filetype will be retained and the object appears with its related Windows extension automatically attached, e.g. "<filename>.jpg". (This also applies with purely RISC OS filetypes ™ a sprite will appear in Windows in the form "<filename>.spr", a drawfile as "<filename>.aff", and so on. We'll look at using these in Windows in Part 2.) There's a cunning way to doubly ensure filetypes are retained, going from Windows to RISC OS, and that is to place the file(s) in a compressed folder. For simplicity, we suggest using SparkFS under RISC OS as this is compatible with the Windows 'Zip' format.
If you don't have SparkFS, you can use Zippee or, alternatively, generate a compressed, 'zipped' folder under Windows. To do this simply right-click anywhere on the desktop and select the New™Compressed (zipped) Folder option. This can then be accessed under RISC OS using SparkPlug. Many files may already be in a compatible, zipped folder anyway; e.g. most objects downloaded from the net. It's also a fool-proof method of retaining filetypes when moving objects from one stand-alone machine to another, using a floppy disc, CD, USB pen drive or what have you.
To summarise so far, we've spent just a few minutes setting up a simple, direct exchange feature to allow objects to be moved very quickly and easily between Windows and RISC OS and back, accessing a single, standard directory/folder from either end. And we've ensured that filetypes are retained under RISC OS and that file extensions are added under Windows.
Exporting from RISC OS
One reason for having the Exchange folder is to be able to conveniently export documents or whatever from RISC OS but, before consigning them to the outside world, e.g. for commercial printing, first giving them a good checkout in a suitable Windows application. So what you see is what (they) get, which sadly isn't necessarily the case if you send work out direct from RISC OS (been there, done that; quality assurance [QA] and all that).
We've already discussed this in a previous article so, to recap, it really does pay dividends if, say, you export your TechWriter masterpiece in 'Word' format and do the QA bit under Windows. 'Word' is intentionally accentuated because, as we discussed, the document doesn't necessarily have to be checked using Microsoft's Word application; a compatible, freeware alternative such as OpenOffice (Writer) invariably will do just as good a job. An alternative export method which has become favoured over, say, PostScript is the Portable Document Format (PDF) as this can solve all sorts of problems, especially as PDF document production is so well supported under RISC OS and there's a very competent, freeware Windows PDF reader in Adobe's Acrobat which is invaluable for QA checking.
We find this especially convenient where, for example, you wish to include and export RISC OS-specific object(s) in your masterpiece and which, from experience, we find can often be troublesome. Draw objects such as dashed lines and arrows are good examples and it's heartening to find these sometimes tricky things routinely appearing perfectly in Acrobat running under Windows.
That said, we've recently heard of some RISC OS users finding their document recipients have problems reading them in Acrobat. Much has been written elsewhere about the choice of outline fonts and so on, but we've only lately become aware of an unfortunate and evidently little-known 'feature' of Acrobat. This is that, when first installed, or (we think) when it is upgraded, Acrobat's text-smoothing and related features are switched off by default.
This catches people out as, for some reason, it is quite independent of the excellent ClearType feature built into Windows and which (especially if fine-tuned for your monitor using the Tuning feature) is considered by many to be pretty close to the superb standard of the RISC OS font antialiasing we all know and have loved from very early days.
Now we appreciate it might not be politic to ask your document recipient to fiddle with their PDF reader settings but, if that's not the case and you know they're having problems reading your masterpieces, you might like to suggest they double-check that Acrobat's text smoothing isn't switched off. To turn it on, they should first select the Edit™Preferences option and, if it says 'None' in the Rendering™Smooth Text: menu (Fig 1), they need to select For Monitor (for CRTs) or For Laptop/LCD screens, as applicable, and click on OK.
Fig 1 : Switching on Smooth Text in Acrobat
Fig 1 Switching on Smooth Text (Acrobat) While they're there, ticking the Smooth line box will also greatly improve the look of vector graphics and, in effect, replicate the visible differences when viewing them in various RISC OS applications. For comparison, Fig 2 attempts to show the difference between a drawfile displayed in Draw (2a) and nicely antialiased in Artworks (2b); also the equivalent differences between Acrobat's Smooth line art being selected Off (2c) and On (2d). Note also the significant difference between Acrobat's Smooth Text being switched Off (2c) and On (2d).
Fig 2 : Viewing vector graphics in RISC OS and Windows
However, all these features affect only what you see on your display and have no effect on, for example, print quality. (How this figure comes out on your display will also depend on the monitor, screen resolution and scale, so please make allowances for all that).
High-speed printing
Although we've mentioned exporting from RISC OS for QA checking and maybe commercial printing, we can of course also use the excellent features of the built-in Windows printing system which can hugely benefit getting our masterpieces onto paper in-house.
VirtualRPC-users are especially well catered for. In the simplest case, you will have a RISC OS printer definition file (another "PDF" ...) for your printer and, having set that up, printing is then every bit as straightforward as it is under ARM-power (don't worry if the printer has a parallel port and the PC doesn't; USB adaptor cables work just as they do with Iyonix). An interesting performance aside arises here though; how does VirtualRPC compare with the TurboDriver system for real machines? Comparative performance tests conducted in 2004 demonstrated the excellence of TurboDrivers running on, say, a Kinetic RiscPC. Not only did they print some three times faster than a stand-alone Iyonix could achieve (using a standard RISC OS PDF), but even VirtualRPC running on fast, Pentium 4 processor PCs couldn't quite keep up with them!
This bizarre situation was reversed only when the more powerful Athlon and Intel dual-core processors became available, but even now the latter are only some 30-50% faster than TurboDrivers, while Iyonix users have to resort to networking with, say, a 'spare' RiscPC to get back the lost performance (using Ray Favre's DirPrint programme available on www.rayfavre.me.uk/dwapps.html Even the now archaic LaserDirect (17 years old) still works well in this 'best of both worlds' arrangement.
But of course the main problem for ARM-powered users (until recently) has been in trying to source a printer for which a RISC OS PDF or proprietary driver such as PhotoReal exists. Given the massive range of printers, plus the speed with which any one model is invariably replaced, it is hardly surprising that the position got worse by the year.
That was until the splendid GimpPrint and then Gutenprint arrived. GutenPrint is available from Martin Wuerthner at www.mw-software.com/software/gutenprint/gutenprint.html. This gives you the capability to drive your choice of contemporary printer(s), from a repertoire of literally hundreds, and from a stand-alone ARM-powered machine, right up to full 'photo-real' standards, and even with borderless printing.
However, there's a considerable limitation (which is fully acknowledged on the Gutenprint website) and this is in the very long times taken to handle the more demanding print jobs. To put a number to that, the website quotes "more than an hour" to print an A4 photograph to full, photo-real standards.
We've not seen anything as long as that and, in any event, reducing print resolution can limit the time accordingly, sometimes without significant degradation in print quality (in our experience this depends very much on the subject matter). But nevertheless it can be a general problem if you really don't want the computer to be tied up for perhaps very long periods.
This limitation simply doesn't exist with VirtualRPC running on even a very modest PC. Print times using either a RISC OS PDF, or the more universal and excellent UniPrint, are a very small fraction of what a stand-alone ARM-powered machine can achieve. Furthermore, contemporary Core 2 Duo machines will hand back full control of the computer typically from within just a few seconds for laser printing, up to no more than 60-90 seconds for a full A4 photo-real print job. And usually there's then sufficient spare 'oomph' to allow continued use of the computer (including VirtualRPC) while, in the background, the Windows-driven printer gets on with the physical printing.
Ultra-high-speed printing
But there's even an ultra-fast(er) method. If you first move the document across into Windows (e.g. as a PDF) and then print it directly, the sheer speed of response is quite extraordinary. Even with an A4 page sent for maximum-resolution, photo-real printing, the hourglass appears typically for only 1-3 seconds (!) before full computer control is returned, after which the physical printing takes place in the background.
Just think about that: To print an A4 page to full photo-real standards using Gutenprint ties up even Iyonix for an hour or so. The same page printed directly under Windows, to exactly the same standard, takes a mere 1-3 seconds before full computer control is returned to Windows or VirtualRPC. Ooer...
We find this to be an incredible bonus in use, both for business and domestic purposes. To give a recent example, one of us was required (by SWMBO) to produce three copies of a 30-page, A4 sized booklet of much-loved family photographs for doting grandparents etc. You know the sort of thing.
He prepared the job using OPro under VirtualRPC and 'printed' it in PDF (the Adobe Acrobat one) using GhostScript and Ray Favre's (I thought it was by Steve Fryatt - ED) PrintPDF. The booklet was checked for QA under Windows and printed. Full computer control was returned in under two minutes, following which the printer printed off the 3×30 pages, entirely in the background, in under two hours (including replacement of various ink cartridges!) How long would printing the OPro file tie up a stand-alone Iyonix? On the face of it, around 30 hours continuous running to produce just one copy. So is it currently feasible to produce such a document using ARM-power? Frankly debatable. And does this demonstrate the 'Best of Both Worlds'? No contest? You decide.
And in Part 2...
Next time we'll continue with this theme, looking at functional control of Windows printers from the RISC OS desktop, further Windows applications which can accept documents produced under RISC OS (e.g. for third-party editing), font-mapping considerations, enhanced graphics thumbnailing, plus anything else we ™ or you ™ can think of (feedback and more ideas will be welcomed!)