MinGW and gropdf

[Deri James]

I hope someone has more knowledge of running groff under MinGW than I!

I have two basic problems with MinGW:-

A) When the postpro entry in DESC is set to "gropdf" it ends up looking for an 
executable called "gropdf.exe", this can be mitigated by installing a file 
called "gropdf.bat" which in turn calls perl with the gropdf script, but I 
wonder if this is the best way of doing it? One drawback in doing this is that 
in calling "perl" from the .bat file you are invoking the windows executable 
search path rather than the MinGW search path (so if you have Active State 
perl installed it is likely to run that version rather than the one installed 
by MinGW in /usr/bin). I don't know if this is related to the second problem 
or not.

B) I am having a problem with CRLF endings. Whilst the PDF specification allows 
all three types of line ending (LF, CR and CRLF) the parts of the PDF which 
are in fact binary data (i.e. anything which have been Flate compressed) must 
not have LF converted to CRLF. To this end I ensure the gropdf driver sets 
stdout to binary mode rather than text mode (to prevent perl itself doing 
intelligent line ending). This seems to work fine (producing an LF only file 
which Windows pdf readers are happy to parse), but this is only true if the 
driver is called on its own:-

groff -T pdf -Z file.trf | gropdf > file.pdf

If groff builds the pipeline itself:-

groff -T pdf file.trf > file.pdf

Then CRs get added which upsets the flate decompression in the pdf readers. The 
file.pdf in the second example can be "fixed" by editting with vim and "set 
ff=unix", the file can now be read quite happily in Windows.

I am stumped why it should work with a manual pipeline but not when groff sets 
up its own pipeline, so if anyone has any thoughts on either problem I would 
be very grateful to hear.

Cheers 

Deri