Type and Back Again: Stealing SVG Designs

Forums » Article Discussions

Discuss the articles posted at DevOpera

Note: You need to login to post in the forums. if you don't have an account you first need to sign up.

By jax Thursday, 18. January 2007, 10:59:23

Without an ounce of skill or originality, this article shows how to get what you want without working for it. Whether that is cool typographical illustration effects or custom-made accessible headlines while you wait (and wait and wait), handling type in SVG shows a lot of promise.

( Read the article )

By jeff_schiller Thursday, 18. January 2007, 12:56:59

Cool. Many of your examples are broken in Firefox though because you tried XML version="1.1" (should be 1.0).

By jeff_schiller Thursday, 18. January 2007, 13:07:53

Another suggestion: Instead of all the different ways to call resetTime() on the digital clock, why not just make it a timer:

window.setInterval(resetTime, 750); // 750ms updates to ensure that no seconds are missed

By jax Thursday, 18. January 2007, 13:49:14

That is the disadvantage of stealing code, you get what you steal. In this case the culprit was Charles, he probably didn't notice since declarative animations don't work in Firefox anyway. That said there is no reason whatsoever to use XML 1.1, none. I will fix that in my own examples, and nag Charles to do the same with his.

What I actually wanted to do was to freeze time, all those whirring clocks reminding you how time flies while you are reading Dev Opera articles are distracting (that is, the examples would use animation, but the article would use stills). Having the analog clocks show the current time and not animate seems to be a little more code than animating the clocks in the first place (enough that the illustration and example wouldn't be that close), so I postponed it.

That didn't prevent me from overdoing it with the digital clock. Initially on clock load, I added hover to give some interactivity, and then focus for a device-independent approach. That was wrong. It would be better to show a static now, that is then, in the article and a running clock in the example. That clock should run on its own, so your setInterval tip should be just right there.

By MacDev_ed Tuesday, 23. January 2007, 08:05:44

Originally posted by jax:

Unfortunately the attributes that can be styled are very limited, at least in the current version of CSS. I would have loved to be able to style the transform attribute, that was the one needing the most fiddling.

...current version of SVG. I find that thing about CSS styling of the transform attribute a bit weird, I don't see that as something you generally style. Transforms don't really follow the CSS cascading rules, transforms are multiplied together, they're not inherited. And what would happen in an example like this:

<svg>
  <style>
    g { transform: rotate(45); }
  </style>
  <g transform="translate(10,10)">
    <g transform="skewX(10)">
    </g>
  </g>
</svg>

Should the style transform be replaced on the <g> element(s), or should they be multiplied together, and in that case in which order, pre- or post-multiplication?

The border between what's semantics and what's presentation is a bit fuzzy for svg since it's a graphics format.

Originally posted by jax:

In principle this meant that the rotation no longer was necessary, but in practice it was more convenient to move (translate) the number towards the rim, rotate it to the proper position, and then rotate the number back to horizontal. For instance "4" was coded <text transform="rotate(120) translate(0,-80) rotate(-120)">4</text>.

You are aware of the syntax for rotating around a point, no? You can use this:

transform="rotate(deg x y)"

(x,y) is the centerpoint of the rotation and deg is the rotation in degrees. I'm not sure if that was what you were looking for, but it is very useful.

The rotate around a centerpoint equals three commands in one: translate-to-origin, rotate, translate-back-to-where-you-were.

By jax Tuesday, 23. January 2007, 09:15:49

Originally posted by MacDev_ed:

...current version of SVG. I find that thing about CSS styling of the transform attribute a bit weird, I don't see that as something you generally style. Transforms don't really follow the CSS cascading rules, transforms are multiplied together, they're not inherited. And what would happen in an example like this:
<svg>
  <style>
    g { transform: rotate(45); }
  </style>
  <g transform="translate(10,10)">
    <g transform="skewX(10)">
    </g>
  </g>
</svg>
Should the style transform be replaced on the <g> element(s), or should they be multiplied together, and in that case in which order, pre- or post-multiplication?

The border between what's semantics and what's presentation is a bit fuzzy for svg since it's a graphics format.

By the CSS rules that would have to be equivalent to

<svg>
  <g transform="rotate(45)">
    <g transform="rotate(45)">
    </g>
  </g>
</svg>

I would expect the selector to be a little more specific than g in real life (e.g. I needed it for the digits, which had a specific class), but there is another problem, which is probably the showstopper. A 'transform' CSS property could be considered a shorthand for a 'transform-rotate', 'transform-translate' and so on. 'transform-rotate' would only override rotate transformations, but no other transformations. But the order matters, rotate(45) translate(10,10) is different from translate(10,10) rotate(45), CSS couldn't handle that.

In my view linear transformations are presentational/projections in nature. A circle viewed from a different angle would appear as an ellipsis, but it would still be a circle in nature.

There are many other CSS properties missing in action. For the digital clock for instance 'border-*' would be very useful, even more so for more fluid text. I miss the flexibility of HTML/CSS layouts in SVG.

Originally posted by MacDev_ed:

You are aware of the syntax for rotating around a point, no? You can use this:
transform="rotate(deg x y)"
(x,y) is the centerpoint of the rotation and deg is the rotation in degrees. I'm not sure if that was what you were looking for, but it is very useful.

Immediately I thought that would be a better solution, but then I realised it is not the same. What the clock uses is really a translation, not a rotation. What I would have needed would be something like translate(length degree). Of course I could have used trigonometry to set the precise x,y coordinates, but it would be less readable and all the coordinates would have to be re-calculated if using a different sized disc. By rotate(deg) translate(radius) rotate(-deg) it would be sufficient to change the radius.

Post edited Tuesday, 23. January 2007, 09:24:07

By MacDev_ed Tuesday, 23. January 2007, 10:27:24

Originally posted by jax:

There are many other CSS properties missing in action. For the digital clock for instance 'border-*' would be very useful, even more so for more fluid text. I miss the flexibility of HTML/CSS layouts in SVG.

Yes, borders would be nice to have. A problem is that svg shapes can have many different boundingboxes, for example all of the following could potentially affect the boundingbox of an element:
- filter effects
- stroking (sharp corners may be outside of the defined path for example)
- markers

Unfortunately SVG 1.1 doesn't have a general bounding box definition like in SVG Tiny 1.2. However the getBBox() SVG DOM method says:

Returns the tight bounding box in current user space (i.e., after application of the transform attribute, if any) on the geometry of all contained graphics elements, exclusive of stroke-width and filter effects).

And there's also a definition for when 'objectBoundingBox' is used here.

By jeff_schiller Wednesday, 24. January 2007, 18:46:28

Originally posted by jax:

Immediately I thought that would be a better solution, but then I realised it is not the same. What the clock uses is really a translation, not a rotation.

Heheh, I was going to offer the same suggestion about the rotate(deg cx cy) thing, but realized the same thing that you did - you want a translation, not a rotation, in this instance...

By stelt Wednesday, 15. August 2007, 15:49:15

Originally posted by jax:

That is the disadvantage of stealing code, you get what you steal.

I found there are some errors(invalidities even, maybe a dev.opera wide test?) in the darts article you stole from (see comments there).

Maybe http://devfiles.myopera.com/articles/75/darts.svg could just be a 'redirect' to http://devfiles.myopera.com/articles/24/darts.svg to save double work in applying fixes.

By chrismills Monday, 17. March 2008, 17:46:10

I've made sure the code source for the darts game is the same as the one for the original article; I've also fixed the initial errors on that article.

By stelt Tuesday, 18. March 2008, 13:09:17

Originally posted by chrismills:

I've ... fixed ...

Great. Now please also change the XML version of the other SVG from 1.1 tot 1.0 as mentioned in a earlier comment.

Moderators: jax | malware | mcx | operadev

Login

Forums » Article Discussions

Type and Back Again: Stealing SVG Designs