home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8336 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  4.7 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.arch
  4. Subject: Re: BUSES and other things
  5. Message-ID: <13749@auspex-gw.auspex.com>
  6. Date: 26 Jul 92 20:31:46 GMT
  7. References: <55077@mentor.cc.purdue.edu> <13742@auspex-gw.auspex.com> <55118@mentor.cc.purdue.edu>
  8. Sender: news@auspex-gw.auspex.com
  9. Organization: Auspex Systems, Santa Clara
  10. Lines: 88
  11. Nntp-Posting-Host: bootme.auspex.com
  12.  
  13. >>...because the hardware doesn't know beans about characters; the
  14. >>software can turn pixels on and off as it chooses.  It's the *software*
  15. >>that's responsible for having the characters available.
  16. >
  17. >At what speeds,
  18.  
  19. Fast enough for my purposes; dunno how fast you require them to be.  For
  20. example, when I fired up the Andrew Toolkit "eq" editor, and asked it to
  21. insert an integral sign, the sign popped up quite quickly.
  22.  
  23. It took some time to tell it to do so, as I just selected the "Insert
  24. Symbol" item from the menu, and typed "int" to its prompt.  There may
  25. well be faster ways of getting it to do so - but, even if there aren't,
  26. that has nothing whatsoever to do with the desktop bus; it has to do
  27. with the user interface design of the editor.
  28.  
  29. >and with how large a source file?
  30.  
  31. The only effect that the size of the source file has on how fast the
  32. display can turn a "this is an integral sign" entry in the document into
  33. an integral sign on the screen is that a larger source file *might*
  34. increase the working set size of the editor, and thus *might* cause
  35. pages containing e.g. code to paint the integral sign to be paged out. 
  36. Both of those are "might"s; the editor might well keep only enough of
  37. the file to paint the current screen in memory at any given time, for
  38. example.
  39.  
  40. >>(And if you're going to argue that "bitmapped displays are the wrong
  41. >>answer", you'll have to explain why your favorite solution is better;
  42. >>I'm sure not going to simply take your word for it....)
  43. >
  44. >Now I am not quite sure how much is software and how much is hardware;
  45. >I suspect that it varies considerably between machines.
  46.  
  47. I suspect that the most that modern machines have in the way of
  48. "hardware assist" for that is hardware to copy bit-mapped images of
  49. characters from one place in memory to another.  I believe some
  50. hardware "PostScript accelerators" of some sort have been cooked up for
  51. laser printers; they may show up as window system accelerators, and if
  52. they transform scalable representations of characters into bitmaps, that
  53. form of "hardware assist" may show up in future machines.
  54.  
  55. >But I would
  56. >prefer a dumb terminal with a downloadable character set of size 2^10,
  57. >and which is easily user-modifiable, to the clumsiness of something
  58. >like TeX.
  59.  
  60. What if the only software you have that supports the creation of papers
  61. with mathematical formulae in them, and that uses that dumb terminal,
  62. *IS* TeX?
  63.  
  64. If it's truly a "dumb terminal", it will not, by itself, allow you to
  65. edit documents; you'll need host software to do that.  And even if it
  66. *does* have a 1024-character character set, that doesn't *necessarily*
  67. mean that you'll get any software for it other than, say, a TeX
  68. previewer.
  69.  
  70. A conceivable - although not necessarily likely - scenario is that you
  71. get an editor that you find less clumsy than a plain-text editor + TeX
  72. running on a machine with a bitmapped display, and naught but a TeX
  73. previewer on your terminal....
  74.  
  75. I.e., you're confusing the issue of the capabilities of your display
  76. hardware with the capabilities of the editing software.  To confuse them
  77. in that fashion is unwise; it can lead to conclusions that may not be
  78. valid, e.g. that a dumb terminal with a large downloadable character set
  79. is more likely to give you a document preparation facility for
  80. mathematical papers that you will find preferable to TeX than is a
  81. system with a bitmapped display.
  82.  
  83. >And I want an easily readable source file, not like those
  84. >clumsy messes on the Macs.
  85.  
  86. I rather doubt that the display hardware will have much, if any, effect
  87. on the source file format.  If you wish to complain about the current
  88. state of software for the preparation of mathematical papers, you will
  89. probably find it much more productive to do so in, say, "comp.editors",
  90. or one of the "comp.doc" groups, than here, unless you can demonstrate a
  91. way in which computer system architecture is directly responsible for
  92. that state.
  93.  
  94. (Or, to put it another way, the fact that the Mac has a bitmapped
  95. display has, as yet, not been demonstrated to have had any effect
  96. whatsoever on the format of the source file used by the
  97. document-preparation software you've used, so if your reasoning is
  98. "well, all these systems with bitmapped displays do not meet with my
  99. approval, therefore bitmapped displays are bad", then, unless you have
  100. some data you haven't shown us all yet, your reasoning is bogus....)
  101.