Ask Slashdot: What Is the Best Open Document Format? 200
kramer2718 writes: I am working on a project that requires uploading and storing of documents. Although the application will need to allow uploading of .docx, doc, .pdf, etc, I'd like to store the documents in a standard open format that will allow easy search, compression, rendering, etc. Which open document format is the best?
Since "best" can be highly driven by circumstances, please explain your reasoning, too.
Have a question for Slashdot's readers? Take a look at other recent questions first to see if someone else has had a similar question. And if not, ask away! The more details and context you include, the more likely your question will be selected.
can't you search the current doc types? (Score:4, Informative)
if you use the API's supplied by their creators?
Re: (Score:2)
docx is just a zip-archive with xml files. And as far as I remember, schemas are published somewhere (althouth format description is several thousands of pages)
Re: (Score:2)
PDF/A (Score:5, Informative)
Re: (Score:2)
+2
Hundreds of people who do this for a living (they're called records managers), and have done for many years, have worked long and hard to come up with a standard format for exactly this. Doesn't do everything, but what does, but it does ensure that it will still do it in 50yrs if not longer.
Caveat 1: OP doesn't mention editing, if he needs it editable then don't convert, or store original and PDF rendition for preservation
Caveat 2: There is a trade off between doc size (OP mention compression) and digita
Don't convert needlessly (Score:5, Insightful)
I would suggest, unless you have a pressing need to convert them, that you should store the documents in the formats they are uploaded in.
Whenever you convert a document you run the risk of completely messing up the layout, style, etc.
Re: (Score:1)
There's storing for later download, and then there's storing for ongoing analysis, indexing, previews, etc. For the latter, it would help a lot to have one standard format. Probably plain text.
To properly analyze .doc / .docx, for instance, you'll probably need a Windows machine with Word installed. It will likely be significantly cheaper to have Word installed on only one or two machines, convert to text (capturing any necessary metadata on the way), and then do further processing on other machines that do
Re: (Score:3, Interesting)
All of the "X" variants of MS Office documents stand for "XML" - that is, the documents are stored in a series of XML files inside of a ZIP file that is renamed to formatX (docx, xlsx, etc). There is no real need to even have Windows or Office installed to index these documents. Just write up a basic script to extract the ZIP file and parse out the related XML documents. Note: this isn't as trivial as it sounds at first, though. This would assume that Microsoft's XML structures (yes, plural), had an easy to
Frequently not "doable" (Score:2)
Meanwhile I can import seismic data from the early 1970s into current software without any conversion - simply because the file format is documented instead of Microsoft's later step backwards.
Re: (Score:2)
Strange, but that is exactly what I am doing at the moment. Or at least, I was doing until a few moments ago, when the task finished. Hi ho! back to the grindstone!
Re:Don't convert needlessly (Score:5, Interesting)
Re:Don't convert needlessly (Score:5, Interesting)
Or store both the original, and a standardized format. The place I work stores everything from engineering drawings, meeting minutes, purchase records, to manuals of old equipment in a central document library. It retains the original file, and makes a pdf of every file, and a link to both is listed in each entry.
THIS.
PDFs (or some similar standard) will ensure that the original documents can be read by everyone and viewed with the original formatting intended by the person creating them. Any differences in the version of Word or whatever is going to tweak the formatting in unpredictable ways.
But the originals should always be retained, since it may make future editing easier. And people also won't be stuck trying to undo whatever unpredictable reformatting or editing (e.g., loss of certain features moving between formats) might go on in your conversion process.
Re: (Score:2)
Really ? You should tell AIIM, LIbrary of Congress, etc. - they've all been doing it wrong for years with PDF/A.
Re: (Score:2)
Even with programs that can import Word/Excel/etc. documents, they do a good job, about 99% well. However, that one percent that is missed can do quite a number on a document.
The answer for a document format... depends.
For a document format that keeps formatting exactly, and isn't intended to be edited, PDF/A is the best thing going, since barring a major world-ending disaster, we will still have utilities that can read PDFs, and PDF/A ensures that the fonts and such are present and readable.
For a document
.txt (Score:5, Interesting)
.txt. If you need pretty formatting, fill it Latex tags.
Re:.txt (Score:5, Insightful)
Generally when I have to worry about integration or longevity, it is still hard to compete with ASCII & LaTeX. While they do not have the every day visibility of various office document types or pdfs, renderers, search tools always know exactly what to do with them. They can even interact with version control systems cleanly since the underlying tools do not need to know anything about the formatting to manipulate it.
Re: (Score:2)
And, despite my agreement (I was actually going to post a similar answer if someone hadn't), there are times when I don't want to bother with the latex overhead for quick documents. Am I doing it wrong?
Re: (Score:2)
I agree. Text works. Now we get to argue over ASCII, Latin-1, ISO, Unicode, tabs vs spaces, emojis versus emoticons, CR/LF vs CR vs LF, byte stream or record format, CamelCase or pythonCase or unixcase, but thankfully we don't have to decide on vim vs emacs as those are external tools.
Re: (Score:2)
Pretty much my thought. Use the simplest format that will do the job. It it's just prose, use txt. Does anyone seriously believe that One Day in the Life of Ivan Denisovitch is somehow enhanced by saving it as .doc or .pdf or .htm or god knows what else? If the text needs some bold and italics, use .txt with markdown. If it needs lots of markup, then something more elaborate -- preferably something with standards and a DTD or equivalent indicating what standard applies. If there are flat tables, use c
Re: .txt (Score:3)
Perhaps fine for Roman characters, not so fine if the document contains Kanji, Hiragana, Katakana, Hebrew, or any of the other character sets that don't play nice with "plain text" formats. For something that you would think would be pretty straight forward, plain text character handling is surprisingly maddening to work with.
Re: (Score:2)
Yes text handling for non-ascii characters can be surprisingly maddening to work with. (Wasn't UTF-8 supposed to fix that?). Problem is that wrapping txt in some more elaborate format like HTML often doesn't make the problem go away. With apologies to Jamie Zawinski It just means that now you have two problems.
Re:.txt (Score:4, Insightful)
How is it impractical?
Re: (Score:3)
How is it impractical?
It is impractical because the average end user will have no idea what to do with a .txt file containing Latex markup. It will look like gibberish. Txt files also have no clickable table of contents, or index, or hyperlinks to other documents.
Re: (Score:2)
And yet we used to have tons of secretaries and administrative assistants in universities who did just fine with LaTeX, or even TeX. There was a time when everyone had to learn new things and it was considered a normal part of the day to day job. It was not considered a human rights issue back then to not use MS Office.
Stupid file extension tricks (Score:2)
Heck, you could save your LaTeX files with a .tex extension and associate that with a script that invokes a TeX to PDF renderer followed by your preferred PDF reader.
Re: (Score:2)
With latex stored, you can render to anything when the user requests it. odf, pdf, docx, bitmap, tex, GIF. Take your pick.
Push the techy stuff on the developer to make the user tasks no brainers.
Re: (Score:3)
Does latex support MS Office? If not then it's very impractical for 95%+ of users.
If I had this question, I would google before asking Slashdot and exposing my ignorance. There are lots of tools.
LaTeX CoNDoM (Score:4, Funny)
LaTeX is the CoNDoM that protects you from Microsoft Office ViRuSeS.
Re:.txt (Score:5, Insightful)
MS Office is also impractical for 95%+ of its users.
Re:.txt (Score:4, Insightful)
If you are in publishing - like in writing or editing books - you need MS Word.
Well, use whatever you want to write the book. But if you are printing it, I'd definitely use something other than MS Word. It just doesn't produce publication-quality documents.
And as far as Latex is concerned, it would be even more work.
That depends on what you are writing. If your document contains lots of equations and you're using MS Word, then God help you.
Latex and other formats are great if you are in complete control from start to finish of the publishing process. But working with other people that are scattered all over the World? Nope.
Again, that depends on who the other people are. Many academics, particularly scientists, use LaTeX.
Re: (Score:2)
The Springer publications via the IACR prefer submissions to be in Latex.
Re: (Score:2)
Can MS Word handle books now? Back in the 90s we had a major revolt of the doc writers at our company when the dictate came down that Word must be used instead of Framemaker, because Word was incapable of working with documents that large (ie, multiple full binders, with a table of contents and index that covers all of them).
In the same way that you can't treat "1" as a lowest common denominator, you shoud not treat MS Office as the lowest common denominator either.
Re: (Score:2)
MS Word is still a complete mess when it comes to numbering sections and lists. This makes it unusable for writing technical books.
Framemaker had a simple and powerful format for describing numbering sequences. It worked well. I haven't used it for a few years.
Latext obviously gets it right. Why wouldn't it?
You don't want it to (Score:2)
Re: (Score:2)
If you want it nice and clean, pay a curator.
People will upload crap. Your converters will introduce crap.
Re: (Score:2)
I only se a goat.
Re:.txt (Score:4, Informative)
Then you end up with Microsoft inserting garbage characters at the start of each text file to make their job easier, breaking scripts and confusing both users and other editors alike.
It's not a garbage character. It's a BOM [wikipedia.org] and it's part of the Unicode standard. If your scripts and text editors can't read the BOM in 2015 then they are the things that are horribly broken.
Re:.txt (Score:5, Insightful)
It's not a garbage character. It's a BOM [wikipedia.org] and it's part of the Unicode standard. If your scripts and text editors can't read the BOM in 2015 then they are the things that are horribly broken.
This is one of those sticky situations. For UTF-8, the Unicode standard discourages the use of a BOM, unless you're converting from a different Unicode format that requires a BOM. The whole purpose of a BOM is to describe the byte order used to generate the file data, however UTF-8 data is broken up into 8-bit code units, and thus endianness doesn't play a role. You simply read the stream one byte at a time.
Indeed, using a BOM is discouraged (by both the Unicode standard and the IETF) precisely because it breaks backward compatibility with ASCII text processors. Unfortunately, Microsoft seems intent on adding an unnecessary (and, in the case of UTF-8, badly named) BOM to virtually every UTF-8 file created on their platform. This is done to make it easier for them to detect the encoding; however there are reliable, published heuristics which do the same job without the need for the BOM. That's what every other platform in existence does to detect UTF-8 streams. Microsoft's BOM use is purely to make their processing easier, even if it means that it breaks backward compatibility with older tools.
Thus, you are technically both correct. It's technically not a garbage character at the beginning of the stream, however it is unnecessary, and contrary to the way every other OS on the planet handles the situation.
(I've run into this more than once in my professional life, dealing with people who are supposed to be technically minded who use Windows Notepad to try to figure out what encoding a file is using. I've had them come back claiming my files weren't UTF-8 because Notepad claimed they were 'ANSI' (never mind that there is no character encoding standard called 'ANSI' in the first place). I've had to explain to more than one person that standard ASCII is valid UTF-8, even going so far as to providing them chapter and verse of the Unicode specs to prove that what Notepad says shouldn't be treated as gospel.)
Yaz
Re: (Score:2)
Thus, you are technically both correct. It's technically not a garbage character at the beginning of the stream, however it is unnecessary, and contrary to the way every other OS on the planet handles the situation.
And yet I use a multitude of text editors and have scripts that can handle UTF-8 text files with a BOM just fine. Your programs and scripts are broken if they can't.
Re: (Score:3)
And yet I use a multitude of text editors and have scripts that can handle UTF-8 text files with a BOM just fine. Your programs and scripts are broken if they can't.
Or they're legacy tools. There are a large number of such tools out there that do various jobs, where having an unnecessary BOM is a liability.
If you're compiling for some legacy embedded hardware, for example, I have little doubt that its compiler would choke on BOM characters, and you may not have access to the source to fix it. And just because YOU don't need or use such tools hardly means that nobody out there does.
Yaz
The only open one - ODF (Score:1)
Re: The only open one - ODF (Score:2)
PDF retains the layout (Score:2)
I am working on a project that requires uploading and storing of documents. Although the application will need to allow uploading of .docx, doc, .pdf, etc, I'd like to store the documents in a standard open format that will allow easy search, compression, rendering, etc. Which open document format is the best?
PDF allows accurate rendering so it's the best choice. It will be a hot mess if you use anything else. Conversion of such complex formats is very error-prone for layout problems.
Re: (Score:2)
But they don't generally reflow [wikipedia.org]. e.g. Viewing a document formatted for portrait on landscape monitor, journal articles with multiple columns, reading on a 4" smartphone are challenges for reading onscreen.
Re: (Score:2)
PDF/A is the ISO standard format for document archiving, as well as printing.
Forget the Universal Format crap (Score:5, Informative)
1) Forget the Universal Format approach - your users will kill you for messing up their formatting, and you'll never get complete feature parity
2) Store the docs in their original format
3) Get Apache Solr to search your content
4) You'll be spending a lot of time on #3, so leave time to tinker
Re: (Score:2)
I'll second everything but step 3. I would get some standard libraries set up to extract the plain text from each format and make that searchable. Probably much simpler.
Re: (Score:2)
Re: (Score:2)
Because it's most likely overkill if all you want is indexing.
Re: (Score:2, Informative)
I work at a typography, and I get a lot of documents from a lot of different people. Those "documents" come as MSWord files with missing fonts, pdfs made with some shoddy software, strange ODTs, many more different types of doc files, the mysterious lnk files that work perfectly fine for them, but not for anyone else and my personal favorites, jpg files (not png or some other lossless format, because that would imply actual thinking).
Strange enough, I've yet to receive any plain text files.
To index everythi
Oldes are the bestes (Score:5, Funny)
Word Perfect Document, because it's been consistent for nearly 20 years. it has a simple underlying format, it's more finely granular than HTML and because I just like obsolete things.
Re: (Score:2)
Re:Oldes are the bestes (Score:4, Funny)
Re: (Score:2)
Coding approach (Score:2)
Are you writing the search/compression/render capability from scratch, or are you using a library to handle that job for you?
If you're handling more than one document type, then go for a library. I don't have a recommendation myself, but I'm sure you can find them on a search.
Also, don't worry about compression, as modern .odf/.docx is already compressed
Need more information (Score:5, Insightful)
As an IT person, I hate questions like this. There's not enough information to give a solid answer. For example:
* What kinds of documents are you talking about? Text? Photos? Spreadsheets? .pdf, etc", what formats are in "etc"?
* What is the source of the documents? Are these currently printed out documents that need to be scanned back in? Are they currently digital, and in a particular file format?
* What will people need to do with them when these documents are retrieved? Do they need to be able to edit the documents?
* How much does formatting matter? If someone retrieves the document in 5 years, will it be important that all the line breaks and page breaks are in the same place? Does it need to have all of the correct fonts? Or are you more interested in being able to have access to the information itself?
* When you say that the application will need to allow ".docx, doc,
There may be many other relevant questions, my point is that there just isn't enough detail here. In general, if the most important thing is that you have a printable document that you want to be able to print out from any machine, maintaining the formatting as much as possible, then PDF is a pretty good choice (be sure to embed the fonts and include searchable text!). If you already have a bunch of Word documents and you want the formatting unchanged, and would like the capability to edit the document after it's retrieved, then I'd typically just recommend keeping it as a .docx. It keeps things simple, will be widely supported, and prevents the risk of something going wrong while you're converting to another format. If you like the idea of using .docx because of what I just said, but want something more "open", then ODF is probably worth looking into.
Really, there are only so many choices, and each have advantages depending on your specific needs.
Re: (Score:2)
* What kinds of documents are you talking about? Text? Photos? Spreadsheets? Photos aren't documents. Spreadsheets tend to be proprietary.
* What is the source of the documents? Are these currently printed out documents that need to be scanned back in? Are they currently digital, and in a particular file format? This! I tend to classify documents as "Primary Data" (Structured) and "freeform Data" (Human Readable)
* What will people need to do with them when these documents are retrieved? Do they need to be ab
Re: (Score:2)
Photos aren't documents. Spreadsheets tend to be proprietary.
Nonsense.
Data needs to be organized by purpose (Record keeping = Primary / structured data) and Executive Summary Type data (human readable).
It depends on what the data is, and what and how it's being used. There is no "correct" organization, and no "one true way" to deal with data. I would not recommend going around cramming documents into some set organization without understanding where the data is coming from and what people hope to do with it.
Your organization may work for your purposes, within the constraints of the company or organization you work in. I've supported a lot of different types of companies over the years, and pe
What Suits Your Needs? (Score:1)
"Best" in this case depends on your needs and resources, not on standards or common practices. Flexibility and "getting the job done" are more important than what everyone else prefers. Do what works for you.
Depends... (Score:2)
I'd highly recommend leaving them in their original format, or if anything, converting them all to .pdf. Conversion is always fraught with danger, and you will be spending an awful lot of time getting to the know the intricacies of Microsoft Word if you go this route. Pdfs display equally nicely on every operating system, they archive very well, and almost every tool out there can read them - but while converting documents to this format usually works better than others, I'd still be very careful to watch
Use a document manager (Score:2)
Re: (Score:2)
worth a look too:
https://tika.apache.org/ [apache.org]
For Two-Millennia Durability... (Score:5, Insightful)
Re: (Score:3)
Re:For Two-Millennia Durability... (Score:5, Informative)
Nonsense, bamboo can't touch papyrus for longevity, and you don't need to worry about pandas.
Damned bamboo shills.
And don't anybody go suggesting cave paintings, it's a completely dead platform.
Re: (Score:2)
And don't anybody go suggesting cave paintings, it's a completely dead platform.
But.. but.. they've lasted the longest! Granted, they're not very mobile.
Re: (Score:2)
Re: (Score:2)
Petroglyphs are more susceptible to treehuggers from Greenpeace than the weather.
Burning Bush (Score:5, Funny)
...you can't beat bamboo strips. The oldest original versions of Lao Tzu's Tao Te Ching are written on rolls of bamboo strips. Not sure how they scan electronically, and you will have to keep your pet pandas away from them, but for document durability, you can't beat that format...
Chisel it into stone tablets, then find an ignorant local. Set up a natural gas line to a nearby bush and hide behind a rock. Cub your hands to add a slight reverb effect and tell him to preach the chiselled word, then break the tablets and hide them in a box and trick nazis into looking at them.
And a pony too? (Score:4, Insightful)
Lets' see ... you want to allow uploading in a large number of formats .. you want to magically turn it into a universal format ... while retaining all of aspects of the original ... and will be easily maniuplated ... and you want it in an open, and documented format? And all for free?
I want one of those too. And a Red Rider BB gun with a compass in the stock and this thing which tells time. And a new skateboard. And a pony.
Honestly, you're asking for the holy grail of document management systems ... the universal, lossless document format.
I'm not sure it exists. And I'm not sure companies like Microsoft or Adobe would allow it to exist.
Re:And a pony too? (Score:4, Informative)
English idiom connoting yet another impossible thing in a child's unrealistic wishlist ... typically placed at the end of a series of outrageous demands: " ... and a pony".
Now, please, don't make me pedantic you again to explain the cromulency of phrases. ;-)
"Best" depends on intent (Score:3)
On the conversion side... If you're taking in PDFs created by a layout/page design program, then you're not likely to get good satisfaction converting them and storing them as something other than PDFs. OTOH, if you're taking in a lot of documents created in an office suite, and they have collaborative notes, and you need to retain the documents for legal purposes, then converting them to PDF is going to lose data.
On the future use side: PDFs are slower to render and search than most formats; they're harder to alter, but they're more reliably rendered than any other format. Office documents offer richer content and easy editing; their layout may vary depending on the output device (good and bad), and office document formats seem to change a bit more than other document types. HTML with CSS is good, and probably now stable enough that future clients will render something similar - but it's not PDF for reliable formatting, nor office docs for feature richness; editing tools for HTML aren't all that intent on preserving what came before. LaTeX is a reliable formatter wrapped around text-centric documents, but it's not something most people will be able to use and edit.
Each document type has its reasons for being - you'll need to decide why you need to store your documents and what you need them for in the future. Retaining the original document along with a text conversion stored and indexed in a search engine may be your best bet - or not.
Re: (Score:2)
Sometimes you people make things WAY too complicated.
In our 'best judgement' -- what's a very open standard for documents? Now, we can ask "what type of document" -- and we can also try and answer for whatever documents we know.
So here goes;
Documents; Try RTFD. Rich Text Formatted Document. It might not be perfect in layout -- but it's open, and accessible to a lot of apps and cross platform. If you get bad results, you might just need to switch to some other "open" app. OpenOffice on all platforms will lik
Docbook? (Score:4, Funny)
Docbook allows you to separate out the content from the presentation. You write in XML and define paragraphs, chapters, images, etc. and then leave it to the various stylesheets to drive how it looks like when it comes out the other end - PDF, HTML, Word, whatever, and the stylesheet makes sure that if some features are supported (hyperlinking from the table of contents to the chapter) it'll be included in there. Since the content is in plain 'ol XML you can use any kind of XML processor to go through it..
Re: (Score:2)
OK, grandpa, it's time for your meds again ... look, Matlock is about co start ... no, they're not on your lawn. ;-) [ Wow, and actual 3-digit id ]
Honestly, for those of us old enough to still have a copy of Goldfarb's [wikipedia.org] book, this has been the holy grail for a very long time.
But in practice, there's still no tools to convert all those formats to it, and most anything you do is going to be custom code.
As a system which takes other formats as input, docbook falls into the category of wishful thinking.
Even us
Re: (Score:2)
But in practice, there's still no tools to convert all those formats to it, and most anything you do is going to be custom code.
I love DocBook. But I've also spent a fair portion of my lifespan persuading other formats to turn into it. Not the most fun I've ever had, to say the least.
Impossible question to answer (Score:2)
There is no "best" document format, open or otherwise, for "easy search, compression, rendering, etc." because those words are too fuzzy.
If your use case is a typical one, then you actually want, for maximum search functionality, text (perhaps with some form of markup so you can assign weights to segments, like higher weight for titles), a HTML5 based
EDI? (Score:2)
How about (Score:3)
Bad idea (Score:2)
Your documents will lose formating when the files are converted, if you want users to be able to download the files in any format you should just store the files in the way that the user uploaded them and convert directly. Create a metadata plain text version for search, maybe a visualization version so that the user be able to see the files inside your application, in this visualization version you should just use the easiest method.
Of course this depends heavily on your requirements.
That's easy (Score:2)
Just convert all the documents into 1200 DPI, 32-bit PNG images.
Three letters (Score:2)
DNA
Millions of years of field testing, and it still mostly works, and DNA itself is not patented.
Use cases? (Score:2)
Who is going to use these stored documents? How will they be used (read-only, revise and check in, etc.)? What tools are authors generating these documents with? Answers to these questions will help determine the best storage format.
For documents intended to be downloaded and read or string searched, PDF is a good choice. There are a lot of PDF readers for different O/Ss available.
Save Space, Switch to ODT (Score:4)
I've written several books. Because ODT's have standard compression, they are usually much smaller. For a 109,683 word book, with styles and formatting:
ODT: 271,090 bytes
Docx: 300,057 bytes
Word 97: 1,379,328 bytes
PDF: 1,050,788 bytes
If bytes cost money to store ODT rules.
Imagine yourself sticking with Word 97 because it's a reliable standard: imagine buying three times as much storage, as well as the backup for the storage,
Silly Rabbit, Trix are for kids.... (Score:4, Interesting)
No, just no....
Store the documents in their original format.
There are many possible reasons why you shouldn't mess with the originals such as formatting, legal implications, loss of content because one format supports stuff that the other doesn't, etc.
The only way that I could see this working is if you converted everything to an open format but kept copies of the originals and linked to them. But if the plan is to dump the original documents, then it just isn't worth it....
LANG=POSIX, 7-bit ASCII text (Score:2)
If you can't read it in flat text, it's not long-term reliable documentatoin.
my 1st and 2nd choice for document format (Score:2)
The best Open Document Format? (Score:2)
The answer's right there in the question...
Re: (Score:1)
Re: (Score:1)
Re: (Score:3)
Dude ... can I point out to you that you got the reference and that many of us wouldn't know WTF it was?
So maybe your question is how many other Slashdotters are Bronies [wikipedia.org] besides you? ;-)
And, for the record, I included that link because I had to google it to find out what it meant.
Now if you will excuse me I need to go apply brain bleach. The images which came up in that google search are terrifying.
Re: (Score:2)
I didn't. But google was "helpful" enough to throw up related images along with the search results.
And now I shall ever be traumatized that 'adults' are dressing up like that.
I can't simply unsee that. I'm going to make it the new Rick rolling ... just randomly stick in links to bronies. Spread around the pain.
Re: (Score:2)
http://img3.wikia.nocookie.net... [nocookie.net]
I do share your feelings about the cosplaying though... unless it's a cute girl dressed like Fluttershy. If that's okay with her, I mean.
Re: (Score:1)
And those .02 wasn't worth much, considering that the most effective way to FUBAR a doc-file is to pass it around to a few users who use different versions or even patches of Word. Nobody is 100% compatible with MS-Word. Not even Microsoft, so so that "format" goes right into the shitter, along with your lame attempt at being cool and suitably hipster "anti-opensource".
Captcha: "Vanity". Indeed.
And Depend (Score:2)
Is a brand of adult diapers [depend.com].
XHTML5 exists (Score:2)
The HTML5 introduction [w3.org] states that XHTML is one of the two syntax forms of HTML5.
Re: (Score:2)
But HTML5 treats XHTML syntax as a resented stepchild because WHATWG hates XML so much. All the sloppy markup that the rest of the spec advocates should be treated that way instead.
Re: (Score:2)
Vote this up. It was my first thought too. Basically, plain ASCII text with formatting instructions that are human readable.
Re: (Score:2)
HTML is primarily a layout language. It does diddley-squat for semantics. You need DocBook XML, or something like it, if you're going to go that route... and good luck with converting to it from something like Word.
Re: (Score:2)
So long as you remember that the M in HTML is "Markup", not "Layout". If it is important that page layout be "perfectly" preserved in the presentation, something else like pdf (Yechhh) might be a better choice.