[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: a novice's question

---

---

anilia bruho writes:
 > If anything, I would like to cast my ballot to vote for a complete set of 
 > programming features to be implemented in the XSL-FO standard. Do you think 
 > this is possible in principle, perhaps in a next version?

I do not see how, because you are not asking for programming features,
you want a different model in which the FO processor is mandated to
have a two-way conversation with the formatter (ie you want to say "if
this, after typesetting, would be more than 4cm wide, do something
different"). that is a radical change of philosophy.

 > >*do* have the multi-switch/multi-case stuff in XSL FO (6.9.3 ff),
 > 
 > This would not solve my problem - those features allow to choose among 
 > sub-trees, but still there are no ways to query any element about its 
 > parameters (fonts, dimensions, colors) and to base the choice on that 
 > information.

you could look at DSSSL. that has, I think, theoretical access to font
metrics (though not implemented). but even that would not help. if two
formatters set "the cat sat on the mat" in Times Romran 12pt, the
results are not necessarily the same, because the algorithm to do the
default interword space may not be the same. typical font metrics (eg
AFM) do not contain this interword space parameter.

 > Now, the first (XSLT) and the last (PDF) steps both have complete 
 > programming capabilities (PDF is effectively Postscript which
 > allows for all sorts of math, loops, etc.)
untrue, sorry. that is explicitly the major portion of PostScript
*omitted* from PDF! a PDF file does not have conditionals

 > Why, then, the middle step - FO - is deprived 
 > of this completely? I see no real reason for this.
because FO is just a DTD, not an application?


 > I, for one, would be glad to try re-building some of my TeX macros
 > in XSL to use in some very real-world projects, but the static
 > nature of XSL FO makes me doubt if this is possible at this stage.

I would urge you to *try* and recast your designs in FO. Report what
you find out. If you used my PassiveTeX implementation of XSL FO, you
would find yourself in familiar territory.

Detailed documentation of real-world designs which cannot be solved in
XSLT + FO would help everyone

Sebastian


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

---