Re: Renderers and XSL-FO, plus other thoughts...

----- Original Message -----
From: Dave Pawson <daveP@dpawson.freeserve.co.uk>
To: <www-xsl-fo@w3.org>
Sent: Wednesday, January 31, 2001 1:49 AM
Subject: Re: Renderers and XSL-FO, plus other thoughts...


> At 03:00 AM 1/31/01, Arved Sandstrom wrote:
> >I'm interested in soliciting comments regarding interfaces for XSL-FO
processors, and the possible use of FO as an interchange format irrespective
of the existence of FO processors.
>
> I speak very strongly against this Arved.
> Rationale. The WAI asked for a statement to be added to the WD to the
effect
> that fo was an intermediate format, i.e. not an interchange format.
> Rationale? Accessibility. Its difficult, if not impossible, for an eyes
free
> access to fo documents.
> There was (is?) one app on the web which permits viewing of fo objects,
> and this was felt to be an indication that this might happen.
>
> My preference is for fo's in their original guise, ie a means of getting
> xml source documents into a (normally paper based) rendered form.

I wasn't aware of this particular WAI-driven clause. I'll have to check it
out.

Why was WAI so against FO as "interchange"? Because in scenarios that I can
envisage, I still wouldn't expect to be visually inspecting FO. And how is
the current situation better, where a visually-impaired person has to still
deal with putting FO inside XSLT templates?

Still, there is clearly something I don't know about this issue, and I will
study on it, as they say. :-)

> >Let us define the software that accepts FO as input, and produces a
formatted area tree (as stipulated by the XSL specification) as output, as a
"formatter", for the sake of this discussion. It seems to me that
"renderers", that is, translators from area-tree information into
print-quality output formats, would (should?) be restricted to stuff like
PDF, PostScript, and the like. That is, _rendering-level_ translation
happens at the back-end. And it happens with formats that can support the
goals of the original FO, not with HTML or RTF.
> >
> >My feeling is that there is nothing to be gained by having, say, an RTF
"renderer", since the real correspondence is between the FO (XSLT result
tree) at the formatter front-end and RTF, not between the formatter _output_
and RTF. That is, _formatting-level_ translation happens at the front-end.
> >
> >What are the opinions on this division? I think it is reasonable.
>
>  From an intuitive viewpoint, this feels wrong. Just 'where' within
fop/xep etc
> the transition takes place from fo's to "something I can view" (pdf/RTF),
from
> a user view I don't care. Can you see this view of things?

I'm not sure that _this_ issue is a "user" issue. This has more to do with
implementations. From the viewpoint of elegance I just object to taking FO
(which in theory I could convert to RTF better at that point), running a
processor on it, then running a renderer on the output to produce RTF, which
will probably have considerably more translation work to do at that point
because the levels of abstraction are different.

The user would see a "print-quality output preparation system" based on XML.
You're right, they wouldn't care, nor should they. Adding to the first
point, in this view FO as an interchange format would also be internal to
the "printing system".

> >Final thought: do users believe that formatter flexibility in also
accepting CSS would be a boon? The formatting model is shared (in theory)
between CSS and XSL-FO. A formatter that accepts CSS-styled XML could
present pretty much the same formatting-object tree to the formatter as we
get through FO. Or so goes the possible argument. Is consideration of this
worthwhile? What do people think?
>
> For someone without the bandwidth to take on board fo's, CSS might be an
easy in?
> I think such a user would soon see the restrictions of CSS1 or even 2.
> If you were talking 3 then perhaps yes.
> Regards DaveP

Right, I think we would have to be talking about CSS3 to make this
realistic. We're still talking (IMHO) about printing here, mainly
(high-quality output); let Web browsers deal with HTML...

Regards,
Arved Sandstrom

Received on Wednesday, 31 January 2001 05:44:27 UTC