[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: experimental release of linuxdoc-tools (based on sgml-tools1.0.9)

Thanks Cees, Adam, and all, for your advices.

In <[email protected]>,
 at "Wed, 17 May 2000 20:58:26 +0200",
  [email protected] (Cees de Groot) writes:

> [email protected] said:
> > > But if you, Adam, or Cees, advise me to use the name of
> > > "SGML-Tools-V1", then I will follow you. 
> > > Please let me know how I should do.
> > I don't know what Cees thinks but I'm fine with the rename. 
> 
> Meetoo. Moof.

Then I will keep to use the name "linuxdoc-tools", until
that tools are required by no user. 

I hope that I can drop it entirely in the end, but currently 
it seems that many users want it to be somehow supported, so 
I think that I should work for them as far as I can.

 # I'm a Debian member, so I follow our Social Contract.
 # It says "Our Priorities are Our Users and Free Software",
 # and it is one of the reasons why I keep the maintainance of
 # the Debian package of sgml-tools v1. another reason will be
 # explained later.

> OBTW: www.sgmltools.org is currently pointing at the SGMLtools-Lite project.
> I intend to have more than that on it ASAP, especially a pointer to 
> linuxdoc-tools. ASAP will probably be somewhere this weekend...

Thanks.

In <[email protected]>,
 at "Wed, 17 May 2000 21:02:22 +0200",
  [email protected] (Cees de Groot) writes:

> [email protected] said:
> >  You changing the command name now will cause more trouble, IMHO..
> 
> He just changed the package name. I think the command names are still 
> "sgml2xxx", whereas SGMLtools-Lite has "sgmltools" (specifically done so it 
> doesn't conflict).

Yes, "sgml2xxxx" and "sgmlcheck" will remain for backward compatibility.
But I changed one command name, which is "sgmltools", because it conflicts
the command in SGMLTools-Lite (and the SGMLTools-2, which is succeeded to
by current SGMLTools-Lite). Anyway, that command "sgmltools" in v1 only
exists for other commands (they are all symbolic links to "sgmltools") and 
it can not be used by users directly to do some productive work, to rename
just this command only, may not cause so much confusion, I think.
And to avoid the conflict with SGMLTools-Lite, this renaming itself is
imperative.

The new command name for old "sgmltools" in v1, is "linuxdoc".
I had tried to use "linuxdoc-tools" for it, but it seems too long for me.

> It looks like SGMLtools-Lite, in order to be compliant with the upcoming LSB 
> recommendation for SGML stuff, needs to parse out the document type of its 
> input document anyway; that would be an option to provide wrappers around 
> SGMLtools-Lite that call linuxdoc-tools (or whatever you call it - the "old 
> Perl stuff for LinuxDoc") so people could indeed trigger everything with 
> "sgmltools --backend....".

I hope so. Please let me know the required task, if there is.

By the way, in order to explain my intention, I quote from README
in the linuxdoc-tools below:

  =====   =====   =====   =====   =====   =====   =====   =====   ===== 
*** This is the README file for the Linuxdoc-Tools package, version 0.1 

*** Currently, there are no official homepage for Linuxdoc-Tools.
    You can reach the current maintainer (me) on ldp-discuss list
    (Infomation about this list is available from LDP website,
     <http://www.linuxdoc.org/>) or sending mail to <[email protected]>.


Linuxdoc-Tools is in fact a small bug-fix version of SGML-Tools 1.0.9.

SGML-Tools 1.0.9 is the last official release of SGML-Tools with the
direct support for LinuxDoc DTD. More recent version of SGML-Tools 2.x 
and its successor, SGMLtools-Lite <http://sgmltools-lite.sourceforge.net/>
only supports the conversion from LinuxDoc DTD sgml into DocBook DTD.

But currently many HOWTO documents in LDP are still provided as 
LinuxDoc DTD sgml files, and many Linux users wish to use the tool
which converts LinuxDoc DTD sgml files into various format direclty.

So I made modification on SGML-Tools 1.0.9, and release the result
as a new branch, in order to avoid the confusion with the SGML-Tools
and the SGMLTools-Lite.

(clip)

This system is tailored for LinuxDoc DTD sgml file, and other DTDs
are not supported. If you needs the tool for DocBook DTD (which is
now more popular DTD than LinuxDoc in writing technical software 
documentation), then you should check SGMLTools-Lite, OpenJade,
and docbook-tools. There is some information page on LDP web site
for these tools.

(clip)

Linuxdoc-Tools depends on the usage of sgml parser from Jade or OpenJade
(nsgmls or onsgmls). You have to install either of them to use this.

Matt Welsh originally created the pacakge under the name Linuxdoc-SGML,
using James Clark's sgmls parser and the QWERTZ DTD by Tom Gordon.
Then Greg Hankins maintained it. It was renamed to SGML-Tools later,
and had been maintained by Cees de Groot <[email protected]>.
SGML-Tools 2.x was heavily changed from 1.0.x to drop the direct support
of Linuxdoc DTD and adopt the support of DocBook DTD using Jade.
SGMLtools-Lite is the latest branch from SGML-Tools 2.x, and it is
maintained by Cees at <http://sgmltools-lite.sourceforge.net/>.

This Linuxdoc-Tools is the branch from SGML-Tools 1.0.9, and its
focus is to provide the backward compatibility for users of old
documents.

This branch uses patch from JF ("The Japanese FAQ Project") to support 
euc-jp encoded Japanese sgml file on sgml2txt, sgml2html, and sgml2latex.
(sgml2info, sgml2lyx, and sgml2rtf are not verified on Japanese support.)

(clip)
  =====   =====   =====   =====   =====   =====   =====   =====   ===== 

I don't want to put too much effort on this branch. I will work
for some more bug fixes if they are found, but would not add
many enhancment on it, except some more i18n support (which is
rather classified as bug-fixes, for me. Because we Japanese
can not use the tools in practice if it lacks the support of
our language).

As for linuxdoc DSSSL stylesheets, I prefer to improve the existing
 ld2db.dsl which is provided by SGMLTools-Lite. I have already 
subscribed the sgml-tools-lite ml, and have once done checkout
of the cvs tree of sgml-tools-lite. But I can't work for that
before I myself learn about DSSSL more.

And, if the Linuxdoc DTD is legacy and will be not used in future,
then I doubt if it is worth the effort to create and maintain 
the totally new stylesheets for this legacy dtd.

More, I have subscribed docbook-tools list, and have read
what Norman Walsh wrote there. Maybe even the DocBook DSSSL 
will be obsoleted in a few years. Nothing can be said for 
LinuxDoc DSSSL.

I think the conversion script using ld2db.dsl is worth
for the effort, because it will work when writers finally
decide to move on the DocBook world (even if it is only
the intermediate step for XML).

But if writers wish to live in the legacy world, then
they wish to use the "old Perl stuff for LinuxDoc" on
their machine, I think.

Here are the report from a user of my Debian package,
sent at December in last year:

   Currently linuxdoc is the only format acceptable to the Linux
   Documentation Project.  When we start accepting DocBook, we plan to
   also permit linuxdoc for those who are familiar with it.  People has
   had problems with the slow speed of using DocBook on old computers.

(You can read the record of this report from:
 <http://cgi.debian.org/cgi-bin/bugreport.cgi?archive=yes&bug=27094>)

if "People has had problems with the slow speed of using DocBook
 (They use the jade, I think) on old computers", then they prefer
to keep using the old staff until they get their new, faster, and
more powerful computers.

I have heard: "Do not put new wine into old bottles."
and I choose to put old wine into old bottles, until
no one wish to drink that old wine.

Thanks.

-- 
  Taketoshi Sano: <[email protected]>,<[email protected]>,<[email protected]>


--  
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]