Date: Mon, 9 Sep 1996 11:41:14 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Hiroyuki Hanai <hanai@hanaigw.astec.co.jp> Cc: doc@freebsd.org Subject: Re: New conversion scheme in place. Message-ID: <Pine.BSI.3.95.960909110850.14433U-100000@fallout.campusview.indiana.edu> In-Reply-To: <199609091542.AAA00307@astec.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Sep 1996, Hiroyuki Hanai wrote: > One or two weeks before, I found the 'tutorial' on the FreeBSD Web and > I searched the source tree to find the source(SGML) files of 'tutorial' > but I could not. > Are they available? Yes, from the web server. For each http://www.freebsd.org/tutorials/foo/foo.html, there is an http://www.freebsd.org/tutorials/foo/foo.sgml. Part of converting to docbook will involve re-evaluating the overall structure of the handbook, and possibly breaking it into a couple more distinct pieces. At that time, we can evaluate the best way to integrate these standalone tutorial type documents. > We also have big TODO!, which is to include our Japanese version of > handbook in the FreeBSD source tree but we don't have clear vision > to do it. I've been thinking about this too. I've got some ideas, but am open to suggestions. I gather the Japanese groff is distributed as patches against groff 1.10. Groff 1.10 which was just brought into current. I'd personally rather not take on the task of bringing the patches into -current. Would anyone like to take responsibility for investigating and ultimately implementing this? Regardless, we can still generate html for Japanese documents with or without j-groff. > Actually, we have no problem so far if we use EUC and I think it'll > be no problem as long as you don't drop the 8th bit of the data content. Dropping the 8th bit is no longer Politically Correct. ;-) > Really? but I think there are serious problems when you want to support > JIS code, isn't it? ;-( It seems like EUC is the path of least resistance so I don't think JIS will be necessary unless there is a particular demand. If I understand correctly, [shift-]JIS <--> EUC conversion is a fairly simple algorithm that could be bolted on the input and output of whatever tools need such conversion. Unicode requires a giant mapping table. > By the way, I wrote about SGML declaration for EUC a few days ago, > how do you think of it? I have not investigated it yet. > P.S. Is there any plan to discard sgmls and use nsgmls for parsing? One reason for sticking with sgmls: ~ $ size `which sgmls` text data bss dec hex 159744 24576 11544 195864 2fd18 ~ $ size `which nsgmls` text data bss dec hex 1089536 12288 8872 1110696 10f2a8 Also, compiling nsgmls on a 16meg or less machine causes pretty intense thrashing. Until we need something that sgmls just can't do (such as unicode), I'd prefer to stick with the old, compact sgmls. -john == jfieber@indiana.edu =========================================== == http://fallout.campusview.indiana.edu/~jfieber ================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.960909110850.14433U-100000>