Slashdot Mirror
Alternatives To .DOC As Standard WP Format?
D. C. Sessions asks: "I'm on the Software Task Group of a standards body (JEDEC) which is, among other things, responsible for the DDR memory standard. You may have heard of it. Currently standards drafts must be submitted in an editable word processing format, which right now is interpreted as FrameMaker or MS Word. I find not only offensive, but dangerous that these standards -should- outlive the current MS software that can manipulate them. I've gotten some sympathy on 'bit rot' from the rest of the committee based on showing what current flavors of Word do to documents saved with older versions, but the problem is this: What do I propose as a replacement?" Two that come to mind right off of the top of my head are LaTeX and, of course, HTML. Any other formats that can work just as well as .DOC in most situations and are cross-platform to boot?
"It should (obviously) be an open file format, preferably with an open source tool to access it. It absolutely must be usable on LoseBlows, should be usable on Mac, and (for my own sake) on Linux and Solaris. It must be capable of structured documentation, numbering, tables, and embedded vector graphics. I just don't know of such a beast at present."
XML may be a way out, but there's no XML-based document format on the horizon. (I don't know about this Open E-Book stuff, though.) All in all, the OSS community has failed to provide an open, flexible document format that could compete with MS Word. I'm as unhappy with that as you are, but if you want to change it, all word processor developers must get together and formulate a standard. Is this ever going to happen? Note that most closed-source word processors want to bind their users to their product by using a proprietary, closed format.
--
Staroffice has all the features you describe, and is portable.
-Martin
SoftMaker Office for Windows|Linux|Android
Use a nice SGML/XML application like DocBook. Tools for manipulation are free, anyone can write DocBook, with or without specialist tools (it looks a lot like HTML to the layman).
Don't use HTML, at least use XHTML making sure that you segregate style from content. If you must use HTML, use stylesheets so that formatting is consistent.
But, my recommendation would be to use DocBook (SGML) and use stylesheets and nice free parsers to output TeX, ASCII, RTF, HTML and whatever else people want.
Consider using TeX/LaTeX, postscript, or an XML/SGML variant, like DocBook or HTML.
Basically, what you want is a format the fits the following criteria:
1) The original text can be easily gotten out of the format. This way even if the programs that read the file go the way of the dodo, future programs could still recover the data.
2) The specification is fully open and documented, and preferrably stable and mature.
3) At least one open-source program handles displaying/converting the format. I would recommend storing a copy of this program in the same place as the standards themselves- including shipping source with standards CDs.
You've gotten over the hardest part already- you've realized you have a problem.
Brian
For straight wordprocessing where no layouts are required, it's great. It's ascii with the expressive power of italics and extended symbol recognition. For straight word smithing, that's all anybody needs.
Here's what I do:
1. Do all wordprocessing using a very basic text editor which saves very basic RTFs.
2. Import those files to whatever layout program is needed. (Quark, Pagemaker, whatever.)
The stability of RTFs lies in two areas; Firstly, there will ALWAYS be a selection of homemade editors available upon which to do your writing, and second, there is no financial incentive for big software manufacturers to make RTFs un-importable to their suites and layout packages.
This means that doing all your basic work in RTF will make files readable for a long time to come.
In any case, particularly in the print publishing field, today's software is finally about as good as it needs to get. There's no real reason to switch tools. Unlike with graphics technology, Times Roman simply doesn't need to motion blur and bump map for a writer to work his or her craft. As long as we all keep our old copies of Wordperfect and Pagemaker, everything is fine.
Fantastic Lad
I'm sorry, but I have to disagree with you.
XML is nothing more than a concept - you store data and text within "tags". The tags can be of pretty much any name. The data can be anything. This isn't a standard, it's not even a format.
Basically, XML boils down to: store it in a text file, delimit data, fields, and content by tags. Sorry, that doesn't cut it. You have to do more.
No, if you want to think about using XML for this, you need to talk about the DTD, not XML itself.
So, the question becomes, which DTD? In order to compete with the competition(LaTeX, HTML, PostScript), it has to be: device-independant, easily rendered, easily edited, and extremelycomprehensive.
Don't shout "XML!!". XML, without a DTD, is almost useless, especially for this application. The DTD has to be all those things I mentioned, plus(for this application), it needs to be standard.
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
I hadn't heard of DocBook, so I went fishing on docbook.org for some basic info.
The state of the documentation for this product is fairly lacking. (Hey, it's a DOCUMENT application!) There's no "getting started with DocBook" stuff. There's no official tutorial.
The closest thing to a tutorial I found is this page: DocBook intro. I'll excerpt the front page.
Here is my tutorial on DocBook. I never completed it, but it is still useful, since others don't focus on a complete beginner tutorial.
Last modified: Mon Jul 27 11:19:57 1998
Frankly, this sums up my issue with many Open Source projects: making a technically superior tool is not enough to generate wide user acceptance. There has to be an easy migration path from what the user's already got.
DocBook needs at least ONE of the following to get people going:
RTF/DOC/FrameMaker/TeX to DocBook converters, supporting at least a good 75% of basic features,
A usable migration tutorial that assumes the user already makes RTF/DOC/FrameMaker/TeX documents,
A usable editor that shows the results, even if it has to be two-paned to show both source and results.
I'm not flaming Open Source in general, but this is not the first time I have heard of a tool that would fit my needs exactly, except they put very large barriers to entry in my path.
[
The difference is in the purpose of the markup - XML is (generally, with a good design) syntactic markup. LaTeX is entirely structural markup, specifying not *what* a particular element is, but how it is to be displayed. As a result, XML is easier to tailor to a particular application's needs - from the XML document you can trivially create the equivalent LaTeX document. The same does not hold true the other way round.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Thanks for showing the maturity everyone has come to expect from the linux community.
Hey linsux users - grow up.
DocBook is your friend
DocBook is a lot to digest at one time, but it is well worth the effort. Personally I prefer DocBook XML and use Norm Walsh's XSLT stylesheets to transform the XML to anything I want... HTML, PDF, whatever.
Here are some resources for your reading pleasure.
DocBook is Open Source, freely available on all platforms of interest, can be used for simple documents to complex books, separates presentation from content, and is extensible. What more could you want from a document format?
...but I think XML is the clear answer here. XML is already very mature, can be used in a number of situations, and can incorporate more than just text.
You can even embed binary data in an XML document (with a tiny bit of creativity) for all those people who like to populate their files with custom fonts, clipart, graphs, etc. (This is accomplished through something, say... <BINARY CLIPART><DATA>[image data]</DATA></BINARY CLIPART>. You get the idea.)
How about special configuration parameters? You could incorporate tags that would handle the way a document is viewed by different people ("are you a techie, marketing drone, webbie, etc" -> certain data becomes visible).
The biggest advantages here are obviously the standards provided by XML (thank you W3C). It's uses are broad. It's got high quality interpreters on ALL platforms (especially JAXP for Java - it's a joy to work with *g*).
The only standards we'd really have to focus on would be which tags would be considered "key" tags.
What else do you need? Doesn't OpenOffice already use XML as it's standard document type?
Sure I could be wrong on this, so don't berate me too much. I've just had a lot of positive experience working with XML for sooo many different applications.
You shouldnt have to worry about the standards outliving TeX - Donald Knuth designed it what that in mind.
TeX (and the LaTeX frontend) runs on about as many platforms as linux.
the output of a tech document is quite frankly spectacular. you just dont get this kind of quality with the word processing programs that are out there today.
many people thing the learning curve high, but this isn't necessarly so. my advisor says that LaTeX has a one paper activation energy. ie it takes you about one document to learn most of what you need to know to get things done... and once you use it you will find it hard to use anything else in the future.
use LaTeX? want an online reference manager that
-- john