On Friday 22 November 2002 2:50 pm, David Carlisle wrote:
it's not clear to me whether there is a real difference in principle
between "a browser that could read FO" and
"a client side pipeline that reads FO, produces PDF and browses the PDF"
whether the internal rendering model is FO or HTML/CSS or PDF, is just
an internal implementation issue isn't it, if FO goes in one end and
something visual and hyperlinked comes out the other, isn't that a
browser?
Perhaps one difference, which in this reality isn't implemented that way
anyway so it matters not. In what we're used to referring to as a 'browser',
we have a window that can be embiggened usually using a handle on the corner
or somewhere. Stuff in the window rushes around madly and rearranges itself
to our viewing pleasure (unless it's Flash, in which case it just sits there
watching with an unaffected expression, like a cat has on when you explain
why it still has to go out when it is raining).
With PDF, you open the browser to max, so you can fit the vertical field of
view in, and it either scales to full, or width, or doesn't at all (depending
on settings pertinent to when the PDF was made). However, altering the
browser viewport doesn't alter the layout. Only the viewable area.
With XSL-FO, you have to specify a real-world actual page size. Even if you
were to specify a page-height or page-width value of "indefinite", you can't
have both that way. Therefore there is always some notion of absolute target
size, even with "auto" as the value (which typically would take the
user-agent's idea of the available space). Generally, you wouldn't do this
for a primarily print-intended publication anyway - too risky.
So if XSL-FO were to be more like HTML or the browser mentality, it would
allow the user to make the browser window bigger and smaller, and the user
would observe all the columns reflowing, all the pictures in blocks inbetween
all the paragraphs in blocks chasing round one after the other as they all
reflow, and the hyphenation exhibiting new linebreaks, with possibly
frightening results in the overflow and clip department.
It's not really like that - it's not 'browser-like' - it's more like viewing a
fixed and dictated layout, which is more like PDF, which is more of a
'viewer' mentality than a 'browser' mentality. I know, the terminology
doesn't suggest those parameters as if they were limitations, and we have
Adobe SVG Viewer, same as Acrobat Viewer, but SVG Viewer isn't really so much
a viewer as a 'player' in the way the Flash plugin or Quicktime plugin is.
Tenuous stuff.
--
Ian Tindale
--
Ian Tindale
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list