Tag: SVG

Blending coming to an SVG renderer near you! (Including Inkscape)

SVG has supported a limited set of blend modes through the use of SVG filters. Now SVG (and HTML) are getting a full set of blend modes that can be directly applied to all graphical objects. Chrome already has some support for the new blending method. Here is a snippet of SVG from the specification CSS Blending and Compositing Level 1: 
<svg>
  <rect width="120" height="120" fill="black"/>
  <circle cx="40" cy="40" r="40" fill="red"/>
  <circle cx="80" cy="40" r="40" fill="lime"/>
  <circle cx="60" cy="80" r="40" fill="blue"/>
</svg>
Normally, SVG uses the painter’s model where each element is painted on top of the previous. So the above SVG gets rendered as (actual inline SVG):

Inlined SVG. Circles drawn using painter’s model.

With CSS blending, one can specify how the blending between the elements is done by setting the ‘mix-blend-mode’ property. The following style rule: circle { mix-blend-mode: screen; } yields the following figure:

Inlined SVG. Circles blended with ‘mix-blend-mode’ = ‘screen’.

which in a browser (recent Chrome) that supports CSS blending should look like this:
Red, lime, and blue overlapping circles, blended with 'screen' mode.

PNG.

Why the black background? If the background was white, the circles would not be visible. This is because the circles blend not only with each other but also with the background. (With the ‘screen’ blending mode, any color blended with a white background results in white.) To stop blending with the background, one can use the ‘isolation’ property. By wrapping the three circles in a group and setting the ‘isolation’ property to ‘isolate’, the three circles are first blended onto a transparent, black background and then the resulting image is painted normally. The code looks like this: 
<svg>
  <g>
    <circle cx="40" cy="40" r="40" fill="red"/>
    <circle cx="80" cy="40" r="40" fill="lime"/>
    <circle cx="60" cy="80" r="40" fill="blue"/>
  </g>
</svg>
and the CSS: circle { mix-blend-mode: screen; } g { isolation: isolate; } The resulting image should look like this:
Red, green, and blue overlapping circles, blended with 'screen' mode.

PNG.

I wasn’t able to get the ‘isolation’ property to work with Chrome (which should support it), thus I used a PNG in the above figure. At the SVG Working Group meeting last week, the group approved moving the CSS Compositing and Blending Level 1 to a Candidate Recommendation. Since this a joint specification, the CSS Working group must also give their approval. A Candidate Recommendation is the last step before becoming a Recommendation (i.e. an official W3C specification). During this last step two things must happen. First a comprehensive test suite must be written and second at least two different implementations must pass the tests for each feature in the specification. This latter requirement ensures that the specification is clear enough that it can be implemented (and also demonstrates there is a real interest in the specification). Chrome already implements the specification so just one more implementation is needed. It is expected that Firefox will soon support the specification. There is also a test plan that includes SVG tests. So we are well on the way to getting this through the last step. In addition, I’ve also just added support for CSS Blending to Inscape trunk. For the moment, a compile time flag must be set to enable the support. There is no GUI (other than the XML editor) and there is still a bit of work to be done (the Inkscape canvas background needs to be isolated from the drawing and I’ve seen a bug when part of the drawing is cached. The CSS Compositing and Blending Level 1 specification also include a full set of Porter-Duff compositing operators. For the moment, they only apply to Canvas. It was intended that they apply to HTML and SVG but the rendering models used by browsers cannot yet accomodate them. They will be included in the next version of the specification, CSS Compositing and Blending Level 2. The SVG working group approved the start on the next level at the last meeting. Blending and compositing has been included in SVG filters from the beginning. However, only a limited set of blending modes and compositing operators are available in SVG filters. Unfortunately, CSS Filters Level 1 has not extended filters to include the new blending modes and compositing operators despite being trivial to implement once the original set has been implemented (it took me all of an hour to add them to Inkscape trunk). Again the motivation is to speed up approval of the level 1 specification; level 2 will include them. Work on level 2 is expected to begin early next year. If you are interested in playing with then new blending modes and compositing modes in Inkscape, check out Inkscape trunk and set the flags WITH_CSSBLEND and/or WITH_CSSCOMPOSITE (see the file configure.ac). As mentioned above, there is no GUI for the new non-filter based blending modes. The new blending modes and compositing operators for filters are available through the Filters dialog. You can also have a look at my Blending Test Page.

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

SVG Buttons in HTML (or SVG Integration in HTML)

It’s been awhile since I posted to this blog. I have been very busy getting the new edition of my Inkscape book ready for the publisher. I wanted to add a new tutorial on using SVG in HTML given that SVG is an integral part of the upcoming HTML5 standard and that IE will finally support SVG. Writing this tutorial turned out to be a lot more difficult than I had anticipated. Not only is there not a lot out there on how SVG fits into HTML5, but there are still major issues to be addressed by the standards groups. I wanted to start out the tutorial by creating a button that could be used as a better PNG. From there I planned to add functionality to the button such as keeping track of its state (i.e. is it on or off?). I also wanted to be able to style the button from HTML. An evolving web page documenting my trials and findings can be found at my Button Test page. Here I will just cover a few of the most important things I learned.

Using an SVG as a better PNG

The first problem I ran into is how to provide a PNG fallback for browsers that don’t support SVG. I wanted to simply replace a PNG button by an SVG button inside an <a> tag. The normal way to provide a PNG fallback is to use the <object> tag: 
  
	<a href="http://tavmjong.free.fr/">
	  <object type="image/svg+xml" data="buttonA.svg">
	    <img src="buttonA.png" alt="A sample button."/>
	  </object>
	</a>
But this doesn’t work (except in IE9 beta) as the SVG “swallows” the mouse clicks when the button is pressed. They never bubble up to the <a> tag. This is probably by design for security reasons. Cameron Cameron McCormack from the SVG working group suggested using an error handler on an <img> tag. This does work (at least in IE8). So the first problem has been solved: 
  
        <a href="http://tavmjong.free.fr/" target="_blank">
	  <img src="buttonA.svg" alt="A sample SVG button."
	       onerror="this.removeAttribute('onerror');
			this.src='buttonA.png'"/>
Ansample SVG button.

Reusing an SVG button on the same HTML page

After I added some functionality to the button via JavaScript (making it keep track of two different states), I faced the problem of how to reuse the button on the same page. When a button is clicked, the SVG script needs to notify the HTML script which instance of the button has been activated. At first it appeared that I would have to move the JavaScript code out of the SVG file and into the HTML file, as well as use an inline SVG wrapper to reference SVG fragments in the external SVG file. Erik Dahlström, also of the SVG working group, suggested that using window.frameElement.id inside the script in the SVG file would let you know which button was pushed. This id can then be passed to the script in the HTML file. This works quite well. This idea also lead to solving another problem: how to style the button from HTML. The SVG standard has a currentColor attribute/style parameter so one would think that one could specify the color in the <object>’s style attribute and the SVG file would pick it up. The SVG standard indicates that this is exactly the purpose of currentColor. Nope. CSS styling doesn’t work across document boundaries. But it is easy to get the color by using window.frameElement.style.color and then setting the button color in an init() function. One can go further. One can customize the text on the button by using <param>s inside the opening and closing <object> tags. The <param>s can also be grabbed by the SVG init() script. Here are two buttons using the same SVG file: Style from CSS (inside SVG) and custom text from <param>s: 
  
    <object type="image/svg+xml" data="buttonG.svg" id="default">
      <param id="TextOn"   name="TextOn"  value="Green" />
      <param id="TextOff"  name="TextOff" value="Red" />
    </object>
If you don’t see a button: go to http://tavmjong.free.fr/blog/ The button text is OFF. Style from <object> and custom text from <param>s: 
  
    <object type="image/svg+xml" data="buttonG.svg" id="pink" style="color:pink">
      <param id="TextOn"   name="TextOn"  value="I am on" />
      <param id="TextOff"  name="TextOff" value="I am off" />
    </object>
If you don’t see a button: go to http://tavmjong.free.fr/blog/ The button text is OFF.