Re: [Groff] Re: conversion to DOC format

[Gaius Mulley]

Dean Allen Provins <address@hidden> writes:

> While poking around on the net, I came across a sourceforge project
> called 'PyRTF', which is a set of Python scripts that write RTF.  When
> it comes to Python, I'm an novice at best, and I had some
> difficulty getting it to go using the examples provided.  After some
> very crude 'hacking', I was successful, but this code is not ready for
> production use yet.
> 
> I had thought that one might marry it (or something like it) to the
> output code from groff to generate RTF directly, but I see (after
> examining groff's output format) and reflecting on RTF that the two are
> fundamentally incompatible.  Groff's output is a description of where to
> put the black marks on the page and RTF is a description of how to
> format text (i.e. center it, bold it etc.).
> 
> I suspect that using an approach much like Gaius did with grohtml might
> be more appropriate.  I believe that he works at an earlier point in the
> groff chain.  Any thoughts?

Firstly congratulations Dean! I've been reading this thread with
interest as I also have to integrate my text with other colleagues who
nearly all use the offering from MS. At work there are a number of
house formats which we have to ad-hear. In these cases I resort to
producing a macro set to mimic the house style (xfig and pic) are
great for this (typically exam front sheets and coursework front
sheets). Groff excels in these areas as one can make groff perform
extra checks (ie add up the exam component marks and check against a
value), ensure the solutions start on an odd page after the questions,
ready for duplex printing. It is also wonderful in that one can
separate the information away from the visual candy.

I'd imagine that a rtf device or doc device could be written that
uses the front end information which grohtml generates. Essentially
when -Thtml is activated the `troff' executable emits meta tags
telling `post-grohtml' executable where a title starts, which lines
are centered, whether justification is on/off etc. The tags go some way
to telling post-grohtml the current troff state. So I think there is a
good chance that rtf/doc device drivers could also exploit this info.

Gaius