Errata

SVG Essentials

Errata for SVG Essentials, Second Edition

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted By Date submitted Date corrected
PDF
Page 9
1st para under "Transforming the Coordinate System"

"is now located at at" --> "is now located at"

Note from the Author or Editor:
Remove duplicate "at" in "is now located at at" (chapter 1)

dml  Dec 01, 2014  May 01, 2015
PDF
Page 42
last paragraph

"neither Apache Batik or Inkscape support them" should be "neither Apache Batik nor Inkscape supports them".

Note from the Author or Editor:
Change "neither Apaceh Batik or Inkscape support them" to "neither Apache Batik nor Inkscape supports them" (since both alternatives are singular, the verb should also be singular).

Daniel Alonso  Dec 04, 2014  May 01, 2015
Printed
Page 59
United States

Page 59 section External Stylesheets advises:

* { ... }

Since this will cause engine to have to look at every single element on page (not just SVG) and is now considered a taboo practice, I'd suggest at minimum to scope the universal selector with something like:

svg * {...}

Note from the Author or Editor:
That particular example (Example 5-3 in printed versions) was really more of a demonstration of what is possible than a recommend practice. That said:

I haven't seen any reliable data on * selectors having significant performance impacts on modern browsers (anything that would support SVG). They are often used to reset browser defaults. If anything, `svg *` would be more of a performance hit because it (a) selects all elements, then (b) checks to see if they have an SVG ancestor. This may be counter-intuitive, but it is how most browsers work!

Using `svg *` could also complicate things because it changes the specificity of the selector. The `*` selector alone has zero specificity, and is over-ridden by any other CSS rule applied to the same element. However `svg *` has equal specificity to `circle` or `path`, so you would have to be careful about the order in which rules are encountered. If the rule was at the top of the stylesheet, and you only had one stylesheet, no problem. Otherwise, things could get confusing.

For the general rule of setting default stroke and fill values, I would actually recommend using `svg { /* default styles */ }` to set defaults to be inherited by every element. This allows you to change the defaults for a section of the graphic by setting new styles on a group element, instead of having to target each element individually.

However, the `*` selector has one very important use case: over-riding presentation attributes created by a WYSIWYG program like Inkscape or Illustrator. For example, `* { fill: inherit; stroke: inherit; }` will force the program to ignore presentation attributes for fill and stroke and use the inherited value unless other CSS rules set different values.

Rob Levin  Nov 27, 2014 
Printed
Page 61
United States

"we emphasize that using style attributes or..."

While I understand the argument that presentational attributes mix the concerns of structure and presentation in the xml/markup, I don't really see the improvement when using specifically inline style attributes. Inline style attributes are, in fact, an attribute of the xml, so aren't they also mixing such concerns? From a practical standpoint, by using inline style attributes I've coupled the style to that element.

To my mind, a style would need to at least be defined in the <defs> and preferably externally/outside of the svg to be fully decoupled.

Note from the Author or Editor:
Those are all good points, Rob. Style attributes do not have the re-usability benefits of stylesheets that are described in the rest of the paragraph, and the text could have been clearer about that distinction.

A better wording would be:

Again, we emphasize that using style attributes or stylesheets should always be your
first choice. Stylesheets, in particular, let you apply...

("in particular" added)

Style attributes nonetheless have other benefits relative to presentation attributes: they clearly indicate which aspects of the element are styles that could be inherited by child elements; and they ensure that the styles you're intentionally applying to a particular element are actually applied, regardless of other CSS. Using presentation attributes can cause unexpected results when a CSS rule takes precedence, as the snippet earlier on p61 emphasizes.

That said, I often use presentation attributes myself in simple examples, because they are easy to write. (I think David is a bit more of a stickler for the separation of presentation versus structure.) And occasionally I use them because I want to be able to over-ride the styles with CSS if need be, although that can make for confusing code if you're not careful.

Rob Levin  Nov 27, 2014  May 01, 2015
PDF
Page 83
Table 6-1

Maybe use singular for coordinate system and plural for coordinates? Now there are singular and plural versions for both terms:

* "user coordinate system" in translate(x, y).
* "all user coordinate systems" in scale(xFactor, yFactor).
* "user coordinate" in both rotates.
* "x/y-coordinates" in skewX/skewY.

Note from the Author or Editor:
Although it doesn't affect technical accuracy, this should be changed for clarity and style. Entries should either refer to "all (x/y-)coordinates" or to "the coordinate system".

The description for scale(xFactor, yFactor) should be changed to
Multiplies all user coordinates by the specified...

The description for rotate(angle) should be changed to
Rotates the user coordinate system by the specified...

The description for rotate(angle, centerX, centerY) should likewise be changed to
Rotates the user coordinate system by...

The other entries should stay as is.

Daniel Alonso  Dec 06, 2014  May 01, 2015
Printed
Page 87
United States

In the first Action it states "Move pen to (40,50)" but the point action is really M 40 60

Note from the Author or Editor:
In this line of asciidoc: | +M 40 60+ |Move pen to (40,50) change 50 to 60.

Rob Levin  Dec 03, 2014  May 01, 2015
PDF
Page 91
last line

Korean flag -> South Korean flag

Note from the Author or Editor:
Change Korean flag -> South Korean flag.

Anonymous  Dec 06, 2014  May 01, 2015
PDF
Page 98
last paragraph

"the right half shows curve" should probably be "the right half shows the curve".

Note from the Author or Editor:
Change text to "the right half shows the curve with the control points" as described in error.

Daniel Alonso  Dec 06, 2014  May 01, 2015
PDF
Page 196
First paragraph

The text description does not match the code:

"The following animation starts at 6 seconds and should last for 12 seconds, but is halted 9 seconds after the document loads (4 seconds after the animation starts)."

But:

<animate attributeName="width" attributeType="XML"
begin="5s" dur="10s" end="9s"
from="100" to="200" fill="freeze"/>

Note from the Author or Editor:
Thanks for the correction. We'd edited this example to make the calculations easier, but somehow while merging the text the old values crept back in! The paragraph text needs to be changed to match the snippet.

The end of the paragraph and the code snippet (at the very end of the "Synchronizing Animation" section in Chapter 12) should read:

... The following animation starts at 5 seconds and should last for 10 seconds, but is halted 9 seconds after the document loads (4 seconds after the animation starts). The animation is stopped 40% of the way through, so the width will freeze at a value of 140 (40% of the distance from 100 to 200):

<animate attributeName="width" attributeType="XML"
begin="5s" dur="10s" end="9s"
from="100" to="200" fill="freeze"/>

Daniel Alonso  Dec 09, 2014  May 01, 2015
PDF
Page 215
Footnote number 4.

"the combined text and markup all descendents of an element" should probably be "the combined text and markup of all descendants of an element" (added "of", changed "descendents" for "descendants").

Daniel Alonso  Jan 13, 2015  May 01, 2015
PDF
Page 220
bullet #1

"maniuplated" --> "manipulated"

Note from the Author or Editor:
Chapter 13, change "maniuplated" to "manipulated" as per erratum.

dml  Dec 14, 2014  May 01, 2015
PDF
Page 224
Bullet #2

"is begin dragged" should be "is being dragged".

Daniel Alonso  Jan 14, 2015  May 01, 2015