Ok, I'm pretty sure cawf 4.10 is the last version of cawf. It's from 1996. The minix version I was playing with earlier is either 4.8 or 4.9.
(groff released in '97, pretty much made cawf pointless)
It was an easy port to RISC OS. I have a little bit of packaging to do yet but it's basically done.
Unfortunately it still can't deal with mandoc or mdoc manpages.
Spent most of the day hacking around with RISC OS cawf.
The old port from the 26-bit era had an "acorn" output device. Turns out this generates output that First Word Plus, an equally ancient RISC OS word processor, can read. Modern Ovation can read this, as can Writer+ (but not quite as well).
RISC OS printer drivers from the era might have understood FWP files directly, I'm not sure.
Also, cawf supports an lj3 output device. LaserJet3=PCL! Ghostscript has a companion program (gpcl) that can (in theory) turn PCL into postscript or whatever. I say "in theory" because so far all I get is a 19 page file of blank pages... Probably missing fonts. RISC OS was once the Master of Fonts, but that was a long time ago...
cawf also has epson output. I'm looking into epson2ps programs. Found a nicely ancient one in a broken shar file.
Still haven't gotten gpcl to do anything useful with cawf's lj3 output.
Stronged has a mode to support PCL files though! Stronged is a text editor though, it doesn't do any pretty rendering for them.
According to the ROOL wiki, PCL files are type &FF3
I don't know if gpcl is being bad or if the cawf output is wrong somehow.
Success!!!!!
guess what? PCL files need CRLF line endings! RISC OS, like UNIX, uses raw linefeeds.
unix2dos on the PCL file and suddenly gpcl can produce working postscript and pdf files from cawf's lj3 output!
gods I'm tired of looking at the cawf manpage. It may be time for the last beer!
I stand corrected!
Real HP PCL printers have a setting to make them accept PCL with bare linefeeds as valid PCL.
It would be nice if that was, say, a cli option in gpcl. I'm investigating.
thanks to Steve Pampling on th ROOL forums
cawf's PCL output has another issue: pcl2whatever thinks they're about 1 line too long per page. Again, I hope to fix this via options to gpcl, but in the meantime, I made a workaround: For lj3 device, cawf now thinks that the output page size is 10 inches, not 11! ;-)
The weird thing about this hack, is that to get it to work, the TERM environment variable needs to be set to lj3. This just shows that cawf is really oriented for displaying man pages on a screen, not paper printouts.
In the process of this hack I actually found a bug!!! cawf uses getenv() to read the environment variables it's interested in but somebody forgot that getenv() always returns the same buffer space, so you must save the results into a different array if you want to keep them!
(and that's not just a RISC OS quirk, that's POSIX!)
This use of TERM to cause an additional device descriptor file to be loaded was obviously not used much...
Amazing what can happen when you RTFM..
So I found 2 ways to set paper size... An escape code inserted directly into the PCL file, but that's pretty horrible to have to do by hand...
Or use PJL "Printer Job Language", supported by gpcl's -J option, to set paper size on the cli.
Humm, which can I catch in a script? ;-)
Simple answer, the default font used by gpcl is HUGE compared to what cawf expects!
Same cawf source, same pdf viewer. The bottom window is the result of epson2ps+ps2pdf. The top window is the result of pcl2pdf.
Never mind pagesizes, I need to argue with gpcl about FONT sizes!
Wrong again!
PCL font stuff is complicated and stubborn!
But I found a setting to set lines per page. I set it to 66 and BOOM cawf's page of output suddenly fits on one page!
I forgot that freakin HP thinks that it can only fit 60 lines on a 8.5x11 inch paper! I should have remembered this from the 90's when I had to deal with hardware laserjets.
Anyway, same setup for the screenshot. The bottom window is the result of epson2ps, top window is pcl2pdf.
RISC OS is a British thing, so all my babble about letter and legal size paper caused a grumble about wanting A4 paper.
I could *swear* I tried setting cawf's papersize with centimeters and it didn't work, so I spent all afternoon tracing the code to figure out if I could add it.
Finally figure out the code, and yes it does speak centimeters.
I try it. It works.
??????
You must trust the Source, Luke.
(actually I may have only tried millimeters. Cawf thinks an "m" is 1/240 inch)
Pretty sure I've bullied ps2ps into making A4 output from cawf's epson output too.
This will make the n Europeans who will actually use RISC OS cawf happy. :-) (n is probably 0, but who knows?)
Also discovered that cawf has been infected with the ANSI-ism that it thinks it should complain about doing things (redefining a macro) that are *specifically* allowed! I don't like that.
@jgoerzen
Early versions of ARM, the status register was the top 6 bits of the program counter, so 26 bit address space.
The change to a seperate status register and full 32bit addresses with ARMv3 broke RISC OS and all its apps. Since the majority of the OS is in assembly, a lot of people had to do a lot of work to make the OS 32bit clean.
And a lot of code was never updated, like most of the apps from stuttgart's old archive. They need partial emulators like aemulor or adffs on ARMv7.
Willard Goosey
John Goerzen