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

Re: [svg-developers] canonical expressions -- part 2: A challenge: accessbility and symbols of the public domain (wikipedia)

Expand Messages
  • ddailey
    Challenge: come up with better symbols for signifying public domain or copyright free. Begin here http://granite.sru.edu/~ddailey/svg/pd3.svg . Look at
    Message 1 of 4 , Nov 7, 2010
    • 0 Attachment
      Challenge: come up with "better" symbols for signifying "public domain" or "copyright free."

      Begin here http://granite.sru.edu/~ddailey/svg/pd3.svg . Look at the source code and then see what you think. I'll get back to that example toward the end of this message.

      As a bit of searching in Google Images*, Wikipedia and Wikimedia Commons will reveal, there are several symbols meant to depict the concepts of "copyright free" or "public domain" or "copyleft." Not only do these concepts have slightly different nuances of meaning, but the symbols have a many-to-many relationship with the concepts. And furthermore, the symbols have differential levels of accessibity, depending on for whom we define "making" "allowing" or "enabling" to be accessible. And, many of the symbols, while looking alike, have very different underlying file structure.

      Following a recent visit to openclipart.org** I was rather prepared for what Jeff Schiller calls "cruft" when I saw the earlier image at http://commons.wikimedia.org/wiki/File:Publicdomain.svg
      as described there.I did the following [Hand edited to remove sodipodi and inkscape references, remove unused gradients, remove unused styles, replaced duplicated paths by <use> elements, simplified complex cubic beziers as simple arc subcommands; used integer arithmetic. Replaced complex arcs by circles. New file is 18 (<lkb) lines of code -- old file was 144 lines (>5kb). New file should have better semantics for re-editing basic objects.]

      Well 18 lines and 895 bytes defintely seems better than 5 kilobytes of code. But is the new code more accessible? Well, I think it is, but how can I tell for sure? How does one come up with the "best" expression for such a simple figure?

      Look inside the two figures and you'll see several questions that pose themselves:
      is it better to use <use>?
      does striking all the sodipodi stuff erase some of the artist's brushstrokes?***
      are two paths with one rotating the other better than one that has twice as coordinates listed?
      doesn't it make more sense to let color be inherited from the group rather than individually defined for each path?
      what about the optical illusion of the letters pd for public domain? Should that be made semantic in our markup?

      I confess it took me a while of fidding to replace all those cubic beziers from Inkscape by the "canonical" arc-equivalents. But I figure that the seven coordinates (or so) that I used, instead of sixty or so in the original path ought to make the content more accessible to future analysists if anyone ever wants to modify it!

      Next question (and maybe more important):

      Take a look at http://granite.sru.edu/~ddailey/svg/pd3.svg

      The image on the left is one of the current images served by wikimedia as the symbol for "copyright free".[2] Perhaps it is based on [3] . Perhaps the metadata associated with the file should show its ancestry?

      The file history shows some well-deserved attempt to rid the file of unneeded complexity and cruft.
      The current image (in its eleventh incarnation on wikipedia). It consists of four circles and three rectangles. One of the rectangles looks like it has been added merely to carve out a portion of a circle to make it look like a "c." This doesn't seem very accessible.

      So in my quick attempt, I put a "c" in the middle of the circle. I defined the circle as not two circles but one. I defined the rectangle as not two but one, and I defined the "C" as not two circles and a rectangle, but as a "c". I also made a stab at adding <title> and <desc> tags to describe the "why and what" of the file.

      So here is the challenge: can we come up with a better version of the symbol that what is there right now?

      Can we come up with one we will all agree is better?

      What I don't like about my attempt is that the "C" is dependent upon system fonts??? Changing from sans-serif to arial makes a huge difference in some browsers!

      Should the circle be one circle or two?

      Should the circle really be carved by a clipPath consisting of two arcs or should it be a circle with a line (rect) that crosses it? I chose a crossing line but was not convinced this was right.

      I stretched the "C" horizontally to make it appear to conform to the circle outside. Circles would have conformed better!

      What is the canonical <title> and <desc> information to go with the proper file?

      What is the proper way to refer to this discussion thread should we ever agree on my desire to replace the four circles and three rects

      cheers
      David

      *I discovered to my great dismay that Ditto.com, as of about 6 months ago, no longer exists[1]. Their lawsuit paved the way for Google images which followed almost to the day the initial ruling in favor of Ditto.com.

      **After spending a bit of time reminding myself of why I (wearing various hats that I do) don't use more images from http://www.openclipart.org/ , I wrote a bit of script to help me find the relevant <path> objects (amidst gradients and filters that are never used) that actually draw the interesting shapes (assigning mouseover event that parse and modify the "style" of the active object).

      *** I remember in the 1980's trying to help students (and a wife) recover their corrupted word-processed files and realizing that the archival copy actually contained not only the document but the "edit history" of the document including backspaces, deletes, copies and pastes!

      [1] http://srufaculty.sru.edu/david.dailey/copyright/legalthumb.htm
      [2] http://en.wikipedia.org/wiki/File:PD-icon.svg

      [3] http://en.wikipedia.org/wiki/File:Red_copyright.svg

      [Non-text portions of this message have been removed]
    • Dailey, David P.
      Oops, the second file I was talking about here was actually http://granite.sru.edu/~ddailey/svg/pd4.svg That s the familiar copyright free symbol in use by
      Message 2 of 4 , Nov 8, 2010
      • 0 Attachment
        Oops, the second file I was talking about here was actually http://granite.sru.edu/~ddailey/svg/pd4.svg
        That's the familiar copyright free symbol in use by Wikipedia.

        The basic question is "how best to make it semantically correct and visually consistent with the appearance?"

        Cheers
        David


        From: svg-developers@yahoogroups.com [mailto:svg-developers@yahoogroups.com] On Behalf Of ddailey
        Sent: Sunday, November 07, 2010 11:32 PM
        To: svg-developers@yahoogroups.com
        Subject: Re: [svg-developers] canonical expressions -- part 2: A challenge: accessbility and symbols of the public domain (wikipedia)



        Challenge: come up with "better" symbols for signifying "public domain" or "copyright free."

        Begin here http://granite.sru.edu/~ddailey/svg/pd3.svg . Look at the source code and then see what you think. I'll get back to that example toward the end of this message.

        As a bit of searching in Google Images*, Wikipedia and Wikimedia Commons will reveal, there are several symbols meant to depict the concepts of "copyright free" or "public domain" or "copyleft." Not only do these concepts have slightly different nuances of meaning, but the symbols have a many-to-many relationship with the concepts. And furthermore, the symbols have differential levels of accessibity, depending on for whom we define "making" "allowing" or "enabling" to be accessible. And, many of the symbols, while looking alike, have very different underlying file structure.

        Following a recent visit to openclipart.org** I was rather prepared for what Jeff Schiller calls "cruft" when I saw the earlier image at http://commons.wikimedia.org/wiki/File:Publicdomain.svg
        as described there.I did the following [Hand edited to remove sodipodi and inkscape references, remove unused gradients, remove unused styles, replaced duplicated paths by <use> elements, simplified complex cubic beziers as simple arc subcommands; used integer arithmetic. Replaced complex arcs by circles. New file is 18 (<lkb) lines of code -- old file was 144 lines (>5kb). New file should have better semantics for re-editing basic objects.]

        Well 18 lines and 895 bytes defintely seems better than 5 kilobytes of code. But is the new code more accessible? Well, I think it is, but how can I tell for sure? How does one come up with the "best" expression for such a simple figure?

        Look inside the two figures and you'll see several questions that pose themselves:
        is it better to use <use>?
        does striking all the sodipodi stuff erase some of the artist's brushstrokes?***
        are two paths with one rotating the other better than one that has twice as coordinates listed?
        doesn't it make more sense to let color be inherited from the group rather than individually defined for each path?
        what about the optical illusion of the letters pd for public domain? Should that be made semantic in our markup?

        I confess it took me a while of fidding to replace all those cubic beziers from Inkscape by the "canonical" arc-equivalents. But I figure that the seven coordinates (or so) that I used, instead of sixty or so in the original path ought to make the content more accessible to future analysists if anyone ever wants to modify it!

        Next question (and maybe more important):

        Take a look at http://granite.sru.edu/~ddailey/svg/pd3.svg

        The image on the left is one of the current images served by wikimedia as the symbol for "copyright free".[2] Perhaps it is based on [3] . Perhaps the metadata associated with the file should show its ancestry?

        The file history shows some well-deserved attempt to rid the file of unneeded complexity and cruft.
        The current image (in its eleventh incarnation on wikipedia). It consists of four circles and three rectangles. One of the rectangles looks like it has been added merely to carve out a portion of a circle to make it look like a "c." This doesn't seem very accessible.

        So in my quick attempt, I put a "c" in the middle of the circle. I defined the circle as not two circles but one. I defined the rectangle as not two but one, and I defined the "C" as not two circles and a rectangle, but as a "c". I also made a stab at adding <title> and <desc> tags to describe the "why and what" of the file.

        So here is the challenge: can we come up with a better version of the symbol that what is there right now?

        Can we come up with one we will all agree is better?

        What I don't like about my attempt is that the "C" is dependent upon system fonts??? Changing from sans-serif to arial makes a huge difference in some browsers!

        Should the circle be one circle or two?

        Should the circle really be carved by a clipPath consisting of two arcs or should it be a circle with a line (rect) that crosses it? I chose a crossing line but was not convinced this was right.

        I stretched the "C" horizontally to make it appear to conform to the circle outside. Circles would have conformed better!

        What is the canonical <title> and <desc> information to go with the proper file?

        What is the proper way to refer to this discussion thread should we ever agree on my desire to replace the four circles and three rects

        cheers
        David

        *I discovered to my great dismay that Ditto.com, as of about 6 months ago, no longer exists[1]. Their lawsuit paved the way for Google images which followed almost to the day the initial ruling in favor of Ditto.com.

        **After spending a bit of time reminding myself of why I (wearing various hats that I do) don't use more images from http://www.openclipart.org/ , I wrote a bit of script to help me find the relevant <path> objects (amidst gradients and filters that are never used) that actually draw the interesting shapes (assigning mouseover event that parse and modify the "style" of the active object).

        *** I remember in the 1980's trying to help students (and a wife) recover their corrupted word-processed files and realizing that the archival copy actually contained not only the document but the "edit history" of the document including backspaces, deletes, copies and pastes!

        [1] http://srufaculty.sru.edu/david.dailey/copyright/legalthumb.htm
        [2] http://en.wikipedia.org/wiki/File:PD-icon.svg

        [3] http://en.wikipedia.org/wiki/File:Red_copyright.svg

        [Non-text portions of this message have been removed]



        [Non-text portions of this message have been removed]
      • th_w@ymail.com
        ... You ain t seen nothing yet! Look at the file history of those: http://commons.wikimedia.org/wiki/File:Spain_traffic_signal_r307.svg
        Message 3 of 4 , Nov 8, 2010
        • 0 Attachment
          --- In svg-developers@yahoogroups.com, "ddailey" <ddailey@...> wrote:
          >
          > Following a recent visit to openclipart.org** I was rather prepared for what Jeff Schiller calls "cruft" when I saw the earlier image at http://commons.wikimedia.org/wiki/File:Publicdomain.svg
          > as described there.

          You ain't seen nothing yet! Look at the file history of those:

          http://commons.wikimedia.org/wiki/File:Spain_traffic_signal_r307.svg
          http://commons.wikimedia.org/wiki/File:Hanse_Rostock.svg

          And here is one damn excellent example where the SVG code just says what the image is about - after someone cleaned it up:

          http://commons.wikimedia.org/wiki/File:Sierpinski-Trigon-7.svg

          Thomas W.
        • G. Wade Johnson
          Interesting topic, as usual. I can only comment about one area. On Sun, 7 Nov 2010 23:31:43 -0500 ... [snip] ... I find all of these questions are variations
          Message 4 of 4 , Nov 8, 2010
          • 0 Attachment
            Interesting topic, as usual. I can only comment about one area.

            On Sun, 7 Nov 2010 23:31:43 -0500
            "ddailey" <ddailey@...> wrote:

            > Challenge: come up with "better" symbols for signifying "public
            > domain" or "copyright free."
            >

            [snip]

            > Look inside the two figures and you'll see several questions that
            > pose themselves: is it better to use <use>?
            > does striking all the sodipodi stuff erase some of the artist's
            > brushstrokes?*** are two paths with one rotating the other better
            > than one that has twice as coordinates listed? doesn't it make more
            > sense to let color be inherited from the group rather than
            > individually defined for each path? what about the optical illusion
            > of the letters pd for public domain? Should that be made semantic in
            > our markup?

            I find all of these questions are variations of one theme that I spend
            a fair amount of time thinking about, in SVG and in programming.

            How do we convey "intent" in the code?

            In many cases, the answer to all of the above questions is "it
            depends". One of the big differences for me between SVG and the raster
            graphics I've worked with before is the fact that objects in SVG can
            retain some identity.

            In raster graphics, you can argue that all that matters is the final
            look of the image. Everything is reduced to a grid of pixels in the end.

            With SVG, on the other hand, we have both the visible result of the
            image and the objects from which it was constructed. Which method was
            used in that construction can reveal some of what the artist was
            thinking when constructing the image. For example, all of the following
            represent the same shape (assuming that #tablerect references the right
            kind of element). But, to me they say different things.

            <rect x="10" y="10" width="100" height="50" />
            <polygon points="10,10 110,10 110,60 10,60" />
            <path d="M10,10l110,10 110,60 10,60z" />
            <use xlink:href="#tablerect" x="10" y="10" />

            The <rect> is a specific shape. If it had an id or class attributes, it
            might tell me more about the intent of this rectangle.

            The <polygon> is a more general construct. I have to pay more attention
            to be sure that it is actually a rectangle. The "rectangle-ness" of the
            object appears less important to the artist.

            The <path> is a really generic element. This kind of implies that the
            artist was less concerned about the "shape" of the object and more
            concerned about the look of the output.

            The <use> element suggests that we are using an instance of a more
            generic object. The id of the referenced element gives us a clue to the
            author's intent.

            To circle back around to some of David's questions, I would ask a
            meta-question. What is the intent of the image: the look or the semantic
            content? If the intent is to generate a particular look, then any
            mechanism that results in the correct look is acceptable.

            If semantics matter, then the questions take on a new meaning.

            The <use> element is appropriate if the references are in some sense
            "identical objects" that we are using in multiple places.

            Using a path and a rotated reference to that path, suggests that they
            are semantically similar or the same. Duplicating the points suggests
            that they are only coincidentally the same (maybe they will change at
            some point).

            Inheriting color from a group suggests that all of the child elements
            involved are part of a set. The color is a representation of this
            relationship.

            In the above text, I say that particular constructions "suggest" rather
            than "declare" particular semantics. I do this because there are
            exceptions to every one of the examples. But, these suggestions are
            part of the (semantic) richness that draws me to SVG as a format.

            Apologies for the long-winded response. I really thought it was going
            to be shorter when I began.<shrug/>

            G. Wade
            --
            Machines take me by surprise with great frequency. -- Alan Turing
          Your message has been successfully submitted and would be delivered to recipients shortly.