ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
* Context against XSL
@ 2004-09-30 14:43 Dirar Bougatef
  2004-09-30 19:06 ` Hans Hagen
  0 siblings, 1 reply; 8+ messages in thread
From: Dirar Bougatef @ 2004-09-30 14:43 UTC (permalink / raw)


[-- Attachment #1: Type: text/html, Size: 794 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Context against XSL
  2004-09-30 14:43 Context against XSL Dirar Bougatef
@ 2004-09-30 19:06 ` Hans Hagen
  2004-09-30 20:53   ` Dirar Bougatef
  2004-10-01  6:52   ` Taco Hoekwater
  0 siblings, 2 replies; 8+ messages in thread
From: Hans Hagen @ 2004-09-30 19:06 UTC (permalink / raw)


Dirar Bougatef wrote:

> Does anyone have informations about tex macro packages and their 
> advantages over XSL (previously known as XSL-FO) ?
> 
> I have read somewhere that tex is a good implementation of the XSL 
> standard !
> 
> I think this is in regard that tex thinks in matter of boxes (Which is 
> the equivalent of XSL blocks). I this case, is the difference between 
> the two in the fact that at the end tex and macros are only algorithms 
> for typesetting blocks automatically ?

xsl is mostly a specification, and there are program soutthere that 
implement parts of is. The page model that xsl uses is not that 
advanced. Also, because you more or less make up the page, you also sort 
of disable all kind of clever things that batch processors like tex + 
macropackages may do. This means that xsl (fo) is suited for a certain 
range of typesetting tasks. From my experience your expectations should 
not be that high with regards to complex layouts.

I'm on and off implementing an fo engine (foxet) and run into fuzziness 
with regards to the specs (a bad omen is that that there i could not 
find a good manual and the ones i have are made up rather poorly, which 
indicated that we're not so much dealing with high end typesetting, but 
with regular batchprocessing of not too complex documents).

Recently i've been playing with css (from which xsl inherits much, which 
does not add to a clear design imo) and i'm surprised that browsers are 
so different that one ends up hacking around as much as one would using 
tex -) In many ways xsl is driven by the web, and not by real 
typesetting (is my guess). paper and screen are different things.

What you use depends on what you need it for. For a long time, the 
midset of designers has been shaped by what page maker, quark, etc can 
and cannot do (therefore all those ragged right docs, where the 
limitations have become the standard). I fear that in the next couple of 
years the limited possibilities of for instance xsl will bring down the 
standards (if it can't be done, one will just lower the demands), which 
also fits in the short lifecycle of most documents.

So, what to use when:

- here i find that using tex directly (using the context xml parser) in 
most cases is rather efficient; the problem is always in getting 
(frequently inconsistent) designs done. In that respect my motto has 
become 'the problem does not change'

- xslt is nice for preprocessing and manipulating documents and often 
one can get away with clean coding

- some scripting is often needed as well (for instance in order to add 
typographical detail, which is rather easy to do with regexps in 
scripting languages)

- xsl (fo), well for the moment i see it as a kind of 'placed xml'; when 
customers want us to use it, we'll do it (gives a feeling of 
independence), but in most cases using some direct mapping onto tex is 
not only easier (cheaper) but also gives a bit more control. It all 
depends on the design.

- so: just use the best of all worlds (which is what xml is about: it's 
consistent -when used all right- and it can be transformed; 
interestingly there are quite some organizations out there that bind 
themselves to just one kind of xml handling app thereby contradicting 
the concept.

In de time i want to write down something on these matters.

Hans

btw, there is a special mailing list for foxet; a preliminary version is 
in the alpha zip


-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Context against XSL
  2004-09-30 19:06 ` Hans Hagen
@ 2004-09-30 20:53   ` Dirar Bougatef
  2004-09-30 22:35     ` Hans Hagen
  2004-10-01  6:52   ` Taco Hoekwater
  1 sibling, 1 reply; 8+ messages in thread
From: Dirar Bougatef @ 2004-09-30 20:53 UTC (permalink / raw)


Hans Hagen wrote:

> Dirar Bougatef wrote:
>
>> Does anyone have informations about tex macro packages and their 
>> advantages over XSL (previously known as XSL-FO) ?
>>
>> I have read somewhere that tex is a good implementation of the XSL 
>> standard !
>>
>> I think this is in regard that tex thinks in matter of boxes (Which 
>> is the equivalent of XSL blocks). I this case, is the difference 
>> between the two in the fact that at the end tex and macros are only 
>> algorithms for typesetting blocks automatically ?
>
>
> xsl is mostly a specification, and there are program soutthere that 
> implement parts of is. The page model that xsl uses is not that 
> advanced. Also, because you more or less make up the page, you also 
> sort of disable all kind of clever things that batch processors like 
> tex + macropackages may do. This means that xsl (fo) is suited for a 
> certain range of typesetting tasks. From my experience your 
> expectations should not be that high with regards to complex layouts.
>
> I'm on and off implementing an fo engine (foxet) and run into 
> fuzziness with regards to the specs (a bad omen is that that there i 
> could not find a good manual and the ones i have are made up rather 
> poorly, which indicated that we're not so much dealing with high end 
> typesetting, but with regular batchprocessing of not too complex 
> documents).
>
> Recently i've been playing with css (from which xsl inherits much, 
> which does not add to a clear design imo) and i'm surprised that 
> browsers are so different that one ends up hacking around as much as 
> one would using tex -) In many ways xsl is driven by the web, and not 
> by real typesetting (is my guess). paper and screen are different things.
>
> What you use depends on what you need it for. For a long time, the 
> midset of designers has been shaped by what page maker, quark, etc can 
> and cannot do (therefore all those ragged right docs, where the 
> limitations have become the standard). I fear that in the next couple 
> of years the limited possibilities of for instance xsl will bring down 
> the standards (if it can't be done, one will just lower the demands), 
> which also fits in the short lifecycle of most documents.
>
> So, what to use when:
>
> - here i find that using tex directly (using the context xml parser) 
> in most cases is rather efficient; the problem is always in getting 
> (frequently inconsistent) designs done. In that respect my motto has 
> become 'the problem does not change'
>
> - xslt is nice for preprocessing and manipulating documents and often 
> one can get away with clean coding
>
> - some scripting is often needed as well (for instance in order to add 
> typographical detail, which is rather easy to do with regexps in 
> scripting languages)
>
> - xsl (fo), well for the moment i see it as a kind of 'placed xml'; 
> when customers want us to use it, we'll do it (gives a feeling of 
> independence), but in most cases using some direct mapping onto tex is 
> not only easier (cheaper) but also gives a bit more control. It all 
> depends on the design.
>
> - so: just use the best of all worlds (which is what xml is about: 
> it's consistent -when used all right- and it can be transformed; 
> interestingly there are quite some organizations out there that bind 
> themselves to just one kind of xml handling app thereby contradicting 
> the concept.
>
> In de time i want to write down something on these matters.
>
> Hans
>
> btw, there is a special mailing list for foxet; a preliminary version 
> is in the alpha zip
>
>
> -----------------------------------------------------------------
>                                           Hans Hagen | PRAGMA ADE
>               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
>      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
>                                              | www.pragma-pod.nl
> -----------------------------------------------------------------
>
> _______________________________________________
> ntg-context mailing list
> ntg-context@ntg.nl
> http://www.ntg.nl/mailman/listinfo/ntg-context
>
> .
>
Hi Hans and thanks for your answers.

 > xsl is mostly a specification, and there are program soutthere that 
implement parts of is. The page model that xsl uses is not that 
advanced. Also, because you more or less make up the page, you also sort
 > of disable all kind of clever things that batch processors like tex + 
macropackages may do. This means that xsl (fo) is suited for a certain 
range of typesetting tasks. From my experience your expectations
 > should not be that high with regards to complex layouts.

Do you mean that i went too far in my interpretation of XSL blocks as 
TEX boxes ?
What i see is that XSL as you said is quiet the same thing as CSS2 hence 
it will support complex layouts (At the end it is only a matter of 
dividing your page into big or small boxes and the ability of accessing 
them, isn't it ?). In this case the difference with tex is only going to 
be that the last handles caracter (with ligatures etc.) and word spacing 
(with regard to hyphenation) according to some rules where the other 
doesn't.

 > .. xsl is driven by the web, and not by real typesetting (is my 
guess). paper and screen are different things.

I have read an article that says that the whole matter about creating 
XSL was printed documents with all what this implies such as headers, 
footers, etc (The stuff that does not concern electronic documents).

 > i find that using tex directly (using the context xml parser) in most 
cases is rather efficient; the problem is always in getting (frequently 
inconsistent) designs done. In that respect my motto has become 'the
 > problem does not change'

What do you mean by this. Is it that i have to stick to only few designs 
and avoid changing too much .. ?

I would like to write my documents in XML, keep THEM on a server and 
generate PDF, when the user clicks on the link to my document.
Of course i want to use Context to typeset my document.  What can i use 
for this  ?  Have you already writen a parser for standard (e.g Docbook) 
documents ?

Bye.

Dirar.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Context against XSL
  2004-09-30 20:53   ` Dirar Bougatef
@ 2004-09-30 22:35     ` Hans Hagen
  0 siblings, 0 replies; 8+ messages in thread
From: Hans Hagen @ 2004-09-30 22:35 UTC (permalink / raw)


Dirar Bougatef wrote:

>  > xsl is mostly a specification, and there are program soutthere that 
> implement parts of is. The page model that xsl uses is not that 
> advanced. Also, because you more or less make up the page, you also sort
>  > of disable all kind of clever things that batch processors like tex + 
> macropackages may do. This means that xsl (fo) is suited for a certain 
> range of typesetting tasks. From my experience your expectations
>  > should not be that high with regards to complex layouts.
> 
> Do you mean that i went too far in my interpretation of XSL blocks as 
> TEX boxes ?
> What i see is that XSL as you said is quiet the same thing as CSS2 hence 
> it will support complex layouts (At the end it is only a matter of 
> dividing your page into big or small boxes and the ability of accessing 
> them, isn't it ?). In this case the difference with tex is only going to 
> be that the last handles caracter (with ligatures etc.) and word spacing 
> (with regard to hyphenation) according to some rules where the other 
> doesn't.

there  is more: pagebreaks, floats, marginal notes, etc those are the 
complicating factors

> I have read an article that says that the whole matter about creating 
> XSL was printed documents with all what this implies such as headers, 
> footers, etc (The stuff that does not concern electronic documents).

indeed, simple docs with only headers and footers -)

>  > i find that using tex directly (using the context xml parser) in most 
> cases is rather efficient; the problem is always in getting (frequently 
> inconsistent) designs done. In that respect my motto has become 'the
>  > problem does not change'
> 
> What do you mean by this. Is it that i have to stick to only few designs 
> and avoid changing too much .. ?

no, that depending on the layout/design, finding a solution for some 
problem will always be difficult; kind of: it's nice to use some 4th 
generation language, but it still leaves us with the 10% hard work in a 
3th one; look at all those editors we see around us: it's no big deal to 
cut and past a basic editor from components readily available, making a 
real good one is still some work -)

> I would like to write my documents in XML, keep THEM on a server and 
> generate PDF, when the user clicks on the link to my document.
> Of course i want to use Context to typeset my document.  What can i use 
> for this  ?  Have you already writen a parser for standard (e.g Docbook) 
> documents ?

some have, not me; it's a matter of mapping elements onto context 
thingies, the parser is already there; just peek in the x-* files

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Context against XSL
  2004-09-30 19:06 ` Hans Hagen
  2004-09-30 20:53   ` Dirar Bougatef
@ 2004-10-01  6:52   ` Taco Hoekwater
  2004-10-01  9:25     ` Hans Hagen
  1 sibling, 1 reply; 8+ messages in thread
From: Taco Hoekwater @ 2004-10-01  6:52 UTC (permalink / raw)



Hans Hagen <pragma@wxs.nl> wrote:

> I'm on and off implementing an fo engine (foxet) and run into fuzziness 
> with regards to the specs (a bad omen is that that there i could not 
> find a good manual and the ones i have are made up rather poorly, which 
> indicated that we're not so much dealing with high end typesetting, but 
> with regular batchprocessing of not too complex documents).
 
The longer one has to read in the XSL-FO specification, the more one 
resents having to do so. If you are lookiing for a road towards creating 
pdf documents, then ConTeXt is like an actual freeway with perhaps a few 
potholes and missing roadsigns, where XSL-FO is a set of directions on how 
to create a jungle road, written down by a civil engineer with terrible
handwriting mirroring a quite chaotic mind who nonetheless insists on 
doing everything "the right way"(tm). 

Various people have been busy trying to build that road according to the 
specifications, and some of the toll (payfare) roads are in fact reasonably 
close. I'm speaking with a certain fondness in my voice really, because I 
am also busy implementing a (commercial) fo engine using ConTeXt.

Greetings, Taco

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Context against XSL
  2004-10-01  6:52   ` Taco Hoekwater
@ 2004-10-01  9:25     ` Hans Hagen
  2004-10-01 10:53       ` Nikolai Weibull
  0 siblings, 1 reply; 8+ messages in thread
From: Hans Hagen @ 2004-10-01  9:25 UTC (permalink / raw)


Taco Hoekwater wrote:

> Hans Hagen <pragma@wxs.nl> wrote:
> 
> 
>>I'm on and off implementing an fo engine (foxet) and run into fuzziness 
>>with regards to the specs (a bad omen is that that there i could not 
>>find a good manual and the ones i have are made up rather poorly, which 
>>indicated that we're not so much dealing with high end typesetting, but 
>>with regular batchprocessing of not too complex documents).
> 
>  
> The longer one has to read in the XSL-FO specification, the more one 
> resents having to do so. If you are lookiing for a road towards creating 
> pdf documents, then ConTeXt is like an actual freeway with perhaps a few 
> potholes and missing roadsigns, where XSL-FO is a set of directions on how 
> to create a jungle road, written down by a civil engineer with terrible
> handwriting mirroring a quite chaotic mind who nonetheless insists on 
> doing everything "the right way"(tm). 

you're right! unfortunately those engineers can ride on the back of the 
horse with xml painted all over it, which makes it good by principle for 
those who pay them; an interesting aspect of this is that while xml 
opens many roads, the tendensy is towards taking one road; there is 
probably some thinking behind this that we suddenly can solve all 
problems for ever and do with one road.

btw, as with much xml related things: much of what is around as 
'standard' is actually just a reversed engineered application interface, 
or worse: serving as an interface to different applications which makes 
it fuzzy; take xsl: there are a lot of dupplicate attributes just to 
serve css; this is strange because the whole idea behind xslt (which is 
mostly ok) is that one can transform, so there is no need for those 
duplicates. The engineer serves to many masters.

apart from the specs, fo lacks a real proper box model: (like css, there 
is no real way to do for instance vertical alignment comparable with 
tex's fill's); it somehow started from the wrong angle;  and then .. how 
about math, chemistry, etc -) a long road ahead

> Various people have been busy trying to build that road according to the 
> specifications, and some of the toll (payfare) roads are in fact reasonably 
> close. I'm speaking with a certain fondness in my voice really, because I 
> am also busy implementing a (commercial) fo engine using ConTeXt.

-)

comparisons between the not-taco engines show big differences (also in 
price) and as soon as extensions start coming into the picture, the 
'acclaimed advantage of fo' disappears. Some peeople pay five digit 
numbers for engines where formulas has to be included as graphic.

I sometimes wonder if it makes sense to cook up an alternative model on 
top of context -)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Context against XSL
  2004-10-01  9:25     ` Hans Hagen
@ 2004-10-01 10:53       ` Nikolai Weibull
  2004-10-01 17:18         ` Matt Gushee
  0 siblings, 1 reply; 8+ messages in thread
From: Nikolai Weibull @ 2004-10-01 10:53 UTC (permalink / raw)


* Hans Hagen <pragma@wxs.nl> [Oct 01, 2004 12:40]:
> comparisons between the not-taco engines show big differences (also in
> price) and as soon as extensions start coming into the picture, the
> 'acclaimed advantage of fo' disappears. Some peeople pay five digit
> numbers for engines where formulas has to be included as graphic.

Heh, serious?  That's incredible.  I'm really beginning to doubt the
"authoring in XML"-bandwagon's legitimacy.
	nikolai

--
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Re: Context against XSL
  2004-10-01 10:53       ` Nikolai Weibull
@ 2004-10-01 17:18         ` Matt Gushee
  0 siblings, 0 replies; 8+ messages in thread
From: Matt Gushee @ 2004-10-01 17:18 UTC (permalink / raw)


On Fri, Oct 01, 2004 at 12:53:22PM +0200, Nikolai Weibull wrote:
> * Hans Hagen <pragma@wxs.nl> [Oct 01, 2004 12:40]:
> > comparisons between the not-taco engines show big differences (also in
> > price) and as soon as extensions start coming into the picture, the
> > 'acclaimed advantage of fo' disappears. Some peeople pay five digit
> > numbers for engines where formulas has to be included as graphic.
> 
> Heh, serious?  That's incredible.  I'm really beginning to doubt the
> "authoring in XML"-bandwagon's legitimacy.
> 	nikolai

You and most of the XML community (I once claimed to be part of that,
but have lately tried to distance myself, partly for the reasons being
discussed here). The original idea was that XML would be a new and
better way to author *Web documents*. Somewhere along the line it
morphed into a general-purpose, universal data exchange format, in which
capacity it serves reasonably well (though it likely should have been
designed differently, had people foreseen how it would actually be
used). 

Meanwhile, a ragged band of diehards continued trying to develop
and promote XML specifically as a web technology and/or a document
technology, but I think very few people have much hope in that area any
more. There was an article on O'Reilly Network's XML.com in July
entitled "XML on the Web has Failed"; that may not settle the question,
but such a statement would have been unthinkable 2 or 3 years ago.

But to get back to the question of XSL: a couple of years ago I was
looking for a way to generate print-ready documents from XML. I tried
the then-latest version of FOP, which was and maybe still is the most
popular open-source XSL-FO processor. I was amazed, after several years
of its development by the Apache project, how many features were
unimplemented, including some that I considered obvious and important
for complex documents (I think, for example, there was no way to do
footnotes). In hindsight, this probably shouldn't have been surprising.
Print documents are complex, and few people are interested in them,
relative to the Web. There probably aren't enough users or interested
programmers to support more than a couple of high-quality products in
this problem space.

Anyway, when I found that FOP wouldn't meet my needs, I started
searching for something else--and found ConTeXt.  Architecturally, it
may not have XSL's Neoclassical tidiness, but it has one huge advantage:
it works.

-- 
Matt Gushee                 When a nation follows the Way,
Haven Rock Press            Horses bear manure through
Englewood, Colorado, USA        its fields;   
books@havenrock.com         When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2004-10-01 17:18 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-30 14:43 Context against XSL Dirar Bougatef
2004-09-30 19:06 ` Hans Hagen
2004-09-30 20:53   ` Dirar Bougatef
2004-09-30 22:35     ` Hans Hagen
2004-10-01  6:52   ` Taco Hoekwater
2004-10-01  9:25     ` Hans Hagen
2004-10-01 10:53       ` Nikolai Weibull
2004-10-01 17:18         ` Matt Gushee

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).