Hello, Baptiste Daroussin <bapt_at_freebsd.org> wrote: |On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote: |> Baptiste Daroussin <bapt_at_freebsd.org> wrote: |>|On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote: |> |>|>> I think keeping a fully functionnal roff(7) toolchain part of the |>|>> base system is very good on a unix. |> |>|>> From what I could check I cannot find any regression when \ |>|>> migrating from gnu |>|>> groff to heirloom doctools, if there is a particular area \ |>|>> when you think extra |>|>> care is needed please share it. |> |> It seems you haven't checked at all. |> It seems to me that e.g. mdoc(7) of n-t-r seems to require quite |> a bit of work in order to be at all usable. | |Lots of work has been done recently on heirloom in particular regarding |the support of mdoc(7) and I have opened tickets for all issues \ |I could find and |they have been fixed. Please point me to issues you can have \ |regarding mdoc(7). .Ns doesn't work right, so is why this strong emphasis of mine in the first sentence. Carsten has this example of mine (last week): .Dd Apr 30, 2015 .Dt xxx 1 .Os .Sh NAME .Nm xxx .Nd yyy . Read the system mailbox of .Ar user (appropriate privileges presumed), and .Dq assume to be .Ar user in some aspects, e.g. in respect to .Ic file Ns \(enexpansions of .Ql % etc.; also see .Ev USER . |(Note that I'm speaking of doctools as of latest git, not latest release) As of last week right shortly after your mail i guess it was. |>|Heirloom in base is a win over groff because it has better \ |>|support for roff(7) |>|better font handling etc. |> |> The macros i use for myself don't work with n-t-r, too: once |> i truly looked (a few months ago) i found that i would have to |> rewrite all traps and other positioning in order to get that |> right. | |Can you tell me more about the macros you do use and a sample \ |document so I can |check and see if we can add support for it? Well Carsten asked me this too last year and i've given him as much as i could. But the macros are really rather simple layout via traps. If i recall correctly the examples i've shown Carsten where letters. I would have to rewrite the macros before i can make them public, but it is pretty "normal" troff stuff with traps and positioning, like e.g. the context-free following, for an example (i think i have sent Carsten some trap info back then?) .MACRO RECEIVER . S:BOOLIFY \\$1 . ie \\n[S:#IS_BOOL] \{\ . vs \\n(.su*\\*[RECEIVER_LINE_SPACING_SCALE_FACTOR] . nf . de S:RECEIVER_TRAP EOT . blm PARA . ds S:RECEIVER_DIVERSION_HOOK . sp 1v \\*[RECEIVER_PREHOOK]\c .EOT . di S:RECEIVER_DIVERSION . blm S:RECEIVER_TRAP . \} . el \{\ . if d S:RECEIVER_DIVERSION_HOOK \{\ \\*[RECEIVER_POSTHOOK]\c . rm S:RECEIVER_DIVERSION_HOOK . \} . di . \" Calculate best position for address field and box out . if (\\n(dnu > \\n[#RECEIVER_HEIGHT]u) \{\ . WARNING \ \\$0 address does not fit in address window! Growing window!! . nr #RECEIVER_HEIGHT \\n(dnu . \} . nr #1 (\\n[#RECEIVER_HEIGHT]u-\\n(dnu)/2u . sp |(\\n[#RECEIVER_START]u+\\n(#1u . rr #1 . S:RECEIVER_DIVERSION . rm S:RECEIVER_DIVERSION . rm S:RECEIVER_TRAP . fi . vs . \} .. Pretty clean letter stuff like that it is. (You asked for an example.) |> Despite that you seem to do what you want to do anyway, n-t-r is |> possibly a usable troff, if you go its way and deal with it you |> may be able to gain a bit nicer output _faster_ and without |> converting your beloved special fonts first, but in no way is |> n-t-r a _replacement_ for groff. | |As I said you will be able to use groff from ports. I do not \ I will have my own one, then. Enough work for getting old. d^.^b |claim that n-t-r is |a replacement for groff in general I propose it for a replacement \ |for groff in |base. | |groff in base is stuck at 1.19.2 version while upstream is at 1.22.3 version |which in particular has a couple of fixes for mdoc(7) format and a bit more. The mdoc(7) macros are BSD licensed. Nothing prevents anyone from taking those from GNU troff [master] branch and integrating them into their own roff version. I did that for (the one that will be) mine. |Every user of groff will have huge benefit using newer groff versions: bug |fixes, full functionnalities available etc. The above macros originate from stuff written under FreeBSD 4.9 and especially 5.3 and ran almost a decade there, very smoothly. Also i'm not so sure about that "huge" when i compare groff 1.19.2-574-gecbf4f1 (which is the last GPL2 commit) and 1.22.3. Also Carsten said that. Until now i have indeed assumed it is purely rhetoric. Out of interest: what do you mean when you say "full functionality"? I see some improvements in the line breaking algorithm and support for PDF images, as well as a perl(1)-based PDF output device. ? Of course i want to have that, but for my personal German and English use the first isn't "deadly" necessary, PDF images i've never used (this is EPS then) and the last, well, time has to bring something. Until then PS to PDF via Ghostscript has to do the trick. It always did so for me. (In fact i would possibly have been better off to start my own troff with a codebase from before the grohtml rewrite polluted even deepest parts of the troff engine itself instead of that last GPL2 commit. And things like preconv(1) etc. i will be able to manage in a different way, too. And MathML support for eqn(1) is possibly overkill if the normal HTML output is completely broken.) Not to be misunderstood. Yes, i dislike the decision to include n-t-r doctools in FreeBSD. I took maintainership of a MUA that was written by the same person and the code was completely broken. (And everybody knew that but myself.) Worse, it was terribly designed, and still is like this for the most part. Even though the doctools came up years later, i guess the changes were made on least effort basis also here. And how is that compatible with FreeBSD? (Yet surely parts of FreeBSD always smelled like rotten. I don't know how often i got a hard locked burncd process, for example.) And of course i like that FreeBSD wants to keep a troff, NetBSD unfortunately seems to go a different route. But what benefit can be something that doesn't work with existing stuff, but that needs to be addressed in a special way in order to get not the desired but the expected results? That doesn't make sense to me. But it definetely is not a win, but something different. Maybe it is a win for those who search the latter, though. --steffenReceived on Tue May 19 2015 - 14:53:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:57 UTC