Hi Eli, Thanks for the explanation.
> > Am I right in thinking that Windows' API is as happy with a/b/c as > > a\b\c > > That's correct. > > > and so wrappers around the code that's cooking up the a\b\c in the > > first place could transliterate there without caring where the a/b/c > > is later to be used? > > The problem with this approach is that these file names are not cooked > by Groff code, they come from the command-line arguments typed by the > user, see above. And AFAIK the (very cool, IMO) feature of > controlling how the user types the command line is not yet in Groff > ;-). Hmm, does that mean the argv[] processing in groff's code is a place to transliterate when it's known to be a filename? No problem if not, of if it's no better than what's been done. I'm just wondering if .lf won't end up being the only place that matters and so changing it on input rather than output might be better, if that's identifiable. Cheers, Ralph.
