Tokyo PC Users Group
	  Home Page
Members Only
Become a Member
Meeting Info & Map
Corporate Members
Workshops & Training
Other Clubs
Job Hunting?

Ionic Column -- October 1997

David Parry

Englishman David Parry lived in Tokyo from 1980 to 1994 and was a TPC member from 1986. A frequent contributor to the AJ, he was Newsletter Publisher from late 1988 to early 1990 and began the Ionic Column in 1992. This column has won a prize and an honorable mention in newsletter awards. To the Tokyo BBS community, he now lives in virtual cyberspace and teleports textually over the ether. On the physical level, he currently lives and works in Düsseldorf, that part of Germany that most resembles Japan.

The Ionic Plinth

This column will be shorter than usual; perhaps we should rename it "The Ionic Plinth." Translation deadlines press harder than usual, and I am leaving shortly for a well-earned week's holiday.

I was going to comment on dictionaries on CD-ROM, but I will hold that over for a while. In the first place, I plan to buy a couple more when I am in London. Secondly, I need to research the subject a bit more. The big question with dictionaries of the sort I am looking for (German-English, primarily) is whether they have a hyperlink function so that you can chase up a whole chain of cross-references to the same work to confirm which of the meanings offered is the most suitable. A dictionary that is basically a list of words and a search engine is not in the same league.

Netroom vs. ASPI

At the moment, the end result of selling my Quantum Tempest SCSI-II hard disk is that I have less hard disk space, a more stable system, and more memory. I can run Netroom as long as I do not attempt to load the ASPI drivers for the NCR SCSI controller. Since I need ASPI to run the CD-ROM drive and the new Jaz drive, it looks as if Netroom will not work on that particular system. Helix Software has had further e-mail from me, I still await a reply. It looks as if I will have to go back to HIMEM.SYS.

The extra memory is much less critical than it used to be, since most of my work is in Windows now. The numerous small DOS-based utilities that I use require little memory, while neither XyWrite nor Q&A are greedy for extra RAM. I was under the impression that having more conventional memory available helped Windows 3.1 to make use of all the extra XMS memory, but I have noticed little if any difference.

All that Jaz

I bought an external Jaz drive, and must have made a mistake in the installation routine, since the installation does not finish under Windows, and the Jaz Tools disk has lost its volume label, which is apparently crucial to the whole process. Iomega provide their own ASPI drivers, which I will test later to see if they coexist with Netroom. The Jaz drive worked when my system was still configured with HIMEM.SYS and the ASPI driver loaded, so I tested it by backing up my hard disk. It was not as fast as I had expected, but its speed and ability to behave as an ordinary disk drive in terms of random access and file management wipes the floor with tape of any kind. I plan to use the Jaz drive to store dictionaries on CD-ROM, plus the mounds of mouldy text files that have accumulated over the years.

File bloat

I keep virtually all the text I have produced over the years; newsletters, translations, and DTP work. Ventura Publisher files were surprisingly compact; the archived TPC newsletters for about 15 months around 1989 fit onto two or three high-density diskettes, including a certain amount of graphics. FrameMaker files are bigger, perhaps two or three times as large in cases where I could make a direct comparison.

My old translations were done with XyWrite, meaning ASCII text with a sprinkling of formatting commands that typically add 2-5% to the size of the file. Five years of work in either French or German could be stored in archived form on one high-density diskette. Then I started to use WinWord in 1994. That year alone took up one diskette. In 1995 I needed two diskettes for the year's work, this being WinWord with little or no graphics-some of the files had a header with a corporate logo, that was about all.

WinWord has the endearing feature that it has a certain minimum file size even if you have only typed one word. A bit like COBOL, which required about 40-50 lines of code just to describe itself. The newer versions of WinWord may be worse, but I don't think I have a WinWord file anywhere under 7 KB. I did notice that the fast save produced noticeably larger files unless one reloaded the file and saved it again, and it also provoked crashes on my SCSI system with a very large file.

Then came the deluge in 1996. A number of jobs included large slabs and blobs of graphics, boosting file sizes. I would get a job with perhaps 300 lines of text, covering about 25 formatted pages and three diskettes. That is, three diskettes when archived. I think I needed about five diskettes for last year. This year? Maybe 10 - 12 diskettes. Next year's output? Filling up a Jaz drive, perhaps?

One issue for text-bashers concerns the newer versions of WinWord. The ones included in Office 95 or Office 97 have a different native format. This caused much gnashing of teeth when a sleepy translator sent a file in Office 97 format to the office here. We could not read it, and nor could the customer. In the end, the translator sent the CD to us so that we could install Office 97 and read the file. That worked, but then we found that Office 97 had wreaked havoc on the original WinWord 7.0 installation, which we finally had to reinstall.

The other problem is that WinWord 7.0 and 8.0 do not have a "Save as" function to save to the format for WinWord 2.0 or 6.0. There is an option on the menu, and it produces a DOC file... which is in fact an RTF (Rich Text Format) file. RTF files are ASCII, and can be huge. Somebody sent me a job with ten of these "DOC" files produced in WinWord 7.0 and saved as RTF. One of the files could not be converted to WinWord's DOC format, either in WinWord or with Word for Word. Two files converted, but refused to load. Why, Buddha alone knows. The other seven squeezed their way in, but turned out to be notably obese. The Billy Bunter Award for Conspicuous Flab must go to the file that tipped the scales at a portly 61 MB uncompressed. A few years back, it would have taken up my entire hard disk. It loaded, but I had time for a coffee break every time I saved that file. The entire job took longer than it should, thanks to the time spent saving. What caused the bloat? Lots of screen dumps in a machine manual of about fifty pages.

Alas, the trend is towards more jobs like that. And the need to add all the formatting of equations, superscripts and subscripts that were not feasible with the old text-based word processors. My pet hate is overwriting files that contains hyperlinks or cross-references; followed only by trying to overwrite text that required complicated formatting that was done by somebody not very familiar with the program and thus made it ten times more difficult to work with. My final peeve; clients who expect me to overwrite files in every word processing or DTP program going. A week ago somebody asked if I had Interleaf, a high-end and expensive DTP program, and could I overwrite a file when translating it? No prizes for guessing my answer.

That's all for this month. I may have comments about new software or system configurations next month, if I have the time to tear myself away from these fascinating but profitable translations.

Comments or feedback or more information?

Contact me:

Compuserve on 100575,2573



© Algorithmica Japonica Copyright Notice: Copyright of material rests with the individual author. Articles may be reprinted by other user groups if the author and original publication are credited. Any other reproduction or use of material herein is prohibited without prior written permission from TPC. The mention of names of products without indication of Trademark or Registered Trademark status in no way implies that these products are not so protected by law.

Algorithmica Japonica

October, 1997

The Newsletter of the Tokyo PC Users Group

Submissions : Editor

Tokyo PC Users Group, Post Office Box 103, Shibuya-Ku, Tokyo 150-8691, JAPAN