Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Gold/Mining/Energy : Canadian Diamond Play Cafi -- Ignore unavailable to you. Want to Upgrade?

To: E. Charters who wrote (773)	4/13/2003 12:47:13 PM
From: WhatsUpWithThat	Read Replies (1) \| Respond to of 16204

An interesting post. A couple of thoughts follow. XML has nothing to do with formatting of pages, that's HTML. HTML isn't a competitor for PDF. PDF (almost) exactly reproduces on a screen the way a document will print on a Postscript printer; it's a screen Postscript interpreter. An HTML document still has to be translated to Postscript or another Page Description Language to print. Acrobat, one PDF generator, includes security add-ons, form capabilities, and so on; many PDF apps don't. PDF documents are not by definition uneditable, but the ability to send an essentially read-only document is very useful in many business situations (I say "essentially read-only" because editing capability is limited even with a PDF editor, and because most people read PDF docs with Acrobat Reader, which has no editing capability). Could HTML docs one day take over from Word/WordPerfect/etc formats? Microsoft's moving that way, but it requires at the moment huge proprietary extensions to the standard to achieve all the you can do in a full-blown word processor. Write a simple page in WordXP and save it in HTML, and compare the amount of code with that produced by a good HTML editor. Your basic point is that HTML should be extended to be sophisticated enough to obviate the need for proprietary word pro doc formats. I guess my only comment there is there's a lot of work to be done, and even if the stds body catches up to today's word pro apps, future capability changes only at a standard body pace (ie. not fast) Could HTML docs one day take over from PDF? They're different beasts. If you create a Web page with a table, an image and some multi-font text, the HTML contains the text and table text, describes the fonts and table layout, links to the image (which must be made available to load each time the page is loaded). If you make the same doc in a word pro app and convert it to PDF, the resulting file is the Postscript commands required to print - and to display in a PDF reader - the page. Which is better? There are micro-charge charging systems; they need only for people to get interested enough to use them more. Touch typing for the masses? All it needs is practice; if people care to, there are apps they can buy, apps they can borrow from the local library, courses, or good old self-practice. The Dvorak keyboard? Sure it's more efficient and faster, but it faces the same battle it's faced for many decades: too many people use the QWERTY (not IBM) keyboard layout and won't bother want to bother to change. It ain't gonna happen ;-) If you want to change your KB layout, by the way, check mwbrooks.com (among others) Increased bandwidth. Well, that's like arguing against having more money! <g> I'd like both, please. It's inarguable that more bandwidth will help us make better use of the Internet for communication. Local, personalized indexing as you visit pages, that's an interesting thought. It puts a much greater CPU demand on each individual PC, which modern PCs should be able to handle but older ones might be bogged down by (think how big the local index of someone who does a lot of browsing would get). A bigger issue, though, is how to handle refreshing the index. Would your local PC include a site spider that would work to update and refresh the index regularly to prevent stale data? I think that'd be a problem, hundreds of millions of PCs each continually revisiting all the Web sites with data in their local index to refresh the data. And how would you weight a search between locally indexed data and data on the Web that is either new since your original search/work or that was available but you didn't access (and therefore index) on your first go-'round? This isn't to say the idea isn't intriguing, just to explore some of the things that will have to be worked out. As to As each key is entered, the remote document is changed I don't understand why. I wouldn't want you to have to sit and watch my creation/editing process: back-and-forward, up-and-down, pause while thinking, move text blocks from A to B, change formats, write two paras but change mind and delete them... And if you're not proposing that this is for live communication between two or more people but just for getting docs to a site for review after writing, why does it have to be real-time? Even chat room apps (almost all) don't display your typing to others until you hit [RETURN]. It'd be terribly confusing to watch, otherwise, especially in multi-person communications. I think there are two distinct markets here: Internet conferencing, which is still in its infancy but IMO doesn't need the full power of a word processor because the end goal is communication rather than fancy output, and word processing, which can be collaborative, but that collaboration shouldn't be realtime because of how people work as they create and edit a larger, complex, document. And thanks for making my brain work so hard on a weekend morning! ;-) Cheers WUWT