home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / text / frame / 2453 < prev    next >
Encoding:
Text File  |  1992-07-24  |  3.3 KB  |  75 lines
  1. Newsgroups: comp.text.frame
  2. Path: sparky!uunet!stanford.edu!ames!data.nas.nasa.gov!sun444.nas.nasa.gov!harding
  3. From: harding@sun444.nas.nasa.gov (Steve Harding)
  4. Subject: Re: Troff vs FrameMaker Productivity
  5. References: <18486@drutx.ATT.COM> <HAMM.92Jul22094612@toto.austoto.sps.mot.com> <MERLYN.92Jul23142709@romulus.reed.edu>
  6. Sender: news@nas.nasa.gov (News Administrator)
  7. Organization: NASA/Ames Research Center
  8. Date: Fri, 24 Jul 92 16:00:43 GMT
  9. Message-ID: <1992Jul24.160043.21238@nas.nasa.gov>
  10. Reply-To: harding@sun444.nas.nasa.gov (Steve Harding)
  11. Lines: 62
  12.  
  13. In article <MERLYN.92Jul23142709@romulus.reed.edu> merlyn@romulus.reed.edu (Randal L. Schwartz) writes:
  14. >regarding the AT&T memo:
  15. >
  16. >this exactly fits my experiences as a technical author for the past 15 years.
  17. >
  18. >A WYSIWYG is great for 1-up posters and small documents, but the
  19. >moment something gets to be over 20 pages long or written by more than
  20. >one author or maintained over time, you lose -- in a major way.
  21.  
  22. I disagree.  I have produced books over over 600 pp using FrameMaker.
  23. Portions were created by other authors.  We had no problems.
  24.  
  25. ]...[
  26.  
  27. >Case in point:
  28. >
  29. >I co-wrote "Programming Perl" (from O'Reilly and Associates) with
  30. >Larry Wall (the creator of the Perl language).  We were 1000 miles
  31. >apart for all but the signing party at its debut.  Yet we achieved
  32. >clean solid seamless merging of our respective texts because I was
  33. >able to provide a limited troff macro package that forced us to focus
  34. >on the writing and not the representation.
  35. >
  36. >Now, I face a similar challenge on its sequel (tentatively titled
  37. >"Learning Perl"), but with FrameMaker (on a Mac) rather than troff
  38. >(all of OR&A's books are being done in Frame these days).  My
  39. >experience so far has been that the process is *much* slower, because
  40. >I have to keep thinking about design issues.  And I haven't even
  41. >*begun* the phase of the work that will involve collaberation, but
  42. >just thinking through the process is scaring me already.
  43.  
  44. It would seem to me that OR&A would/should have provided you with
  45. templates.  That way you need not be concerned with design issues.
  46.  
  47. >For example, sometimes I'd send a piece of troff text to larry.  He'd
  48. >edit it, and send me back the edited version.  I'd simply run that
  49. >through diff (even if I had changed the draft in the meanwhile), and
  50. >boom, there's the parts he changed.  Way too easy to merge!  Try
  51. >*that* with a Frame doc!
  52.  
  53. Change bars with cut & paste.
  54.  
  55. >And I could also send the doc to others.  Troff is nearly universal
  56. >now that there's a GNU -roff.  And even if they didn't want to format
  57. >it, the source text is recognizable even with the embedded formatting
  58. >controls.  MIF?  You've got to be kidding.
  59. >
  60. >I'm not even going to bring up what the performance differences are
  61. >for me between a good command-line interface that I can layer with
  62. >scripts, and a stoopid point-and-shoot mac-type luser interface.
  63. >
  64. >Grumph.  "Learning Perl" is going to be a tough project.  Down with
  65. >WYSIWYGs for big things!
  66.  
  67. All of the above proves the point that I made in an earlier post.  Authors
  68. are most comfortable in the environment they are used to.  Personally, I
  69. couldn't wait to forget n/troff.
  70.  
  71. steve
  72. --
  73. harding@nas.nasa.gov (work)     steveh@cupertino.ca.us (play -- 408.252.0578)
  74.               Prince trapped in the body of a dirty old man.
  75.