Loading ...
Sorry, an error occurred while loading the content.
 

RE: [XSL-FO] XSL-FO

Expand Messages
  • Peter Wu
    Greetings, In regards to John s point, ...isn t that what open standards are for - to allow people to offload those tasks in an easy way from their app to
    Message 1 of 19 , Oct 20, 2005
      Greetings,

      In regards to John's point, "...isn't that what open
      standards are for - to allow people to offload those
      tasks in an easy way from their app to other, more
      specialized apps? Sure it is", I whole-heartedly
      agree. I appologize for my rather limited thinking.
      Just because the XSL-FO spec doesn't speak directly to
      XForms doesn't mean that Xforms can not potentially be
      used to implement Xforms using features that have
      already been incorporated in the specification like
      what Elliott mentioned, namely instream-foreign object
      and objects for interactive renderings.

      Like John said, Microsoft, Adobe and others have
      already implemented the active documents. I don't know
      in fact if Xforms as supported by OpenOffice
      incorporates FO semantics for formatting purposes but
      the typical OpenOffice word processing document does
      and I imagine that Xforms processors can be developed
      to translate the FO instructions or make use of them
      in the same way.

      Thanks,
      peter






      --- John Madden <john.madden@...> wrote:

      > Peter/Eliot/others,
      >
      > Thanks for the info, particularly the perspective on
      > XSL-FO (which I'll just
      > call XSL) + XForms.
      >
      > Re: Eliot's point about XForms eliciting specific
      > changes in the XSL
      > standard only when-and-if implementers demand it ---
      > That's a fair point.
      >
      > But, evidently Adobe, Microsoft, etc. have
      > recognized an important niche for
      > "active" documents that have reproducible
      > cross-platform appearance (well,
      > Adobe anyway). Thus .pdf has its own whole
      > specifications suite of
      > interactive features (annotations, forms controls,
      > events, etc.) that apply
      > to screen-rendered pdf.
      >
      > As I slowly begin to learn more about XSL, I wonder
      > a little bit about
      > whether a focus on printed output is a little bit
      > odd in today's world. For
      > example, is there an XSL rendering engine today that
      > outputs display
      > postscript? Is there an XSL rendering engine today
      > that outputs pdf with the
      > interactive features accurately rendered when the
      > pdf file is displayed in
      > an Adobe Reader browser window?
      >
      > You could say, well just have your (let's say) web
      > app take responsibility
      > that its XHTML screen output matches your printed
      > output. But on the other
      > hand (and I'm being provocative here), isn't that
      > what open standards are
      > for - to allow people to offload those tasks in an
      > easy way from their app
      > to other, more specialized apps? Sure it is.
      >
      > John
      >
      >
      >
    • Peter Wu
      Greetings, You know what? I think that I might be wrong about XForms incorporating format semantics. I just created one using OpenOffice that contain several
      Message 2 of 19 , Oct 20, 2005
        Greetings,

        You know what? I think that I might be wrong about
        XForms incorporating format semantics. I just created
        one using OpenOffice that contain several input
        fields. I noticed by looking at content.xml that the
        XForm and input objects defined within it do not
        specify how they are rendered at all. That information
        is specified as embedded ODF (Open Document Format)
        instructions (that include FO and SVG type
        instructions) that are inserted and processed
        separately by OpenOffice as the XForm container
        application.

        This implies that John's EMRs, once transformed into
        ODF can be instantiated with a consistent look and
        feel by any ODF compliant XForm client on any
        platform.

        Thanks,
        peter


        --- Peter Wu <peterlwu@...> wrote:

        > Greetings,
        >
        > In regards to John's point, "...isn't that what open
        > standards are for - to allow people to offload those
        > tasks in an easy way from their app to other, more
        > specialized apps? Sure it is", I whole-heartedly
        > agree. I appologize for my rather limited thinking.
        > Just because the XSL-FO spec doesn't speak directly
        > to
        > XForms doesn't mean that Xforms can not potentially
        > be
        > used to implement Xforms using features that have
        > already been incorporated in the specification like
        > what Elliott mentioned, namely instream-foreign
        > object
        > and objects for interactive renderings.
        >
        > Like John said, Microsoft, Adobe and others have
        > already implemented the active documents. I don't
        > know
        > in fact if Xforms as supported by OpenOffice
        > incorporates FO semantics for formatting purposes
        > but
        > the typical OpenOffice word processing document does
        > and I imagine that Xforms processors can be
        > developed
        > to translate the FO instructions or make use of them
        > in the same way.
        >
        > Thanks,
        > peter
        >
        >
        >
        >
        >
        >
        > --- John Madden <john.madden@...> wrote:
        >
        > > Peter/Eliot/others,
        > >
        > > Thanks for the info, particularly the perspective
        > on
        > > XSL-FO (which I'll just
        > > call XSL) + XForms.
        > >
        > > Re: Eliot's point about XForms eliciting specific
        > > changes in the XSL
        > > standard only when-and-if implementers demand it
        > ---
        > > That's a fair point.
        > >
        > > But, evidently Adobe, Microsoft, etc. have
        > > recognized an important niche for
        > > "active" documents that have reproducible
        > > cross-platform appearance (well,
        > > Adobe anyway). Thus .pdf has its own whole
        > > specifications suite of
        > > interactive features (annotations, forms controls,
        > > events, etc.) that apply
        > > to screen-rendered pdf.
        > >
        > > As I slowly begin to learn more about XSL, I
        > wonder
        > > a little bit about
        > > whether a focus on printed output is a little bit
        > > odd in today's world. For
        > > example, is there an XSL rendering engine today
        > that
        > > outputs display
        > > postscript? Is there an XSL rendering engine today
        > > that outputs pdf with the
        > > interactive features accurately rendered when the
        > > pdf file is displayed in
        > > an Adobe Reader browser window?
        > >
        > > You could say, well just have your (let's say) web
        > > app take responsibility
        > > that its XHTML screen output matches your printed
        > > output. But on the other
        > > hand (and I'm being provocative here), isn't that
        > > what open standards are
        > > for - to allow people to offload those tasks in an
        > > easy way from their app
        > > to other, more specialized apps? Sure it is.
        > >
        > > John
        > >
        > >
        > >
        >
        >
      • John Madden
        Hey Peter, This may be just what I am looking for. I know only a very little about ODF as of right now, but it s one of the standards I promised myself I would
        Message 3 of 19 , Oct 20, 2005
          Hey Peter,

          This may be just what I am looking for. I know only a very little about ODF
          as of right now, but it's one of the standards I promised myself I would
          look at. Actually, I think I might like it because it's OASIS, and I'm a
          Relax NG/DSDL fanatic. So maybe I should look at it closely.

          I do wish I could look to XSL (aka XSL-FO) itself for this, because I'd like
          a W3C standard. But (and Eliot, here's my point) people who are looking for
          cross platform presentation standards these days are going to almost
          inevitably demand an easy route to incorporate active features. I'm only
          just now trying to grasp how XSL inline formatting objects would work for
          this, and maybe it will turn out that XSL is just as good a target as ODF.

          In fact, I'd love that, because really I am not looking for a "final"
          presentation format, but rather for a presentation-format-aware adapter
          format that could serve as an intermediate target for my data-oriented XML,
          and could be processed into a variety of end-formats.

          On a related topic (and again cut me some slack, because I'm a complete XSL
          newbie), I've found it kind of odd that I've not come across many
          discussions of XSL processors that target XHTML as *output* (some
          discussions talk about using HTML/XHTML as input for transformation to XSL).
          In my application, I'm trying to get my data-oriented XML into a variety of
          presentation formats including both workstation displays and print. Do any
          XSL processors out there emit XHTML as output?

          John


          _____

          From: XSL-FO@yahoogroups.com [mailto:XSL-FO@yahoogroups.com] On Behalf Of
          Peter Wu
          Sent: Thursday, October 20, 2005 4:02 PM
          To: XSL-FO@yahoogroups.com
          Subject: RE: [XSL-FO] XSL-FO


          Greetings,

          You know what? I think that I might be wrong about
          XForms incorporating format semantics. I just created
          one using OpenOffice that contain several input
          fields. I noticed by looking at content.xml that the
          XForm and input objects defined within it do not
          specify how they are rendered at all. That information
          is specified as embedded ODF (Open Document Format)
          instructions (that include FO and SVG type
          instructions) that are inserted and processed
          separately by OpenOffice as the XForm container
          application.

          This implies that John's EMRs, once transformed into
          ODF can be instantiated with a consistent look and
          feel by any ODF compliant XForm client on any
          platform.

          Thanks,
          peter


          --- Peter Wu <peterlwu@...> wrote:

          > Greetings,
          >
          > In regards to John's point, "...isn't that what open
          > standards are for - to allow people to offload those
          > tasks in an easy way from their app to other, more
          > specialized apps? Sure it is", I whole-heartedly
          > agree. I appologize for my rather limited thinking.
          > Just because the XSL-FO spec doesn't speak directly
          > to
          > XForms doesn't mean that Xforms can not potentially
          > be
          > used to implement Xforms using features that have
          > already been incorporated in the specification like
          > what Elliott mentioned, namely instream-foreign
          > object
          > and objects for interactive renderings.
          >
          > Like John said, Microsoft, Adobe and others have
          > already implemented the active documents. I don't
          > know
          > in fact if Xforms as supported by OpenOffice
          > incorporates FO semantics for formatting purposes
          > but
          > the typical OpenOffice word processing document does
          > and I imagine that Xforms processors can be
          > developed
          > to translate the FO instructions or make use of them
          > in the same way.
          >
          > Thanks,
          > peter
          >
          >
          >
          >
          >
          >
          > --- John Madden <john.madden@...> wrote:
          >
          > > Peter/Eliot/others,
          > >
          > > Thanks for the info, particularly the perspective
          > on
          > > XSL-FO (which I'll just
          > > call XSL) + XForms.
          > >
          > > Re: Eliot's point about XForms eliciting specific
          > > changes in the XSL
          > > standard only when-and-if implementers demand it
          > ---
          > > That's a fair point.
          > >
          > > But, evidently Adobe, Microsoft, etc. have
          > > recognized an important niche for
          > > "active" documents that have reproducible
          > > cross-platform appearance (well,
          > > Adobe anyway). Thus .pdf has its own whole
          > > specifications suite of
          > > interactive features (annotations, forms controls,
          > > events, etc.) that apply
          > > to screen-rendered pdf.
          > >
          > > As I slowly begin to learn more about XSL, I
          > wonder
          > > a little bit about
          > > whether a focus on printed output is a little bit
          > > odd in today's world. For
          > > example, is there an XSL rendering engine today
          > that
          > > outputs display
          > > postscript? Is there an XSL rendering engine today
          > > that outputs pdf with the
          > > interactive features accurately rendered when the
          > > pdf file is displayed in
          > > an Adobe Reader browser window?
          > >
          > > You could say, well just have your (let's say) web
          > > app take responsibility
          > > that its XHTML screen output matches your printed
          > > output. But on the other
          > > hand (and I'm being provocative here), isn't that
          > > what open standards are
          > > for - to allow people to offload those tasks in an
          > > easy way from their app
          > > to other, more specialized apps? Sure it is.
          > >
          > > John
          > >
          > >
          > >
          >
          >




          SPONSORED LINKS
          Xml
          <http://groups.yahoo.com/gads?t=ms&k=Xml+xsl&w1=Xml+xsl&w2=Xsl&w3=Xsl-fo&c=3
          &s=34&.sig=qJNw325nPUVJp-j4hI-Zmg> xsl Xsl
          <http://groups.yahoo.com/gads?t=ms&k=Xsl&w1=Xml+xsl&w2=Xsl&w3=Xsl-fo&c=3&s=3
          4&.sig=9XiQq_Vj008M0D4X7cwELA> Xsl-fo
          <http://groups.yahoo.com/gads?t=ms&k=Xsl-fo&w1=Xml+xsl&w2=Xsl&w3=Xsl-fo&c=3&
          s=34&.sig=8RNnbDshkhY26gg0VNw76Q>

          _____

          YAHOO! GROUPS LINKS



          * Visit your group "XSL-FO <http://groups.yahoo.com/group/XSL-FO> "
          on the web.


          * To unsubscribe from this group, send an email to:
          XSL-FO-unsubscribe@yahoogroups.com
          <mailto:XSL-FO-unsubscribe@yahoogroups.com?subject=Unsubscribe>


          * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
          <http://docs.yahoo.com/info/terms/> .


          _____




          [Non-text portions of this message have been removed]
        • Peter Wu
          Hi John, I don t know if there are any interactive display technologies in existence today that are based entirely on XSL (please help John by correcting me on
          Message 4 of 19 , Oct 20, 2005
            Hi John,

            I don't know if there are any interactive display
            technologies in existence today that are based
            entirely on XSL (please help John by correcting me on
            this if I'm wrong).

            Of course you can transform your EMR data using XSL so
            that it can be displayed in a variety of output
            formats (HTML, XHTML, SVG, XSL-FO) but I think that
            you may already know that. On the other hand, if
            that's what you need, you might want to look at this
            on-line demo for this product called Stylus:
            http://www.stylusstudio.com/videos/tutorial1/tutorial1.html.

            However, I think what you're really asking for is a
            way to translate EMR's into a portable display and
            editing format, preferably XSL-based. This one's kind
            of tough. Eliot, do you have any ideas?

            The problem with HTML, of course, is that it's not
            well formed so that your forms can be parsed. Of
            course, you can solve this particular problem by
            switching over to XHTML. However, your solution may
            very well lie in the world of XForms at least as an
            SVG implementation. I think that only XForms provide
            both interactive read and write capability.

            I don't know how far IBM and Corel has progressed in
            developing this technology
            (http://www-128.ibm.com/developerworks/library/x-svgxf2/).
            Supposedly, by having your customer download an
            SVG/XForms browser plug-in, they would be able to
            retrieve their EMR, read it and update it using
            web-services or other means. On the other hand, why
            install an SVG plug-in when you download a browser
            that displays (and I presume, updates) XForms, SVG,
            XSL-FO and XHTML all at the same time
            (http://www.xsmiles.org/).

            Thanks,
            peter



            --- John Madden <john.madden@...> wrote:

            > Hey Peter,
            >
            > This may be just what I am looking for. I know only
            > a very little about ODF
            > as of right now, but it's one of the standards I
            > promised myself I would
            > look at. Actually, I think I might like it because
            > it's OASIS, and I'm a
            > Relax NG/DSDL fanatic. So maybe I should look at it
            > closely.
            >
            > I do wish I could look to XSL (aka XSL-FO) itself
            > for this, because I'd like
            > a W3C standard. But (and Eliot, here's my point)
            > people who are looking for
            > cross platform presentation standards these days are
            > going to almost
            > inevitably demand an easy route to incorporate
            > active features. I'm only
            > just now trying to grasp how XSL inline formatting
            > objects would work for
            > this, and maybe it will turn out that XSL is just as
            > good a target as ODF.
            >
            > In fact, I'd love that, because really I am not
            > looking for a "final"
            > presentation format, but rather for a
            > presentation-format-aware adapter
            > format that could serve as an intermediate target
            > for my data-oriented XML,
            > and could be processed into a variety of
            > end-formats.
            >
            > On a related topic (and again cut me some slack,
            > because I'm a complete XSL
            > newbie), I've found it kind of odd that I've not
            > come across many
            > discussions of XSL processors that target XHTML as
            > *output* (some
            > discussions talk about using HTML/XHTML as input for
            > transformation to XSL).
            > In my application, I'm trying to get my
            > data-oriented XML into a variety of
            > presentation formats including both workstation
            > displays and print. Do any
            > XSL processors out there emit XHTML as output?
            >
            > John
            >
            >
            > _____
            >
            > From: XSL-FO@yahoogroups.com
            > [mailto:XSL-FO@yahoogroups.com] On Behalf Of
            > Peter Wu
            > Sent: Thursday, October 20, 2005 4:02 PM
            > To: XSL-FO@yahoogroups.com
            > Subject: RE: [XSL-FO] XSL-FO
            >
            >
            > Greetings,
            >
            > You know what? I think that I might be wrong about
            > XForms incorporating format semantics. I just
            > created
            > one using OpenOffice that contain several input
            > fields. I noticed by looking at content.xml that the
            > XForm and input objects defined within it do not
            > specify how they are rendered at all. That
            > information
            > is specified as embedded ODF (Open Document Format)
            > instructions (that include FO and SVG type
            > instructions) that are inserted and processed
            > separately by OpenOffice as the XForm container
            > application.
            >
            > This implies that John's EMRs, once transformed into
            > ODF can be instantiated with a consistent look and
            > feel by any ODF compliant XForm client on any
            > platform.
            >
            > Thanks,
            > peter
            >
            >
            > --- Peter Wu <peterlwu@...> wrote:
            >
            > > Greetings,
            > >
            > > In regards to John's point, "...isn't that what
            > open
            > > standards are for - to allow people to offload
            > those
            > > tasks in an easy way from their app to other, more
            > > specialized apps? Sure it is", I whole-heartedly
            > > agree. I appologize for my rather limited
            > thinking.
            > > Just because the XSL-FO spec doesn't speak
            > directly
            > > to
            > > XForms doesn't mean that Xforms can not
            > potentially
            > > be
            > > used to implement Xforms using features that have
            > > already been incorporated in the specification
            > like
            > > what Elliott mentioned, namely instream-foreign
            > > object
            > > and objects for interactive renderings.
            > >
            > > Like John said, Microsoft, Adobe and others have
            > > already implemented the active documents. I don't
            > > know
            > > in fact if Xforms as supported by OpenOffice
            > > incorporates FO semantics for formatting purposes
            > > but
            > > the typical OpenOffice word processing document
            > does
            > > and I imagine that Xforms processors can be
            > > developed
            > > to translate the FO instructions or make use of
            > them
            > > in the same way.
            > >
            > > Thanks,
            > > peter
            > >
            > >
            > >
            > >
            > >
            > >
            > > --- John Madden <john.madden@...> wrote:
            > >
            > > > Peter/Eliot/others,
            > > >
            > > > Thanks for the info, particularly the
            > perspective
            > > on
            > > > XSL-FO (which I'll just
            > > > call XSL) + XForms.
            > > >
            > > > Re: Eliot's point about XForms eliciting
            > specific
            > > > changes in the XSL
            > > > standard only when-and-if implementers demand it
            > > ---
            > > > That's a fair point.
            > > >
            > > > But, evidently Adobe, Microsoft, etc. have
            > > > recognized an important niche for
            > > > "active" documents that have reproducible
            > > > cross-platform appearance (well,
            > > > Adobe anyway). Thus .pdf has its own whole
            > > > specifications suite of
            > > > interactive features (annotations, forms
            > controls,
            > > > events, etc.) that apply
            > > > to screen-rendered pdf.
            > > >
            > > > As I slowly begin to learn more about XSL, I
            > > wonder
            > > > a little bit about
            > > > whether a focus on printed output is a little
            > bit
            > > > odd in today's world. For
            > > > example, is there an XSL rendering engine today
            > > that
            > > > outputs display
            > > > postscript? Is there an XSL rendering engine
            > today
            > > > that outputs pdf with the
            > > > interactive features accurately rendered when
            > the
            > > > pdf file is displayed in
            > > > an Adobe Reader browser window?
            > > >
            > > > You could say, well just have your (let's say)
            > web
            > > > app take responsibility
            > > > that its XHTML screen output matches your
            > printed
            > > > output. But on the other
            > > > hand (and I'm being provocative here), isn't
            > that
            > > > what open standards are
            > > > for - to allow people to offload those tasks in
            > an
            > > > easy way from their app
            > > > to other, more specialized apps? Sure it is.
            > > >
            > > > John
            > > >
            > > >
            > > >
            > >
            > >
            >
            >
            >
            >
            >
            === message truncated ===
          • Eliot Kimber
            ... XSL-FO is explicitly about generating *paginated* output. Therefore it wouldn t make sense to generate XHTML as the output of an XSL-FO processor. As
            Message 5 of 19 , Oct 20, 2005
              John Madden wrote:

              > On a related topic (and again cut me some slack, because I'm a complete XSL
              > newbie), I've found it kind of odd that I've not come across many
              > discussions of XSL processors that target XHTML as *output* (some
              > discussions talk about using HTML/XHTML as input for transformation to XSL).
              > In my application, I'm trying to get my data-oriented XML into a variety of
              > presentation formats including both workstation displays and print. Do any
              > XSL processors out there emit XHTML as output?

              XSL-FO is explicitly about generating *paginated* output. Therefore it
              wouldn't make sense to generate XHTML as the output of an XSL-FO processor.

              As others have pointed out, that's what XSLT is for.

              Cheers,

              Eliot
              --
              W. Eliot Kimber
              Professional Services
              Innodata Isogen
              9390 Research Blvd, #410
              Austin, TX 78759
              (512) 372-8841

              ekimber@...
              www.innodata-isogen.com
            • John Madden
              Peter/Eliot, ... Yeah, kind of. Actually, I m involved more in EMR standards development than in EMR implementation, and what I m really looking for is not a
              Message 6 of 19 , Oct 20, 2005
                Peter/Eliot,

                > However, I think what you're really asking for is a
                > way to translate EMR's into a portable display and
                > editing format, preferably XSL-based.

                Yeah, kind of. Actually, I'm involved more in EMR standards development than
                in EMR implementation, and what I'm really looking for is not a solution for
                any particular implementation of EMR, but rather an XML target format that
                could serve as a framework component that would:

                (a) be pretty close to the presentation layer, but not quite there;
                (b) hence easily interconvertible by end-implementers into whatever "actual"
                display format they wanted (html, xhtml, doc, pdf, rtf, OpenDocument, txt,
                whatever);
                (c) would yield consistent output;
                AND
                (d) would have a concept of active features when converted to an onscreen
                presentation view.

                Not much to ask, eh? (Forget which popular song had the line: "I don't want
                much, just give me the world.")

                I kind of (sigh) think the closest thing to this is pdf itself. It prints,
                it displays onscreen, it displays on handheld devices, and it supports
                onscreen interaction. But the pdf specification is so arcane (and not
                entirely XML-based, not to mention proprietary), that it isn't a target
                format that most implementers would consider a great framework component.
                That's what's nice about XSL.

                But XSL (like Eliot says) is committed to things like pagination, etc., that
                is it doesn't have a native model of paper-CRT equivalence. I guess the idea
                of a paper page is almost impossible to translate accurately to a screen.

                PDF gets around this by making pdf's appear paginated even when they are
                being displayed inside a reader window in a browser, but I'll be first to
                admit it yields a stilted experience for the user. Ever go crazy trying to
                read a pdf document in a browser window? It drives me nuts, and I almost
                always end up printing the darn thing out and reading the paper version
                instead.

                > The problem with HTML, of course, is that it's not
                > well formed so that your forms can be parsed. Of
                > course, you can solve this particular problem by
                > switching over to XHTML.

                Yeah, I think the real problem even with XHTML is the browser-to-browser
                variations in appearance.

                Anyway, its great of both of you to share your wisdom on this. I think I
                will focus on learning XSL-FO for now and hope that by the time I get good
                at it, somebody else will have figured this all out!!

                John
              • Peter Wu
                Hi John, Don t mean to take up more of your time but just out of curiosity, are you using or planning to use HL7 to encode your EMRs and is HL7 what your
                Message 7 of 19 , Oct 20, 2005
                  Hi John,

                  Don't mean to take up more of your time but just out
                  of curiosity, are you using or planning to use HL7 to
                  encode your EMRs and is HL7 what your transforming
                  into XSL-FO?

                  Thanks,
                  peter

                  --- John Madden <john.madden@...> wrote:

                  > Peter/Eliot,
                  >
                  > > However, I think what you're really asking for is
                  > a
                  > > way to translate EMR's into a portable display and
                  > > editing format, preferably XSL-based.
                  >
                  > Yeah, kind of. Actually, I'm involved more in EMR
                  > standards development than
                  > in EMR implementation, and what I'm really looking
                  > for is not a solution for
                  > any particular implementation of EMR, but rather an
                  > XML target format that
                  > could serve as a framework component that would:
                  >
                  > (a) be pretty close to the presentation layer, but
                  > not quite there;
                  > (b) hence easily interconvertible by
                  > end-implementers into whatever "actual"
                  > display format they wanted (html, xhtml, doc, pdf,
                  > rtf, OpenDocument, txt,
                  > whatever);
                  > (c) would yield consistent output;
                  > AND
                  > (d) would have a concept of active features when
                  > converted to an onscreen
                  > presentation view.
                  >
                  > Not much to ask, eh? (Forget which popular song had
                  > the line: "I don't want
                  > much, just give me the world.")
                  >
                  > I kind of (sigh) think the closest thing to this is
                  > pdf itself. It prints,
                  > it displays onscreen, it displays on handheld
                  > devices, and it supports
                  > onscreen interaction. But the pdf specification is
                  > so arcane (and not
                  > entirely XML-based, not to mention proprietary),
                  > that it isn't a target
                  > format that most implementers would consider a great
                  > framework component.
                  > That's what's nice about XSL.
                  >
                  > But XSL (like Eliot says) is committed to things
                  > like pagination, etc., that
                  > is it doesn't have a native model of paper-CRT
                  > equivalence. I guess the idea
                  > of a paper page is almost impossible to translate
                  > accurately to a screen.
                  >
                  > PDF gets around this by making pdf's appear
                  > paginated even when they are
                  > being displayed inside a reader window in a browser,
                  > but I'll be first to
                  > admit it yields a stilted experience for the user.
                  > Ever go crazy trying to
                  > read a pdf document in a browser window? It drives
                  > me nuts, and I almost
                  > always end up printing the darn thing out and
                  > reading the paper version
                  > instead.
                  >
                  > > The problem with HTML, of course, is that it's not
                  > > well formed so that your forms can be parsed. Of
                  > > course, you can solve this particular problem by
                  > > switching over to XHTML.
                  >
                  > Yeah, I think the real problem even with XHTML is
                  > the browser-to-browser
                  > variations in appearance.
                  >
                  > Anyway, its great of both of you to share your
                  > wisdom on this. I think I
                  > will focus on learning XSL-FO for now and hope that
                  > by the time I get good
                  > at it, somebody else will have figured this all
                  > out!!
                  >
                  > John
                  >
                  >
                  >
                • Dave Pawson
                  ... It might be better understood (or at least explicit) if you continued to use XSL-FO John? XSL is still interpreted by some as meaning XSLT, the transform
                  Message 8 of 19 , Oct 21, 2005
                    On Thu, 2005-10-20 at 12:39 -0400, John Madden wrote:
                    > Peter/Eliot/others,
                    >
                    > Thanks for the info, particularly the perspective on XSL-FO (which I'll just
                    > call XSL)

                    It might be better understood (or at least explicit) if you continued
                    to use XSL-FO John?


                    XSL is still interpreted by some as meaning XSLT, the transform
                    language.

                    It was a single entity, split into XSL and XSLT
                    and was messy for a while. The use of XSL-FO
                    seems to keep it clear in most circles.

                    HTH
                    --
                    Regards,

                    Dave Pawson
                    XSLT + Docbook FAQ
                    http://www.dpawson.co.uk
                  • John Madden
                    Dave, I ll do that from now on. And btw, I m using your excellent book to learn it! Thanks. John ________________________________ From: XSL-FO@yahoogroups.com
                    Message 9 of 19 , Oct 21, 2005
                      Dave,

                      I'll do that from now on. And btw, I'm using your excellent book to learn
                      it!
                      Thanks.

                      John


                      ________________________________

                      From: XSL-FO@yahoogroups.com [mailto:XSL-FO@yahoogroups.com] On
                      Behalf Of Dave Pawson
                      Sent: Friday, October 21, 2005 1:42 PM
                      To: XSL-FO@yahoogroups.com
                      Subject: RE: [XSL-FO] XSL-FO


                      On Thu, 2005-10-20 at 12:39 -0400, John Madden wrote:
                      > Peter/Eliot/others,
                      >
                      > Thanks for the info, particularly the perspective on XSL-FO (which
                      I'll just
                      > call XSL)

                      It might be better understood (or at least explicit) if you
                      continued
                      to use XSL-FO John?


                      XSL is still interpreted by some as meaning XSLT, the transform
                      language.

                      It was a single entity, split into XSL and XSLT
                      and was messy for a while. The use of XSL-FO
                      seems to keep it clear in most circles.

                      HTH
                      --
                      Regards,

                      Dave Pawson
                      XSLT + Docbook FAQ
                      http://www.dpawson.co.uk



                      ________________________________

                      YAHOO! GROUPS LINKS


                      * Visit your group "XSL-FO
                      <http://groups.yahoo.com/group/XSL-FO> " on the web.

                      * To unsubscribe from this group, send an email to:
                      XSL-FO-unsubscribe@yahoogroups.com
                      <mailto:XSL-FO-unsubscribe@yahoogroups.com?subject=Unsubscribe>

                      * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                      Service <http://docs.yahoo.com/info/terms/> .


                      ________________________________
                    • Peter Wu
                      I m getting quite an education. Thanks Dave!
                      Message 10 of 19 , Oct 21, 2005
                        I'm getting quite an education.

                        Thanks Dave!


                        --- Dave Pawson <DaveP@...> wrote:

                        > On Thu, 2005-10-20 at 12:39 -0400, John Madden
                        > wrote:
                        > > Peter/Eliot/others,
                        > >
                        > > Thanks for the info, particularly the perspective
                        > on XSL-FO (which I'll just
                        > > call XSL)
                        >
                        > It might be better understood (or at least explicit)
                        > if you continued
                        > to use XSL-FO John?
                        >
                        >
                        > XSL is still interpreted by some as meaning XSLT,
                        > the transform
                        > language.
                        >
                        > It was a single entity, split into XSL and XSLT
                        > and was messy for a while. The use of XSL-FO
                        > seems to keep it clear in most circles.
                        >
                        > HTH
                        > --
                        > Regards,
                        >
                        > Dave Pawson
                        > XSLT + Docbook FAQ
                        > http://www.dpawson.co.uk
                        >
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.