W3C home > Mailing lists > Public > public-svg-ig@w3.org > April to June 2009

Re: revision strategies [was RE: [Moderator Action] Re: Progress on SVG book]

From: Helder Magalh„es <helder.magalhaes@gmail.com>
Date: Wed, 22 Apr 2009 10:27:23 +0100
Message-ID: <2a1ddf8a0904220227m1ec4d67cgca226aa3862040b4@mail.gmail.com>
To: public-svg-ig@w3.org
(Sorry for the somehow delayed message but it got stuck somewhere in
between my SVG-IG join process. I hope that, now that my messages are
directly accepted, that my participation within the SVG-IG can
increase.)

Hi David et. al.,


> I had not heard of Subversion, and  so read about it a bit on Wikipedia.

It's fairly easy, even for GUI lovers (like myself, naturally
depending on the scope), to get started with SVN. On Windows, there's
the excellent TortoiseSVN [1] which integrates into Windows Explorer
and makes revision control pretty intuitive. Of course there are also
other SVN GUI frontends for other operating systems, but I imagine you
are using Windows (from your statements about MS Word markup
decontamination). The documentation is great so, even if you are not
familiar with SVN (SubVersioN), for example in chapter 2 of the TSVN
(TortoiseSVN) manual there's introductory information about versioning
control concepts. ;-)  If you want to go deep into SVN, then you may
consider reading The Book [2] (it's a great example of a collaborative
effort in the sense we are trying here, by the way). :-)


> lists sorta like this:
>
> [
>    1. /original text/revised text/
>    2. /more text/more new text/
>    .
>    .
>    .
>    n.  /old stuff/new stuff/
> ]
>
> that way I can find the stuff that needs to be changed.

With version control you receive a patch and, while merging (applying
the patch to your local copy), you can have a visual indication on
what lines are to be changed from it. Pretty neat! :-)


> Right now, Shaun Roe has volunteered for an XSLT (/AJAX) section

I might also give a hand there later. I've made some XML+XSL
generating XHTML+SVG lately so I might give a hand or two. :-)  I have
an item in my TODO stack (which keeps increasing no matter how) to
published something about these experiments but I have no idea when
will that be done, unfortunately... :-|


> Please review that list of topics to see if a) there is a topic or two
> you might volunteer for or
> b) if there is a topic missing from the book that really ought to be added to that list.

Yes, I'll definitely take a look at it and compare with the set of
high level suggestions I've been harvesting. :-)


> As I mentioned in a previous email I've also not put any live SVG in
> the document, because of not wanting to crash IE which chokes when more than 100 or so separate SVG's are included.

I'd suggest not doing it even if IE didn't crashes. Having tens or
hundreds of SVG files being rendered will probably choke most
implementations or, at least, put the CPU in a high stress level
(SMIL, filters, etc.) when the user is probably not even looking at
that particular set of images -- this would give a terrible impression
about SVG, specially for newbies/starters. Also, using live examples
may fail to catch a particular state of an SMIL animation, for
example. So in my opinion best would be either:
 * Using raster images and placing a link in them to the SVG file used
to generate them;
 * Use scripting to replace the image tag to an SVG object whenever
activated (not focused):
   * This just occurred to me and I haven't made any experiment yet
but sounds like it would be neat!
   * Raster images could have a (HTML) "title" attribute with
something like "Activate/click to render image" or "Activate/click to
see original file".


> Of course, once the infusion of real SVG into the document were done,
> then one would want to make all the source listings be auto-generated
> through JavaScript from the live SVGdocument, and that starts making
> everything a bit more fragile.

Yeah, that sounds tricky. Another approach would be inserting the
source listings though a server-side script -- something like
(HTML+pseudo-code):
  <pre>
    <code>
	insert-code-snippet(SOURCE_FILENAME, START_LINE_NUMBER, END_LINE_NUMBER);
    </code>
  </pre>
This would allow inserting code snippets instead of whole files, as
apparently is already being done. :-)

In the current approach (static text embedded in the HTML as far as I
was able to see), keeping the source listing and the live examples
coherent can be a source of trouble but not hard to deal with: someone
making changes or creating patches will just need to keep in mind that
the changes need to be done in both places (naturally assuming the
live SVG examples will be also put into version control).


Cheers,
 Helder


[1] http://tortoisesvn.tigris.org/
[2] http://svnbook.red-bean.com/
Received on Wednesday, 22 April 2009 09:28:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:28:24 UTC