From owner-freebsd-current@FreeBSD.ORG Tue May 19 17:21:39 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F12684D7 for ; Tue, 19 May 2015 17:21:39 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D4CF1AFA for ; Tue, 19 May 2015 17:21:39 +0000 (UTC) Received: by wgfl8 with SMTP id l8so25785149wgf.2 for ; Tue, 19 May 2015 10:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=aXMtOMWljqmwaurCNiHBfSEwHv17DjqSWiic99S3YPI=; b=CIC+0BVeAurhy+7h5cLopvuXTydXHBSVMmwnNkQhVjmnt6gdXof/Z9LeZgccPg39Fz e12nBIoU3Q5Yk8x8mTUg/FtWpShONA/Izair9uq7yn5mwx0Gk0NYfnuzgRhFPRFjjZJR N5kPQuwKAxpcMzycuV9EoDnpWLXqgicDrOLaCSlN4gX+eEXJ8PBrx+1QD5JEkKNceUas aRcAPevXlMHKq3j7UvTLoPPgXEdrSeaH/D4v5D7hal7lGjzDLpsuxSRe925LoVeYWjH5 88wEuv9848rgDV+osea2v0MKA+Nx378pWc4SDgX4N8Mk7xojYl7ZWmn8EQyCo+MaxTcY OI9Q== X-Received: by 10.194.176.225 with SMTP id cl1mr56036428wjc.45.1432056098001; Tue, 19 May 2015 10:21:38 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id b10sm18287433wic.1.2015.05.19.10.21.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 10:21:36 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 19 May 2015 19:21:34 +0200 From: Baptiste Daroussin To: current@freebsd.org Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools Message-ID: <20150519172134.GE52236@ivaldir.etoilebsd.net> References: <20150514000211.GA9410@ivaldir.etoilebsd.net> <201505152342.t4FNgRgq076946@fire.js.berklix.net> <20150519112644.GB52236@ivaldir.etoilebsd.net> <20150519123722.KSZHLtTvPWw8%sdaoden@yandex.com> <20150519153654.GC52236@ivaldir.etoilebsd.net> <20150519165240.TQ0rmV5a_Z-g%sdaoden@yandex.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wchHw8dVAp53YPj8" Content-Disposition: inline In-Reply-To: <20150519165240.TQ0rmV5a_Z-g%sdaoden@yandex.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 17:21:40 -0000 --wchHw8dVAp53YPj8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 19, 2015 at 06:52:40PM +0200, Steffen Nurpmeso wrote: > Hello, >=20 > Baptiste Daroussin wrote: > |On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote: > |> Baptiste Daroussin wrote: > |>|On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote: > |>=20 > |>|>> I think keeping a fully functionnal roff(7) toolchain part of the > |>|>> base system is very good on a unix. > |>=20 > |>|>> 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. > |>=20 > |> 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). >=20 > .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): >=20 > .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 . >=20 Thanks I will have a look at it soon > |(Note that I'm speaking of doctools as of latest git, not latest releas= e) >=20 > As of last week right shortly after your mail i guess it was. >=20 > |>|Heirloom in base is a win over groff because it has better \ > |>|support for roff(7) > |>|better font handling etc. > |>=20 > |> 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? >=20 > 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?) >=20 > .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 > . \} > .. >=20 > Pretty clean letter stuff like that it is. (You asked for an > example.) Same I'll have a look :) >=20 > |> 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 \ >=20 > I will have my own one, then. Enough work for getting old. d^.^b >=20 > |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 ve= rsion > |which in particular has a couple of fixes for mdoc(7) format and a bit = more. >=20 > 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. >=20 > |Every user of groff will have huge benefit using newer groff versions: = bug > |fixes, full functionnalities available etc. >=20 > 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. >=20 > 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. By full functionnality yes I meant all this + X11 support + things like groffpdf, all the roff2* commands etc. >=20 > (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.) >=20 > 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? I do understand that you have been beaten by your experience. The goal here= is to have a working and maintainable roff toolchain, so far heirloom's seems = to do it. Of course it is not perfect, but from all documentation we do have in base, it does a better job (speaking of fully roff documentation not manpag= es). For all manpages that mandoc(1) does not handle, it makes a decent fallback renderer and often gives better rendering that groff(1) if Interested I can= give you a couple of example where the rendering is better than the one from gro= ff. > (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. >=20 Of course feedback like yours are interesting and taken in account. I will = make sure to harass (in a friendly way :)) upstream to fix all bugs (if I cannot= fix them myself) reported by users. I went the route of proposing this change because doctools is working prope= rly with all the existing stuff we do have in base! (minus a couple of pending fixes) this mail was sent to actually get feedback (like yours) from users = about issue they might have with it so we can address them in time and finish evaluating this tool. I will create a branch soon to make the integration in base happening and testable by more people, then send a call for testing so people can actually test what we would provide to them. Best regards, Bapt --wchHw8dVAp53YPj8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlVbcR4ACgkQ8kTtMUmk6EzK8wCeOmECVljo9bfi2vljMoLbm9r7 nCgAn26kBPHl7floNDC2R7lcZ/i+MpUx =4V8b -----END PGP SIGNATURE----- --wchHw8dVAp53YPj8--