Ingo wrote: > I don't quite understand what you mean by "out of the reach of > preconv(1)."
I also share in my website the macros I wrote for my novels in case anyone may find them useful: https://en.roquesor.com/Downloads/page.tmac I call that tmac file from my Makefile: pdf: ${doc}.tr soelim ../hcode.tr ${doc}.tr | preconv -e utf8 | pic |\ groff -wall -m pic -m page.tmac -P-p${size} > ${doc}.ps Besides the ellipsis definition I mentioned, you'll also see (line 193): ie '\\n[CT_num]'0' .tl ''\\*[Title]'Ep\[^i]logo' If I use there the UTF-8 iacute as is, this is what I get in my PDF after compiling: EpÃlogo > > I didn't review that yet, not sure i will. I didn't expect you to do it. I mentioned my program just to show you with an example that, except for your first tip, I already knew about all you explain in your first answer. And since we are being detailed, regarding your first tip (quoted from you first answer): > to "wchar_t" doesn't really make sense. On OpenBSD, it only > works because UTF-8 is the only supported character encoding *and* > [...] As far as I used and tested my program along the years (and I did it hard), defining those constants the way I did at first did not cause me any problems under Linux (at least). > Quoting from that page: > > :: As the title says, fmtroff is another version of the old fmt(1) > :: that you'll find in any unix-like system[*]. > > I'm not sure that is accurate. That paragraph on my website is just a colloquial introduction; when I say "any unix-like ...", I don't mean it in absolute terms. That paragraph is only there to warn some Linux or MacOS users who have never used fmt(1) and assume that my program is a roff parser, as someone on the Groff mailing lists did. If someday I feel like writting a man page, I'll see about being accurate regarding the history of Unix. But, for who knows fmt(1), the help my program prints is a good start: $ fmtroff -h Usage: fmtroff [-bhlnp] [-w width] [file ...] -b break sentences with a new line -h print this help -m try to skip mail headers and quoted text -n format also lines beginning with a dot character -o lowercase letters can begin a sentence (you may need this with man pages) -p indent the whole paragraph copying the first line indentation -w set maximum line width (default 72 columns) There you already have some clues as to the little differences. > > :: This version, apart from improving some features present in > :: other fmt versions also brings an innovation to make it easier > :: (and more reliable) to work with roff files (to edit my novels > :: I used groff, the GNU version.) > > That sounds a bit misleading, too. I mean, Kurt Shoens' original > version of fmt(1) as it appeared in 2BSD in 1979 already left > two kinds of lines alone: RFC 822 email headers and roff(7) > request and macro lines, and fmt(1) has been supporting the > processing of roff(7) files ever since, for over 45 years. > That isn't surprising either since in 1978, essentially any > kind of serious text processing on Unix and BSD used *roff(1). > > Since you do not provide documentation for your version of fmt(1) - > or maybe i did not find it yet - i'm not sure what exactly is > missing in OpenBSD fmt(1). This certainly works fine for me: > > $ fmt -w40 $(man -w mandoc) > mandoc.1 > $ man mandoc > normal.0 > $ mandoc mandoc.1 > rewrapped.0 > $ diff -u normal.0 rewrapped.0 > > The rewrapped page formats identically to the original, except > that fmt(1) wraps the text lines inside a .Bd -literal block - > which is OK, Compile my program and name it 'fmtroff' and make it visible in your PATH. Add this line to your ~/.nexrc: map v !}fmtroff Open mandoc.1 from vi(1), put your cursor at any line and hit 'v'. Then, in ~/.nexrc, replace from 'fmtroff' for 'fmt', and repeat the test. You'll see the difference. You can also try (not necessarily related to roff) some differences implicit in the help above: - compare what both programs do with the option '-p'. - the option '-b'. - format American English style quoting (quotes or parenthesis after period). > parsing and understanding block macros is beyond > the scope of fmt(1). I've lost count of the number of times I've tried to show you that I'm on your side in this. I completely agree that fmt(1) should be limited to doing what it does. My program does not intend to be a replacement for any version of fmt. It's just a little program I wrote to fit my needs. After using different versions of fmt, as well as the paragraph format feature embedded in Vim or GNU Emacs, I noticed subtle differences, some documented, others not. I took what I found useful from each and created my own abomination. Some users contacted me thanking me and asking for features, so what I did must be useful for something. -- Walter
