Slashdot Mirror

I run this file through wmf2eps from libwmf and get this:
ERROR: player.c (463): libwmf: wmf with bizarre record size; bailing...
ERROR: player.c (464): please send it to us at http://www.wvware.com/
maximum record size = 61
record size = 2344836616

Mariner Software released DropDoc, which is based on the GPL'ed wvWare libraries. It converts Word documents to .rtf, which maintains most of the basic formatting of a Word document.

I have used it and it works fairly well.

wvWare has a library and a set of utilities. I use this all the time to convert Word attachments to HTML so I can read them.

wvHtml: convert your Word document into HTML4.0

wvLatex: convert your Word document into visually (pretty) correct LaTeX

wvCleanLatex: convert into 'cleaner' LaTeX containing less visual mark-up, more suitable for further use and LyX import. Work in progress

wvDVI: converts word to DVI. Requires 'latex'

wvPS: converts word to PostScript. Requires 'dvips'

wvPDF: converts word to Adobe PDF. Requires 'distill' from Adobe [Someone do a pdflatex or pdfhtml version :-)]

wvText: converts word to plain text. Textually correct output requires 'lynx.' For poor output, this doesn't require anything special.

wvAbw: converts word to Abiword format. (Far better just to use Abiword.)

wvWml: converts word to WML for viewing on portable devices like WebPhones and Palm Pilots.

wvRtf: a basic version exists

wvMime: can be plugged as a MIME helper application into your browser/mail client; presents the document on-screen inside GhostView, while all intermediate files generated go into the /tmp directory.

wv is a library which allows access to Microsoft Word files. It can load and parse Word 2000, 97, 95 and 6 file formats. (These are the file formats known internally as Word 9, 8, 7 and 6.) There is some support for reading earlier formats as well: Word 2 docs are converted to plaintext.

Word docs could get piped through msdoc2txt (If it only existed!).

text/html; /usr/bin/w3m -dump -T text/html '%s'; copiousoutput; description=HTML Text; nametemplate=%s.html
application/msword; word2text %s; copiousoutput

And then put lines in your .muttrc similar to the following:

auto_view text/html
auto_view application/msword

Then the HTML and MS-Word attachments will show up as plain text right in mutt's internal pager. I'm sure there are similar procedures for other mail readers. More information is available.

As I understand it, the major problem is that Microsoft themselves aren't fully aware of the internal file formats for some of their older products! The information originally was on the wvWare site, although I can't find the exact snippet now.

Another advantage of having the Office file formats opened is that my work among other places could start to properly convert .DOC files to HTML...

Once again, nice work - but I really think it's a teeny bit misguided.

2. Combine word with CVS and give complete modification histories, and keep all undos in files. Sure, they grow large, but you could also show precise branches and replay changes done by one person on another file.

To a degree perhaps it could just be done with CVS and a backend ASCII-with-markup representation that worked nicely (i.e., equivalent documents would really have equivalent code).

I do some work at a publishing company, and they (like all publishers) are incredibly tied to Word. I've never even really considered mentioning any weening off of Word (the pain has been mitigated by wvWare, though). But with CVS-like features... well, even if I couldn't convince them, their ears would certainly perk up when I listed the possibilities.

I mean, I've almost started thinking of getting them to use Word like an HTML editor, and actually store the HTML in CVS -- which is forgoing most of the features of Word anyway.

The only negative -- freelancers, with their own software, have to be able to work in the system. They all have Word, and it would be twice as hard to change them over (since they work with other publishers and all that).

The Gimp is a real piece of Free Software. It was built as such, with the more modest goals that go with it. Star Office is very commercial, even as it's been freed. Hobby programmers don't like making something that does everything, but does everything poorly. Commercial programmers are forced to make that sort of thing.

Something with more modest goals has a real chance to be like the Gimp -- not full-featured, not a complete replacement, but a pretty darn good piece of software in its own right, with at least some real advantages over the commercial counterpart. Maybe AbiWord can be this -- they are certainly working small to large, and paying more attention to sound design and robustness than featuritis. Gnumeric is pretty decent already. I don't know what all is going on in the KDE world, but it seems like pieces of an office suite are coming about there too. Good pieces will win out over steaming pile of integrated software that is Star Office. I think Smart Suite and the like have failed in the way SO is failing, no need to go down that path yet again.

Hell, if just wvWare can be made really good you'll have half the features needed (for anyone to use) -- real Word import.

translates Word .DOCs. Has saved me from microsoft using coworkers many times. Check it out at http://www.wvware.com/.

But I haven't done the pre-requisite research - can word .DOCs be interpreted by something that can be run on the command-line? At least to show text-only, or even add some limited formatting, á là lynx...

Maybe a separate group, dedicated to an OSS translator of Word-format documents, would be sufficient?

I'd just like to point out that Microsoft have released the full-specs for Word .doc files and an open source .doc reader is available, it's called wvware.

Word View Ware made Wordview, a MS Word 8 conversion tool for Unix.

C.

• http://www.wvWare.com/, maybe the best open source Word converter? Formerly "mswordview", it's a library and a front-end app, which is currently AbiWord's converter.
• word2x
• AbiSource, a company producing an open source, cross platform, comercial office suite. Their motto was "SHOW ME THE SOURCE!!!", which we had to scream at the March 1999 Linuxworld Expo in order to get their t-shirt.
• Adobe FrameMaker for Linux -- Not sure if it does Office, but it's a commercial word processor!
• VistaSource / ApplixWare -- Cross platform, partially open source, complete office suite and integrated development environment in the form of either a local app, or as a Java-based thin client plus app server architecture. Compare to StarOffice. My experience has been that you can send an un-convertable Office document to Applix's closely-monitored community support mailing list, and they will attempt to modify Applixware's import filters around it, and send you a patch. How cool is that?
• S un StarOffice. Very good as well. Complete office suite. StarOffice and Applixware are capable of replacing Microsoft Office for literally most people.
• Corel Wordperfect -- See also Corel's Linux distribution.
• KDE's KOffice -- Open source office suite.
• Freshmeat.net's index of office apps

• StarOffice for Dummies http://www.us.buy.com/books/pr oduct.asp?sku=30490259 $14.99 (Save $1.00 over amazon.com) Replaces: http://www.amazon.com/exec/obidos/ASIN/0764505769/ ref%3Dsim%5Fbooks/103-4415661-32230 16

• Special Edition Using StarOffice, replaces htt p://www.amazon.com/exec/obidos/ASIN/0789719932/ref =sim_books/002-2291160-6260020.

• Applixware 5 Bible for Linux w/cd-rom http://www.us.buy.com/books/pr oduct.asp?sku=30546347 $29.99 ($2 less than amazon.com) Replaces: http://www.amazon.com/exec/obidos/ASIN/0764534033/ qid%3D959095708/sr%3D1-3/002 -2291160-626002

• http://www.us.buy.com/books/pr oduct.asp?sku=30400392 $14.99 ($1 less than amazon.com) Replaces: http://www.amazon.com/exec/obidos/ASIN/0672314126/ ref=sim_books/002-2291160-6260020

• Mastering Koffice for Linux w/ cd-rom http://shop.barnesandnoble.com/b ooksearch/isbnInquiry.asp?userid=4LAQC2IL93&mscssi d=DLK6S46966S92MG1001PQUW78818A314&srefe r=&isbn=0782126529, replaces http://www.amazon.com/exec/obidos/ASIN/0782126529/ qid%3D959095770/002-0803865-4820213

Its GPLed, granted it needs work. So scoot onto the abiword mailing list and cvs down the latest version, get hacking on it and sort it out.

ole2 is fully sorted out with libole2, excel is being handling by gnumeric.

What is not handled by wv is not by lack of documentation or design, its simply a matter of spending some time at it. Easy peasy. Info on the MSDN docs can be got from here. They can be gotten off the MSDN 1998 July cd, or you can get some of them from wotsit.org. I even wrote ivt2html for you to convert the office.ivt file into html. Like what else do you need.

90% of all the hard work has been done, wv can parse fast and simple with no bother to it, which was a nightmare to do, it can construct the correct PAP (paragraph properties) and CHP (character properties) for a given run of text. Feed you the correct characters and charset and font, the TAP (table properties), graphic properties and handle to graphics. The correct OLE handle for embedded objects. Document properties etc. There is an example html conversion program included for reference (wvHtml).

I put together libwmf to convert wmf file into something useful as well. Theres a half done implementation of an Escher (the graphics for Office) importer floating around in there as well.

Theres also an implementation of a Summary Stream displayer for all ole2 documents.

I even bust my ass and dragged together the right bunch of motivated people to help implement the decryption module for word 97, 95 and 6, and that was not fun at all to say the least

The hard work is done, if you want something improved you have a very very solid base to work from. Yes the spec is confusing, yes its not a great format, yeah is sort of moves over time, but in a fairly rational way that can be supported with some work. There are any number of equally crap formats with weak documentation supported in various tools.

There is just this false myth that the Microsoft formats are inpenetrable and/or not available. Just download wv, fair enough there might be problem documents, if there are, just debug wv and get onto the abiword list and work it out with them. If something fails it can be fixed and improved, its not a case of "ah well, its a MS format, nothing can be done". If you truly want to handle Microsoft formats there are a number of people working on it that you can help.

So its right there for the right bunch of motivated people to work on. C.

Its GPLed, granted it needs work. So scoot onto the abiword mailing list and cvs down the latest version, get hacking on it and sort it out.

ole2 is fully sorted out with libole2, excel is being handling by gnumeric.

What is not handled by wv is not by lack of documentation or design, its simply a matter of spending some time at it. Easy peasy. Info on the MSDN docs can be got from here. They can be gotten off the MSDN 1998 July cd, or you can get some of them from wotsit.org. I even wrote ivt2html for you to convert the office.ivt file into html. Like what else do you need.

90% of all the hard work has been done, wv can parse fast and simple with no bother to it, which was a nightmare to do, it can construct the correct PAP (paragraph properties) and CHP (character properties) for a given run of text. Feed you the correct characters and charset and font, the TAP (table properties), graphic properties and handle to graphics. The correct OLE handle for embedded objects. Document properties etc. There is an example html conversion program included for reference (wvHtml).

I put together libwmf to convert wmf file into something useful as well. Theres a half done implementation of an Escher (the graphics for Office) importer floating around in there as well.

Theres also an implementation of a Summary Stream displayer for all ole2 documents.

I even bust my ass and dragged together the right bunch of motivated people to help implement the decryption module for word 97, 95 and 6, and that was not fun at all to say the least

The hard work is done, if you want something improved you have a very very solid base to work from. Yes the spec is confusing, yes its not a great format, yeah is sort of moves over time, but in a fairly rational way that can be supported with some work. There are any number of equally crap formats with weak documentation supported in various tools.

There is just this false myth that the Microsoft formats are inpenetrable and/or not available. Just download wv, fair enough there might be problem documents, if there are, just debug wv and get onto the abiword list and work it out with them. If something fails it can be fixed and improved, its not a case of "ah well, its a MS format, nothing can be done". If you truly want to handle Microsoft formats there are a number of people working on it that you can help.

So its right there for the right bunch of motivated people to work on. C.

I have had to put a great deal of research into this because I'm doing a project for a client right now that requires converting .DOC files to HTML and inserting them into a MySQL db. So far I've found plenty of worthy solutions for converting the text, but none of them will handle the linked TIFF graphics in the documents.

Here are a few of my bookmarks:

WVWare - GPL library for reading .doc files, used by AbiWord, currently incomplete

W3C's list of converters

HyperNews' list of converters - really old

Filtrix - Good commercial, closed-source converter, now available for Linux, great price, but doesn't handle linked TIFF files :P

InfoAccess - Makers of HTML Transit, the Cadillac of closed-source commercial document converters, also exorbitantly expensive ($5000+) and AFAIK not avail for Linux

KOffice (KDE2) filters page - not much here, but AFAIK they intend to ship with MS-Word import capabilities

So, is anyone aware of any open-source MS-Word filter projects that I don't know about? Especially one that recognizes/converts linked graphics contained in the document?

- phutureboy

Wordpad supports Word 97/2000 files

Hrmm, nope, not on my 'puter it doesn't. Believe me, that's the first thing I try when I get a .doc file from someone I don't feel comfortable directing to resend the data in a standard format. It does work sometimes - other times I have to hit WvWare home page to get a readable translation.

Now, since it's obvious from your other post you are this weeks official M$ apologist, and since I am in fact a paying M$ customer (getting closer and closer every day to ending my 10 years as such) - explain this for me. If M$ truly cares about producing software which serves the customers needs instead of just creating lock-in, WHY do they continue with this ridiculous .doc format in all of it's endless change-it-just-enough-to-break-the-converters versions, instead of switching to an open format like TeX?

I remember when M$ at least felt a need to pretend to care about the needs of their customers - those days seem to be long gone now.

I think you are 100% right, and if I hadn't used up my last moderator point on a good post yesterday, I'd bump you a point myself. Not that your comment was particularly informative (no links to back up your point, shame shame) but it definitely qualifies as insightful. MSDoc format is an abomination, while it is a good thing there are in fact decent converters available (see WvWare) for those occasions when we just have to read a .doc file, but the goal should not be conversion of this disgusting format, but elimination of it in favour of open standards (text, TeX and html, depending on the document.)

... by at least one project, WvWare which has a very functional word to html converter available online, and the routines behind it are all open source.

The problems remaining are two - the .doc format keeps changing every release, and second, honestly, it sucks. Even converting it to a real format can be interpreted as giving it credence. I have used the link above in a couple of cases where it was really necessary, but generally, when I get sent a .doc document I reply please send me the data in a standard format. This usually gets the point across. It isn't like word can't output to rtf or txt formats, but for the rare occasion when you don't dare insist some PHB converts his data to a real format, this is a viable converter. And of course if you are writing a GPL Word Processor you are free to use the routines published here to create your own conversion filter...

There are also links on the page to all sorts of resources related to the ms word document format.

> They already ARE open. You can download them
> from various places on the net. There are
> various Open Source fileconverters based on
> them. You can get them
> on the Jan 1999 edition of the MSDN library.
> How much more open do they have to be?

Well, no. I'm not an authority on the subject, but this chap is.

Interview with Caolan.
WV info.

Incomplete documentation, it seems.

This is totally true. In fact, our importer (wv) imports even the features you mentioned, it's just that we can't deal with them. The quality of our importer is due primarily to one person, Caolan McNamara, who wrote wv and deserves mad props for it.
Sam TH

Additonally, Word does use embedded codes, unless you never press control-b or any other such command. If you don't believe me, read the code for wv, which is the word importer we use for AbiWord.
Sam TH

• Why do people play musical instruments (non-professionally) when it's possible to get all the music you want from your Tower Records store, at a cost much lower than the opportunity cost of the time spent?
  
  
• Why do people work as scientists, when it's possible to work as an engineer in the corresponding field, often at a much higher pay?
  
  
• Why do people teach, or write, when it's possible to simply practice the field?
  
  

Also my wv project has a passable word reader that abiword is using as a word importer, and gnumeric has quite a good excel importer

C.

Right now, abiword is helping wv achieve winword exporting to go with wv's current ability to import word 2000,97 and 6 formats

Some code to help those projects would be 100 times better than waiting for any microsoft code to appear, as even if this very unlikely event took place the code would certainly be windows/intel centric and horrific to extract and integrate anyhow

Getting microsoft code will not be a magic pill, even with the best will in the world as with mozilla it is very hard to seperate and make modular huge codebases, it is even difficult to read and understand them as so much of the knowledge required to make head or tails of them exists only in the heads of the original developers

Its difficult when they want to make themselves understood, imagine if they were forced

C.

Right now, gnumeric can import excel, and could do with more help

abiword uses wv to import word documents, kword also uses wv though they have seen fit to branch off their own version to do so. It too could do with more help

These specifications are also available on the July 1998 MSDN Microsoft Developer CD. They are stored on this CD in the proprietry .ivt format, but nonetheless I've even implemented an .ivt to .html converter for you to read those files under linux.

Get ivt2html and convert that office.ivt on disk 3

Alternatively wotsit.org has versions of many of them as well, including the word 6 file format which wv can handle as well

Now if someone wanted to do something constructive but wants to start small, then rather than sitting around on their arse blathering uselessly they could take a look at the public specs for mathtype and put together a linux equation edit file format to mathml converter which both abi and kword might use as an importer for equations.

Or they could help enhance libwmf to convert wmf files into svg format.

Its not just the office formats that are the problem, its the fact that they all embed or are based upon, or otherwise require the ability to convert all the secondary windows formats as well, so theres loads to see and do

C.

The wv library has working word import capacity right now

The basics of import are completed, i.e. word 95 and word 97 and word 2000 fastsave and fullsave support. Fastsave has always been the bugbear of word importation import, wv is on one level complete. It only requires some minor modifications here and there to complete its work, as abiword gains more features to equal word, then wv can be used to map the word features to the abi ones.

Koffice could also use wv for its word import, I wrote it as a library which should be reasonable easy to use from inside any word processor, the code to use it from inside abiword is pretty straightforward. I'd reccommend a look at it, wv has wvHtml as a standalone app to convert word docs to stylesheet enabled html which (if netscape wasn't so crap as using the data) would give almost identical html layout to the original doc layout

Its not perfect, but its as good in many aspects (or even better in some) as the commercial offerings

C.

Its something that is of particular interest to me as I have written the wv library(mswordview) which abiword among others uses to import word documents, along with a sample word to html program (which has a config file allowing word to latex and word to groff possibilities)

Such a table of all possible word features is painstaking to create, and repeating the process of importing and exporting word features from abi/so/corel/applix and kword so as to compare them properly is a huge task, but one that really needs to be done, it is no good saying "the import of word documents is ok, needs a bit of work afterwards to fix it", a company or other heavy word processor user that is thinking of linux needs to have better information, and more precise data as to how good or bad is the import

You can have the best little wp in the world, but you have to have very good word import to be able to interoperate with others and not go completely insane with the poor quality import, so we need to isolate the capabilities of word and address the import of each of them point by point. Text attributes, graphic capabilities, ole import, equations, tables, table attributes, language support, revision support, absolute layout, hypertext capabilities, forms, etc etc etc

This is a task that requires no programming ability only patience and a copy of microsoft word, create a huge amount of documents that are an example of just about every feature of word and make them available as a test suite for various wp's importers. It would help greatly to have a database of word functionality, then you would have some data of enough validity on which you could fairly judge which wp will provide the best value for users which need to work with others in an organization which runs predominately word, i.e. all of them

C.

Try MSWordView (now called wvware, in an effort to make people sound really flubby when naming it...)

www.wvWare.com/

abiword has a pretty good word importer, using the mswordview engine wv.

It doesn't provide 100% M$ Word support yet, and it doesn't do Excel. Still, it's something and it's here today, even though it's not at version 1 just yet.

I haven't checked out koffice yet, but those screen shots look really nice.