Re: Re: WordPerfect 3.5e and Publishers Today [long]
- "gary.badcock" gary.badcock@... wrote:
> > I have for some weeks been thinking of returning to renewedand "johnhokanson1980" john.hokanson.jr@... responded:
>> WordPerfect 3.5e use, and starting a new writing project with
>> it, for reasons relating to a desire to "re-use and recycle" old
>> computer hardware and software, the wordprocessing
>> capabilities of which are still basically unsurpassed (who
>> really needs graphics and Quartz for composing text?).
>> WordPerfect fits the bill because it runs on really old hardware
>> as well as newer equipment.
>I agree. I just bought a 350Mhz G3 iMac recently, and it's perfectlyAs a writer-editor-translator, I would certainly agree that it's overkill for normal writing purposes. In fact, I do most of my writing in plain text in Eudora or BBEDit or even SimpleText. I believe one writes better, faster without the distractive elements of messing with fonts and formatting commands, and the resulting text can be imported into any program for the appropriate formatting at the editing or layout stage.
>adequate for word processing in WP 3.5e. Maybe even a little overkill
>seeing as it was originally programmed for the 68k Macs.
I'm also a longtime eco-nut so I think it's great to keep those solid old 68ks working as long as possible. I've got a collection of Pluses, SEs and later models waiting for slacker times when I can check them over, load appropriate systems and freeware, and pass them along to kids or seniors who can't afford higher-end stuff but could benefit from wordprocessing, e-mail and basic Web access.
>...How viable isand John H. pointed out:
> > WordPerfect 3.5e for writing a manuscript today, given that
>> publishers need to be able to read and typeset what an
>> author produces? Is conversion to RTF for these purposes
>...Some people have also had problems getting .RTF conversions working.Publishers, of whom I've dealt with many over 40+ years, vary widely in their software preferences and degree of interest in having authors format their own files. (Trust me: most authors are terrible at it and much of my editing work consists of cleaning out their mistakes.) Some publishers use formatted Word .doc, "Track changes" through editing, and import into Quark or InDesign for print publication. Others ask authors to submit only plain text, use in-text markup for editing, and let the layout people deal with font choices, insertion of graphics, etc. Still others have moved to XML-based content management systems.
>Thanks to Edward, we might have made progress towards identifying and
>nipping that in the bud (it now works for me). When all the patches
>and conversions are installed, you can save in Word 6.0 format, which
>is still loadable in the current revisions of Microsoft Office, and
>it might be the best format for portability (WP for PC format is
What an author needs to do is follow the individual publisher's instructions, whatever they may be, and submit what's compatible with their publishing workflow. If A wants a pre-formatted Word file, that's what they'll tell you, but B may well insist on plain text with endnotes hand-numbered in a separate text file, with no formatting but in-text indications of bold and italic.
>Also, as you noted, you won't want to save in the WP Mac (4.x)Right. You can't even count on the recipient's ability to open a .doc file from within their own version of Word if it doesn't automatically open and convert the file when it's double-clicked on the desktop, alas. My own feeling is "K.I.S.S." -- I've got an old Word 5.1a (Mac) I use to check .doc or .rtf files exported from other programs and make sure they arrive at their destination with M$'s own icons to avoid confusing the unsophisticated. Where "Track changes" is required -- as it is by most American businesses -- I have no choice but to use Word 2001, but the rest of the time I can suit myself ;-)
>format, since it's an esoteric format that no modern word process
>seems to recognize.
RTF will be fine most of the time but is not completely reliable between systems -- even between two PCs running the same version of WinWord, it seems, let alone PC and Mac running different programs. The main question is "what appearance features need to be represented by RTF coding?" RTF can't do Word macros or wordprocessor commands -- it just provides the receiving program with instructions as to how to show the visible elements of the manuscript on the screen. The more complex the material, the more things can foul up in transmission.
As "Geoff Gilbert" Geoff@... said,
>...Cross-referenced footnotes do not bring cross theI may be an even older bitch ... but not as much of one as some of the problematic "features" like wordprocessor autonumbering. These "features" are to be avoided in manuscript preparation unless the client instructs you to use them -- in which case any problems are theirs, not yours.
>generated footnote number, but I can save as
>WPWin 6-8, I run Parallels on my MBP, open the
>fie in WPWin and save as Word from there and the
>footnote references are saved.
>I may be a victim of the adage that you can't teach an old dog new tricks.
"Rick Albright" logres@...'s publishers know what they're doing:
>...After all, this is publishing, which was long dominated by MacMy guess is that the OS versions aren't relevant to them: they've got filters (maybe from MacLink Plus?) that will open your 3.5e files.
>hardware and software, so I figured they would have access to
>necessary software. You usually have to complete an information form
>that specifies the software used, the version, and the operating
>system. I made it clear that, at least in my case, it was WordPerfect
>Mac 3.5e, and that it ran under "Classic" (MacOS 9.2.2) under Mac OS
>10.4.11. That's pretty much the way that I filled out the form, and
>no one ever asked any questions.
>I'm only speculating here about RTF, but it may be that publishersNot necessarily, though in some sectors -- for example, for the publishers of software manuals or third-party computer books -- the writers are expected to do most of the formatting themselves, taking and inserting screenshorts and so on, before submitting.
>would prefer that the MS be in a format that has more robust
>formatting features than RTF.
>Another wrinkle is that usuallyFor the sake of the editors who will be working over your manuscript, making sure every element is consistent with CMS and/or the "house style" before it goes to the typography/layout stage. It costs a lot more to fix that kind of thing at the proofreading level.
>publishers are pretty specific (mine was) that the hardcopy you give
>them has to match *exactly* the electronic file, because the editors
>and printers will often compare the two. (The Chicago Manual of
>Style, which is the "bible" for most book publishers, emphasizes this
>point very strongly.) Mine indicated that they did not want a
>converted file, but one that matched the hardcopy exactly.
"Geoffrey S. Mendelson" gsm@... said:
>...Where WP falls down in writting books is that it lacks the "large document"which is why, alas, I've not been using WPMac professionally and am hoping eventually to go back to WP5 for DOS which has a "master document" feature that works splendidly, unlike the Word version which never has been reliably. This puzzles me since in principle it's simple enough: you make a "master" file which allows you to expand individual chapter and appendix files, each of which can contain its own local formatting but takes on the overall document formatting of the master.
>features that real publishing software includes. Most word processors,
>include OpenOffice and the current Microsoft Word do too, so it's not
>much of a loss.
>However if you are writing a book that is mostly text from one source,Actually, the issue there is to use a program whose file format is non-bloated and non-self-corrupting, at which point there's no problem inserting material from multiple files to save it in one, whether it's a book in manuscript or destined to be output to a Postscript printer or made into a PDF.
>without needing to combine various sub documents, illustrations of varying
>kinds and sources, etc, you can produce a decent looking book, pamphlet,
Of course, another issue is whether you are going to use a proper layout program or try to lay the book out in a wordprocessor which wasn't really designed for that job. If professional layout is intended, there's no real reason why the whole book should be supplied in one file: in fact, it makes more sense to provide the text in chapters and the illustrations as individual files to be inserted properly by a pro.
>As for typeseting, you can always produce a postscript document, which willNot many typesetters these days edit postscript language directly. More often than not, you should get specific instructions as to how the printer wants to receive the material for pre-press.
>do ok for small volume typesetting and may do be fine for larger documents
>if the published does not need to add to them.
>If you have Acrobat (the publisher version) installed on the computer youIn fact, quality print publication requires the "distilling" of PDFs from PostScript with a lot of technical skill with cryptic settings, rather than the simple PDF export which is fine for general-purpose documents and can be done in any OS X Mac program or with utilities of the Print2PDF variety.
>can produce PDF files, which are the standard for on-line distribution,
>and if you don't they can be easily converted from postscript files.
> >Basically, I am worried that WordPerfect's "codes" approachThis is why so much of the publishing world is looking at true XML (not the bastardized Microsoft "standard" meant to prevent this) where the files are effectively plain text "tagged" by semantic function and the appearance of tagged elements is set by a separate stylesheet ... which, amongst other things, means the same text can be output to optimize separate uses: for example, with different typefaces and high-res graphics for print, and with screen-optimized typefaces, low-res graphics, additional audio and video, etc. for a Web site.
>>to formatting might cause problems later down the line, as
>>it is rather alien (from what I understand) to today's standards.
>>Very few programs, even on the Mac, can read native WP 3.5e
>>format any more.
>It's a reasonable concern and to be quite blunt, if you want compatibility
>with modern computers, in a form that can be read 20 years from now, you
>probably should stick to Microsoft Office. I'm not saying that 20 years
>from now you won't be able to find someone who can convert the files
>to something usable, but it won't be a computer you buy at the supermarket.
The latest versions of Word use the .docx format (their non-standard OOXML, imperfectly applied) which incorporates some characteristics of XML while retaining various idiosyncracies from multiple generations of Word (line-spacing, indents, etc. etc. defined in terms of prior .doc formats in the spec for the "standard"). Bottom line: sticking to Office formats now, as before, means your files will be problematic in the future. We should all be looking into open standards and files which will be as openable in 20 years as the plain text files of the 1980s are openable now.
> >Any advice appreciated, especially with regards to whatHaving seen what can happen, I don't blame your publisher. In all those decades, nothing has ever fouled up for me with manually-numbered notes in a plain text file, which is more than I can say for notes in any wordprocessor's format. The issue isn't that the codes are hidden from view but that they are actually commands to the computer which are specific to its program and/or operating system. If I recall correctly, EndNote, like other programs of that type, does allow you to export the resulting file in CSV format (comma-separated text, no command codes) which can be imported into practically anything for typesetting purposes.
>>conversion software does with the hidden codes. My publisher
>>does not like hidden codes, objecting even to the use of
>>EndNote and such!
>I suggest in that case you use alternate methods of publishing if you wantThis isn't always at the author's personal option. It obviously depends on who is doing the publishing, but also on who the material is intended for.
>to use WP. There still is lots of room in the world for postscript and PDF
>files, and working old computers for people who need them but don't have
PostScript is great for people in publishing who use PostScript printers but not too useful to anyone else but the "geeks" who use software that will convert it to readable form.
PDF files are everywhere these days and are supposedly portable to any computer but keep in mind that many recent enhancements to the format won't work in older versions of the Reader software, while the size of many modern PDFs is more than older RAM can handle and the fonts on older systems won't be as plentiful or have the same characters as the newer Unicode fonts.
Modern print publishing often involves a workflow like this:
In wordprocessor(s:) author -> editor
-> In layout program: layout and typesetting -> Postscript file
->Distill to PDF to printer's specs
-> Print, bind and distribute
but large publishing operations are increasingly calling for
Author writes to specs for content management system (CMS) and uploads
-> editor(s) work within online CMS
-> layout/typesetting is done within CMS
-> output is styled for multiple uses and archived for future multiple uses
In these systems, it's an axiom that the content has value in itself, regardless of which way one chooses to present it for a particular readership in a particular medium.
Either way, though, the last thing an editor or conventional publisher wants to see is a manuscript in PDF -- even camera-ready rather than "not ready for prime time" -- since the author's work is the start of the process rather than its finished product.
>Despite what people said about the "paperless office" when small computersA great many people don't, though:
>first came out, people still need and want hard copy books. Many people
>I know (including myself) print out PDF files for off-line reading.
- it's unnecessary if you're comfortable reading onscreen
- it's unecological to print stuff to be read only once
- it's normally more expensive to print a PDF book than to buy a printed copy
- the resulting printed copy is more awkward and less durable than a properly printed book.
While some people take easily to electronic reading devices (Amazon's Kindle, the Sony Reader, various PDAs and high-end cellular phones) I suspect there is a bright future for the print-on-demand book. Not so much the order-online, get-it-by-snail-mail kind, but much more for the Espresso Book Machine type of thing where (as you can already do in New York and Calgary) you can go into a bookstore and have them print and bind you a real physical book in less than half an hour from your choice of thousands stored electronically.
Meanwhile, of course, I expect people will continue e-mailing or downloading all kinds of PDF documents which could as easily (and more economically and ecologically) be circulated in plain text or even HTML, since the fancy fonts and colours and whatnot laboriously added by amateur layout artists detract from rather than add to the value of reading the content.
The obsession with "keeping up appearances" means I get multiple megabytes of fancy-formatted stuff that's really not worth reading, whose authors hope the visual aspects will keep people from noticing how badly they write and how little they really have to say for themselves.
By the way, the more savvy publishers also know that there are security risks inherent in any file format that contains something more than plain text. Word macroviruses, malware-containing HTML messages, infected PDFs, spoofed Web sites, etc. are real threats to one's business; software designed to protect against such things isn't perfect and can't be. (See "* 12 security suites tested and 12 security suites fail"
http://ct.techrepublic.com.com/clicks?t=72164037-6d0bee25f1f62d049a797cfceaf731f3-bf&brand=TECHREPUBLIC&s=5 and the archives of Bruce Schneier's very useful CRYPTO-GRAM newsletter http://www.schneier.com/crypto-gram.html for more information.)
####### "Judyth la pomme" #########
Judyth Mermelstein <lapomme@...>
rédactrice, réviseure, traductrice et plus
writer, editor, translator and more
- --- In firstname.lastname@example.org, Judyth Mermelstein <judyth.mermelstein@...>
[a wonderfully long response to my query and ensuing discussion
that included the following]:
> This is why so much of the publishing world is looking at trueXML (not the bastardized Microsoft "standard" meant to prevent
this) where the files are effectively plain text "tagged" by semantic
function and the appearance of tagged elements is set by a separate
stylesheet ... which, amongst other things, means the same text
can be output to optimize separate uses: for example, with
different typefaces and high-res graphics for print, and with
screen-optimized typefaces, low-res graphics, additional audio
and video, etc. for a Web site.
>I am interested in WP basically because it will run on archaic
computers, rather than because of its many and varied List
functions (which publishers manifestly do not want to see in
the files we send them), but the XML reference in Judyth's
post startles me, for reasons relating to accessibility and
the likely longevity of XML files. I hadn't thought of this
before, but (bear with me here), if XML is the future, can
I not readily convert to XML format after the writing is done
An import into OpenOffice would work this magic, wouldn't it?
And isn't OpenOffice one of the best software options for
reading old WP for Mac file formats?
(By the way, WordPerfect codes and structures look to my
untrained eye at least to be a lot like XML.)
>2a. Re: WordPerfect 3.5e and Publishers Today [long]Thanks for the kind words, and I'm sorry to be so late replying: I had no Internet access for a time during the holidays and some fools clogged my e-mail with #$%^& Christmas videos so Yahoo put me on "bounce" and stopped all my list mail. I didn't get to fix that until Monday so I've missed anything interesting that happened after the 25th and haven't had time to catch up.
> Posted by: "gary.badcock" gary.badcock@... gary.badcock
> Date: Sat Dec 13, 2008 9:07 pm ((PST))
>--- In email@example.com, Judyth Mermelstein <judyth.mermelstein@...>
>[a wonderfully long response to my query and ensuing discussion
>that included the following]:
>[snip]You certainly could, and no doubt will some day. When I have some free time, I'll have a look at the WP format; however, I expect some of the cleverer people here will beat me to it and know a lot more about creating a really good macro.
>I am interested in WP basically because it will run on archaic
>computers, rather than because of its many and varied List
>functions (which publishers manifestly do not want to see in
>the files we send them), but the XML reference in Judyth's
>post startles me, for reasons relating to accessibility and
>the likely longevity of XML files. I hadn't thought of this
>before, but (bear with me here), if XML is the future, can
>I not readily convert to XML format after the writing is done
>An import into OpenOffice would work this magic, wouldn't it?Yes to the first. I have no personal experience of the second but I've heard that it works.
> And isn't OpenOffice one of the best software options for
>reading old WP for Mac file formats?
>(By the way, WordPerfect codes and structures look to myThe underlying principle is similar, in that the formatting instructions are separate from the actual content they format. However, WP uses proprietary programming to tell the computer how things should appear. In theory, only Wordperfect itself can do the job, and perhaps only some versions of Wordperfect at that. In practice, some other programs have conversion filters that work reasonably well, translating WP commands into the commands the destination program uses, but these conversions will probably "lose" some information in the process.
>untrained eye at least to be a lot like XML.)
In XML, the "codes" are just plain text tagging so the files themselves can be opened in any text-compatible program on any platform. The tags are interpreted based on their definitions in another plain text file, the "DTD" (document type declaration) which defines which tags are used and how they should appear in their final layout ... but you can format the same content different ways simply by switching the DTD from, say, "Print" to "Web." The DTD itself is endlessly reusable and also cross-platform, so (with the proviso that the same fonts are available or suitable substitution prescribed) your document should appear correctly on somebody else's computer when interpreted by their software, which may well be different from yours.
Note, though, that an XML file and its associated DTD are translated into a visible layout by software, of which there are many kinds with different degrees of sophistication. I haven't yet found a good XSLT program for OS 9 and earlier, so it's a good thing I like working with source files rather than WYSIWYG.
N.B. I am off-line much of the time these days: please
phone if you need me urgently, and bear with me if less
urgent matters take a while to resolve.
Judyth Mermelstein "cogito ergo lego ergo cogito..."
Montreal, QC <judyth.mermelstein@...>
Canada H4G 1J4 <lapomme@...>
"A word to the wise is sufficient. For others, use more."
"Un mot suffit aux sages; pour les autres, il en faut plus."