Inkscape | Tavmjong Bah's Blog

Descending into the bowels of Inkscape code

Introduction

This post is more geared to Inkscape developers than Inkscape users. I hope that by recording my trials and tribulations here it can help others in their coding efforts. I have been working on adding support for ‘context-fill’ and ‘context-stroke’ to Inkscape. These magical ‘fill’ ans ‘stroke’ property values will allow Inkscape to finally match marker fill (e.g. arrowhead color) to path stroke (e.g. arrow tail) in a simple way. These new property values are part of SVG 2. Adding this support is a multi-step process. First one must be able to read the new values and then one must be able to apply the values. The former part is rather straight forward. It simply required modifying the SPIPaint class by adding a new ‘enum’ SPPaintOrigin with entries that keep track of where the paint originates. The previous ‘currentColor’ boolean has been incorporated into this new ‘enum’. The latter part proved to be much more of a challenge.

Where does the ‘apply’ code go?

The ‘context-fill’ and ‘context-stroke’ values are applicable to things that are cloned. The driving force for these values is certainly the <marker> element but <symbol> and <pattern> elements could also find the values useful as could anything cloned by the <use> element. For the moment, I concentrated on implementing the values in markers and things cloned by the <use> element. The first question that comes to mind is: Where in the code is styling applied? This turns out to not be best starting question for cloned objects. A better question is: How does the cloning take place? To answer this question I implemented three routines with the same name: recursivePrintTree(); but, as member functions of different classes: SimpleNode, SPObject, and DisplayItem. These represent different stages in Inkscape’s processing of an SVG document. Here are the findings:

XML Tree (SimpleNode): The XML Tree matches the structure of the XML file with some extra elements possibly added by Inkscape such as <metadata> and <sodipodi:namedview>. This is the tree that is shown in the XML editor dialog. No cloning is evident.
Object Tree (SPObject): The object tree is similar to the XML tree. Its main purpose is to handle the CSS styling which involves merging the various sources of styling (external style sheets (rect: {fill:red;}), styling properties (style=”fill:red”), and presentation attributes (fill=”red”), as well as handling all the necessary cascading of styles from parent to child. A few non-rendering elements are missing such as <RFD:rfd> and some new elements appear. Here is our first clue: the object tree includes the unnamed clones of elements created by the <use> element. It makes sense that they appear here. Cloned objects descending from a <use> element participate in the style cascading process. Marker clones, however, are no where to be seen.
Display Tree (DisplayItem): The display (or rendering) tree includes only elements that will be rendered. All the styling has been worked out; all the placement and sizing of graphical items has been calculated. The metadata, the Inkscape editing data, and the <defs> section are all gone. But now clones of the markers appear, one clone for each node where a marker is placed, each containing the geometric data of position, scale, and orientation. This is a quite reasonable way to handle markers as each marker clone is identical to its siblings (at least until ‘context-fill’ and ‘context-stroke’ came along).

The above “tree” analysis gives the structure of each tree after it has been built, but doesn’t explain how each tree is created. This has ramifiations of how one can handle the ‘context-fill’ and ‘context-stroke’ values.

Creating the XML tree

There are a couple of ways to create the XML tree. The most common is via sp_repr_read_file(). This is used in SPDocument::createNewDoc() as well as routines to read in filters, templates, etc. Files opened by Inkscape from the command line use XSLT::open() which allows XSLT stylesheets to be applied to the SVG file (something I didn’t know we supported). Both functions call sp_repr_do_read() to read the actual files and both end up with an Inkscape::XML::Document.

Creating the object tree

Once the XML tree is created, it is passed to SPDocument::creatDoc() which builds the object tree top down via the recursive calling of SPObject::invoke_build() starting with the document root <svg> element. SPObject::invoke_build() calls the virtual function SPObject::build() which handles element specific things such as reading in attributes. Attributes are read by calling SPObject::readAttr() which performs a few checks before calling the virtual SPObject::set() function. The set() function for SPUse reads in ‘href’, the reference to the object to be cloned by the <use> element. Reading in the reference inserts a copy of the referenced object (the clone) into the object tree via SPUse::href_changed(). Markers are not cloned; only references to the marker elements are added at this step, in the SPShape::build() function.

Creating the display tree

The display tree is created by calling recursively SPItem::invoke_show() on the root object (SPItem, derived from SPObject, is for visible objects). This is done in SPDesktop::setDocument(). SPItem::invoke_show immediately calls the virtual function SPItem::show() which handles element specific things. (SPRoot::show() calls SPGroup::show() which calls SPGroup::_showChildren.) SPItem::show() creates an instance of an appropriate display class object that is derived from Inkscape::DrawingItem(). The virtual function DrawingItem::setStyle() is called to set the style information. One thing to note is that the a child is constructed (with styling) before adding it to the tree so a child’s style cannot be directly dependent on an ancestor in the tree. But ‘context-fill’ and ‘context-stroke’ need ancestor style information so we need to supply that in a different way. Markers are tracked by a map of vectors of pointers to Inkscape::DrawingItem instances. This map is stored in SPMarker. The map is indexed by a key for each type of marker (start, mid, end) on a particular path. The vector has an entry for each position along the path a marker is to be placed. The DrawingItem instances are created in a two step process from SPShape::show(). First a call to sp_marker_show_dimensions() ensures that the vector is of the correct size. Then a call to sp_shape_update_marker_view() calls sp_marker_show_instance() which creates a new Inkscape::DrawingItem instance if it doesn’t already exist.

Setting the style of a clone

As mentioned above, style is handled in the virtual function DrawingItem()::setStyle(). The DrawingShape and DrawingText setStyle() functions call NRStyle.set() where the work of translating the style information from the object tree form to the display tree form takes place (in the display tree, the styling information is in a form used by the Cairo rendering library). To handle ‘context-fill’ and ‘context-stroke’ we would like to walk up the display tree to find the style of the element that references the clone, i.e. the <use> element or the <path> or <shape> elements in the case of markers. But at the point the setStyle() function is called on an element in the clone, the clone has not yet been inserted into the display tree, so one cannot walk up the display tree. What we can do is hand two sets of styling information from the object tree to to the setStyle() function, the first being the stying information for the object at hand and the second being the styling information that should be used in the case of ‘context-fill’ and ‘context-stroke’. We know the later for the <use> element as its clone is in the object tree. All that is required is setting a pointer to the context style information in the SPUse class and then passing it down to its children. This solution doesn’t work for markers as their clones are not in the object tree. The solution for markers is calling a function that walks down the tree setting the correct styling information after the cloned marker elements are added to the display tree.

Future work

There are still quite a few things to be done. In particular, before we can switch to using ‘context-fill’ and ‘context-stroke’, as well as the ‘orient’ attribute value ‘auto-start-reverse’ (which allows us to handle both start and end arrows with just one marker) we’ll need a fallback solution for SVG 1.1 renderers. Here is a list of things to do:

Handle gradients and patterns.
Handle text (appendText()).
Export to SVG 1.1.
Redo markers.svg (source of markers in Inkscape).

Reflections

All the code is now in trunk. To implement ‘context-fill’ and ‘context-stroke’, I added about 200 lines of code. I don’t know the exact amount of time it took, but I would guess a minimum of 20 hours. That works out to about 10 lines per hour… not very productive. The first part, reading in ‘context-stroke’ and ‘context-fill’ took about an hour. I am quite familiar with this part of the code, having C++ified the SPStyle and related classes and having implemented other new properties and property values. It was the second part that took so long. Although I have worked with parts of this code before, it was often quite opaque as to which code is doing what (and why). I ended up going down many false paths. There is a serious lack of comments and often confusing variable and function names (what the heck is an ‘arenaitem’?). A few comments at the appropriate places could have shaved up to 90% of the time it took. In this case, the different way markers and clones are handled required solving the same problem twice. When you begin a project, it is very hard to estimate the time it will take. I would have thought this project could be done in less than 5 hours, possibly in just a couple. It didn’t turn out that way. On the otherhand, implementing the new CSS property ‘paint-order’ which I thought would take considerable time, took only a couple of hours.

The ‘paint-order’ property in SVG 2

Introduction

SVG 2 has a new ‘paint-order’ property which can be used to select the order in which the fill, stroke, and markers are painted. This is of especially great use for text where having the stroke painted on top of the fill leads to distorted glyphs.

Sample text showing effect of paint-order.

Sample text showing the effect of the ‘paint-order’ property.

As of March 2014, Chrome and Firefox Nightly support the ‘paint-order’ property. Inkscape trunk also has rendering support for the property (if compiled in).

Test SVGs

Tests with different orders of 'fill', 'stroke', and 'markers'.

Each square has the indicated value of the ‘paint-order’ property.

Each line of text has the indicated value of the ‘paint-order’ property.

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.

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. 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 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.

SVG 2 Requirement.
SVG 1.2 Working Draft (27 October 2004.
CSS Exclusions Working Draft (3 May 2013).
CSS Exclusions Editor’s draft (22 May 2013).
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 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:

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

[1] The commercial version actually has 18 faces.
[2] Comment on Microsoft and font-config.
[3] Note on font-weight.
[4] The subroutine that defines the skewing matrix is _pango_cairo_core_text_font_new in the file pangocairo-coretextfont.c.
[5] The subroutine to embolden a glyph is FT_Outline_EmboldenXY() in the file ftoutln.c.

Spec Writing Madness

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)

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

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.

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: V_out = A V_in^ɣ where V_out is the intensity to be displayed, A is a constant, V_in 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.

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:

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.

Transportation and Passenger Symbols

I poked around the Internet for a set of symbols to add to Inkscape for use in the new Symbols Dialog. I was looking for a set that was more artistic than the typical symbol sets used for diagramming (I already added logic symbols as an example). I found that there are surprisingly few sets of high quality symbols available for free. Search results are dominated by commercial companies (who are happy to sell you symbols that are in the public domain). I rather quickly settled on the AIGA (American Institute of Graphic Arts) symbol set. This set was commissioned by the US Department of Transportation (DOT) in the 1970’s to create a standard set of symbols for use in airports and other transportation hubs. You will have to have lived your entire life as a hermit to have never seen the symbols in use. This symbol set served as the basis of other symbols sets like the NPS symbol set for maps, the Japanese ECOMO Public Information symbol set, and the ISO 7001 standard symbol set.

Some common AIGA symbols (Toilets, Smoking, Immigration, Telephone).

The AIGA symbols have held up well over time (the symbols are almost 40 years old!). Only one symbol is really outdated (the Gift Shop symbol with a pipe) and one symbol never caught on (exit).

Example of an outdated symbol (Shops) and an unused symbol (Exit).

I chose to redraw the symbols using the EPS files from the AIGA website as templates. This allowed me to optimize the SVG, aligning nodes where practical on pixel boundaries as well as using SVG elements like <circle> where possible. Redrawing the 50+ symbols gives one an insight into their design. The symbols were designed to be easily recognizable from a distance thus they use simple lines, circles, and circular arcs. Bodies are represented without feet or hands. The symbols were drawn in a pre-CAD era. This may explain some anomalies like figures not being accurately centered and small inconsistencies (i.e. the key in the Baggage Lockers symbol scaled differently than the one in the Car Rental symbol). Cut and paste meant a different thing in the 1970s. The NPS symbol style is based on the AIGA style with some minor changes. The changes were probably motivated by the different target use of the two sets; the AIGA symbols targeted signs while the NPS symbols are for maps. In retrospect, the NPS set might have been a better choice to have added to Inkscape. The NPS set also has the advantage of being regularly updated.

Comparison of AIGA (left) vs NPS (right) symbols. Note how in the NPS version the fork has been simplified and how the separation between the legs/arms and bodies has been increased.

Both the ECOMO and ISO 7001 symbols sets are obviously inspired by the AIGA set. These sets, however, have the appearance of being designed by committee. There are style inconsistencies between various symbols, and those symbols that have obvious roots in AIGA seem to have often been changed for just the sake of change. Comparisons between the sets are complicated since the ISO standard is not freely available on the Web.

Examples of AIGA vs ECOMO and ISO symbols.

Comparison of AIGA (left), ISO 7001 (middle), and ECOMO (right) symbols.

One symbol that is conspicuously missing from the AIGA set is a symbol for Handicap Access; handicap access just wasn’t as an important issue among transportation planners back in the 1970s. The International Symbol of Access (ISA) was created in 1968. The original symbol left a lot to be desired from an artistic/design point of view. It basically looks like a stick figure with a head thrown on… and this is exactly how it was created. The original designer, a student, created a headless stick figure sitting in an oversized wheelchair. The head was added by the director the Swedish Handicap Institute to humanize the figure. The organization Rehabilitation International (RI) worked to get the symbol accepted by the ISO. This symbol is currently part of the ISO 7000 standard. A version more consistent with the style of the AIGA symbols is in the ISO 7001 standard as well as the 1996 NPS symbols set. A version with feet (not as consistent with the AIGA style) is in the current NPS symbol set. All these versions of the Handicap Access symbol have been subject to critique as it shows a disabled person sitting passively (helplessly?) in a wheelchair. A newer version, showing an active wheelchair user has been created but not widely adopted (in fact, RI appears to be hostile to it). And even this new symbol is subject to criticism because it represents only one kind of handicap access.

Comparison of various Handicap Access symbols. From left to right: original (ISO 7000), NPS (1996) and ISO 7001, NPS (current), active version (quasi AIGA style).

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.

An example of arcTo. In this example, p₀ is the previous path point. p₁, p₂, 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.

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>

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.

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: