[Groff] Discussion: devwp ??

[Ted Harding]

Hi Folks,

I've been thinking a bit lately about a situation I quite
often find myself in. You create a document with groff, so
that you get it printed as you want it to be seen.

But someone else (e.g. a publisher) wants the document in
a word-processor format (e.g. Word, WordPerfect).

Now you can, of course, go through the troff source by hand,
eliminating troff requests, taking out "superfluous" newlines
(so that a paragraph is one long line), putting in searchable
tags for beginning and end of italics/bold/... so that you can
go through the resulting Word file and make the changes, etc.
But I don't have to tell you how tedious that can be.

[Incidentally, before I go on, people may be interested to
know that you can convert a pure text file into a valid
WordPerfect-5.1 document very simply: just insert the following
76 bytes (given below in hex) at the start of the file:

  0000000 |  ff 57 50 43 4c 00 00 00 01 0a 00 01 00 00 00 00
  0000020 |  fb ff 05 00 32 00 00 00 00 00 06 00 08 00 00 00
  0000040 |  42 00 00 00 08 00 02 00 00 00 4a 00 00 00 00 00
  0000060 |  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0000100 |  00 00 08 00 7c 00 78 00 00 00 00 00

The resulting file is then a valid WP5.1 document and can
be imported into anything which will import WP5.1.]

Anyway, to get back to the point. You can achieve some of
the requirements already in groff (e.g. make page width and
line length very large; set para-drop to zero). You can filter
the file with sed/awk to replace things like \fB...\fP with
something more palatable, or even insert the correct "target"
binary codes for special characters [e.g. I know the WO-5.1
codes for the "international" and other character sets, and
so I can run a 'sed' script to replace e.g. "\(C," which is my
groff for C-cedilla with the WP code: (hex) "C0 26 01 C0".]
This takes some of the tedium out of it.

You can even go some way to making tables importable. If you
give groff the option -Tascii or -Tlatin1, give all table columns
spacing=0, and use "|" as the "separator" for Word's "convert
block to table" tool, then you have an importable formatted
ASCII file and have also got rid of some (but by no means all)
of the tedium.

However, I'm thinking towards something more generic. The
output from gtroff is groff's version of ditroff output,
and a lot of the things like font changes etc. are encoded
therein. So also can special characters be (which may be
encapsulated in font-change requests to the device).

So, is it feasible to think of a post-processor, let's call
it "devwp", which would take the ditroff otuput and generate
a file suitable for importing into a "word processor"?

Where details like special characters and font or style changes
are concerned, this should be straightforward (and really amounts
to coding things I have described above into devwp). However,
I'm not seeing that this would be easy for things like
tables (and I'm not even contemplating, for the moment,
stuff like equations or 'pic' code). Here, the best source
for filtering into input for a WP would be the formatted
output of say 'grotty', where it is already laid out; but
maybe requests like "\X'wp: TS'" ... "\X'wp: TE'" would be enough
to get the 'devwp' to do the right thing with what gtroff outputs
for "...". (The "\X'wp...'" requests could be planted by troff
macros.)

The above is really only speculative musing. Part of my uncertainty
has to do with not being at all sure of what should be required
and/or permissible for a file which is to be a valid importable
file for a "generic word processor".

Other people's comments and discussion would be most welcome.

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 167 1972
Date: 10-Aug-01                                       Time: 16:10:06
------------------------------ XFMail ------------------------------