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 _______________________________________________ bug-groff mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-groff
