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

Re: Adobe Mars: static SVG inside PDF

Expand Messages
  • Doug Schepers
    Hi, Leonard- Congrats on your new post. Your experience with PDF and SVG make you a valuable team member for Adobe, I m sure. So, please don t take what I say
    Message 1 of 23 , Nov 2, 2006
    • 0 Attachment
      Hi, Leonard-

      Congrats on your new post. Your experience with PDF and SVG make you a
      valuable team member for Adobe, I'm sure.

      So, please don't take what I say next personally. ;) Also, these are my
      views, not necessarily those of the SVG WG.


      Leonard Rosenthol wrote:
      > On 11/2/06, Andreas Neumann <neumann@...> wrote:
      >> The lack of some of the text features, markers and textpath hurts and
      >> is certainly a problem when it comes to creating "maps on demand" or
      >> other more complex graphics.
      >>
      > The issue is that although we are using SVG syntax, we are using
      > it for a different purpose than a "true" SVG viewer. We are using it
      > in a way similar to the original 1.0 (eg. a pre-layed out static
      > rendering) as opposed to the more modern "dynamic rendering" of 1.1
      > and 1.2.

      I'm not sure that's a fair characterization of SVG 1.0. From the
      beginning, SVG was intended to have rich text features, including
      textPath, text styling, and text positioning. Markers, rich colors,
      filters... all of these are SVG 1.0 features, and it is a
      misrepresentation to claim or insinuate otherwise.


      > What you need to remember, is that Mars does NOT contain an SVG
      > rendering engine. It's not our intent to "reinvent" ASV inside of
      > PDF. Instead, we are using SVG (a standard XML grammar) as a way to
      > represent PDF graphics. This is true for all parts of Mars. It's NOT
      > a replacement for PDF - it's just another way to represent/serialize
      > the existing "data objects".

      You are using a small subset of SVG. Nothing wrong with that, of
      course, but it doesn't make you conformant to any standard, any more
      than using the <p>, <ul>, and <table> elements in isolation in some
      other format would make that format conforming HTML. The benefits of
      using SVG in this case are not really clear (other than the benefits of
      XML in general [1]). The content cannot really be repurposed, or
      reliably derived from other SVG generators. As it stands, it only works
      within your particular environment, undercutting the whole point of an
      open standard.

      This is a real disappointment to me. Adobe is going from having one of
      the most complete SVG implementations, to have one of the least. I'm
      afraid I have to agree with Andreas here, though without his optimism.
      Using SVG in this way sounds like a superficial marketing bulletpoint.

      Don't get me wrong. I'm hoping that Adobe will come around once again
      to see the benefits of really using SVG (in print and on the Web). But
      this ain't it, and I'll call bullshit on any PR attempts to make
      sunshine out of shadows.


      >> For the long run I hope
      >> that Adobe Mars will support all the static SVG features when it
      >> targets the print world with Mars.
      >>
      > Mars extends SVG to support numerous high end printing feature
      > that are present in PDF but not standard SVG (or even SVG-P(rint))
      > such as Overprinting and Knockout.

      As you may be aware, now that SVG Tiny 1.2 is in CR phase (that is, in
      the can, so to speak), work has resumed on SVG-Print, aiming at just the
      high-end printing market you describe. It would be great if Adobe (and
      everyone else) were to contribute a list of features that are needed, so
      that we can have an open print graphics standard that will address
      market needs without reverting to proprietary formats.


      [1] http://tech.groups.yahoo.com/group/svg-developers/message/53513

      Regards-
      -Doug
    • Doug Schepers
      Hi- For those of you who don t know, I m not a big fan of CSS. In general, I don t care much for the set of problems they chose to solve or not solve, and I m
      Message 2 of 23 , Nov 2, 2006
      • 0 Attachment
        Hi-

        For those of you who don't know, I'm not a big fan of CSS. In general,
        I don't care much for the set of problems they chose to solve or not
        solve, and I'm not convinced that the manner in which the solutions were
        approached was a good choice in retrospect. To be fair, it may be that
        the implementations of CSS are to blame, not the CSS specifications
        themselves.

        Specifically, though, I don't think CSS is that useful outside of
        HTML... in particular, I don't think it's well-suited for use in SVG.
        Thus, my following questions and comments.

        Leonard Rosenthol wrote:
        > On 11/2/06, brucerindahl <rindahl@...> wrote:
        >>
        >> 1. No CSS attrubutes in SVG. While XML attributes are possible, it
        >> is just easier in some cases to use style attributes in SVG. The lack
        >> of support in Mars will make this very difficult.

        Bruce, what specific aspects of CSS do you normally use that would make
        its absence "very difficult"? I'm assuming you use classes, rather than
        selectors? What use cases in SVG do you have that are solved by CSS,
        and is CSS as it stands adequate for those use cases or could it (or
        some other mechanism) be changed to suit them better?


        > We are simply following the SVG committee itself in the movement
        > away from CSS to attributes - because attributes are more in line with
        > XML philosophy and can be MUCH more easily validated & schema'd.

        Just to set the record straight, that isn't really accurate. SVG Tiny
        1.2 doesn't use CSS (nor did SVG Tiny 1.1), but mainly as a footprint
        issue for smaller devices, not out of a philosophical or technical
        disagreement with CSS. SVG Full will still use CSS, and we are planning
        to work more closely with the CSS WG to make sure that authors have the
        best options available.

        Admittedly, opinions about the utility of CSS in SVG do differ in the
        SVG Working Group; I am clearly not a proponent of CSS, but there are
        other active members of the SVG WG take the opposing view. All of us
        agree that for the CDF (Compound Document Format, or
        XHTML+SVG+CSS+JS+??) use case, CSS is very important, and how exactly it
        works with SVG should be clearly defined.


        Regards-
        -Doug
      • Leonard Rosenthol
        ... I won t - don t worry! In exchange, you can t take my comment as attacks on SVG or the work of the committee... ... You are correct that markers and
        Message 3 of 23 , Nov 3, 2006
        • 0 Attachment
          On 11/2/06, Doug Schepers <doug@...> wrote:
          > So, please don't take what I say next personally. ;) Also, these are my
          > views, not necessarily those of the SVG WG.
          >
          I won't - don't worry! In exchange, you can't take my comment
          as attacks on SVG or the work of the committee...


          > I'm not sure that's a fair characterization of SVG 1.0. From the
          > beginning, SVG was intended to have rich text features, including
          > textPath, text styling, and text positioning. Markers, rich colors,
          > filters... all of these are SVG 1.0 features, and it is a
          > misrepresentation to claim or insinuate otherwise.
          >
          You are correct that markers and filters are certainly parts of
          SVG 1.0, as are text styling & positioning...though they were
          certainly added during the process and not necessary things that were
          there "at the beginning". But point taken!


          > You are using a small subset of SVG.
          >
          True. We are MUCH closer to SVG Tiny than to full SVG - and I
          will certainly revisit the Tiny spec, given your later comment on it's
          status to see if we are better served by leveraging that instead of
          "SVG Full".

          Also, although today we are using this small subset to address
          our needs, it leaves us with a potentially huge growth path for the
          future based on comments such as these and customer requests during
          the trial period. I will certainly take your feedback back (that's
          part of my job, after all!) - and I HIGHLY recommend that any/all of
          you do send your comments in via Labs as well. The more we hear from
          "real people", the more we know what you want.


          > The benefits of
          > using SVG in this case are not really clear (other than the benefits of
          > XML in general [1]). The content cannot really be repurposed, or
          > reliably derived from other SVG generators.
          >
          I disagree with that, since the content CAN be repurposed and
          created from existing generators (or at least some of them). It also
          enables the use of the myriad of existing SVG libraries to consume the
          content, manipulate it, and regenerate as necessary. It enables the
          use of existing XSLT scripts for SVG for things such as "search &
          replace", "restyling", etc.


          > This is a real disappointment to me. Adobe is going from having one of
          > the most complete SVG implementations, to have one of the least.
          >
          I think the problem here is one of marketing :(. And I do
          understand your disappointment in not finding in Mars the replacement
          for ASV. But that's not it's goal - nor do I expect it will ever be.
          However, it is an EXCELLENT opportunity for the SVG community to
          leverage it's experience and tool set on a file format that will have
          a much wider impact (sorry to say it, but it's true).

          Taking off my Adobe hat for a second... _I_ was the one who (as a
          3rd party developer) fought for the use of SVG for Mars's page
          content. It's something, that you know from my participation here
          over the years, that I believe in. Even in the "subset" that it is
          today, the use of SVG as part of Mars continues to breath life into
          SVG - and in my opinion will only HELP to bring it back to the
          mainstream!

          > I'm hoping that Adobe will come around once again
          > to see the benefits of really using SVG (in print and on the Web).
          >
          If you are looking for Adobe to adopt SVG as a replacement for
          Flash or PDF - it's simply not going to happen. (and any discussion
          on this can go to /dev/null)

          HOWEVER, there is an EXCELLENT opportunity for SVG to thrive
          (albiet in a limited form) inside of Mars. We had SVG in PDF before -
          and Adobe took it away (because it wasn't documented/supported). NOW,
          it's the basis for EVERYTHING that gets rendered on the viewed/printed
          page. That's a HUGE leap, though I can also understand why you see it
          as baby steps.

          > I'll call bullshit on any PR attempts to make
          > sunshine out of shadows.
          >
          I'd rather have you support me and the Mars team in promoting SVG
          and keeping it alive and well inside of Adobe - instead of giving
          people reason to drop it again :(. Who knows - if the reaction from
          the world about our use of SVG is positive - maybe we can add more and
          more support for additional features. But if it's negative, the
          chances of that are going to be pretty slim.


          > As you may be aware, now that SVG Tiny 1.2 is in CR phase (that is, in
          > the can, so to speak), work has resumed on SVG-Print, aiming at just the
          > high-end printing market you describe.
          >
          Well...

          I personally think that the SVGPrint committee would be better
          served in working with us (Adobe) to bring Mars to a standards body
          (ISO, AIIM, etc.) as the basis for SVG-based printing. We've solved
          the problem...We use SVG...And as it is simply an alternate
          representation of PDF, it will have greater traction in the print
          publishing industry than anything coming from an unknown (to that
          world) group.


          > open print graphics standard that will address
          > market needs without reverting to proprietary formats.
          >
          That's Mars. 100% based on open standards. Just not (yet!) a
          standard itself.

          Leonard
        • Lance Dyas
          ... Well you don t feel that new ... perhaps the recognition is new... ;-) and the Adobe Systems on the end.
          Message 4 of 23 , Nov 3, 2006
          • 0 Attachment
            Leonard Rosenthol wrote:
            > On 10/31/06, Andreas Neumann <neumann@...> wrote:
            >
            >> Seems like SVG is not yet dead inside Adobe.
            >>
            >>
            > Not at all!
            >
            >
            >
            >> Here is another project
            >> by Adobe to embed static SVG inside a "Mars" file format, which is
            >> basically a zip folder containing xml files (one per page) which
            >> links to SVG/PNG/JPEG/JPEG2000 files.
            >>
            >>
            > You can also read about it on my blog at
            > <http://www.acrobatusers.com/blogs/leonardr>. As you'll see, I am
            > also now with Adobe and one of my responsibilities is the
            > evangelization (is that a real word?!?!) of Mars.
            >
            > In addition to Mars, the new Digital Editions project from Adobe also
            > supports static SVG inside of XHTML-based eBooks.
            >
            >
            > Leonard
            > newly minted, "Technical Standards Evangelist"
            > Adobe Systems
            >
            >
            >
            Well you don't feel that new ... perhaps the recognition is new... ;-)
            and the Adobe Systems on the end.
          • brucerindahl
            ... than ... Doug First I am by no means an expert here so if you have suggestions let me know! I use CSS for symbology in SVG maps. For example when I
            Message 5 of 23 , Nov 3, 2006
            • 0 Attachment
              --- In svg-developers@yahoogroups.com, Doug Schepers <doug@...> wrote:
              > Bruce, what specific aspects of CSS do you normally use that would make
              > its absence "very difficult"? I'm assuming you use classes, rather
              than
              > selectors? What use cases in SVG do you have that are solved by CSS,
              > and is CSS as it stands adequate for those use cases or could it (or
              > some other mechanism) be changed to suit them better?
              >
              Doug
              First I am by no means an expert here so if you have suggestions let
              me know!
              I use CSS for symbology in SVG maps. For example when I retrieve
              highways and roads from the database the class attribute is the
              typically the road type, i.e an interstate, arterial, down to local
              street. By specifying a class the same result from the database can
              be displayed in different ways in two different applications - color,
              dashed lines, etc. If I hard code this in the database interface with
              attributes don't I have to account for each display I want? Would the
              performance suffer if I searched through the DOM and set the display
              attributes based on another attribute?
              Controlling text is also another place I use CSS. Different fonts and
              styles are use using classes. If I need to adjust the font size for
              many locations I just change the style.
              The GUI's on Carto.net also use sytles. All of the various GUI's can
              be changed at once by linking to a different script specifying
              different styles.
              Just some ideas - Is there a better way?
              Thanks
              Bruce
            • Doug Schepers
              Hi, Leonard- ... Nope. :) FWIW, it s a Working Group (WG), not a committee... the difference being that we don t merely oversee the development of SVG, we get
              Message 6 of 23 , Nov 3, 2006
              • 0 Attachment
                Hi, Leonard-

                Leonard Rosenthol wrote:
                > On 11/2/06, Doug Schepers <doug@...> wrote:
                >> So, please don't take what I say next personally. ;) Also, these are my
                >> views, not necessarily those of the SVG WG.
                >>
                > I won't - don't worry! In exchange, you can't take my comment
                > as attacks on SVG or the work of the committee...

                Nope. :) FWIW, it's a Working Group (WG), not a committee... the
                difference being that we don't merely oversee the development of SVG, we
                get our hands dirty and write the technical aspects of the spec itself.


                >> You are using a small subset of SVG.
                >>
                > True. We are MUCH closer to SVG Tiny than to full SVG - and I
                > will certainly revisit the Tiny spec, given your later comment on it's
                > status to see if we are better served by leveraging that instead of
                > "SVG Full".

                Closer, but SVG Tiny still has advanced text capabilities. I totally
                understand why you wouldn't include declarative animation for a print
                spec (needless overhead for static content), but the text styling and
                textPath are desirable there.


                >> The benefits of
                >> using SVG in this case are not really clear (other than the benefits of
                >> XML in general [1]). The content cannot really be repurposed, or
                >> reliably derived from other SVG generators.
                >>
                > I disagree with that, since the content CAN be repurposed and
                > created from existing generators (or at least some of them). It also
                > enables the use of the myriad of existing SVG libraries to consume the
                > content, manipulate it, and regenerate as necessary.

                This assumes that you have sufficient control over the generator to
                restrict its output to the subset of SVG that Mars supports, which is
                quite an assumption. That Mars's subset is not a proper profile of SVG
                complicates this even further.

                As an aside, the text generator you're using for your sample content
                (presumably the same one as in Illustrator?) is making rather chopped-up
                text. It looks fine from a visual perspective, and will certainly print
                fine, but at the XML level, it's cruddy. For example, in
                "mars_sample_files\1_Basic Document\page\0\pg.svg", there are 2
                instances of the word "consumer", but doing a text search will only find
                one... because the first instance is broken up thus: "<text ...
                >c</text><text ...>onsumer</text>" (for no apparent reason, not even at
                a line break... maybe it's for kerning? But SVG has a mechanism for
                that... ). From an XML perspective, that's a step back from HTML. If
                your intended audience expects to be able to use Mars files digitally,
                including search capabilities, you should fix that. I'd be happy to
                give you advice.


                >> This is a real disappointment to me. Adobe is going from having one of
                >> the most complete SVG implementations, to have one of the least.
                >>
                > I think the problem here is one of marketing :(. And I do
                > understand your disappointment in not finding in Mars the replacement
                > for ASV.

                No, I wasn't expecting that. But there are needless restrictions on
                content that would be appropriate for print.


                > But that's not it's goal - nor do I expect it will ever be.
                > However, it is an EXCELLENT opportunity for the SVG community to
                > leverage it's experience and tool set on a file format that will have
                > a much wider impact (sorry to say it, but it's true).

                No, it's not true. It may be an informed opinion, and it may even be
                likely, but it's not a fact. Just because Adobe backs something doesn't
                guarantee its success (or even that Adobe will see it through the
                gates). Meanwhile, SVG Tiny is storming over the mobile world, and is
                becoming natively supported across browsers (just one more to go). No
                offense, but I think you're looking at this measure of success through
                document-centric glasses, rather than as documents and applications and
                graphics.

                Of course, this is just *my* opinion.


                > Taking off my Adobe hat for a second... _I_ was the one who (as a
                > 3rd party developer) fought for the use of SVG for Mars's page
                > content. It's something, that you know from my participation here
                > over the years, that I believe in.

                I have no doubt in your personal intent, and I thank you for your
                dedication to open standards.


                > Even in the "subset" that it is
                > today, the use of SVG as part of Mars continues to breath life into
                > SVG - and in my opinion will only HELP to bring it back to the
                > mainstream!

                It's possible.


                >> I'm hoping that Adobe will come around once again
                >> to see the benefits of really using SVG (in print and on the Web).
                >>
                > If you are looking for Adobe to adopt SVG as a replacement for
                > Flash or PDF - it's simply not going to happen. (and any discussion
                > on this can go to /dev/null)

                No, I am realistic enough to not consider that for a moment. It *could*
                support SVG in its Flash player (as Macromedia claimed for FlashLite),
                but I don't see that happening either.


                > HOWEVER, there is an EXCELLENT opportunity for SVG to thrive
                > (albiet in a limited form) inside of Mars. We had SVG in PDF before -
                > and Adobe took it away (because it wasn't documented/supported). NOW,
                > it's the basis for EVERYTHING that gets rendered on the viewed/printed
                > page. That's a HUGE leap, though I can also understand why you see it
                > as baby steps.

                No, I agree that that's good. But Adobe has proved inconsistent in the
                past, so I will reserve judgement until they actually release a product.


                >> I'll call bullshit on any PR attempts to make
                >> sunshine out of shadows.
                >>
                > I'd rather have you support me and the Mars team in promoting SVG
                > and keeping it alive and well inside of Adobe - instead of giving
                > people reason to drop it again :(. Who knows - if the reaction from
                > the world about our use of SVG is positive - maybe we can add more and
                > more support for additional features. But if it's negative, the
                > chances of that are going to be pretty slim.

                First off, my opinions are my own, and not those of the SVG WG. I'm
                sure that officially, the SVG WG and most of its members see this as a
                very positive thing. And I certainly don't object to its use. As long
                as statements about Mars' use of SVG are accurate, and as long as Mars
                uses a proper subset of SVG (and refrains from arbitrary and
                incompatible "extensions"), we'll get along just fine. :)


                >> As you may be aware, now that SVG Tiny 1.2 is in CR phase (that is, in
                >> the can, so to speak), work has resumed on SVG-Print, aiming at just the
                >> high-end printing market you describe.
                >>
                > Well...
                >
                > I personally think that the SVGPrint committee would be better
                > served in working with us (Adobe) to bring Mars to a standards body
                > (ISO, AIIM, etc.) as the basis for SVG-based printing. We've solved
                > the problem...We use SVG...And as it is simply an alternate
                > representation of PDF, it will have greater traction in the print
                > publishing industry than anything coming from an unknown (to that
                > world) group.

                I'm puzzled by this statement. Adobe is still technically part of the
                SVG WG. Asking a standards body to work with a single company, rather
                than that company working with the standards body, is the tail wagging
                the dog. But maybe the SVG WG would be interested in helping promote
                Mars... you should send an email to the WG describing how you'd like us
                to help.


                >> open print graphics standard that will address
                >> market needs without reverting to proprietary formats.
                >>
                > That's Mars. 100% based on open standards. Just not (yet!) a
                > standard itself.

                From a technical standpoint, what does Mars bring to the plate that SVG
                doesn't provide? I have glanced through your documentation, but I'd
                like to hear your professional assessment.


                Regards-
                -Doug
              • Leonard Rosenthol
                ... Understand that the following is NOT a 100% comprehensive list - but simply some things off the top of my head . Also, I am comparing Mars vs. SVGPrint
                Message 7 of 23 , Nov 3, 2006
                • 0 Attachment
                  On 11/3/06, Doug Schepers <doug@...> wrote:
                  >
                  > >> open print graphics standard that will address
                  > >> market needs without reverting to proprietary formats.
                  > >>
                  > > That's Mars. 100% based on open standards. Just not (yet!) a
                  > > standard itself.
                  >
                  > From a technical standpoint, what does Mars bring to the plate that SVG
                  > doesn't provide? I have glanced through your documentation, but I'd
                  > like to hear your professional assessment.


                  Understand that the following is NOT a 100% comprehensive list - but simply
                  some things "off the top of my head". Also, I am comparing Mars vs.
                  SVGPrint - for the specific purpose of creating, transporting and finally
                  printing "content". And finally, keep in mind that because Mars is an
                  alternate representation of PDF - all of the standard PDF vs. SVGPrint
                  things apply, since Mars incorporates all of the functionality of PDF today.

                  * Mars includes the use of ZIP for a packaging format, thus enabling the use
                  of binary data (w/o B64 encoding) and a single file with no external
                  reference (as might occur with SVGPrint for images, etc.). In a related
                  note, Mars supports embedding of "native font formats" (eg. OpenType) and
                  ICC profiles.

                  * Mars supports a larger set of colorspaces used by the printing industry -
                  including Spot/Separations, DeviceN, and Lab.

                  * Mars supports prepress concepts used primarily (though not exclusively) in
                  a pre-separated workflow. This includes overprinting, knockout, halftones
                  and more.

                  * Mars supports more industry standards for better compression & quality of
                  raster content, including JPEG2000 and JBIG2.

                  * Mars supports complex printing workflows that involve technologies such as
                  OPI.

                  I am sure I am missing things - but that's a good start ;).

                  Leonard


                  [Non-text portions of this message have been removed]
                • CPK Smithies
                  ... - since I ve worked with iterating over PDF documents in the past. For present purposes, the significant issue is that SVG - and XML projects generally -
                  Message 8 of 23 , Nov 3, 2006
                  • 0 Attachment
                    An interesting discussion. The following rang a bell:

                    > As an aside, the text generator you're using for your sample content
                    > (presumably the same one as in Illustrator?) is making rather
                    > chopped-up
                    > text. It looks fine from a visual perspective, and will
                    > certainly print
                    > fine, but at the XML level, it's cruddy. For example, in
                    > "mars_sample_files\1_Basic Document\page\0\pg.svg", there are 2
                    > instances of the word "consumer", but doing a text search
                    > will only find
                    > one... because the first instance is broken up thus: "<text ...
                    > >c</text><text ...>onsumer</text>" (for no apparent reason,
                    > not even at
                    > a line break... maybe it's for kerning?

                    - since I've worked with iterating over PDF documents in the past.

                    For present purposes, the significant issue is that SVG - and XML
                    projects generally - are being designed to support the ordering and
                    design of information in a logical way. The presumption is that the more
                    logically information is structured, the easier it is to search and
                    process programmatically, and the more accessible it's possible to make
                    it for disabled people or for people using limited channels of
                    communication.

                    It seems to me that the aim of PDF and of traditional word processor
                    software is to produce a precisely controlled hard copy.

                    I'm not sure whether it makes sense to try to address these two goals in
                    combination. Except in very simple cases, the very design of the
                    underlying information for one medium or the other is enough of a job in
                    itself without considering the maybe incompatible requirements of these
                    two presentation scenarios.

                    It may well be that some subset of SVG might prove useful for the
                    production of hard copy. However, I think that for SVG and for XML
                    projects in general the right course is to focus upon the best
                    information architecture to address a potentially infinite set of future
                    presentation scenarios.

                    I would certainly rather try to construct precisely controlled hard copy
                    out of logical content than vice versa. But it seems to me these are
                    different projects with different problem spaces, different criteria and
                    different (particularly, differently aged) target audiences.

                    I know of one (rather obese) word processing program that, while
                    apparently designed to produce paginated, printed documents, not only
                    aspires to produce web content but actually has a facility to insert
                    animated borders. I ask myself: Is this a hydra? What is it trying to
                    do?

                    History suggests that limited, clear objectives win the best and most
                    enduring solutions. I for one would rather have a dedicated sound
                    system, wristwatch and bathroom scales than a combination
                    speak-your-weight alarm-clock-radio. (Let no man wed that which God hath
                    put asunder!)

                    Regards to all,
                    CPK Smithies
                  • Leonard Rosenthol
                    ... This is quite true - that in order to present information to people with accessibility needs, the information needs to be as structured as possible so that
                    Message 9 of 23 , Nov 4, 2006
                    • 0 Attachment
                      On 11/3/06, CPK Smithies <cpks@...> wrote:
                      >
                      > For present purposes, the significant issue is that SVG - and XML
                      > projects generally - are being designed to support the ordering and
                      > design of information in a logical way. The presumption is that the more
                      > logically information is structured, the easier it is to search and
                      > process programmatically, and the more accessible it's possible to make
                      > it for disabled people or for people using limited channels of
                      > communication.


                      This is quite true - that in order to present information to people with
                      accessibility needs, the information needs to be as structured as possible
                      so that it can be "repurposed" as appropriate (eg. screen readers, braille
                      printers, etc.). It is one reason that back in PDF 1.4, Adobe introduced
                      Structue & Tagging to PDF files - to enable the "best of both worlds".

                      With Mars and SVG, we are still working through the best solutions for how
                      to continue to intermix the two - since SVG itself doesn't incorporate the
                      level of structure necessary for accessbility. For example, how do you
                      differentiate paragraphs or columns? (let alone, something as complex as a
                      table). Yes, there are W3C guidelines for such things - and we're working
                      through all the options.


                      Leonard


                      [Non-text portions of this message have been removed]
                    • Doug Schepers
                      Hi- ... I don t agree that SVG can t pull double duty as structured markup and as pixel-level placement control. SVG derives its high level of structure from
                      Message 10 of 23 , Nov 7, 2006
                      • 0 Attachment
                        Hi-

                        Leonard Rosenthol wrote:
                        > On 11/3/06, CPK Smithies <cpks@...> wrote:
                        >> For present purposes, the significant issue is that SVG - and XML
                        >> projects generally - are being designed to support the ordering and
                        >> design of information in a logical way. The presumption is that the more
                        >> logically information is structured, the easier it is to search and
                        >> process programmatically, and the more accessible it's possible to make
                        >> it for disabled people or for people using limited channels of
                        >> communication.

                        I don't agree that SVG can't pull double duty as structured markup and
                        as pixel-level placement control. SVG derives its high level of
                        structure from XML (and XML best practices should be used, including
                        proper markup for text), but in addition it is a visual medium, and so
                        has facilities for both the logical structure and the precise
                        appearance. There is no reason for text to be split up in the way I
                        complained about.

                        But...


                        > This is quite true - that in order to present information to people with
                        > accessibility needs, the information needs to be as structured as possible
                        > so that it can be "repurposed" as appropriate (eg. screen readers, braille
                        > printers, etc.). It is one reason that back in PDF 1.4, Adobe introduced
                        > Structue & Tagging to PDF files - to enable the "best of both worlds".
                        >
                        > With Mars and SVG, we are still working through the best solutions for how
                        > to continue to intermix the two - since SVG itself doesn't incorporate the
                        > level of structure necessary for accessbility. For example, how do you
                        > differentiate paragraphs or columns? (let alone, something as complex as a
                        > table). Yes, there are W3C guidelines for such things - and we're working
                        > through all the options.

                        ... I do agree with Leonard (and CPK Smithies) here that there is a
                        missing part of the equation, when it comes to full accessibility. I'm
                        not really sure that there *is* a W3C technology that solves this
                        problem (yet), though I'd love to be proved wrong. But I do applaud
                        anyone who is making an effort to get this right... even Adobe. ;) (jk,
                        Leonard.)

                        If anyone is interested, I wrote a ridiculously long post about this in
                        my blog at http://schepers.cc/?p=11#more-11 . I'd welcome examples or
                        discussion.

                        Regards-
                        -Doug
                      • Jonathan Chetwynd
                        Re: Structural mark up, http://www.peepo.co.uk/temp/gui-schema# is an RDF schema (2004) for describing GUIs for instance in SVG here: http://www.peepo.co.uk
                        Message 11 of 23 , Nov 24, 2006
                        • 0 Attachment
                          Re: Structural mark up,

                          http://www.peepo.co.uk/temp/gui-schema# is an RDF schema (2004) for
                          describing GUIs for instance in SVG here: http://www.peepo.co.uk

                          more generally W3C is also developing similar concepts with DIAL (2006)
                          http://www.w3.org/TR/dial/

                          regards

                          Jonathan Chetwynd



                          On 7 Nov 2006, at 18:15, Doug Schepers wrote:

                          Hi-

                          Leonard Rosenthol wrote:
                          > On 11/3/06, CPK Smithies <cpks@...> wrote:
                          >> For present purposes, the significant issue is that SVG - and XML
                          >> projects generally - are being designed to support the ordering and
                          >> design of information in a logical way. The presumption is that
                          the more
                          >> logically information is structured, the easier it is to search and
                          >> process programmatically, and the more accessible it's possible
                          to make
                          >> it for disabled people or for people using limited channels of
                          >> communication.

                          I don't agree that SVG can't pull double duty as structured markup and
                          as pixel-level placement control. SVG derives its high level of
                          structure from XML (and XML best practices should be used, including
                          proper markup for text), but in addition it is a visual medium, and so
                          has facilities for both the logical structure and the precise
                          appearance. There is no reason for text to be split up in the way I
                          complained about.

                          But...

                          > This is quite true - that in order to present information to
                          people with
                          > accessibility needs, the information needs to be as structured as
                          possible
                          > so that it can be "repurposed" as appropriate (eg. screen readers,
                          braille
                          > printers, etc.). It is one reason that back in PDF 1.4, Adobe
                          introduced
                          > Structue & Tagging to PDF files - to enable the "best of both
                          worlds".
                          >
                          > With Mars and SVG, we are still working through the best solutions
                          for how
                          > to continue to intermix the two - since SVG itself doesn't
                          incorporate the
                          > level of structure necessary for accessbility. For example, how do
                          you
                          > differentiate paragraphs or columns? (let alone, something as
                          complex as a
                          > table). Yes, there are W3C guidelines for such things - and we're
                          working
                          > through all the options.

                          ... I do agree with Leonard (and CPK Smithies) here that there is a
                          missing part of the equation, when it comes to full accessibility. I'm
                          not really sure that there *is* a W3C technology that solves this
                          problem (yet), though I'd love to be proved wrong. But I do applaud
                          anyone who is making an effort to get this right... even Adobe. ;) (jk,
                          Leonard.)

                          If anyone is interested, I wrote a ridiculously long post about this in
                          my blog at http://schepers.cc/?p=11#more-11 . I'd welcome examples or
                          discussion.

                          Regards-
                          -Doug
                        • Charles McCathieNevile
                          On Fri, 24 Nov 2006 20:38:09 +0900, Jonathan Chetwynd ... Actually even more relevant to SVG is the work of WAI-PF on ARIA [1] - essentially a simple
                          Message 12 of 23 , Nov 27, 2006
                          • 0 Attachment
                            On Fri, 24 Nov 2006 20:38:09 +0900, Jonathan Chetwynd
                            <j.chetwynd@...> wrote:

                            > Re: Structural mark up,
                            >
                            > http://www.peepo.co.uk/temp/gui-schema# is an RDF schema (2004) for
                            > describing GUIs for instance in SVG here: http://www.peepo.co.uk
                            >
                            > more generally W3C is also developing similar concepts with DIAL (2006)
                            > http://www.w3.org/TR/dial/

                            Actually even more relevant to SVG is the work of WAI-PF on "ARIA" [1] -
                            essentially a simple mechanism for tagging arbitrary XML with information
                            that describes its semantics. This is the high-level repurposable version
                            of what XBL is meant to do - and that is also work happening at W3C (XBL2
                            [2] is in last call still I think).

                            [1] http://www.w3.org/TR/aria-roadmap/
                            [2] http://www.w3.org/TR/xbl/

                            cheers

                            Chaals

                            --
                            Charles McCathieNevile, Opera Software: Standards Group
                            hablo español - je parle français - jeg lærer norsk
                            chaals@... Try Opera 9 now! http://opera.com
                          • Leonard Rosenthol
                            The issue with both of your references is that they only address the GUI aspects of the SVG content - buttons, controls, etc. They don t, in any way, address
                            Message 13 of 23 , Nov 27, 2006
                            • 0 Attachment
                              The issue with both of your references is that they only address the
                              GUI aspects of the SVG content - buttons, controls, etc. They don't,
                              in any way, address the true semantic nature of the content for
                              non-GUI content.

                              This is esp. important when rendering blocks of text with SVG, and the
                              need to clearly identify paragraphs, sections, etc. Though there
                              are also significant issues when considering graphic/vector elements
                              in the SVG - how to identify sub-sections (eg. rooms in a floor plan,
                              cities on a map, etc.)


                              Leonard
                            • mm_nn9000
                              ... the ... don t, ... the ... there ... elements ... plan,
                              Message 14 of 23 , Nov 27, 2006
                              • 0 Attachment
                                --- In svg-developers@yahoogroups.com, "Leonard Rosenthol"
                                <leonardr@...> wrote:
                                >
                                > The issue with both of your references is that they only address
                                the
                                > GUI aspects of the SVG content - buttons, controls, etc. They
                                don't,
                                > in any way, address the true semantic nature of the content for
                                > non-GUI content.
                                >
                                > This is esp. important when rendering blocks of text with SVG, and
                                the
                                > need to clearly identify paragraphs, sections, etc. Though
                                there
                                > are also significant issues when considering graphic/vector
                                elements
                                > in the SVG - how to identify sub-sections (eg. rooms in a floor
                                plan,
                                > cities on a map, etc.)
                                >
                                >
                                > Leonard
                                >
                              Your message has been successfully submitted and would be delivered to recipients shortly.