Re: [Groff] groff html output, eqn and journals

[Joerg van den Hoff]

On Sun, Mar 11, 2007 at 12:26:37PM -0700, Frank Jahnke wrote:
> I have a paper set in groff, and I wish to submit it to a journal for
> publication.  Their standard line is to submit in DOC or RTF formats;
> needless to say, that is not helpful, particularly since it is full of
> differential equations.
> 
> One option that I tried is to use the -Thtml flag to convert the output
> to HTML, and see if I could import that into Word.  Unfortunately, I
> lost all of the text delimited by .EQ and .EN, though the in-line
> equations worked OK.  It also gave me a number of "divide by zero"
> errors, even though the .ps and .pdf files are fine.
> 
> Suggestions on how I might correct that would be appreciated.  More
> broadly, how have people dealt with collaborating with users who work
> only in Word?  I am working on some heavy-duty math, and PDF (or ps) is
> just not a very helpful form in which to make corrections.
> 
> Also, what experiences have others had submitting articles for
> publication that were written in groff?  It undoubtedly depends on the
> publication (the target for this one is "Electrophoresis", Wiley-VCH
> Verlag publication).
> 
> Thanks!
> 
> Frank
> 
> 
> 
some weeks ago there was quite some traffic on this list concering E. Raymonds
plan to translate troff -man to Docbook. He seemingly also managed to get an 
eqn -> MathML translator running, maybe you could check how to get hold of that
(I did not yet have time to find out myself). as far as I understand, MathML is 
more or
less (as usual with MSWord and friends) what the Word equation editor produces.
I think at least one could demand from any publisher to be able to read MathML.

I'm planning to use this approach from now on (if the above actually works):

1.) extract all equations from the groff source with an awk (or perl, ruby,
python, ...) script and translate to MathML

2.) use `groff -a' and a HUGE line length and a HUGE page length to generate
single page (no page break) ascii approximation where each line corresponds to
one paragraph (I have a block:

.ie d TWEAK \{\
.   ll 1000c
.   \"if 'll' is long enough, this is essentially the max. number of paragraphs:
.   pl 500c  
.   ds LF
.   nr HY 0
.   na\
\}
.el \{\
.   \" A4
.   pl 29.7c
.   ll 21c-2i\
\}

which is sourced in each document, so I can call `groff -a -d TWEAK' to enforce
the desired huge line/page length). there are several benefits from this:
-- special characters are marked by `<some_thing>' codes 
(e.g. `<bu>' for a bullet) which can be identified in the output and "repaired"
manually.
-- running headers/footers are appearing only at the very beginning and end of
the output
-- footnotes are "collected" at the end which facilitates their handling further
"downstream".

3.) maybe convert to rtf :

enscript --language=rtf file.txt | sed 's/\\line/\\par/g'

(`enscript' seems to convert line feeds to line breaks instead of paragraph
breaks. this is repaired by piping it through `sed'). the only benefit of this
step (compared to directly submitting the asciit text) is that one can adjust
the rtf to any prescribed font(size) and line spacing (sometimes the limit for a
manuscript is defined in number of pages in font x, size y, line spacing z).

concering general experience: in some branches (e.g. physics journals) you might
get away with TeX. the rest seems to want documents generated with "an arbitrary
Word Processor as long as it is MSWord".  In some cases I managed to tell the
publisher "here is the text as rtf (as prepared by the above strategy), the
equations should be as in the accompanying pdf-file, please insert these
yourself I can't deal with MSWord". admittedly these were cases with only, say, 
10
equations. if the manuscript is really equation-heavy and _if_ the MathML
converter is working that would probably be the best way for the equations.

overall it's a pain, but avoiding MSWord is worth it ...

joerg