Long answer: no, unless there are tools for converting TeX/METAFONT fonts to Adobe Type 1 (not merely PostScript; Type 1 is a specially structured subset of PS) or TrueType. I haven't heard of any. It's more likely that there exist tools to make a set of bitmap (BDF/PCF) fonts from a METAFONT font, but that's not quite the same.
I think you're missing the point. For X screen fonts, you don't want Type 1 PostScript or TrueType fonts, you want well-crafted bitmaps that have been designed for screen display. I don't know about your machine, but on my system, Type 1 and TrueType fonts (other than Microsoft's Web fonts, which were specifically designed for screen display) look awful. Only the bitmap fonts (and Microsoft Web fonts) are readable and acceptable for everyday use. I leave PostScript fonts to gv.
The mf program translates METAFONT format (MF) source files into GF (font raster) and TFM (TeX Font Metrics) files; GF files must be processed by gftopk to produce PK (packed font raster) files. xmbdfed, however, can import PK or GF font files and produce BDF files.
For a neat example of PK fonts in use as screen fonts, check out TeXmacs, which gives you a really nice looking WYSIWYG display (better than anything else I've ever seen running under X). TeXmacs uses fairly large font sizes, however; I'm not sure if you can get legible PK fonts at smaller sizes (for, say, a terminal window).
(By the way, the Type 1 Utils are not GPLed, but are freely available for use or modification (provided you maintain the existing copyright notices), and can be found on Eddie Kohler's Web site. If you want Debian packages, an ancient (pre-Eddie) version is available from the main archives (t1utils), with the current version (t1utils-ek) available from this site (as source, unless you have a PowerPC machine).)
Just what is the attraction of shows such as Survivor anyway?
Where I live now, we have a channel that shows ``Real Life TV'', and it looks awful! I have a life, thank you, and I'm not especially interested in hearing other ``real'' people argue about meaningless topics, fight over who'll get the last slice of bread, debate which of two kinds of music (both of which I despise) is the greatest, have babies, get married, survive on an island (with a huge television crew watching their every move), or anything else!
What happened to having to write shows? To having intelligent people think about ideas and create a dramatic presentation? Oh, yes, it's expensive. It's much cheaper to throw together some people no one would even talk to if they didn't already know them, force them to interact under surveillance, and broadcast the results.
If you want to watch some ``reality'' television that still has some educational and entertainment value, I recommend Junkyard Wars (originally Scrapyard Challenge in Britain), now airing on The Learning Channel.
For some reason, many (maybe even most) of the people writing code for the Macintosh have the idea that they deserve to be paid -- that being rewarded by enthusiastic users thanking them and saying nice things about them is not enough. Although there are some wonderful shareware programs for the Mac that are worth every cent their authors charge and more, there are also many tiny programs whose authors demand US$5-$15 that would be given away for free without a second thought by Unix hackers.
In discussions I've had about why this might be, my friends and I have generally come to the conclusion that because the Macintosh has always been sold as a ``premium'' platform (Macs cost more than roughly comparable PCs, and have traditionally been marketed to appeal to people who want to believe they're ``better'' than the average person), combined with the fact that the Macintosh user community has tended to be less hands-on technically adept, may have created a user community that equates money with quality, and so expects to pay for a quality tool, no matter how trivial. (The Macintosh user community tends to be stereotyped as incompetent and technically ignorant -- in fact, most Mac users just want to concentrate on their work and not on the tools they use to do their work. If they have to pay attention to their tools, they're being distracted from their goals.)
It's also possible that programming the Macintosh is such a chore that Mac programmers do much less of the kind of ``scratch-my-own-itch hacking'' (``I have a problem I need to solve for myself. Hack, hack, hack. Done! Gee, now that I've solved it, I bet other people might interested in this code, too!'') that we see in the open source community. Because the Macintosh presents a polished, closed interface, Mac users don't have the ``gateway drug'' experience Unix users have with the shell: learning how to use shell commands, then learning to assemble those commands into pipelines, writing simple scripts, and then, perhaps, learning to write more complicated programs in languages such as Perl, Python, and C. (Apple provides AppleScript, and people can and have built fairly complicated workflow solutions using AppleScript, but most Mac users never find a need to justify purchasing or printing out the thick manual and learning the language. Even if they did, many Mac applications support only the most basic set of (required) AppleScript commands, making them essentially unscriptable.)
It may be (and we can hope) that MacOS X, with its Unix underpinnings, will allow the world of free (as in both beer and speech) software to penetrate the Macintosh world in a way it never could before. If people can download the vast library of free and open source tools and put them to use (either as compilable source code or as MacOS X installer packages), then shareware that handles the same tasks but can't be modified for a user's specific needs might take a beating, provided that the quality is there.
They only thing they won't let us do is take a picture of our cage -- no cameras allowed anywhere in the facility!
Hmm. When I worked for a startup with a cage at Exodus, we put an AXIS Network Camera in our cage. Since our cage was right by the door, we could see anyone coming in or out of their facility....
Yes, NEXTSTEP and OPENSTEP use Display PostScript. So does Mac OS X Server.
Also what is the network capablitly of the old NeXT display system?
NEXTSTEP and OPENSTEP (hereafter NEXTSTEP) work much like X does: you can display applications running remotely on your screen. But both ends have to be running NEXTSTEP, and the applications have to be native NEXTSTEP applications. That is, you can't display a NEXTSTEP application on your Linux box running X, nor can you display an X client application on your NEXTSTEP machine (unless you're running an X server on that machine, of course).
Quartz no longer uses Display PostScript, as Adobe isn't interested in licensing it (at least not for a low enough price). Quartz is more like ``Display PDF'', and it incorporates much of the font and text support from the orphaned QuickDraw GX.
Also, Quartz is the imaging model; Aqua is the interface. Aqua needs Quartz, but Quartz doesn't need Aqua.
Whoops. I clicked on Submit by accident, but thought I caught it in time. Guess not. Read this message instead...:-\
I cannot argue with the lack of functional, friendly editors for either *ML or its stylesheets. Have we identified a need? Is there a place for a WYSIWYG word processor which manages the tension between local formatting and reuse for the user, which integrates and abstracts away the management of DTD/schemas and stylesheets? Maybe, maybe not. Does our friend want to post his chemistry paper to the web, archive it? Does giving LyX an *ML fluent backend accomplish this goal?
Well, some applications do keep their documents in an SGML or XML format: AbiWord saves files with an abw extension that are (according to file) ``exported SGML document text''. AbiSource's FAQ states that their native file format is XML (and gives some reasons and a link to their DTD). A brief example document might look like the following:
<p style="Heading 1">This is a major heading, level one</p>
<p></p>
<p>So, here we have a basic AbiWord document.</p>
<p></p>
<p>"Say, Joe, whaddya know?" Hmm, no smart quotes.</p>
<p></p>
<p style="Heading 2">This is a second-level header</p>
<p></p>
<p>Some more plain text that isn't particularly important.</p>
<p></p>
<p style="Heading 3">Here we have a third-level header</p>
<p style="Normal"></p>
<p style="Normal">And we're back to normal.</p>
<p style="Normal"></p>
<p style="Normal"></p>
<p style="Normal">Out of curiosity, we have <c props="font-weight:bold">some bold text,</c> and <c props="font-style:italic">some italic text.</c></p>
<p style="Normal"></p>
<p style="Plain Text">This text is in the plain text style, which is kind of like \texttt. Bizarre.</p>
<p style="Normal"></p>
<p style="Block Text">And this text is in the block text style, which I'm guessing is like quotation or quote or <blockquote>.</p>
<p style="Normal"></p>
<p style="Normal">Looks like I was right.</p>
</section>
</abiword>
AbiWord's interface is very Word-like, including rulers for margin adjustment and toolbars with buttons to open, save, and close files; appear in multiple columns; make text italic, bold, underlined, and so forth; and set justification. As such, it's very useful for people moving from other computing platforms who are looking for replacements for their commercial word-processing applications, but that also means that it's not ideal as a structured SGML/XML editor (without a significant amount of additional work, at any rate).
Other applications, such as Dia, a diagramming application, save their output in recognizable XML (file says ``XML 1.0 document text'', and the document looks like XML when you view it in a text editor).
Finally, as I mentioned previously, Conglomerate is specifically designed to be an XML editor, but isn't really available yet. Conglomerate looks like an SGML editor -- it clearly shows the tagging of various bits of text.
In any case, I'm not sure I'm convinced that a WYSIWYG editor is the best approach -- I think some sort of simplified syntax (such as that provided by LaTeX) that could easily be translated to SGML or XML might be a better solution. I like the ideas shown in the screenshots of Conglomerate because they make the structural and other markup very clear without the illusion of control that would be provided by an interface such as AbiWord's. What I think is needed is an interface that would make the structure and other tags clear, and allow tags to be inserted by typing them directly (presumably with some macro features) or selecting from a mutable menu or palette (that would only present viable options for the selected text or cursor location). Although I hate to say it (because I hate them), I don't know that ``wizards'' would be entirely out of place for help with some complicated constructs.
I do think that you're right to believe that such tools will evolve themselves into existence, and that, as they do, more and more people may find themselves using SGML or XML without even realizing that they are. Time will tell.
I find it absolutely incredibly that a publisher is shooting plates from 600dpi laser output, although I can probably guess the publisher.
That makes two of us. I was surprised that they didn't want the LaTeX source, shocked when I found out they didn't want the PostScript, and horrified when I found out what they actually used.
I cannot argue with the lack of functional, friendly editors for either *ML or its stylesheets. Have we identified a need? Is there a place for a WYSIWYG word processor which manages the tension between local formatting and reuse for the user, which integrates and abstracts away the management of DTD/schemas and stylesheets? Maybe, maybe not. Does our friend want to post his chemistry paper to the web, archive it? Does giving LyX an *ML fluent backend accomplish this goal?
Well, some applications do keep their documents in an SGML or XML format: AbiWord saves files with an abw extension that are (according to file) ``exported SGML document text''. AbiSource's FAQ states that their native file format is XML (and gives some reasons and a link to their DTD). A brief example document might look like the following:
<!-- ================================================== =================== --> <!-- This file is an AbiWord document. --> <!-- AbiWord is a free, Open Source word processor. --> <!-- You may obtain more information about AbiWord at www.abisource.com --> <!-- You should not edit this file by hand. --> <!-- ================================================== =================== --> <!-- Build_ID = (none) --> <!-- Build_Version = 0.7.7 --> <!-- Build_Options = LicensedTrademarks:Off Debug:Off --> <!-- Build_Target =/project/debian/abiword-0.7.7/abi-0.7.7/src/Linux_ 2.3.6_ppc_OBJ/obj --> <!-- Build_CompileTime = 12:48:12 --> <!-- Build_CompileDate = Dec 16 1999 --> <abiword version="0.7.7"> <section> <p style="Heading 1">This is a major heading, level one</p> <p></p> <p>So, here we have a basic AbiWord document. Jeez, its spell checker doesn't even know about the spelling of the application's name? That's kind of lame.</p> <p></p> <p>"Say, Joe, whaddya know?"</p> <p></p> <p style="Heading 2">This is a second-level header</p> <p></p> <p>Some more plain text that isn't particularly important.</p> <p></p> <p style="Heading 3">Here we have a third-level header</p> <p style="Normal"></p> <p style="Normal">And we're back to normal.</p> <p style="Normal"></p> <p style="Normal"></p> <p style="Normal">Out of curiosity, we have <c props="font-weight:bold">some bold text,</c> and <c props="font-style:italic">some italic text.</c></p> <p style="Normal"></p> <p style="Plain Text">This text is in the plain text style, which is kind of like \texttt. Bizarre.</p> <p style="Normal"></p> <p style="Block Text">And this text is in the block text style, which I'm guessing is like quotation or quote or <blockquote>.</p> <p style="Normal"></p> <p style="Normal">Looks like I was right.</p> </section> </abiword>
AbiWord's interface is very Word-like, including rulers for margin adjustment and toolbars with buttons to open, save, and close files; appear in multiple columns; make text italic, bold, underlined, and so forth; and set justification. As such, it's very useful for people moving from other computing platforms who are looking for replacements for their commercial word-processing applications, but that means that it's not ideal as a structured SGML/XML editor (without a significant amount of additional work, at any rate).
Other applications, such as Dia, a diagramming application, save their output in recognizable XML (file says ``XML 1.0 document text'', and the document looks like XML when you view it in a text editor).
Finally, as I mentioned previously, Conglomerate is specifically designed to be an XML editor, but isn't really available yet. Conglomerate looks like an SGML editor -- it clearly shows the tagging of various bits of text.
I find it absolutely incredibly that a publisher is shooting plates from 600dpi laser output, although I can probably guess the publisher.
That makes two of us. I was surprised that they didn't want the LaTeX source, and shocked when I found out they didn't want the PostScript, and horrified when I found out what they actually used.
SGML's "takeoff" is pretty well established, friend. You would be hard pressed to find a professional, hot-type emulating typesetting system which does not speak SGML. And as a basis for solid, enterprise level document management system, it's fundamental constructs (and by extension XML's) are unparalleled. ... The balance of your critique is specific to the desktop platforms and Linux in particular, where the demand for professional-quality type layout and DMS are somewhat limited and, as you say, the popularity and quality of the TeX tools have discouraged innovation.
I think it would be fair to say that all of my critique is specific to desktop platforms, and not just to Linux, either. SGML and XML clearly have a role to play in the world of professional publishing and ``enterprise-level document management systems'', and I acknowledged that role up front. But the specific question asked by Cactvs142 dealt with whether he should write his lab reports using DocBook or TEI, which hardly falls into the areas you describe.
In the world of professional publishing, I suspect that you have either proprietary (and expensive!) software to make creating SGML/XML content not much more complex than writing with a standard word processor (I'm thinking of tools such as Frame, or newspaper systems that provide the user with a terminal complete with specialized function keys to apply styles, etc.) or professionals who are both well versed in and happy to use the raw interfaces. I imagine the same is true for people who have to work with ``enterprise-level document management systems''.
But working with SGML and XML on desktop systems today means working with their raw forms: what tools there are require users to get intimately involved with the internal structures of the systems -- applying tags by hand in a text editor and running obscure command-line tools to generate usable output.
In the world of the average user (corporate or home), however, even command-line interfaces can be scary. People want (and rightly so) an interface like Word's. Users don't want to (or can't) remember obscure tags; they want to write their memos, letters, essays, or lab reports and have the look the way they want; and to not have to do anything more complicated than click on a few buttons and choose some menu items.
Even in the world of the hacker, the current tools for SGML and XML make it harder to use than it needs to be (for instance, it would be nice if psgml-mode switched to a DocBook mode when the DTD in use is DocBook, with a menu containing DocBook tags).
The only tool I'm aware of for editing XML that looks like it might be heading in the right direction (based on the screenshot alone -- the demo isn't much different, given that it doesn't allow you to actually change a document you're viewing) is Conglomerate, and it isn't even close to being ready for public release. If you know of other user-friendly tools, please tell us -- the tools I see at xml.apache.org are all server-oriented, not authoring tools by any stretch of the imagination, and the same seems to be true after a quick search on freshmeat.
When it comes to separating content from appearance, I'm all for it. I do so with both my HTML and LaTeX code. But if SGML/XML editors are rare, tools for creating and editing the style sheets that govern the appearance of those SGML/XML documents don't even seem to be on the drawing board. (Editing text files doesn't count as a user-friendly interface.)
Finally, as for the existence of ``professional, hot-type emulating typesetting systems [that] speak SGML'', it's great that those systems are out there, but just because such systems are available doesn't mean they're universally (or even commonly) used. I'm wrapping up the editing of a book to be published by a fairly well-known technical publisher (a division of a very well-known publisher). The book was written using LaTeX, but the publisher doesn't even want to see PostScript, let alone the LaTeX source; instead, they want the author to print the book out and send them the printed copy. For his last book, the author only had access to a 600 dpi printer, and the quality of the finished book shows that lack. This book will, at least, be printed using a 1200 dpi printer. If a major publishing house is still publishing commercial books in this primitive way, can anyone seriously expect the average business or home user to switch to using SGML or XML for managing far less complex documents?
XML is keen, sure, but so is SGML, and look how it's taken off. Both have their places, although those roles are probably a lot more limited than those being proposed these days. I can see investing in SGML and XML for writing documentation that has to be worked on by large numbers of people or live for a long time, but for anything else I can't quite see the point.
I have to imagine that a big objection to LaTeX is that LaTeX source code doesn't do enough to separate content from appearance, because it doesn't have generic commands to denote specific kinds of content. That's a cop out, though, because it would be fairly trivial to create a standard set of such commands (with a new document class or package), and using them consistently would even allow you to translate your documents to SGML or XML at some later date if you had reason to do so. And it would be a lot easier on authors, as well.
One of the big problems I see with XML/SGML is that the idea of their separating content from appearance has taken hold to the point that people who haven't actually tried to use them don't realize that for each DTD, you need one or more separate applications to translate documents written using that DTD into other, more directly usable formats (such as TeX, LaTeX, HTML, PostScript, or PDF). There is no ``XMLtoPDF'' or ``SGMLtoHTML'' tool. Instead you have DTD-specific tools such as the debiandoc2format tools on my system. I can't quite see how this system is much different, let alone better, than having to use a TeX system to translate LaTeX source code into other formats. I can't even see how it's much better than the situation that existed when people were using AMS-TeX, AMS-LaTeX, LaTeX 2.09, and Plain TeX to write papers, all of which were incompatible to one degree or another, even though they were based on the same core system.
SGML and XML have a long way to go on the road to decent tools for writing documents using their DTDs, as well. Psgml mode for Emacs is swell, but it's not even close to being as useful as AUCTeX is for LaTeX, or even the most basic HTML editors are for HTML. Short of something like Frame, I think SGML needs some serious tool development before it's ready to be a serious contender.
LaTeX, on the other hand, has lots of quite good tools to help you write it, ranging from source-code--oriented tools such as AUCTeX to WYSIWYG tools such as LyX, Textures, and Scientific Word.
Finally, the idea that appearance is unimportant is ludicrous. Maybe someday in the distant future, when everything is viewed in some sort of electronic pad (ala Star Trek), SGML and XML will come into their own. Now, however, the ultimate page-display technology is paper, and I have yet to see a document written in SGML or XML that produced decent printed output without extensive tinkering. Whether that fact can best be explained by accidental weaknesses in the applications doing the translations or deliberate weaknesses imposed by the idea that printed output is irrelevant, I can't say. But attention to the end appearance of documents is an important area that will have to be addressed before I can seriously consider doing all, or even much, of my writing using SGML or XML.
My favorite pointing device of all time is the Kensington TurboMouse trackball. Four physical buttons, one chord. I bought it for my Mac clone, and the software it came with allowed me to do all sorts of amazing things. Program a button to save bookmarks in Netscape? Sure. Avoid Apple's control-click workaround for having one-button mice? Sure. Build a whole menu of things accessible with the click of a button? That, too.
Now that I'm running Debian, I don't get all those wonderful features (although I suppose I could if I bothered). But I still have a three-button trackball that's large enough to use with the palm of my hand or with several fingers instead of a single fingertip, and has the potential to do even more.
The TurboMouse equivalent for the PC is the ExpertMouse, which looks to be exactly the same trackball I have (except for the wiring). Newer solutions include the TurboBall (four buttons, large ball, and a mouse wheel), which I might consider as a replacement for my TurboMouse if I ever buy a newer machine; and the Orbit, which only seems to have two buttons, but still has a large ball.
A great place to look for information about the interaction between society and technology is Phil Agre's Red Rock Eater List. Phil is a professor at UCLA, specializing in the study of the social effects of technology. RRE allows him to share some of the information he comes across -- postings include book lists and excerpts; preprint papers; white papers on technological issues (there's been lots of valuable information on UCITA and ICANN); notes on what he's been reading and thinking about, as well as pointers to cheap pens; conference announcements; and more.
The RRE Web site (notes above) includes some links to book excerpts, including the following:
Sorting Things Out: Classification and Its Consequences by Geoffrey C. Bowker and Susan Leigh Star (November 1999).
The Social Life of Information by John Seely Brown and Paul Duguid (February 2000).
Society on the Line: Information Politics in the Digital Age by William H. Dutton (January 1999).
Database Nation by Simson Garfinkel (January 2000).
Telecommunications and the City: Parallel Transformations by Stephen Graham and Simon Marvin (October 1996).
Net Loss: Government, Technology and the Political Economy of Community in the Age of the Internet by Nathan Newman (July 1999).
Ben Franklin's Web Site: Privacy and Curiosity from Plymouth Rock to the Internet by Robert Ellis Smith (March 2000).
You'll also find links to David Noble's ``Digital Diploma Mills'' series (on the rise of ``distance learning''), and lots more.
Speaking of David Noble, he also specializes in the study of the social impacts of technology, and one or more of his books might be appropriate for your class (although he's not particularly focused on computing). I first encountered his work as an undergrad in a class called ``Science, Technology, and Society'', which included Noble's America by Design (Knopf, 1977) (about the professionalization of engineering in America). Your best bet would probably be Progress Without People (Between the Lines, 1995).
Donald Norman, although mostly focused on user-centered design of computers and software, also has lots of insights into the ways in which people work with computers. The Design of Everyday Things (Doubleday, 1988; called The Psychology of Everyday Things in hardcover) is a classic; you may be especially interested in Things That Make Us Smart: Defending Human Attributes in the Age of the Machine (Addison-Wesley, 1993) and The Invisible Computer: Why Good Products Can Fail, the Personal Computer is So Complex, and Information Appliances are the Solution (MIT Press, 1998).
Finally, take a look at Peter G. Neumann's Computer-Related Risks (based on the RISKS Digest) (ACM Press (Addison-Wesley), 1995) and Thomas K. Landauer's The Trouble with Computers: Usefulness, Usability, and Productivity (MIT Press, 1995).
Re:To M or not to M, that is the question
on
Inversions
·
· Score: 1
AFAIK Mr. Banks is now carrying out his oft expressed plan of releasing ALL his books as Iain M. Banks, regardless of content.
Having just received The Business, his very latest, for Christmas, I have to cast doubt on your assertion. The Business is boldly attributed to Iain Banks (no M.).
You might want to check out the Hometime Web site -- during the last couple of years they've built some houses with amazing home technology built into them -- networking, home theatre/sound systems, and automation, too.
If you read closely, you'll find that Corel isn't really offering a product for Linux -- they're offering a product for x86 Linux.
While it's great to see companies working on commercial Linux applications, it would be nice if they understood that Linux is an operating system that runs on many different platforms, not just x86 machines.
And, yes, I know that they're aiming for the biggest market they can find, and that they need to pay their bills, and all those arguments. But isn't Linux supposed to be about more than that?
Another active chair is the PostureBall, which is basically a large (65 cm diameter) rubber ball like the ``Swiss balls'' used in physical therapy and exercise programs. You inflate it, then sit on it and let air out 'til your hips are just slightly higher than your knees. Because it's a ball, you have to use lots of muscles in your back and legs that don't get used with regular chairs to keep yourself stable. Plus you can roll around a bit (like rocking, but in any direction), and lean back and stretch out your spine, along with some other exercises. Oh, yes -- you can bounce up and down on it!
I've had it for about seven months, and I think it's helped my posture (and my back) quite a bit. I chose the PostureBall over a kneeler chair (which my SO uses) for three reasons: (1) all the kneeler chairs we could find locally were cheap-looking and ugly (my SO's chair was made by a small company in Victoria, BC, that's no longer in business); (2) I felt that the kneeler chairs put too much weight on my knees; and (3) the PostureBall was only US$45 -- we figured that if it didn't work out, it was cheap enough that we could keep it as a conversation piece.:) (It looks like the Fitball people have pretty much the same balls for less money; if you're interested, you might consider going that route.)
As for desks, I use an Ikea Effectiv desk. It's very basic -- essentially it's a table -- but it can be adjusted for height and is modular, with many different shapes and sizes of table tops available. (Mine is very long -- 240 cm (94 in) -- to provide space for our printer and some reference books.)
I also have an Ikea Jerker desk, which is currently in the States. The Jerker is much more adjustable than the Effectiv, but is definitely more of a computer desk than a general purpose desk.
I have a Jerker, too, although I'm not using it right now (complicated situation -- bought it in Canada, took it to California, and then came back to Canada, so I left it with my brother in Seattle, who uses it with his SPARCstation, 20" monitor, etc.). It's a nice desk, and is very adjustable (provided you get someone to help you hold various pieces in place while you move the screws -- I put it together by myself, but needed help to take it apart and put it together again). The Jerker was available in the States as of April, 1999 -- I saw it there when I was visiting Seattle.
I'm currently using an Effektiv desk from Ikea's business furniture section. It's a beautiful (beech top, silver legs and rails), if basic desk, 160 cm x 80 cm (5'3" x 2' 7.5"). We splurged and got an 80 cm x 80 cm section as well (yes, that's right, the desk is 80 cm (2' 7.5") deep and 240 cm (7' 10") long, with a total of seven legs, one of which is a special leg that supports the joint between the desktops but still allows you to scoot back and forth without hitting anything). All of the legs adjust in height. Total cost was somewhere around CN$550, I believe. My computer sits in the corner, with my monitor next to it, and my keyboard and trackball in front. Our printer lives on the far end, leaving me plenty of space in the middle for writing, piling stacks of paper and books, and all the other traditional uses for flat surfaces.
For a chair, I'm using a PostureBall -- a 65 cm diameter rubber ball. Believe it or not, it's really comfortable (once you get used to it), and it's helped my posture a lot (since you need to keep your legs on the floor to keep yourself sitting up, you have to sit up straight). The PostureBall sells for US$45 (we also bought the optional pump).
Lately I've been working as an editor rather than as a Unix sysadmin (editing books on LaTeX, as it happens), and I can tell you that it is infinitely easier to edit textual material using paper and pen than on screen.
Why?
1. Screen resolution is still very low.
Macs have 72 dpi; Windows 96 dpi. X seems to use either 75 or 100 dpi, depending on what fonts you have installed. None of these are very high quality for long-term reading, especially if you consider flicker, sunlight (or room lights) bouncing off the screen, and other related factors. Compare that with the output of a modern laser printer. Mine does 1200 dpi, and it's fast. Most printers these days produce output with at least 600 dpi resolution. Even 300 dpi (from the bad old days) is better on your eyes than staring at a screen.
2. Word processors and text editors encourage sloppy writing.
It's very easy to copy and paste, and equally easy to fail to adjust the pasted text properly. Verbs and articles don't match (``these objects was''), words are repeated (``the the''), words are left out (``when Charlie he wanted''). Because you can't see the whole text (see #3), it's also easy to repeat yourself, or leave something important out.
Spell checkers don't catch most of these errors (some will catch the repeated words). They also won't stop you from using a properly spelled word in the wrong way (``It's over their!'').
3. You can never see the whole text at once.
When you're trying to remember what you wrote five pages back, it's far easier to flip back five pages and compare them side by side than to search out the phrase in an editor. Sure you can open a new window and compare them, but you're still looking at them on screen, and how much screen real estate do you really have?
4. It's easier to reorganize physical objects than virtual ones.
While reading through a text, it's easy to spot how two things in different sections relate, and recombine them, even using scissors and tape, glue, or staples (the original cut and paste!).
5. Reading material on paper encourages rewriting and rethinking, which are almost always a good thing.
Sentences and phrases that seemed great when you wrote them often pale when you read them again. Because a paper copy is detached from the electronic version, you're forced to look at the rewrite holistically, rather than concentrating on one or two words.
Not only that, but reviewing what you've written may give you some new insights into the material, allowing you to see how some ideas fit together or complement one another.
6a. Printed material is cleaner than electronic material.
Assuming you're not using a WYSIWYG editor, it's much easier to concentrate on the *content* of your writing when you don't have all the markup instructions cluttering your view. This goes for LaTeX, HTML, XML, SGML, and any other similar system.
6b. Printed material lets you see how things really look.
Even if you're using a tool that allows you to concentrate on the content rather than the appearance of your document, you often can't really see (WYSIWYG or no) what your document looks like until you have it in front of you in its final form. This comment doesn't really apply to HTML, of course, since you can never really know what a page will look like on every user's browser.
As for code, today's editors certainly make it easier to see what various parts of your code are (through keyword coloring, changes in typeface, etc.). Ultimately, however, extremely subtle problems can often only be found after a detailed code review -- away from the machine where you can be distracted by an endless number of tiny changes you could try, where your code has to stand on its own. Such code review encourages clear writing and the extensive use of comments to explain what's going on. A really clever trick that saves you a few milliseconds may, after examination, turn out to be completely incomprehensible, even to you, and a nightmare to maintain. Having your code spread out in front of you is also apt to give you more insight into ways in which you can combine functions to reduce the overall complexity of your program.
I have serious doubts that computers (in whatever form, even as paper-sized screens with incredible resolution) will ever truly replace pen and paper as the ultimate writing tool. Computers are useful tools, especially for keeping track of citations and references, and for producing high-quality (i.e., typeset) output, but high-quality output depends on high-quality input, and in some very important ways the strengths of the computer interfere with the production of that high-quality input. (To sum up the last paragraph, GIGO.)
I don't know whether they really help with productivity, but I bought mine to help me get on top of all the issues involved with starting a new job: buying a car (and dealing with all of the paperwork, inspections, insurance, testing, and other headaches), keeping track of my new colleagues' contact information (especially e-mail addresses and pager numbers), appointments to interview new staff members, and so forth. I would have been lost (and probably in trouble with the government!) without it.
(I also loaded an application that allowed me to generate the necessary repsonses to skey challenges, needed to access the Linux box that controlled access to the network from outside, which meant that I didn't need to worry about whether the equivalent application was available on any random machine I had to use. Very handy.)
Slashdot Mirror
Long answer: no, unless there are tools for converting TeX/METAFONT fonts to Adobe Type 1 (not merely PostScript; Type 1 is a specially structured subset of PS) or TrueType. I haven't heard of any. It's more likely that there exist tools to make a set of bitmap (BDF/PCF) fonts from a METAFONT font, but that's not quite the same.
I think you're missing the point. For X screen fonts, you don't want Type 1 PostScript or TrueType fonts, you want well-crafted bitmaps that have been designed for screen display. I don't know about your machine, but on my system, Type 1 and TrueType fonts (other than Microsoft's Web fonts, which were specifically designed for screen display) look awful. Only the bitmap fonts (and Microsoft Web fonts) are readable and acceptable for everyday use. I leave PostScript fonts to gv.
The mf program translates METAFONT format (MF) source files into GF (font raster) and TFM (TeX Font Metrics) files; GF files must be processed by gftopk to produce PK (packed font raster) files. xmbdfed, however, can import PK or GF font files and produce BDF files.
For a neat example of PK fonts in use as screen fonts, check out TeXmacs, which gives you a really nice looking WYSIWYG display (better than anything else I've ever seen running under X). TeXmacs uses fairly large font sizes, however; I'm not sure if you can get legible PK fonts at smaller sizes (for, say, a terminal window).
(By the way, the Type 1 Utils are not GPLed, but are freely available for use or modification (provided you maintain the existing copyright notices), and can be found on Eddie Kohler's Web site. If you want Debian packages, an ancient (pre-Eddie) version is available from the main archives (t1utils), with the current version (t1utils-ek) available from this site (as source, unless you have a PowerPC machine).)
Just what is the attraction of shows such as Survivor anyway?
Where I live now, we have a channel that shows ``Real Life TV'', and it looks awful! I have a life, thank you, and I'm not especially interested in hearing other ``real'' people argue about meaningless topics, fight over who'll get the last slice of bread, debate which of two kinds of music (both of which I despise) is the greatest, have babies, get married, survive on an island (with a huge television crew watching their every move), or anything else!
What happened to having to write shows? To having intelligent people think about ideas and create a dramatic presentation? Oh, yes, it's expensive. It's much cheaper to throw together some people no one would even talk to if they didn't already know them, force them to interact under surveillance, and broadcast the results.
If you want to watch some ``reality'' television that still has some educational and entertainment value, I recommend Junkyard Wars (originally Scrapyard Challenge in Britain), now airing on The Learning Channel.
For some reason, many (maybe even most) of the people writing code for the Macintosh have the idea that they deserve to be paid -- that being rewarded by enthusiastic users thanking them and saying nice things about them is not enough. Although there are some wonderful shareware programs for the Mac that are worth every cent their authors charge and more, there are also many tiny programs whose authors demand US$5-$15 that would be given away for free without a second thought by Unix hackers.
In discussions I've had about why this might be, my friends and I have generally come to the conclusion that because the Macintosh has always been sold as a ``premium'' platform (Macs cost more than roughly comparable PCs, and have traditionally been marketed to appeal to people who want to believe they're ``better'' than the average person), combined with the fact that the Macintosh user community has tended to be less hands-on technically adept, may have created a user community that equates money with quality, and so expects to pay for a quality tool, no matter how trivial. (The Macintosh user community tends to be stereotyped as incompetent and technically ignorant -- in fact, most Mac users just want to concentrate on their work and not on the tools they use to do their work. If they have to pay attention to their tools, they're being distracted from their goals.)
It's also possible that programming the Macintosh is such a chore that Mac programmers do much less of the kind of ``scratch-my-own-itch hacking'' (``I have a problem I need to solve for myself. Hack, hack, hack. Done! Gee, now that I've solved it, I bet other people might interested in this code, too!'') that we see in the open source community. Because the Macintosh presents a polished, closed interface, Mac users don't have the ``gateway drug'' experience Unix users have with the shell: learning how to use shell commands, then learning to assemble those commands into pipelines, writing simple scripts, and then, perhaps, learning to write more complicated programs in languages such as Perl, Python, and C. (Apple provides AppleScript, and people can and have built fairly complicated workflow solutions using AppleScript, but most Mac users never find a need to justify purchasing or printing out the thick manual and learning the language. Even if they did, many Mac applications support only the most basic set of (required) AppleScript commands, making them essentially unscriptable.)
It may be (and we can hope) that MacOS X, with its Unix underpinnings, will allow the world of free (as in both beer and speech) software to penetrate the Macintosh world in a way it never could before. If people can download the vast library of free and open source tools and put them to use (either as compilable source code or as MacOS X installer packages), then shareware that handles the same tasks but can't be modified for a user's specific needs might take a beating, provided that the quality is there.
Hooray for LinuxPPC and all, but they aren't the only source for these tools on PowerPC -- Debian has 'em, too, and has for some time.
I looked at the LinuxPPC page, read the descriptions of the RPMs, then did apt-cache search SDL, which told me
Then I did
and my system happily installed these and two additional packages (libggi2 and libgii0), and I was in business.
It's not like the Debian people scrambled to catch up, either. I'm using potato (frozen), which hasn't updated packages for PPC for several days.
Linux != x86 Linux; LinuxPPC != PPC Linux.
They only thing they won't let us do is take a picture of our cage -- no cameras allowed anywhere in the facility!
Hmm. When I worked for a startup with a cage at Exodus, we put an AXIS Network Camera in our cage. Since our cage was right by the door, we could see anyone coming in or out of their facility....
Yes, NEXTSTEP and OPENSTEP use Display PostScript. So does Mac OS X Server.
NEXTSTEP and OPENSTEP (hereafter NEXTSTEP) work much like X does: you can display applications running remotely on your screen. But both ends have to be running NEXTSTEP, and the applications have to be native NEXTSTEP applications. That is, you can't display a NEXTSTEP application on your Linux box running X, nor can you display an X client application on your NEXTSTEP machine (unless you're running an X server on that machine, of course).
Quartz no longer uses Display PostScript, as Adobe isn't interested in licensing it (at least not for a low enough price). Quartz is more like ``Display PDF'', and it incorporates much of the font and text support from the orphaned QuickDraw GX.
Also, Quartz is the imaging model; Aqua is the interface. Aqua needs Quartz, but Quartz doesn't need Aqua.
Whoops. I clicked on Submit by accident, but thought I caught it in time. Guess not. Read this message instead... :-\
I cannot argue with the lack of functional, friendly editors for
either *ML or its stylesheets. Have we identified a need? Is there a
place for a WYSIWYG word processor which manages the tension between
local formatting and reuse for the user, which integrates and
abstracts away the management of DTD/schemas and stylesheets? Maybe,
maybe not. Does our friend want to post his chemistry paper to the
web, archive it? Does giving LyX an *ML fluent backend accomplish this
goal?
Well, some applications do keep their documents in an SGML or XML
format: AbiWord saves files
with an abw extension that are (according to file)
``exported SGML document text''. AbiSource's FAQ
states that their native file format is XML (and gives some reasons
and a link to their
DTD). A brief example document might look like the following:
AbiWord's interface is very Word-like, including rulers for margin
adjustment and toolbars with buttons to open, save, and close files;
appear in multiple columns; make text italic, bold, underlined, and so
forth; and set justification. As such, it's very useful for people
moving from other computing platforms who are looking for replacements
for their commercial word-processing applications, but that also means
that it's not ideal as a structured SGML/XML editor (without a
significant amount of additional work, at any rate).
Other applications, such as Dia, a diagramming
application, save their output in recognizable XML (file says
``XML 1.0 document text'', and the document looks like XML when you
view it in a text editor).
Finally, as I mentioned previously, Conglomerate is specifically
designed to be an XML editor, but isn't really available yet.
Conglomerate looks like an SGML editor -- it clearly shows the tagging
of various bits of text.
In any case, I'm not sure I'm convinced that a WYSIWYG editor is
the best approach -- I think some sort of simplified syntax (such as
that provided by LaTeX) that could easily be translated to SGML or XML
might be a better solution. I like the ideas shown in the screenshots of
Conglomerate because they make the structural and other markup
very clear without the illusion of control that would be provided by
an interface such as AbiWord's. What I think is needed is an
interface that would make the structure and other tags clear, and
allow tags to be inserted by typing them directly (presumably with
some macro features) or selecting from a mutable menu or palette (that
would only present viable options for the selected text or cursor
location). Although I hate to say it (because I hate them), I don't
know that ``wizards'' would be entirely out of place for help with
some complicated constructs.
I do think that you're right to believe that such tools will evolve
themselves into existence, and that, as they do, more and more people
may find themselves using SGML or XML without even realizing that they
are. Time will tell.
I find it absolutely incredibly that a publisher is shooting
plates from 600dpi laser output, although I can probably guess the
publisher.
That makes two of us. I was surprised that they didn't want the
LaTeX source, shocked when I found out they didn't want the
PostScript, and horrified when I found out what they actually
used.
I cannot argue with the lack of functional, friendly editors for either *ML or its stylesheets. Have we identified a need? Is there a place for a WYSIWYG word processor which manages the tension between local formatting and reuse for the user, which integrates and abstracts away the management of DTD/schemas and stylesheets? Maybe, maybe not. Does our friend want to post his chemistry paper to the web, archive it? Does giving LyX an *ML fluent backend accomplish this goal?
Well, some applications do keep their documents in an SGML or XML format: AbiWord saves files with an abw extension that are (according to file) ``exported SGML document text''. AbiSource's FAQ states that their native file format is XML (and gives some reasons and a link to their DTD). A brief example document might look like the following:
AbiWord's interface is very Word-like, including rulers for margin adjustment and toolbars with buttons to open, save, and close files; appear in multiple columns; make text italic, bold, underlined, and so forth; and set justification. As such, it's very useful for people moving from other computing platforms who are looking for replacements for their commercial word-processing applications, but that means that it's not ideal as a structured SGML/XML editor (without a significant amount of additional work, at any rate).
Other applications, such as Dia, a diagramming application, save their output in recognizable XML (file says ``XML 1.0 document text'', and the document looks like XML when you view it in a text editor).
Finally, as I mentioned previously, Conglomerate is specifically designed to be an XML editor, but isn't really available yet. Conglomerate looks like an SGML editor -- it clearly shows the tagging of various bits of text.
I find it absolutely incredibly that a publisher is shooting plates from 600dpi laser output, although I can probably guess the publisher.
That makes two of us. I was surprised that they didn't want the LaTeX source, and shocked when I found out they didn't want the PostScript, and horrified when I found out what they actually used.
I think it would be fair to say that all of my critique is specific to desktop platforms, and not just to Linux, either. SGML and XML clearly have a role to play in the world of professional publishing and ``enterprise-level document management systems'', and I acknowledged that role up front. But the specific question asked by Cactvs142 dealt with whether he should write his lab reports using DocBook or TEI, which hardly falls into the areas you describe.
In the world of professional publishing, I suspect that you have either proprietary (and expensive!) software to make creating SGML/XML content not much more complex than writing with a standard word processor (I'm thinking of tools such as Frame, or newspaper systems that provide the user with a terminal complete with specialized function keys to apply styles, etc.) or professionals who are both well versed in and happy to use the raw interfaces. I imagine the same is true for people who have to work with ``enterprise-level document management systems''.
But working with SGML and XML on desktop systems today means working with their raw forms: what tools there are require users to get intimately involved with the internal structures of the systems -- applying tags by hand in a text editor and running obscure command-line tools to generate usable output.
In the world of the average user (corporate or home), however, even command-line interfaces can be scary. People want (and rightly so) an interface like Word's. Users don't want to (or can't) remember obscure tags; they want to write their memos, letters, essays, or lab reports and have the look the way they want; and to not have to do anything more complicated than click on a few buttons and choose some menu items.
Even in the world of the hacker, the current tools for SGML and XML make it harder to use than it needs to be (for instance, it would be nice if psgml-mode switched to a DocBook mode when the DTD in use is DocBook, with a menu containing DocBook tags).
The only tool I'm aware of for editing XML that looks like it might be heading in the right direction (based on the screenshot alone -- the demo isn't much different, given that it doesn't allow you to actually change a document you're viewing) is Conglomerate, and it isn't even close to being ready for public release. If you know of other user-friendly tools, please tell us -- the tools I see at xml.apache.org are all server-oriented, not authoring tools by any stretch of the imagination, and the same seems to be true after a quick search on freshmeat.
When it comes to separating content from appearance, I'm all for it. I do so with both my HTML and LaTeX code. But if SGML/XML editors are rare, tools for creating and editing the style sheets that govern the appearance of those SGML/XML documents don't even seem to be on the drawing board. (Editing text files doesn't count as a user-friendly interface.)
Finally, as for the existence of ``professional, hot-type emulating typesetting systems [that] speak SGML'', it's great that those systems are out there, but just because such systems are available doesn't mean they're universally (or even commonly) used. I'm wrapping up the editing of a book to be published by a fairly well-known technical publisher (a division of a very well-known publisher). The book was written using LaTeX, but the publisher doesn't even want to see PostScript, let alone the LaTeX source; instead, they want the author to print the book out and send them the printed copy. For his last book, the author only had access to a 600 dpi printer, and the quality of the finished book shows that lack. This book will, at least, be printed using a 1200 dpi printer. If a major publishing house is still publishing commercial books in this primitive way, can anyone seriously expect the average business or home user to switch to using SGML or XML for managing far less complex documents?
Exactly what I was wondering.
XML is keen, sure, but so is SGML, and look how it's taken off. Both have their places, although those roles are probably a lot more limited than those being proposed these days. I can see investing in SGML and XML for writing documentation that has to be worked on by large numbers of people or live for a long time, but for anything else I can't quite see the point.
I have to imagine that a big objection to LaTeX is that LaTeX source code doesn't do enough to separate content from appearance, because it doesn't have generic commands to denote specific kinds of content. That's a cop out, though, because it would be fairly trivial to create a standard set of such commands (with a new document class or package), and using them consistently would even allow you to translate your documents to SGML or XML at some later date if you had reason to do so. And it would be a lot easier on authors, as well.
One of the big problems I see with XML/SGML is that the idea of their separating content from appearance has taken hold to the point that people who haven't actually tried to use them don't realize that for each DTD, you need one or more separate applications to translate documents written using that DTD into other, more directly usable formats (such as TeX, LaTeX, HTML, PostScript, or PDF). There is no ``XMLtoPDF'' or ``SGMLtoHTML'' tool. Instead you have DTD-specific tools such as the debiandoc2format tools on my system. I can't quite see how this system is much different, let alone better, than having to use a TeX system to translate LaTeX source code into other formats. I can't even see how it's much better than the situation that existed when people were using AMS-TeX, AMS-LaTeX, LaTeX 2.09, and Plain TeX to write papers, all of which were incompatible to one degree or another, even though they were based on the same core system.
SGML and XML have a long way to go on the road to decent tools for writing documents using their DTDs, as well. Psgml mode for Emacs is swell, but it's not even close to being as useful as AUCTeX is for LaTeX, or even the most basic HTML editors are for HTML. Short of something like Frame, I think SGML needs some serious tool development before it's ready to be a serious contender.
LaTeX, on the other hand, has lots of quite good tools to help you write it, ranging from source-code--oriented tools such as AUCTeX to WYSIWYG tools such as LyX, Textures, and Scientific Word.
Finally, the idea that appearance is unimportant is ludicrous. Maybe someday in the distant future, when everything is viewed in some sort of electronic pad (ala Star Trek), SGML and XML will come into their own. Now, however, the ultimate page-display technology is paper, and I have yet to see a document written in SGML or XML that produced decent printed output without extensive tinkering. Whether that fact can best be explained by accidental weaknesses in the applications doing the translations or deliberate weaknesses imposed by the idea that printed output is irrelevant, I can't say. But attention to the end appearance of documents is an important area that will have to be addressed before I can seriously consider doing all, or even much, of my writing using SGML or XML.
My favorite pointing device of all time is the Kensington TurboMouse trackball. Four physical buttons, one chord. I bought it for my Mac clone, and the software it came with allowed me to do all sorts of amazing things. Program a button to save bookmarks in Netscape? Sure. Avoid Apple's control-click workaround for having one-button mice? Sure. Build a whole menu of things accessible with the click of a button? That, too.
Now that I'm running Debian, I don't get all those wonderful features (although I suppose I could if I bothered). But I still have a three-button trackball that's large enough to use with the palm of my hand or with several fingers instead of a single fingertip, and has the potential to do even more.
The TurboMouse equivalent for the PC is the ExpertMouse, which looks to be exactly the same trackball I have (except for the wiring). Newer solutions include the TurboBall (four buttons, large ball, and a mouse wheel), which I might consider as a replacement for my TurboMouse if I ever buy a newer machine; and the Orbit, which only seems to have two buttons, but still has a large ball.
A great place to look for information about the interaction between society and technology is Phil Agre's Red Rock Eater List. Phil is a professor at UCLA, specializing in the study of the social effects of technology. RRE allows him to share some of the information he comes across -- postings include book lists and excerpts; preprint papers; white papers on technological issues (there's been lots of valuable information on UCITA and ICANN); notes on what he's been reading and thinking about, as well as pointers to cheap pens; conference announcements; and more.
Phil has lots of papers on his personal page, many of which would satisfy your request. There's also a bibliography of books on the social aspects of computing, and some excellent resources (highly recommended: Networking on the Network, How to Help Someone Use a Computer, and Advice for Undergraduates Considering Graduate School.
The RRE Web site (notes above) includes some links to book excerpts, including the following:
You'll also find links to David Noble's ``Digital Diploma Mills'' series (on the rise of ``distance learning''), and lots more.
Speaking of David Noble, he also specializes in the study of the social impacts of technology, and one or more of his books might be appropriate for your class (although he's not particularly focused on computing). I first encountered his work as an undergrad in a class called ``Science, Technology, and Society'', which included Noble's America by Design (Knopf, 1977) (about the professionalization of engineering in America). Your best bet would probably be Progress Without People (Between the Lines, 1995).
Donald Norman, although mostly focused on user-centered design of computers and software, also has lots of insights into the ways in which people work with computers. The Design of Everyday Things (Doubleday, 1988; called The Psychology of Everyday Things in hardcover) is a classic; you may be especially interested in Things That Make Us Smart: Defending Human Attributes in the Age of the Machine (Addison-Wesley, 1993) and The Invisible Computer: Why Good Products Can Fail, the Personal Computer is So Complex, and Information Appliances are the Solution (MIT Press, 1998).
Finally, take a look at Peter G. Neumann's Computer-Related Risks (based on the RISKS Digest) (ACM Press (Addison-Wesley), 1995) and Thomas K. Landauer's The Trouble with Computers: Usefulness, Usability, and Productivity (MIT Press, 1995).
AFAIK Mr. Banks is now carrying out his oft expressed plan of releasing ALL his books as Iain M. Banks, regardless of content.
Having just received The Business, his very latest, for Christmas, I have to cast doubt on your assertion. The Business is boldly attributed to Iain Banks (no M.).
You might want to check out the Hometime Web site -- during the last couple of years they've built some houses with amazing home technology built into them -- networking, home theatre/sound systems, and automation, too.
If you read closely, you'll find that Corel isn't really offering a product for Linux -- they're offering a product for x86 Linux.
While it's great to see companies working on commercial Linux applications, it would be nice if they understood that Linux is an operating system that runs on many different platforms, not just x86 machines.
And, yes, I know that they're aiming for the biggest market they can find, and that they need to pay their bills, and all those arguments. But isn't Linux supposed to be about more than that?
Another active chair is the PostureBall, which is basically a large (65 cm diameter) rubber ball like the ``Swiss balls'' used in physical therapy and exercise programs. You inflate it, then sit on it and let air out 'til your hips are just slightly higher than your knees. Because it's a ball, you have to use lots of muscles in your back and legs that don't get used with regular chairs to keep yourself stable. Plus you can roll around a bit (like rocking, but in any direction), and lean back and stretch out your spine, along with some other exercises. Oh, yes -- you can bounce up and down on it!
I've had it for about seven months, and I think it's helped my posture (and my back) quite a bit. I chose the PostureBall over a kneeler chair (which my SO uses) for three reasons: (1) all the kneeler chairs we could find locally were cheap-looking and ugly (my SO's chair was made by a small company in Victoria, BC, that's no longer in business); (2) I felt that the kneeler chairs put too much weight on my knees; and (3) the PostureBall was only US$45 -- we figured that if it didn't work out, it was cheap enough that we could keep it as a conversation piece. :) (It looks like the Fitball people have pretty much the same balls for less money; if you're interested, you might consider going that route.)
As for desks, I use an Ikea Effectiv desk. It's very basic -- essentially it's a table -- but it can be adjusted for height and is modular, with many different shapes and sizes of table tops available. (Mine is very long -- 240 cm (94 in) -- to provide space for our printer and some reference books.)
I also have an Ikea Jerker desk, which is currently in the States. The Jerker is much more adjustable than the Effectiv, but is definitely more of a computer desk than a general purpose desk.
I have a Jerker, too, although I'm not using it right now (complicated
situation -- bought it in Canada, took it to California, and then came
back to Canada, so I left it with my brother in Seattle, who uses it
with his SPARCstation, 20" monitor, etc.). It's a nice desk, and is
very adjustable (provided you get someone to help you hold various
pieces in place while you move the screws -- I put it together by
myself, but needed help to take it apart and put it together again).
The Jerker was available in the States as of April, 1999 -- I saw it
there when I was visiting Seattle.
I'm currently using an Effektiv desk from Ikea's business furniture
section. It's a beautiful (beech top, silver legs and rails), if
basic desk, 160 cm x 80 cm (5'3" x 2' 7.5"). We splurged and got an
80 cm x 80 cm section as well (yes, that's right, the desk is 80 cm
(2' 7.5") deep and 240 cm (7' 10") long, with a total of seven legs,
one of which is a special leg that supports the joint between the
desktops but still allows you to scoot back and forth without hitting
anything). All of the legs adjust in height. Total cost was
somewhere around CN$550, I believe. My computer sits in the corner,
with my monitor next to it, and my keyboard and trackball in front.
Our printer lives on the far end, leaving me plenty of space in the
middle for writing, piling stacks of paper and books, and all the
other traditional uses for flat surfaces.
For a chair, I'm using a PostureBall -- a 65 cm diameter
rubber ball. Believe it or not, it's really comfortable (once you get
used to it), and it's helped my posture a lot (since you need to keep
your legs on the floor to keep yourself sitting up, you have to sit up
straight). The PostureBall sells for US$45 (we also bought the
optional pump).
Lately I've been working as an editor rather than as a Unix sysadmin
(editing books on LaTeX, as it happens), and I can tell you that it is
infinitely easier to edit textual material using paper and pen than on
screen.
Why?
1. Screen resolution is still very low.
Macs have 72 dpi; Windows 96 dpi. X seems to use either 75 or
100 dpi, depending on what fonts you have installed. None of
these are very high quality for long-term reading, especially if
you consider flicker, sunlight (or room lights) bouncing off the
screen, and other related factors. Compare that with the output
of a modern laser printer. Mine does 1200 dpi, and it's fast.
Most printers these days produce output with at least 600 dpi
resolution. Even 300 dpi (from the bad old days) is better on
your eyes than staring at a screen.
2. Word processors and text editors encourage sloppy writing.
It's very easy to copy and paste, and equally easy to fail to
adjust the pasted text properly. Verbs and articles don't match
(``these objects was''), words are repeated (``the the''), words
are left out (``when Charlie he wanted''). Because you can't
see the whole text (see #3), it's also easy to repeat yourself,
or leave something important out.
Spell checkers don't catch most of these errors (some will catch
the repeated words). They also won't stop you from using a
properly spelled word in the wrong way (``It's over their!'').
3. You can never see the whole text at once.
When you're trying to remember what you wrote five pages back,
it's far easier to flip back five pages and compare them side by
side than to search out the phrase in an editor. Sure you can
open a new window and compare them, but you're still looking at
them on screen, and how much screen real estate do you really
have?
4. It's easier to reorganize physical objects than virtual ones.
While reading through a text, it's easy to spot how two things
in different sections relate, and recombine them, even using
scissors and tape, glue, or staples (the original cut and
paste!).
5. Reading material on paper encourages rewriting and rethinking,
which are almost always a good thing.
Sentences and phrases that seemed great when you wrote them
often pale when you read them again. Because a paper copy is
detached from the electronic version, you're forced to look at
the rewrite holistically, rather than concentrating on one or
two words.
Not only that, but reviewing what you've written may give you
some new insights into the material, allowing you to see how
some ideas fit together or complement one another.
6a. Printed material is cleaner than electronic material.
Assuming you're not using a WYSIWYG editor, it's much easier to
concentrate on the *content* of your writing when you don't have
all the markup instructions cluttering your view. This goes for
LaTeX, HTML, XML, SGML, and any other similar system.
6b. Printed material lets you see how things really look.
Even if you're using a tool that allows you to concentrate on
the content rather than the appearance of your document, you
often can't really see (WYSIWYG or no) what your document looks
like until you have it in front of you in its final form. This
comment doesn't really apply to HTML, of course, since you can
never really know what a page will look like on every user's
browser.
As for code, today's editors certainly make it easier to see what
various parts of your code are (through keyword coloring, changes in
typeface, etc.). Ultimately, however, extremely subtle problems can
often only be found after a detailed code review -- away from the
machine where you can be distracted by an endless number of tiny
changes you could try, where your code has to stand on its own. Such
code review encourages clear writing and the extensive use of comments
to explain what's going on. A really clever trick that saves you a
few milliseconds may, after examination, turn out to be completely
incomprehensible, even to you, and a nightmare to maintain. Having
your code spread out in front of you is also apt to give you more
insight into ways in which you can combine functions to reduce the
overall complexity of your program.
I have serious doubts that computers (in whatever form, even as
paper-sized screens with incredible resolution) will ever truly
replace pen and paper as the ultimate writing tool. Computers are
useful tools, especially for keeping track of citations and
references, and for producing high-quality (i.e., typeset) output, but
high-quality output depends on high-quality input, and in some very
important ways the strengths of the computer interfere with the
production of that high-quality input. (To sum up the last paragraph,
GIGO.)
I don't know whether they really help with productivity, but I bought
mine to help me get on top of all the issues involved with starting a
new job: buying a car (and dealing with all of the paperwork,
inspections, insurance, testing, and other headaches), keeping track of
my new colleagues' contact information (especially e-mail addresses and
pager numbers), appointments to interview new staff members, and so
forth. I would have been lost (and probably in trouble with the government!) without it.
(I also loaded an application that allowed me to generate the
necessary repsonses to skey challenges, needed to access the Linux box
that controlled access to the network from outside, which meant that I didn't need to worry about whether the equivalent application was available on any random machine I had to use. Very handy.)