lout-users
[Top][All Lists]
Advanced

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

RE: HTML 4/XML+CSS2 front-end


From: Matěj Cepl
Subject: RE: HTML 4/XML+CSS2 front-end
Date: Mon, 4 Jan 1999 11:11:01 -0000

Thanks for reply (BTW, I am on lout mailing list again, so you do not
have to send me mails directly).

> -----Původní zpráva-----
> Od:   Valeriy E. Ushakov [SMTP:address@hidden
> Odesláno:     29. prosince 1998 17:30
> Komu: Lout Mailing List
> Předmět:      Re: HTML 4/XML+CSS2 front-end
> 
> On Tue, Dec 29, 1998 at 12:23:00PM -0000, Matej Cepl wrote:
> 
> > So, my idea of the best writing has changed a little bit.  The input
> > would be SGML-like (plus some stylesheet -- but when I gave just a
> > very short look to DSSSL, I began to panic -- do you really want me
> > to learn _such huge_ stuff?)
> 
> SGML/DSSSL (without loss of generality, this equally applies to
> XML/XSL as well) are targeted to a slightly different usage profile.
> It is assumed that you have huge volumes of SGML marked data and you
> have a DTD and a DSSSL stylesheet for the DTD written once.  Thus you
> invest in the DTD/stylesheet once and you reap benefits afterwards.
> Thus it saves you efforts when you're a big company, or if you use
> some well established DTD (like DocBook).
> 
        [MCepl]  I think so (that DSSSL is not for me).

> As you correctly point out, it's the same as many things on the free
> software world.  You could invest in the open source product to make
> it up to your task or you could invest in the commercial product that
> is up to your task.  In most cases you have to invest and you just
> decide which product, free or commercial, to invest into (with all due
> respect to RMS, I don't share his hatred to commercial software, but
> that's a quite different topic).
> 
        [MCepl]  Well, RMS position on commercial software is not so
rigid as you are suggesting -- I am not able to get on
http://www.gnu.org, but there is some article about possibility of
selling free software).

> Re footnote bug.  First, in case you missed it, I have posted the
> simple fix (Lout level, so no need to recompile) for this problem to
> the list that you could use while waiting for 3.13 to be released.
> Second, every software has bugs and the open source is about being
> able to fix them yourself, not waiting for vendor to release the fix.
> 
        [MCepl]  Yes, sorry to miss it.

> Vendors are often slow and reluctant to introduce changes because one
> man's bug is another man's feature.  Vendor has customers that
> invested in their product and fixing a bug may actually break
> someone's code, so the fix is put on hold (and I do have actual first
> hand experience of this situation).  Open source product gives user an
> advantage of customizing product to suit his needs and to fix bugs
> that are important for you to have fixed (but again, this means
> investment).
> 
        [MCepl]  I can agreee, that vendors are reluctant to add new
features, but I cannot see why they would not want to make bugifxes. If
anybody makes his documents non-compliant with manual to overcome bugs,
thus making his own bugs, let him suffer. Moreover, to your comment,
that I can make changes. Well, I cannot, because I am a lawyer and I
have no time to learn programming.

> Since Russian is an inflected language as well, I see your point.
> However, since declination of words written in latin script usually
> requires an apostrophe to sepatate the stem form the ending, @TeX'u
> (with Russian `u') will do the trick for me.  In your case you could
> use @TeX{u}, perhaps.
> 
        [MCepl]  Not so in Czech, but @TeX{u} may work.

> > You are saying, that HTML4 does not have a future. 
> 
> Huh?  I haven't said this.
> 
> I don't think this route makes sense.  If you want to target multiple
> formats your best bet (in the long term) is SGML+DSSSL/XML+XSL.

        [MCepl]  Well, you said this. Which seems to me pretty close.

> I bet that 95% of the web will not pass through an SGML
> parser.
> 
        [MCepl]  Well, my documents are 100% text and 100% valid HTML
(my biggest project was periodically tested until it fitted in HTML form
-- I am not able to upload and I do not know about any email-aware HTML
validator) according to validator.w3.org (or was it at
www.htmlhelp.org?).

> If you stick to the rigid valid HTML, that using XML/XSL is just one
> little step away (SGML/DSSSL being the next step), but making this
> step gives one (in theory, at least) significant benefits, as you step
> on the firm ground of *standard*.
> 
        [MCepl]  Well, HTML4/CSS2 are standards as well, aren't they?

> If you are looking for an open source SGML/DSSSL engine, than Jade,
> the monumental effort by James Clark, is definetly the first candidate
> to consider (actualy, it's Jade that I had in mind when I wrote about
> Lout backend for a DSSSL engine).
> 
        [MCepl]  I know about Jade, but I am still reluctant to use
DSSL. However, jade it seems to me doesn't handle neither CSS2 nor XSL
or does it? And it produce TeX. BTW, see
http://www.finetuning.com/xsl.html -- there are some interesting
resources as well (I run CSS2 through AltaVista -- result is huge!).

> There's a number of non-DSSSL SGML formatters as well.  In particular
> documentation project for a Debian GNU/Linux uses a simple DTD that is
> converted to HTML and PostScript (via Lout).
> 
        [MCepl]  But SGMLTools and DebianTools DTDs are so primitive,
that not usable for me.  I shoud try html2ps, but I am not sure whether
it will work for me. 

> I think that this boils down to a question: "where to invest".  Some
> open source projects are mature enough so that you usually can "just
> use it" because other people has already invested much in these
> projects and you can just enjoy the fruits (e.g. gcc).  But SGML only
> gaining "momentum" now under XML disguise, so there's no esablished,
> ready to use open source tools yet, though Jade will be probably in
> this position within a couple of years.
> 
        [MCepl]  looking forward to it.

                        Matthew 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]