Date: Mon, 18 Oct 1999 21:03:05 +1300 From: Greg Lehey <grog@lemis.com> To: Nik Clayton <nik@FreeBSD.ORG>, Neil Blakey-Milner <nbm@mithrandr.moria.org> Cc: John Baldwin <jobaldwi@vt.edu>, Jesus Rodriguez <jesusr@ncsa.es>, FreeBSD Documentation Project <doc@FreeBSD.ORG> Subject: Re: Two spaces OK Message-ID: <19991018210305.43873@mojave.worldwide.lemis.com> In-Reply-To: <19991009193308.D21521@catkin.nothing-going-on.org>; from Nik Clayton on Sat, Oct 09, 1999 at 07:33:08PM %2B0100 References: <XFMail.991008110503.jesusr@ncsa.es> <199910081051.GAA86553@server.baldwin.cx> <19991008154459.C33390@mithrandr.moria.org> <19991009193308.D21521@catkin.nothing-going-on.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 9 October 1999 at 19:33:08 +0100, Nik Clayton wrote: > On Fri, Oct 08, 1999 at 03:44:59PM +0200, Neil Blakey-Milner wrote: >> If noone has any other evidence, I'd like to propose the more >> readable form. >> >> I get the impression it just ignores a starting and ending empty >> lines - blank (ie, with spaces) lines still show up. > > The stylesheets we *currently* use used to consider the whitespace at > the beginning and end to be significant, and would include them in the > output. Norm stopped them doing this some time back. He can do this with > SGML docs, because, IIRC, the whitespace handling inside an element is > allowed to be flexible. > > Should we ever want to switch to different stylesheets (or perhaps allow > people to use SGML editors that have their own stylesheets) there's no > guarantee that they'll be as flexible. > > In addition, I think it's likely that at some point we'll transit to an > XML based approach, rather than an SGML based approach. This transition > point is somewhere in the future, and I couldn't predict when it will > happen. However, it's a fairly safe bet that it will happen. > > XML is much stricter about white space inside elements. If it exists then > it has to be preserved, and passed on to the application that's doing the > final formatting. The application would then have to know that certain > elements are 'special', and that leading white space can be stripped. If > you want your documentation to be processed the same way by all these > different applications then you'll need to go around configuring all these > applications with this knowledge. > > With this in mind, I'd prefer that we sacrificed a little bit of readability > in the documentation source in return for some future proofing and simpler > interoperability with other apps. > > If you look through the Handbook you'll doubtless find areas where I've > been inconsistent about this. If anyone's looking for a background task > to work on, fixing these would be handy. . . I'm not 100% sure what you're saying here, but it appears to be "let's go back to a single grey space after a period". I'm not really happy about this, since an alternative might be to get XML to make the decision. In any case, if you do do this, it would be nice to have modified Emacs macros which will still find the ends of sentences. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991018210305.43873>