Category: SVG

Flowed text in SVG: One step forward, one step back.

Background

The ability to flow text into an arbitrary shape or even a simple box has been a feature long in demand in SVG. Thus it is on the list of required features for SVG 2.[1] The SVG 1.2 draft specification[2] included the ablility to flow text (and graphics!) into arbitrary shapes. Unfortunately, SVG 1.2 never got off the ground and only Inkscape and Batik seem to have implemented parts of flowed text. Inkscape’s implementation supports text flowed into arbitrary paths. If the path has a hole, text will wrap around it. Inkscape also supports text flowed into multiple shapes. Inkscape (nor Batik) implemented flowing images or some of the fancier elements that control line and paragraph breaks.
Text flowed inside a Chinese coin. Text wraps around hole.

Text flowed into a Chinese Coin. Done in Inkscape.

Text flowed into three circles.

Text flowed into three circles. Done in Inkscape.

Flowed text in SVG 1.2 does have some problems. First, it is complicated. There are eleven separate elements (Inkscape supports five, Batik seven). Second, there is some missing functionality. For example, there is no way to set a margin (as seen in the above examples). Third, the reality is that none of the browsers will implement SVG 1.2 flowed text even if it were part of SVG 2. They want a solution that works for both HTML and SVG.

Enter CSS and a step forward

Almost nine years after the SVG 1.2 draft came out, interest in flowing text into and around shapes has made it to HTML. The CSS working group has produced a draft specification[3] for text flowing and wrapping. The specification is fairly simple and straight forward. One specifies shapes to flow text into (‘shape-inside’) and shapes to flow text around (‘shape-ouside’). Then one specifies how the text should wrap (e.g. only wrap on the left side of a ‘shape-outside’ shape) and how close the text should come to the shapes (‘wrap-margin’ for outside shapes and ‘wrap-padding’ for inside shapes). There are a set of canned shapes defined (rectangle, circle, ellipse, or polygon) or one can link to an SVG shape or path. One can also use the alpha value of an image to generate a shape. With this, 95% of the work for getting text wrapping in SVG is done. A few small changes are needed to adapt to the spec to SVG. For example, in HTML, one always has a box to provide a ‘wrapping-context’. In SVG you must supply the wrapping context using the ‘shape-outside’ property. In SVG, you might want to limit shapes to actual SVG shapes or paths (rather than using the canned shapes). SVG would need to add the value ‘justified’ to ‘text-align’ and add the property ‘line-height’ (already defined in CSS). The ‘x’ and ‘y’ attributes on <text> and <tspan> would be ignored (but left for use as a fallback). The trickiest part is figuring out how SVG would specify linebreaks and paragraphs since SVG does not have the <br/> and <p></p> elements. Here is a simple example of how CSS Exclusions might work in SVG: 
<def>
  <circle id="mycircle" cx="150" cy="150" r="125"/>
</def>
<text x="100" y="100" font-size="18px" text-align="justified"
       line-height="125%" wrap-margin="25"
       shape-inside="url(#myshape)">This is a mockup of...</text>
Text flowed using CSS Exclusions.

Text flowed into circle using CSS Exclusions.

And one step back

I just knocked off adding hatches to SVG 2 this week and was ready to take a closer look at text wrapping so I could present a plan for its specification at the upcoming SVG Working Group meeting. I looked at the lastest CSS Exclusions public working draft and started formulating a plan. Things looked easy. But then, a few days ago, it was announced on the CSS Working Group mailing list that the CSS Exclusions draft had been split into an Exclusions specification[4] and a Shapes specifications[5]. This seemed OK at first but in looking at the current editor’s drafts (a step before publishing a public working draft) I noticed two problems. In the Exclusions editors draft ‘shape-inside’ had been removed, to be postponed to a future specification; and in the Shapes draft, it was no longer possible to reference SVG shapes and paths. These are the VERY two things that are most required for having flowed text in SVG are gone. Hopefully we can get these back.
  1. SVG 2 Requirement.
  2. SVG 1.2 Working Draft (27 October 2004.
  3. CSS Exclusions Working Draft (3 May 2013).
  4. CSS Exclusions Editor’s draft (22 May 2013).
  5. CSS Shapes Editor’s draft (20 May 2013).

Inkscape and Font Faces, a drama featuring SVG, Pango, and others.

I have just disabled “faux” or “synthesized” font faces in Inkscape trunk. The post explains why.

Background

Fonts often come in groups of related faces that all belong to the same family. For example, the group for the family ‘Nimbus Roman No9 L’ consists of the faces Regular, Regular Italic, Medium, and Medium Italic.[1]
Four lines of text showing the four different faces.

The four faces of ‘Nimbus Roman No9 L’. From top to bottom: Regular, Regular Italic, Medium, and Medium Italic.

Font designers take a lot of time to create the different faces. This can be illustrated by comparing individual characters between the faces.
Comparison of the letters 'a', 'f', 'l', 'v', 'z', and 'Q'.

Comparison between the Regular and Regular Italic faces of ‘Nimbus Roman No9 L’. Note how the font designer customized the different characters.

Comparison of the letters 'O', 'X'.

Comparison between the Regular and Medium faces of ‘Nimbus Roman No9 L’. Note that the Medium glyphs (black) are not just thickened versions of the Regular glyphs (red outline). In fact, the top and bottom of the bolder ‘O’ are actually thinner.

Font Faces and SVG

Since Inkscape uses SVG as its native file format, we need to take a quick look at how SVG describes font faces. SVG 1.1 (which for fonts is basically the same as CSS 2.1 ) defines the following font-selection properties:
  • font-family.
  • font-style: normal, italic, oblique.
  • font-variant: normal, small-caps.
  • font-weight: normal, bold, bolder, lighter, 100, 200, 300, 400, 500, 600, 700, 800, 900.
  • font-stretch: normal, wider, narrower, ultra-condensed, extra-condensed, condensed, semi-condensed, semi-expanded, expanded, extra-expanded, ultra-expanded.
In the past, most software offered only a choice of four faces: Regular, Italic, Bold, and Bold-Italic. This was a limitation set by Microsoft Windows as it only supported four faces inside one font file.[2] The creation of faux faces ensures that each of these four faces are present even if only one true face is available. But font foundries typically offer more than four faces in a family. For example, ‘Helvetica’ from Linotype has 34 faces, ‘DejaVu Sans’ has nine. SVG and CSS, recognizing this, allow access to more faces. But still there are limitations. For example, SVG and CSS only supports nine weight variants, the numbers 100, 200, …, 900 but some faces have a weight of 1000 (as supported by FontLab).[3] Since Inkscape relies on SVG, it cannot directly support a weight of 1000. Also, SVG and CSS have no way to distinguish between two faces in the same font-family that differ in away not described by the above properties (e.g. Pochoir Regular and Pochoir Sprayed). One should note that the Bold and Italic buttons in the Inkscape text toolbar have recently been replaced by a drop-down list to accommodate more face options. There is a new CSS3 Font module being written. The main change from CSS2 is that the property font-variant is being changed from a font-selection property to a font-feature property with expanded functionality. It will allow one to select between various glyphs in a single font face. Small caps will no longer be found in a separate face but be embedded into a “normal” face. As of now, CSS3 Fonts does not add the font weight 1000. (If you think that this is important, tell them!)

Font Faces and Pango/Cairo/FreeType/Fontconfig

Inkscape interfaces to the fonts on a system through Pango. There is surprisingly little documentation on how this works. If a font does not have an Italic/Oblique or a Bold face, Pango will still indicate that it does. At some point along the line synthesized faces are created. A little bit of sleuthing finds that Pango can create an Oblique face from a Regular face in the Pango/Cairo interface code but does not appear to be able to embolden a face. The Oblique face is made by skewing the “Regular” glyphs by 25%.[4] The style name is set to “Oblique”. This doesn’t appear to be what is happening with Inkscape. Hunting further, one finds that Cairo has functions that interact with FreeType to request synthesized fonts. The enumeration “cairo_ft_synthesize_t” can have the values (from the documentation):
  • CAIRO_FT_SYNTHESIZE_BOLD: Embolden the glyphs (redraw with a pixel offset).
  • CAIRO_FT_SYNTHESIZE_OBLIQUE: Slant the glyph outline by 12 degrees to the right.
FreeType has functions that create faux faces.[5] However, a close examination shows that the faux Italic faces in Inkscape are not skewed by 12 degrees. On Linux, font configuring is handled by Fontconfig. On my Fedora box, all the configuration options for synthesized faces are located in the file /etc/fonts/conf.d/90-synthetic.conf. This file dictates that fonts without a slanted face (Italic or Oblique) should have a faux face created with a skew of 20%. This is exactly what I saw when I examined a faux Italic face in Inkscape. Taking a step back, one finds that Pango has routines that directly interact with Fontconfig. It is one of the supported back ends (the others being Uniscribe on MS Windows and CoreText on MacOS X). In the function pango_fc_list_faces() one finds the source of the names for the faux faces: “Regular”, “Bold”, “Italic”, “Bold Italic”. So we have found the source of the faux faces in Inkscape (at least on Linux). On Linux, you can disable faux font faces by removing the 90-synthetic.conf configuration file (however, this does not disable faux faces in Chrome). This is probably not what you want to do. For programs that consume content, such such as Web browers, the Italic and Bold faux faces would probably be missed. The different faces are often used to highlight important information. In addition, browsers use font fallbacks to replace missing glyphs. A faux face might be a better fallback than a distantly related font face. As the glyphs are typically rendered small, you probably won’t notice much the inferior design. In the future, when a web designer wants more control over the use of faux faces, CSS3 Fonts will have a property to disable font synthesization. It doesn’t appear that any browser supports this yet.

Font Faces and Inkscape

Inkscape has happily provided the user with synthesized font faces without warning. These faces are at best imitations of the properly designed faces. Here is an example of the font face “Impact Condensed” as displayed by Chrome:
Two lines of text using Impact.

The top line is the normal (condensed) face while the bottom line is a faux bold face. Notice how the space between the dot and the base of the ‘i’ has disappeared, there is no longer a gap in the ‘e’, and how some letters overlap others.

The Firefox version is even worse! Who in their right mind would want to use a faux bold Impact face? For programs that create content, like Inkscape, the usefulness of faux faces is questionable. Fortunately, Inkscape did not actually render faux bold faces on the canvas (although they did appear in the style lists and the preview section of the Text and Font dialog). The faux Italic/Oblique faces were rendered on the Inkscape canvas. This doesn’t seem so bad at first since the rendering quality of a faux Italic/Oblique face is not nearly as bad as a faux Bold face. However, it too was not so desirable:
  • The artist was not made aware that they were using a poor imitation of a real Italic font.
  • There was a good chance the face won’t be rendered correctly downstream. At least on Linux, PDF and Postscript output will show the regular face rather than the faux Italic face (but quite perversely, will show the faux Bold face).
  • Different operating systems may create the faux fonts in different ways. On Linux, the faux faces were created by the Fontconfig backend.
  • Only one each of faux Italic, Bold, and Bold-Italic faces were created per font-family even if more than one “regular” face exists (for example, a face with four weights would have just one faux Italic face created).
One could have tracked down and fixed the faux face rendering problems for all three Pango backends, and one could have added a warning in the Inkscape Text toolbar and Text and Font dialog that one is using a faux face, but it didn’t seem like it was worth the amount of effort it would have taken. The simplest solution (and the best in my view and the majority of those who have commented on this in the Inkscape Developer’s mailing list) was to disable faux font faces in Inkscape. It was a one line fix.

Work-arounds

How to work around not having the faux font faces if you find you really need them?
  • The easiest solution is to choose another font-family that does have the faces you need. There are an incredible number of font-families out there.
  • One is still able to type “Italic” or “Bold” in the Text toolbar Style entry box. (The rendering problems remain unchanged but the styling will be saved in the SVG.)
  • A faux Italic face can be simulated by skewing a text object. The only problem with this method is that multiline text won’t be lined up properly. The Transform dialog can be used to set a precise amount of skewing.
  • A faux Bold face can be simulated by adding a stroke to the text. The text may then need to be shrunk and shifted slightly to account for the added width and height with the stroke, and the distance between the glyphs may need to be adjusted; there is an entry in the Text toolbar that allows one to adjust glyph spacing.

Footnotes

Spec Writing Madness

Hidden image for G+. In the last SVG Working Group teleconference we discussed some aspects of CSS clipping. This discussion highlighted the sometimes unintended consequences of what seems to be a series of simple rational choices. First, some background. Chunks of the SVG specification are being pulled out of the spec in order that they can be shared between SVG and CSS. This is overall a good thing. Web designers gains new features that are consistent across both SVG and HTML; things like filter effects, transforms, animation, etc. Web browser vendors are more motivated to perfect their implementation of old SVG features and implement new ones if they are also used in HTML. But this modularization process has its problems. The CSS forces are stronger than the SVG forces and their interests sometimes overwhelm those who see SVG as more of a pure drawing specification. CSS clipping is part of the CSS Masking spec. With this spec, it is possible to define masks and clip paths in terms of the bounding box of the object that is being masked or clipped. Three ways to determine the bounding box are specified:
  • ‘border-box’
  • ‘padding-box’
  • ‘content-box’
Note that these terms are rooted in the CSS box model.
Image from the CSS2 specification showing a series of boxes within each other.

The CSS2 box model as shown in the CSS2 specification.

Equivalent SVG based terms might be:
  • ‘painted-box’ (includes fill, stroke, markers)
  • ‘stroke-box’ (includes fill, stroke)
  • ‘geometric-box’ (includes fill)
Triangle with fill but no stroke.

The dashed line is the bounding box for ‘geometric-box’.

Triangle with fill and stroke.

The dashed line is the bounding box for ‘stroke-box’.

Triangle with fill, stroke, and markers.

The dashed line is the bounding box for ‘painted-box’.

The default value is ‘border-box’. This may make perfect sense in HTML space. For consistency, the default value should be the same for masking and for clipping and it should be the same for HTML and SVG. During our meeting, we discussed what would make the most sense for SVG. Most people (including me) would find it very strange if the clipping of an object depended on what we would consider styling, thus ‘geometric-box’ would make the most sense. It might be possible to have the default style sheet set to that value for SVG but it is not clear this is what the SVG WG will choose to do. If they don’t, then by default, a clip path will depend on styling. Which can lead to some strange effects. Suppose you have a triangle with a stroke. The ‘stroke-box’ and ‘painted-box’ depend on the thickness of that stroke, the line-join type, and in the case of miter join, the miter-join limit. OK, we can do the calculation to find the resulting bounding box, its just a few CPU cycles. Next lets add a dash pattern to the stroke. I was surprised to learn, that some people think that the dash pattern should effect the ‘stroke-box’ and that many graphics libraries are programmed that way. The box changes depending on if a dash hits a corner or not.
Triangle with fill, and dashed stroke.

The dashed line is the bounding box for ‘stroke-box’.

Now let’s go way out, suppose we animate the dash pattern (something you can so in SVG). As the dashes march around the triangle the bounding box will change. And since the clip path depends on the bounding box, it too will change… Probably not something that you would have expected or actually wanted.
A triangle showing an animated dash pattern marching around the triangle.

Note how the bounding box changes as the dash pattern moves.

Color Interpolation in SVG

I recently added support for the value linearRGB on SVG property color-interpolation-filters to Inkscape. Here is a short post on what that means: SVG 1.1 specifies two possible values for the color space used while compositing or while interpolating between two color values (as in a gradient or animation). The values are linearRGB and sRGB. The first, linearRGB, as the name suggests, describes a color space where the brightness (intensity) of a color is proportional to the numerical value that describes that color. This seems at first like an obvious choice. If shining one lamp on a surface produces an intensity of 100 lux, shining two identical lamps produces an intensity of 200 lux. But it turns out that this doesn’t match human vision very well. The eye’s sensors (rods and cones) and the circuitry (neurons) that process the signals are not linear. Doubling the intensity does not appear to the eye as doubling the brightness. When you have only eight bits (or 256 levels) per color channel to store brightness levels you want to maximize the usefulness of those bits. As the eye can distinguish between closer values of brightness at lower values than higher it is better to use a non-linear color space for recording brightness. One way of doing this is to use gamma correction. This can be described by the function:
Vout = A Vinɣ
where Vout is the intensity to be displayed, A is a constant, Vin is the input level. Typical values of ɣ are around 2.2 to 2.4 for TV and computer monitor signals. A secondary motivation for using a ɣ around those values was that it is close to the typical brightness response to the applied voltage of the electron gun in CRTs, making manufacturing of CRTs easier. (With LCD screens, which have very non-linear response functions, the gamma correction is handled by circuitry.) The sRGB color space uses an effective ɣ of about 2.2. The exact formula is a bit more complicated than that shown above but it is close enough for the purposes here. Below is a comparison between linearRGB and sRGB. The linearRGB example is encoded with an inverse gamma correction so when your display applies the sRGB conversion the result is a linear brightness. Key points: an sRGB value of 0.5 (on a scale of 0 to 1) corresponds to a brightness of about 20% of that for a value of 1 and a brightness of 50% corresponds to an sRGB value of about 0.73.
Two lines with blocks of different brightness.

The top row consists of blocks with linear steps in brightness. The bottom row consists of blocks with even steps in sRGB color space. Note the rather large perceived step in brightness in the top row between the two darkest blocks and the rather small difference in the two lightest. How different the blocks look will depend on how your screen is calibrated (or not calibrated).

When interpolating between colors, which color space should one use? Consider a linear gradient between red and blue. If one interpolates between the two colors using sRGB, the middle of the gradient appears dark. This is easy to understand. Consider one color component (red or blue) where the maximum value is 1. At the middle, the interpolated value is half the maximum value (0.5). If the interpolation is done in sRGB, this corresponds to a brightness of about 20% of the maximum value, not the 50% one would first expect. To get the expected value, one needs to interpolate in linearRGB space and then encode that value in sRGB color space (0.73 as discussed above). Clearly, using linearRGB while interpolating gives a better result.
Two gradients using different color spaces for interpolation.

The top gradient was created using interpolation in the sRGB color space while the bottom was created using linearRGB.

So why not use linearRGB in SVG drawings? The primary one is that browsers don’t support it! In addition most (all?) graphics libraries don’t support it. It is not part of the PostScript and PDF standards nor the Cairo rendering library that Inkscape (as of version 0.49) uses for rendering. The Batik based SVG viewer Squiggle does implement linearRGB interpolation for gradients but not for compositing. Here is a simple test:
Three gradients using different values of 'color-interpolation'.

SVG test file. The top gradient uses the SVG default interpolation (sRGB), the middle gradient uses sRGB interpolation, and the bottom uses linearRGB. If the bottom gradient looks like the other two then your browser doesn’t implement linearRGB interpolation.

Using linearRGB would also slow down rendering as objects would have to be converted from sRGB colorspace to linearRGB for compositing and the back to sRGB for display. And, for most purposed, using sRGB for compositing works well enough. There is one place where browers do support linearRGB and that is in filters. In fact, the default color space for SVG 1.1 filters is linearRGB. I don’t know for sure why the writers of the original SVG specification chose to make that the default color space for filters while using sRGB for everything else. Perhaps it was viewed that filters would be used most frequently to build up complex effects that simulate point light sources shining on protrusions which would naturally call for using a linear color space. The introductory example filter in the SVG 1.1 specification shows just such an effect. Up until now, Inkscape rendered all filters using the sRGB color space. This lead to rendering differences between browers and Inkscape for non-Inkscape created filters (Inkscape for some time now has set color-interpolation-filters to sRGB when using an Inkscape stock filter effect or when creating a filter effect inside Inkscape). Should you expect Inkscape to support linearRGB outside of filters? Probably not. Filters are always rendered as bitmaps and it was fairly easy to add code to track the color space of the intermediate bitmap surfaces used while building up a filter effect and make the necessary conversions. Outside of filters, Inkscape uses direct calls to the Cairo rendering library and Cairo knows nothing about color spaces so it would be quite difficult to implement mixed color spaces (using sRGB some places and linearRGB other places). And as browers don’t currently support linearRGB, it would not be all that useful.
A variety of squares with tests for sRGB and linearRGB interpolation in filters.

SVG test file. For each tested filter primitive there are two sets of squares; ‘color-interpolation-filters’ is set to sRGB on the left and linearRGB on the right. A test passes if only one large square is seen. It fails if the inner square is a different color than the outer. Several of the tests rely on feFlood be rendered correctly. There is some discussion as to how the color in feFlood (as well as the lighting primitives) should be rendered so not all the tests may be valid. There may also be artifacts if the image isn’t viewed at a 100% scale and even at 100% the two vertical lines in the feConvolveMatrix filter are expected.

SVG Path Morphing

As usual, if you are reading this in a blog aggregator and the images don’t display correctly, try viewing on my blog website. Aggregators don’t play well with SVG.
Four different Batman logos.
I have a project where I want to morph some paths. To experiment a bit, I looked for something simple to start with. I came across a poster of Batman logos over time. What a perfect thing to morph, I thought. I then looked a little bit further and saw that the designer actually got their idea from someone who had already produced a video of morphing Batman logos. Well, I still though it would be interesting to do in SVG so I continued. I wanted to use SMIL animation as this is simpler than JavaScript and will work where JavaScript is disabled due to security concerns. SMIL works in all the major browsers except IE. Here is the result:
Morphing Batman logos.

A variety of Batman logos, animated with SMIL.

I used Inkscape to trace the paths and then extracted the path data using the XML Editor. I pasted the data into a hand-written SVG file. Inkscape’s SVG is rather verbose and adding animation inside Inkscape is not so simple. Here is a very simple animation of a short path. Note how the <animate> element is inserted in between opening and closing <path> element tags. The d attribute is animated with the values attribute containing the required path data. 
  <path d="M 100,50 100,250 300,250">
    <animate dur="5s" repeatCount="indefinite"
             attributeName="d"
	     values="M 100,50 300, 50 300,250;
		     M 100,50 100,250 300,250;
		     M 100,50 300, 50 300,250;"/>
  </path>
Here are a few notes about the process:
  • The paths must have the exact same structure. I took a look at the various logos and decided on a set that shared the same topological features so they would use the same number of Bezier curves. I choose to use all Cubic Bezier curves since they can simulate straight lines too.
  • In the Inkscape Preferences dialog under the SVG output tab, I disabled the use of relative paths. Inkscape can choose to use relative path data if it results in a shorter path string. This can result in inconsistent path structure. At the same time I reduced the numeric precision to three decimal places, I wasn’t so interested in getting the logos perfectly exact.
  • For each new logo, I copied the path from the previous logo to insure the same structure. I then deleted the right half of the path, adjusting only the left half to match the new logo. To get the right half, I duplicated the path and flipped the copy horizontally and moved it into place. I then combined the two halves into one path, merging the end nodes. I tried to use the same procedure each time to keep the path syntax the same. Occasionally, I ended up with a path that required flipping horizontally to get the starting point at the right place.
  • The animation part is rather straight forward. A few things to know: One has to repeat the first path at the end. I repeated each path twice so there would be a bit of a pause between morphs. I put each path on its own line so I could spot errors quicker. The most common error I made was forgetting the semicolon at the end of each path. Chrome has a bug where space after the last quote mark kills the animation. I am sure a person with more SMIL fu could come up with a better way of handling the morphing and the text fades but this SVG file does what I set out to do.

SVG Working Group Meeting Report – Rigi Kaltbad

The SVG Working Group had a three day Face-to-Face meeting in Rigi Kaltbad (Switzerland) just after The Graphical Web (formerly SVG Open) conference. Thanks to the conference organizer, Andreas Neumann, I was able to attend the meeting in person. While a lot of the work focused on the nitty-gritty details of more interest to browser vendors and developers, there were still a number of things of interest to artists and designers:
  • New path commands will be added to make the drawing of arcs easier: “arc”, “ellipse”, and two forms of “arcTo”. These will match the path implementation found in canvas.
    Two lines connected by a curve of radius r.

    An example of arcTo. In this example, p0 is the previous path point. p1, p2, and the radius r are arguments of the arcTo command.

  • If arcTo isn’t enough goodness for you, making rounded corners for shapes, polygons, and polylines will be child’s play with a new rounded corner option where one supplies the radius for the rounded corners. It is still to be decided if generic paths will have this option.
    Two paths with rounded corners of radius r.

    An example of rounded corners for two polyline elements.

  • Speaking of polygons, SVG2 will have a star/polygon element for convenience. It will support most if not all the options available with the Inkscape Star Tool.
  • A new extrapolated line join style was tentatively approved at the last SVG Face-To-Face meeting (see my previous blog entry). It is now approved to be added to the specification.
  • Hatches have been approved. The exact syntax has yet to be worked out. It will be something like: 
    <hatch id="complex" angle="90"
        hatchUnits="userSpaceOnUse"
        pitch="10" x="0" y="0">
    <hatchPath offset="0" stroke-width="1"/>
    <hatchPath offset="5" stroke-width="1"
               stroke-dasharray="5 2 1 2"/>
</hatch>

    <hatch id="complex" angle="90"
        hatchUnits="userSpaceOnUse"
        pitch="6" x="0" y="0">
    <hatchPath offset="0" stroke-width="1"
       d="m 1,0 c 0,4 8,6 8,10 8,14 0,16 0,20"/>
</hatch>
    Two examples of hatchings.

    Examples of the hatches given above.

    Cross hatching will be handled by allowing one to combine two hatchings together.
  • Marker fill automatically matching stroke color got a step closer to reality with “context-fill”, “context-stroke”, and “context-fill-opacity” being approved for SVG2. A new property, “context-value” was also endorsed. This value allows one to pass in stroke style properties such as “dash-array”. 
    <marker id="yeah" fill="context-stroke" .../>
  • The Working Group endorsed auto-smoothing of mesh gradients (without smoothing, gradients are subject to Mach banding). Auto-smoothing is done both by Adobe and CorelDRAW. However, when they export the meshes, for example to PDF, they export an 8 x 8 array of patches for each native patch since PDF (and PostScript) don’t have smoothing built in. The Working Group has asked the Adobe representative if Adobe would be willing to make public their smoothing algorithm. This would allow, for example, Illustrator to directly write smoothed meshes to SVG.
  • Connectors, useful for flow charts, organizational charts, etc. will be standardized in a separate module. A very simple routing (basically a straight line) will be provided. Content creation programs (e.g. Visio, Dia, Inkscape) can override the default routing and supply a more complicated connecting path. See the Editor’s Draft for details.
  • As a result of a comment at SVG Open, the Working Group has approved Internationalization of <title> and <desc> elements. One will be able to supply multiple elements with different “lang” attributes. An SVG renderer will select which element to use via these attributes.
  • The Working Group is investigating a new type of noise for filters that would be easier for hardware acceleration.
  • Mozilla demonstrated the use of SVG inside of Open Type Fonts. Firefox nightly has experimental support for Mozilla’s SVG OTF proposal. Adobe also has a proposal on the table with a different syntax. The two proposals will need to be merged.
    The letter A and a star rendered from a test Open Type Font using SVG glyphs.

    Here are two glyphs with different fill colors that are passed into the glyphs using “context-fill” and “context-stroke”.

Meeting minutes can be found at:

A Spinning Newspaper or a Study of HTML vs. SVG

While wandering through the Web, I came across a simple but nice demo of CSS3 Animations: a spinning newspaper cover like one would see in an old black and white movie. It would be just perfect for a personal website I have but there is one problem: the example uses an image, JPEG to be exact. I want to be able to easily change the text. No problemo… I can just substitute a <div> for the <img> element and then fill that how I want. To begin, I followed the demo example and used the following CSS: .newspaper { animation-name: spinning; animation-duration: 1s; animation-timing-function: ease; animation-iteration-count: 1; animation-direction: normal; } @keyframes spinning { 0% {width:10px; height: 7px; transform:rotate(0deg);} 100% {width:468px; height: 330px; transform:rotate(1440deg);} } One thing to note is that this CSS won’t actually work in any browser at the moment. Firefox and Webkit based browsers support CSS3 Animations but only using prefixes (i.e. -moz-, -webkit-). While prototyping and testing in multiple browsers I found it convenient to use the “-prefix-free” JavaScript code that automatically adds the necessary prefixes (read the documentation about how to use it locally with Chrome and Opera). After you get everything working, you can manually add the prefixes if you need to avoid using JavaScript. I added a <div> for the newspaper name and immediately came across the first problem. The text doesn’t scale. Following the given example, I adjusted the @keyframe to include “font-size: 0%” and “font-size: 100%”. This didn’t work as expected. The fonts scaled alright, but as they scaled the font size was being rounded to an integer. This lead to discrete jumps in font size which caused visable effects in the text layout. I have to admit my CSS box-model fu is sadly lacking. I was having trouble getting everything to layout correctly. Later I realized that I had introduced a typo in my CSS style sheet. <rant>I personally hate how HTML5 has gone the route of allowing errors to go unnoticed. Coming from a programming background, I much prefer that my HTML/CSS crashes and burns when there is a syntax error. I’ve wasted more time trying to understand why something isn’t working the way I think it should only to discover later I was missing a simple colon.</rant> Given the frustrations I was having with CSS layout and with the font-sizing problem (which was a show stopper), I decided to try inline SVG for the layout. This worked out suprising well and within a few minutes I had the layout I wanted. (It helped that I was able to recycle some of the CSS classes I had already defined.) I still had a problem with how the animation was working. The transformation origin was moving so the spinning was starting around the top-left corner. At this point I realized that the @keyframes CSS was not optimal. There was no need to change the width, height, and font-size when a scaling could be simply added to the transform. I change the appropriate lines to: 0% { transform:scale(0) rotate(0deg);} 100% { transform:scale(1) rotate(1440deg); } Now the amination worked as expected. Once I got the SVG version working, I went back and tackled the CSS/HTML version. It took quite awhile, but I finally got it to look (almost) like the SVG version. Having completed that exercise I can give the following summary: SVG Advantages:
  • Easy layout. No dealing with collapsing margins, shifting borders, paddings, floats, vertical centering hacks. The one problem I came across was that paths must be defined in terms of user units (pixels) and not the percentages that I used everywhere else.
  • Easy to add vertical separators of random length.
CSS Advantages:
  • SVG does not have text wrapping but one can use a <p> inside <foreignobject>.
  • SVG text cannot automatically be vertically centered. Changing font-size requires manually shifting text.
Here are the final figures. Note that these are just PNGs. For a look at the spinning SVG and HTML covers go to my website (it is too difficult to get these to work inside the blog).

SVG/CSS

Newspaper cover mockup.

HTML/CSS

Newspaper cover mockup.

Animation in SVG and CSS

David White created a nice SVG background he calls “The digital river” with animated circles. Unfortunately it only works in Firefox due to incorrect handling of events inside the <use> tag (which allows cloning of objects, in this case a circle) by other browsers. The other browsers apply mouse events to the referenced object rather than just the cloned objects. David’s SVG uses SMIL for animation. Unfortunately, Microsoft has declared in no uncertain terms that it will not implement SMIL in their browers. They see CSS Transitions and CSS Animations as the proper way forward for supporting animation in SVG however no browser at the moment supports this although all the browsers do support experimental (read: prefixed) CSS transitions and animations on HTML elements. Here are two experiments inspired by David’s work. The first uses CSS with CSS Transitions, the second SVG with SMIL. Pass your cursor over the circles. The CSS version uses rounded corners on <div>s to simulate circles. It has the advantage of cross-browser support (except Firefox messes up the first row of circles). The SVG version only works properly in Firefox. It is more powerful as you can easily scale circles or use other shapes. CSS Ripples 
    
    


      

	

	

	

	

	

	

	

	

	

	

      


      

	

	

	

	

	

	

	

	

	

	

      


      

	

	

	

	

	

	

	

	

	

	

      


      

	

	

	

	

	

	

	

	

	

	

      


      

	

	

	

	

	

	

	

	

	

	

      


      

	

	

	

	

	

	

	

	

	

	

      


      

	

	

	

	

	

	

	

	

	

	

      


      

	

	

	

	

	

	

	

	

	

	

      


      

	

	

	

	

	

	

	

	

	

	

      


      

	

	

	

	

	

	

	

	

	

	

      

    

   
    

      
You must be reading this via Graphics Planet. Go to my blog site to see the demos. Graphics Planet strips out the styling needed to make the demos work.
SVG Ripples

Your browser does not support SVG! Too bad.

CSS3 Transforms and Animation Experiments

I’ve been experimenting with CSS3 3D Transforms and Animations. Currently only Firefox and WebKit browers support these features. Don’t use these in production. The specs are not finalized! Note to those reading this in Graphics Planet… the feed strips out the style elements that are required for the animated image. No JavaScript used, only CSS with inlined SVG. You can see more examples including a stereo version of the dodecahedron at my SVG and CSS page. 
    

     

    

      
You must be reading this via Graphics Planet. Go to my blog site to see the animation.

      Multicolor Dodecahedron

SVG 2: Now is the time to act!

The SVG working group is close to finishing a review of all the proposed new features for SVG 2. This is the time to make your voice heard if you want something added to the specification! While a final SVG 2 standard is probably two years away, things can show up in browsers earlier. SVG 2 will consist of a core standard plus modules and references to other standards, especially those from CSS 3, some of which are already approved or are close to being approved. You can now use CSS 3 Colors inside SVG in browsers. This allows, for example, describing a color in terms of HSL as I’ve done in the example below: 


   

   
   HSL
Appearing relatively soon will be CSS 3 Transforms which includes both 2D and 3D transforms. All the major browsers already support 2D transforms in HTML with Firefox and Chrome supporting some 3D transforms (at the moment one must use browser specific prefixes but that should change in the next couple of months). Expect this support to extend to SVG in the near future. (Hover over the box below! All done with CSS!) 
    
    

      

        
Front

	
Right

	
Back

	
Left

	
Top

	
Bottom
There are a number of items that Inkscape users and developers have expressed interest in seeing added to the SVG specificaition. If you have something you want to see added, leave a comment. There are some things that the SVG working group is open to adding but nobody in the group is willing to spend much time on them. If someone in the community were to step up, the likelihood that they would be added would be much greater. One item in this catagory is connectors.