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

Re: [XSL-FO] XSL-FO

Expand Messages
  • Eliot Kimber
    ... I think you must mean FOP not XSL-FO. XSL-FO is just the standard and says nothing about specific renderered results. ... I think you re misunderstanding
    Message 1 of 19 , Oct 20, 2005
      Peter Wu wrote:
      > Greetings,
      >
      > XSL-FO can output HTML but not XForms.

      I think you must mean FOP not XSL-FO. XSL-FO is just the standard and
      says nothing about specific renderered results.

      > Unfortunately, FO doesn't speak XForms at least not
      > beyond format semantics. It is therefore unlikely that
      > an Xform output adapter will ever be created for FO
      > unless the specification is extended to explicitly
      > cover XForms which for now lies beyond its charter.

      I think you're misunderstanding both what XSL-FO is and isn't for and
      how it has been designed to work with other specifications.

      XForms forms could be integrated with larger FO documents using
      instream-foreign object, just as you can include SVG graphics. There's
      nothing about the FO spec that prevents it or that needs to explicitly
      allow it. It would still be up to specific FO processors to do something
      sensible with the result.

      XSL-FO does include some (largely unimplemented) formatting objects for
      interactive renderings (multi-switch, etc.).

      It's possible that there could be a tighter integration of XForms with
      FO in the sense that the various XForms elements could be mapped to
      formatting objects with their FO-processing-context semantics defined
      (that is, what the area tree implications of a given form component
      are). But I think that activity would be more appropriately driven by
      the XForms community, if it's needed at all.

      Remember that W3C specifications are driven largely by implementation
      which is in turn driven largely by what tool developers do in response
      to customer requirements.

      Therefore, if an FO implementation starts doing interesting things with
      XForms integration beyond simply allowing forms to be embedded in FO
      instances then something might happen in the specs. Until that time it
      is a certainty that nothing will happen.

      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/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
      Message 2 of 19 , Oct 20, 2005
        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
        Hmmm...this is interesting. Elliott, if I understand what you are saying, it s really up to the Xforms community to support FO format semantics. So instead of
        Message 3 of 19 , Oct 20, 2005
          Hmmm...this is interesting.

          Elliott, if I understand what you are saying, it's
          really up to the Xforms community to support FO format
          semantics. So instead of having an FO processor output
          Xforms, they would compile an XForm with embedded FO
          semantics with which to decorate it...like what
          OpenOffice does with embedded FO attributes in ODF.

          Elliott, do you think that it will be feasible to
          implement an FO processor to render XForms as well as
          support XForms functionality perhaps by implementing
          FO objects for interactive renderings? I know that
          several companies including IBM and Corel are
          implementing XForms using SVG. I don't know if any
          effort is being contemplated for FO.

          Thanks,
          peter


          --- Eliot Kimber <ekimber@...> wrote:

          > Peter Wu wrote:
          > > Greetings,
          > >
          > > XSL-FO can output HTML but not XForms.
          >
          > I think you must mean FOP not XSL-FO. XSL-FO is just
          > the standard and
          > says nothing about specific renderered results.
          >
          > > Unfortunately, FO doesn't speak XForms at least
          > not
          > > beyond format semantics. It is therefore unlikely
          > that
          > > an Xform output adapter will ever be created for
          > FO
          > > unless the specification is extended to explicitly
          > > cover XForms which for now lies beyond its
          > charter.
          >
          > I think you're misunderstanding both what XSL-FO is
          > and isn't for and
          > how it has been designed to work with other
          > specifications.
          >
          > XForms forms could be integrated with larger FO
          > documents using
          > instream-foreign object, just as you can include SVG
          > graphics. There's
          > nothing about the FO spec that prevents it or that
          > needs to explicitly
          > allow it. It would still be up to specific FO
          > processors to do something
          > sensible with the result.
          >
          > XSL-FO does include some (largely unimplemented)
          > formatting objects for
          > interactive renderings (multi-switch, etc.).
          >
          > It's possible that there could be a tighter
          > integration of XForms with
          > FO in the sense that the various XForms elements
          > could be mapped to
          > formatting objects with their FO-processing-context
          > semantics defined
          > (that is, what the area tree implications of a given
          > form component
          > are). But I think that activity would be more
          > appropriately driven by
          > the XForms community, if it's needed at all.
          >
          > Remember that W3C specifications are driven largely
          > by implementation
          > which is in turn driven largely by what tool
          > developers do in response
          > to customer requirements.
          >
          > Therefore, if an FO implementation starts doing
          > interesting things with
          > XForms integration beyond simply allowing forms to
          > be embedded in FO
          > instances then something might happen in the specs.
          > Until that time it
          > is a certainty that nothing will happen.
          >
          > Cheers,
          >
          > Eliot
          > --
          > W. Eliot Kimber
          > Professional Services
          > Innodata Isogen
          > 9390 Research Blvd, #410
          > Austin, TX 78759
          > (512) 372-8841
          >
          > ekimber@...
          > www.innodata-isogen.com
          >
          >
        • 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.