FOSSASIA and Openclipart are launching a contest for International students, artists and designers to design a T-shirt graphic representing “The Internet of Things for Me.” 1st place winner of the contest will win a FiftyThree Pencil and final design placement on the official FOSSASIA 2016 T-shirt. Second and third place winners’ graphics will be used as design elements at the conference main party on the second day of the event.

“FOSSASIA 2016’s theme is about the Internet of Things for Me,” said chair of FOSSASIA, Hong Phuc Dang. “What better way to represent this idea visually than to unleash local Singaporean and international designers, artists, professionals and students to make artwork representing their ‘things’ and expression about this topic.”

FOSSASIA 2016 challenges all participants to join the contest at Openclipart, the world’s largest collection of original and free to use clipart. The contest begins February 11, 2016 and runs for two weeks until February 24, 2016 where three judges will select the top three compositions. The 1st, 2nd and 3rd place winners will be selected, awarded, and announced publicly.

“Since 2004, Openclipart has been a dynamic creative community of artists and designers producing more than 89,000 clipart by more than 4,900 artists,” stated Openclipart founder, Jon Phillips. “This competition is to bring creativity to the conference, and use the powerness of Open to create image composition of what the Internet of Things is all about. Even better, all the artwork made in the competition will be released into the public domain using Creative Commons Zero 1.0 license so that anyone may use the images for any reason, even commercially.”

Judges for the competition will be Singapore-based artist and designer Gloria Chiang, chair of FOSSASIA Hong Phuc Dang and technologist and co-organizer Mario Behling. After the two-week competition ends on February 24, 2016, results will be announced March 2, 2016.

“Singapore is a hub of software and cultural innovation,” said Singapore-based artist, Gloria Chiang. “FOSSASIA 2016 is a brilliant place to showcase international innovation trends and work with local artists, designers and students to illustrate these concepts.”

“FOSSASIA 2016 T-shirt design competition participants artwork will be showcased not only on T-shirts and publicly on the web, it will also be used to create an atmosphere for the 2nd night of the FOSSASIA 2016 conference,” said organizer Hong Phuc Dang. “All participants of the FOSSASIA 2016 conference are invited to attend this special event and share the works found at our party with the hashtag #FOSSASIA. With lots of surprises, you will not want to miss FOSSASIA 2016.”

Join the competition at: http://openclipart.org/fossasia2016

February 18, 2016 06:56 PM

div.figure { padding: 5px; margin-bottom: 20px; text-align: center; background: #cccccc; } div.figure img { } div.figure p { font-size: 10px; } The SVG Working Group had a four day face-to-face meeting in Sydney this month. Like last year, the first day was a joint meeting with the CSS Working Group. I would like to thank all the people that donated to Inkscape’s SVG Standards Work fund as well as to the Inkscape general fund that made my attendance possible.

Joint CSS and SVG Meeting

Minutes

CSS Stroke and Fill Specification

The CSS working group would like to allow the use of the SVG ‘stroke’ and ‘fill’ properties on CSS text as well as other places in CSS (e.g. box border). They’ve created a prototype document that basically copies the SVG stroke and fill text adding the necessary parts to get it to work with CSS text. This document has been temporary called Text Decoration 4 (the title will certainly be changed). They’ve proposed converting the ‘stroke’ and ‘fill’ properties to short-hands. (A short-hand property allows setting multiple CSS properties at the same time.) They also would like to see the ‘stroke-alignment’ property implemented (this property allows one to stroke only the inside or only the outside of a shape). I pointed out the difficulty in actually defining how ‘stroke-alignment’ would work. The SVG WG moved some of the advance stroking properties out of the SVG 2 specification into an SVG Stroke module to avoid holding up the SVG 2 specification. (See my blog entry on this as well as the issues in the SVG Stroke module.) Other issues discussed were how glyphs are painted (‘paint-order’, ‘text-shadow’), multiple strokes/fills, dashing, and ‘text-decoration-fill/stroke’.

Text Issues

Next we covered a whole slew of text issues I raised dealing with flowed text in SVG.

Strategy for using CSS in SVG for wrapping

The first issue was to agree on how SVG and CSS are related. I presented my strategy: that HTML/CSS and SVG have there own methods to define an area to fill called the wrapping area. Once this area is defined, one uses CSS rules to fill it. Here is how one defines the wrapping area in both HTML/CSS and SVG:

The CSS/HTML code:

    <style>
      .wrapper { shape-inside: xxx; ... }
      .float-left { shape-outside: yyy; ... }
      .float-right { shape-outside: zzz; ... }
    </style>
    <div id="wrapper">
      <div id="float-left"/>
      <div id="float-right"/>
      <p>
	Some text.
      </p>
    </div>

The result: The CSS/SVG code:

    <style>
      .my_text { shape-inside: xxx; shape-outside: yyy, zzz; ... }
    </style>
    <text id="my_text">Some text.</text>

The result: It was pointed out at a discussion on Day 2, that the use of ‘shape-outside’ in SVG was not consistent with the CSS model. The ‘shape-outside’ property defines the effective shape of an element as seen by other elements. We agreed to change ‘shape-outside’ to an SVG only property ‘shape-subtract’.

How is the first line placed in a wrapped shape?

When the top of a wrapping area is not horizontal, how do you decide where the first line of text is placed? We were informed that with CSS floats, the line is moved down until the first text chunk fits. To be consistent with CSS, we should follow the same rule. A future CSS Line Grid specification may allow one to control line position.

Overflow text

What should happen when the shape isn’t big enough for all the text? This is mostly an issue for browsers where the user can specify a larger font (i.e. for accessibility reasons). CSS has an ‘overflow’ property that selects either clipping or scrolling. Neither of these is a great solution for SVG. The tentative solution in the CSS Shapes 2 specification of extending the <div> below the wrapping area doesn’t work for SVG. I proposed that there should be a means to expose the overflowed text, such as displaying it on hovering over the ellipses at the end of the displayed text. There was some interest in this. For the moment, the best solution is probably to explicitly not define what should happen, leaving it to a future time to specify the behavior. In reflecting on this after the meeting, I think one strategy is to suggest that authors provide an overflow region by adding an additional shape to the value of the ‘shape-inside’ property.

How does text wrap in a shape with a doughnut hole or other feature that breaks a line into parts?

Since SVG can have arbitrary shapes, it is possible to create shapes that break a single text line into parts. How should these shapes be filled? The ‘wrap-flow’ property does not apply here as that dictates how text is flowed around floats. A new ‘wrap-inside’ property has been proposed. For the moment, however, it was agreed that text should flow as shown in the above figure. This would be the default value of any new property.

Flowing into multiple shapes

The aborted SVG 1.2 specification allowed text to be flowed sequentially into multiple shapes. This is something that Inkscape implemented and I would like to see this ability preserved. The proposed CSS methods for doing this don’t work for SVG. I proposed giving the ‘shape-inside’ property a list of shapes. It was agreed that this would be an acceptable solution for SVG. (And it can provide a place for over-flowed text.)

How is the first glyph positioned on a line?

When dealing with rectangles, it is straight forward to find the position of the first glyph but with arbitrary shapes it is more difficult. I asked what was the correct CSS method. I was told that one considers the glyph box extended upwards/downwards as dictated by using the height of the entire line box. (For example, if one has a ‘line-height’ value of 2 with a 16px font, the line box has a height of 32px.) It’s not clear where this is specified in CSS.

Baseline issues

We next switch from text wrapping to baseline issues. Text is normally laid out along a baseline which can be different depending on the script. For example, western scripts normally use an Alphabetic baseline while Indic scripts use a Hanging baseline. The proposed CSS definition of the ‘dominant-baseline’ property differs from the SVG 1.1 definition in that several of the SVG 1.1 values are missing. We discussed the missing values. Some of the missing values will be added to the CSS definition. There is one fundamental difference between CSS and SVG 1.1: With SVG 1.1 (and XSL 1.1), the baseline table does not change automatically when the font size is change. One must explicitly reset the table by setting the ‘dominant-baseline’ property to the ‘reset-size’ value. The proposed CSS definition will automatically reset the table on change in font size. I’m not sure this is a necessarily good change (it’s definitely not backwards compatible) but then this is probably such a small corner case that it doesn’t really matter.

The CSS ‘auto’ value has one small problem for SVG. With vertical text, if the value of ‘text-orientation’ is ‘sideways’, the alphabetic baseline is used. SVG 1.1 always uses the central baseline for vertical text. The CSS specification will be fixed to be compatible with SVG 1.1.

We also discussed default values for the various baselines. In principle, one gets the values of the baselines from the font but most fonts don’t have baseline tables; for interoperability we need defaults. It was decided that the CSS group would investigate this more and come up with a recommended set of default values.

Filters

I brought up a couple of issues dealing with SVG/CSS Filter Effects module. The first was the status of the document. Progress towards finishing this document seems to have stopped. Two of the three editors are no longer very active. The third editor was present and said he would push this through.

I was also interested in the next level as I have a filter primitive I would like to see added. It turns out that Level 2 has already been started. Not much is in there now. Apple, however, has a bunch of filter primitives they would like to add.

Next we covered the issue of artifacts created by using eight bit per channel colors (8 bpc) in the filter chain. The specification as written doesn’t directly specify that 8 bpc color should be used but a couple examples do assume this. I proposed that they be converted to use the range 0 to 1 so that one can use floats to describe color channels. This would solve the problem. Dean Jackson from Apple will investigate the possibility of requiring that floats be used rather than ints in the filter chain.

Gradient Banding

An unplanned topic… how to get rid of banding in gradients. Dithering is a well known technique. Can dithering be added to CSS gradients? There seems to be support for this idea. The syntax and technique needs to be specified.

SVG Meeting — Day 1

Minutes

Path Stroking: Conformance

I brought up some time ago the inconstancy in how paths are stroked with the half the stroke width is greater than the radius of curvature (see my blog post). I suggested that maybe we define the proper way to stroke a path. Another SVG Working Group member took an action to research this topic more. He consulted members of the PDF standards group as well as hardware vendors. After he presented his findings we agreed that being more specific at this time wasn’t really a viable option as the way paths are stroked is such a fundamental property of the underlying graphics libraries that are used to render SVG.

Fallback for the ‘arc’s Line Join

It has been noted that the currently specified fallback for the ‘arcs’ line join of a ‘miter’ join is less than idea. I presented a number of alternative options to the working group. They agreed to a change in the fallback to one of two possible fallbacks: I added to Inkscape trunk’s ‘Join type’ LPE the different possible fallbacks for people to test. A full discussion can be found at here. If you have an opinion, let me know.

Path morphing

With the possible demise of SMIL animations, I asked what was the status of turning the path data attribute into a property so that it can be animated using CSS/Web Animations. The response was that it hasn’t been forgotten and that Chrome will soon have an implementation. (SMIL usage shot up dramatically after YouTube started to use SMIL to animate the Play/Pause button.) CSS path animation will be based on SVG 1.1’s path animation. A future version might include more flexible rules for path interpolation (at the moment, animated paths must have the same number and type of path commands).

SVG Meeting — Day 2

Minutes (Some minutes missing due to operator error…. The meeting crossed midnight GMT which confuses the minute making bot.)

Presentation Attributes

SVG has the idea of presentation attributes. These are attributes that can also be set using CSS. Recently, we’ve promoted quite a few geometric attributes to be presentation attributes to allow setting them with CSS (it does seem a bit strange to “style” the position of a rectangle… but that is what we’ve enabled). As we add new properties, should these also be turned into presentation attributes? It is a bit of a maintenance burden to ensure all new properties are also presentation attributes, especially as we adopt a plethora of new text properties. We have already decided to require CSS so there is not necessarily a need for new presentation attributes. HTML has already deprecated/removed presentation attributes in favor of CSS. After a bit of discussion, we have decided to follow HTML’s lead.

Other Topics

Topics covered included how SVG is integrated into HTML, coordinate precision in generated content, and aligning dashes to corners. As mentioned earlier, we decided to create a ‘shape-subtract’ property rather than misuse the ‘shape-outside’ property. Most of the afternoon was spent with specification editing.

SVG Meeting — Day 3

This was a specification editing day. (It is extremely useful to have the working group present when editing as any issues that arise can be immediately dealt with.)

February 17, 2016 12:21 PM

The Inkscape website has recently been updated, bringing our community a lot of new features to bring them closer together. While we were working on updating the website, we experienced some rough spots (slowness, unavailability), but hopefully, most of those have been evened out by the determined work of our team.

New features at a glance:

New Gallery

The new gallery now really makes our community's artwork shine. It's easy to browse and discover inspiring art and Inkscape add-ons created by other Inkscape users. You can sort by gallery, type of upload, age and other parameters and search for keywords.

Contests

There is now a mechanism in place that allows us to hold contests for artwork on our website. We expect to make use of this for community voting, e.g. the About Screen contests.

Teams

Users and developers, the Inkscape Board, as well as website editors and translators can now join their respective teams. Teams can have their own chat rooms, mailing lists and galleries to exchange ideas and images (the actual mailing lists will only be moved later from their current location at sourceforge). Chat access from our website is now only available to logged in users, which makes it possible that the people giving support can reach out to them even after they logged off from chat (of course, access to the chat channels is also possible using an IRC client software, just like before). There is also a new chat bot with a couple of fun features, and a chat tutorial for our users.

Releases

We have now got a new releases app, which will soon replace the current CMS downloads pages. It's being filled in step by step with all our old and current download files. If you can help write up and link up all the downloads, please get in touch. The new releases page will be made available to the public in the coming months.

Website Design

In many places, the design of the website has been updated and improved: the website footer, the user profile, as well as the CMS pages and many other locations all got a small brushing-up.

Mails

The website is now able to send other mails than just the registration mails to users. Currently, this new mailing system is used to alert you of private messages another user sends you, without exposing their private email address. You can now also follow any other user on the website, to be notified of new uploads to their gallery.

Translations

All menues in all languages are now complete, as missing, untranslated contents is filled in by its English fallback. All parts of the website are available for translation now.

Security

Our website software, Django, has been updated to the latest long term support version. This fixes a lot of vulnerabilites, while at the same time reducing the frequency of maintenance updates for our website developers.

Updates for Editors and Staff

Our editors and translators can now subscribe to pages, to get an email when those have been edited. The editing workflow and interface have been updated, and things like spell-checking now work directly while editing. There have also been changes made to the available plugins.

Bug fixes

Many small and big bugs were squashed during the months that preceded the current website release. For example, our planet blog aggregator is now working again. For a full list of changes, please refer to our website's release milestone page - and if you encounter any bugs we didn't address yet, please report them to our bug tracker.

February 09, 2016 10:46 PM

Budget 2016

We have budgeted $22,850 for expenditures this year. We are estimating $12,600 income from donations this year.

We also are establishing separate funding pools for Hackfests, SVG WG meetings, and funded projects, for targeted fundraising purposes.

read more...

GPLv2 Licensing Intent

A few GPLv3 licensed files in the Inkscape codebase engendered a question about what the project's intent should be for licensing. With this vote we've established that at least for now, the codebase should be licensed GPLv2 or newer.

There seems to be some interest in migrating to GPLv3, but that will be a separate discussion.

read more

Hackfest 2016 in Leeds, England

Following on our successful hackfest last year, a new one is being organized to be held in conjunction with the Libre Graphics Meeting in London. We're going to have the hackfest in nearby Leeds though, both due to London being expensive and because an Inkscape developer lives there and can handle logistics.

read more

SVG Working Group Meeting in Sydney, 2016

Tavmjong Bah is willing to represent Inkscape once again this year at the SVG Working Group meeting in Australia, and we've approved expenses. We've started dedicated fundraising for these meetings, which has garnered $286.54 so far, and we've also allocated an additional $2250 from Inkscape's general fund. The board has formally approved the amount of $2,536.54 for this trip.

read more

January 14, 2016 07:57 PM

The non-profit home of Inkscape, Software Freedom Conservancy, is in urgent need of your immediate support!

Conservancy must move to a Supporter-driven organization so it can focus on critical free software issues that nobody else is tackling. Inkscape relies on Conservancy and we ask you to donate today:

https://sfconservancy.org/supporter/

January 11, 2016 10:00 PM

div.figure { padding: 5px; margin-bottom: 20px; text-align: center; background: #cccccc; } div.figure img { } div.figure p { font-size: 14px; } pre { font-size: 14px; } ol.circled { list-style: symbols("\2776" "\2777" "\2778" "\2779" "\277A" "\277B" ); font-family: "Inconsolata"; font-size: 14px; }

Introduction

Mesh gradients are great for creating life-like illustrations. Long asked for, they were one of the first things we added to the SVG 2 specification. I added mesh support to Inkscape (behind a compiler flag) for testing. There was one problem that was immediately apparent: as mesh gradients use bilinear interpolation between corner colors, there were non-smooth color transitions between the mesh patches leading to unwanted visual artifacts. See my blog post from a few years ago for more details about this problem.

A little bit of investigation showed that Adobe Illustrator and CoralDRAW use some sort of smoothing algorithm to get rid of the artifacts. We asked Adobe if they would give us the algorithm but they replied no. I did a little research and found that using bicubic interpolation would be a good solution. After adding a trial implementation in Inkscape and demonstrating it at last year’s Sydney SVG working group meeting, I got the group’s approval to add this to the SVG 2 specification.

Heat Maps

The discussion in the Wikipedia of bicubic interpolation has some nice heat map illustrations showing the effects of bilinear vs. bicubic interpolation. I thought it would be interesting to duplicate these illustrations using SVG. Here is how I did it.

The first step is to create a mesh. It is rather easy to do this in Inkscape with the mesh tool. I created a raw mesh with a 3×3 array of patches to match the one in the Wikipedia article. The tricky part is then to set each patch corner to a gray level based on the data. I estimated the data values from looking at the color chart in the Wikipedia illustrations. I then converted each gray level into an appropriate RGB hex color value. Here is the result with bilinear interpolation:

One can clearly see the visual artifacts at the mesh boundaries (enhanced by Mach Banding). Switching to bicubic interpolation produces a smoother mesh as seen next:

The next step is to transform the gray levels into a color scale. For this I turned to SVG filters. I used a filter consisting of a single Component Transfer filter primitive. I created a table to map gray level to color by inverting the estimation I used to convert the colors into gray values. Here are the results for both bilinear and bicubic interpolation:

The match between these images (generated with Inkscape) and those in the Wikipedia article are pretty good.

Plea

Convincing the SVG working group to add meshes to SVG and then to adding the auto-smoothing option would not of been possible without attending the SVG working group meetings in person. It is much easier to lobby for things when one can provide live demonstrations. At these meetings I’ve been able to get auto-flowed text, text on a shape, font-features support, hatch fills, the arcs and clipped miter line joins, etc. into the SVG 2 specification. The Inkscape board has been allocating funds for my travel (thanks Inkscape donors!). To enable travel to future working group meetings, a designated fund for SVG specification work has been set up. The SVG working group holds about three face-to-face meetings each year (in addition to weekly teleconferences). If you are interested in supporting SVG development from an end-user perspective, please consider donating. More information on the work I’ve done as well a donations link can be found at the Inkscape website on the SVG Standards Work page. (Donations are tax deductible in the US.)

January 09, 2016 10:16 PM

div.figure { padding: 5px; margin-bottom: 20px; text-align: center; background: #cccccc; } div.figure img { } div.figure p { font-size: 10px; } The SVG Working Group had a four day face-to-face meeting in Sydney this month. The first day was a joint meeting with the CSS Working Group. I would like to thank the Inkscape board for allocating the funds for this trip as well as all the Inkscape donors that made it possible. This was an expensive trip as I was traveling from Paris and Sydney is an expensive city… but I think it was well worth it as the SVG WG (and CSS WG, where appropriate) approved all of my proposals and worked through all of the issues I raised. Unfortunately, due to the high cost of this trip, I have exhausted the budgeted funding from Inkscape for SVG WG travel this year and will probably miss the two other planned meetings, one in Sweden in June and one in Japan in October. We target the Sweden meeting for moving the SVG 2 specification from Working Draft to Candidate Recommendation so it would be especially good to be there. If anyone has ideas for alternative funding, please let me know. Highlights:

• CSS will support color palettes for OpenType SVG fonts.
• Publishing Shapes Level 2 (needed for SVG 2 auto-wrapped text in a shape) as a Working Draft approved.
• New clipped miter line-join approved.
• Using ‘z’ to auto-close curved paths approved.
• Text on a shape approved (extension of text on a path).
• Option to auto-smooth mesh gradients approved.

A summary of selected topics, grouped by day, follows:

Joint CSS and SVG Meeting

Minutes

• SVG sizing in HTML.

  We spent some time discussing how SVG should be sized in HTML. For corner cases, the browsers disagree on how large an SVG should be displayed. There is going to be a lot work required to get this nailed down.

• CSS Filter Effects:

  We spent a lot of time going through and resolving the remaining issues in the CSS Filter Effects specification. (This is basically SVG 1.1 filters repackaged for use by HTML with some extra syntax sugar coating.) We then agreed to publish the specification as a Candidate Recommendation.

• CSS Blending:

  We discussed publishing the CSS Blending specification as a Recommendation, the final step in creating a specification. I raised a point that most of the tests assumed HTML content. It was requested that more SVG specific test be created. (Part of the requirement for Recommendation status is that there be a test suite and that two independently developed renderers pass each test in the suite.)

• SVG in OpenType, Color Palettes:

  The new OpenType specification allows for multi-colored SVG glyphs. It would be nice to set those colors through CSS. We discussed several methods for doing so and decided on one method. It will be added to the CSS Fonts Level 4 specification.

• Text Rendering:

  The ‘text-rendering‘ property gives renderers a hint on what speed/precision trade-offs should be made. It was pointed out that the layout of text flowed into a box will change as one zooms in and out on a page in Firefox due to font-hinting, font-size rounding, etc. The Google docs people would like to prevent this. It was decided that the ‘geometricPrecision’ value should require that font-metrics and text-measurement be independent of device resolution and zoom level. (Note: this property is defined in SVG but both Firefox and Chrome support it on HTML content.)

• Text Properties:

  Text in SVG 2 relies heavily on CSS specifications that are in various states of readiness. I asked the CSS/SVG groups what is the policy for referencing these specs. In particular, SVG 2 needs to reference the CSS Shapes Level 2 specification in order to implement text wrapping inside of SVG shapes. The CSS WG agreed to publish CSS Shapes Level 2 as a Working Draft so we can reference it. We also discussed various technical issues in defining how text wraps around excluded areas and in flowing text into more than one shape.

SVG Day 1

Minutes

• CamelCase Names

  The SVG WG decided some time ago to avoid new CamelCase names like ‘LinearGradient’ which cause problems with integration in HTML (HTML is case insensitive and CamelCase SVG names must be added by hand to HTML parsers). We went through the list of new CamelCase names in SVG 2 and decided which ones could be changed, weighing arguments for consistency against the desire to not introduce new CamelCase names. It was decided that <meshGradient> should be changed to <mesh>. This was mostly motivated by the ability to use a mesh as a standalone entity (and not only as a paint server). Other changes include: <hatchPath> to <hatchpath>, <solidColor> to <solidcolor>, …

• Requiring <foreignObject> HTML to be rendered.

  There was a proposal to require any HTML content in a <foreignObject> element to be rendered. I pointed out that not all SVG renderers are HTML renderers (Inkscape as an example). It was decided to have separate conformance classes, one requiring HTML content to be rendered and one not.

• Requiring Style Sheets Support:

  It was decided to require style sheet support. We discussed what kind of style sheets to require. We decided to require basic style sheet support at the CSS 1 or CSS 2.1 level (that part of the discussion was not minuted).

• Open Issues:

  We spent considerable time going through the specification chapter by chapter looking at open issues that would block publishing the specification as a Candidate Recommendation. This was a long multi-day process.

SVG Day 2

Minutes

Note: Day 2 and Day 3 minutes are merged.

• Superpaths:

  Superpaths is the name for the ability to reuse path segment data. This is useful, for example, to define the boundary between two shapes just once, reusing the path segment for both shapes. SVG renderers might be able to exploit this information to provide better anti-aliasing between two shapes knowing they share a common border. The SVG WG endorses this proposal but it probably won’t be ready in time for SVG 2. Instead, it will be developed in a separate Path enhancement module.

• Line-Join: Miter Clipped:

  It was proposed on the SVG mailing list that there be a new behavior for the miter ‘line-join’ value in regards to the ‘miter-limit’ property. At the moment, if a miter produces a line cap that extends farther than the ‘miter-limit’ value then the miter type is changed to bevel. This causes abrupt jumps when the angle between the joined lines changes such that the miter length crosses over the ‘miter-limit’ value (see demo). A better solution is to clip the line join at the ‘miter-limit’. This is done by some rendering libraries including the one used on Windows. We decided to create a new value for ‘line-join’ with this behavior.

• Auto-Path Closing:

  The ‘z’ path command closes paths by drawing a line segment to the first point in the path. This is fine if the path is made up of straight lines but becomes problematic if the path is made up of curves. For example, it can cause rendering problems for markers as there will be an extra line segment between the start and end of the path. If the last point is exactly on top of the first point, one can remove this closing line segment but this isn’t always possible, especially if one is using the relative path commands with rounding errors. A more detailed discussion can be found here. We decided to allow a ‘z’ command to fill in missing point data using the first point in the path. For example in: d=”m 100,125 c 0,-75 100,-75 100,0 c 0,75 -100,75 z” the missing point of the second Bezier curve is filled in by the first point in the path.

• Text on a Shape:

  An Inkscape developer has been working on putting text on a shape by converting shapes to paths while storing the original shape in the <defs> section. It would be much easier if SVG just allowed text on a shape. I proposed that we include this in SVG 2. This is actually quite easy to specify as we have already defined how shapes are converted to paths (needed by markers on shapes and putting dash patterns on shapes). A couple minor points needed to be decided: Do we allow negative path offsets? (Yes) How do we decide which side of a path the text should be put? (A new attribute) The SVG WG approved adding text on a shape to SVG 2.

• Marker knockouts, mid-markers, etc:

  A number of new marker features still need some work. To facilitate finishing SVG 2 we decided to move them to a separate specification. There is some hesitation to do so as there is fear that once removed from the main SVG specification they will be forgotten about. This will be a trial of how well separating parts of SVG 2 into separates specifications works. The marker knockout feature, very useful for arrowheads is one feature moved into the new specification. On day 3 we approved publishing the new Markers Level 1 specification as a First Public Working Draft.

• Text properties:

  With our new reliance on CSS for text layout, just what CSS properties should SVG 2 support? We don’t want to necessarily list them all in the SVG 2 specification as the list could change as CSS adds new properties. We decided that we should support all paragraph level properties (‘text-indent’, ‘text-justification’, etc.). We’ll ask the CSS working group to create a definition for CSS paragraph properties that we can then reference.

• Text ‘dx’, ‘dy’, and ‘rotate’ attributes:

  SVG 1.1 has the properties ‘dx’, ‘dy’, and ‘rotate’ attributes that allow individual glyphs to be shifted and rotated. While not difficult to support on auto-wrapped text (they would be applied after CSS text layout), we decided that they weren’t really needed. They can still be used on SVG 1.1 style text (which is still part of SVG 2).

SVG Day 3

Minutes

Note: Day 3 minutes are at end of Day 2 minutes.

• Stroking Enhancements:

  As part of trying to push SVG 2 quickly, we decided to move some of the stroking enhancements that still need work into a separate specification. This includes better dashing algorithms (such as controlling dash position at intersections) and variable width strokes. We agreed to the publication of SVG Strokes as a First Public Working Draft.

• Smoothing in Mesh Gradients:

  Coons-Patch mesh gradients have one problem: the color profile at the boundary between patches is not always smooth. This leads to visible artifacts which are enhanced by Mach Banding. I’ve discussed this in more detail here. I proposed to the SVG WG that we include the option of auto-smoothing meshes using monotonic-bicubic interpolation. (There is an experimental implementation in Inkscape trunk which I demonstrated to the group.) The SVG WG accepted my proposal.

• Motion Path:

  SVG has the ability to animate a graphical object along a path. This ability is desired for HTML. The SVG and CSS working groups have produced a new specification, Motion Path Module Level 1, for this purpose. We agreed to publish the specification as a First Public Working Draft

.

January 09, 2016 10:08 PM

Inkscape, being an open source project, saves its files in an open, standardized, highly compatible file format called SVG (Scalable Vector Graphics) to ensure that your art and other work can be displayed and edited using any program that supports this standard. This way, your work won't be lost, even if you don't have access to Inkscape anymore, and you can use files created with Inkscape directly on your website, because your web browser manufacturer also has access to and makes use of the SVG standard.

One of our developers, Tavmjong Bah, is Inkscape's representative in the W3C (World Wide Web Consortium) SVG Working Group, which creates the SVG standard. His goal is to improve the standard and to ensure that Inkscape's voice is heard.

Aside from weekly teleconferences, several times a year, Tavmjong needs to meet up with the Working Group in person, so important decisions can be made. But travelling is costly - and this is where you can help us!

More information and an account of what has already been achieved for Inkscape, its users and the web as a whole is available here.

December 27, 2015 09:06 PM

Here is another neat tutorial from Olga Bikmullina describing how to draw a cartoon style vector crown using Inkscape.In this tutorial, Olga first describes the how to create the basic shape of the crown, and how to get the view... Continue Reading →

November 29, 2015 08:50 AM

I’m excited to see other people thinking about userspace-to-kernel attack surface reduction ideas. Theo de Raadt recently published slides describing Pledge. This uses the same ideas that seccomp implements, but with less granularity. While seccomp works at the individual syscall level and in addition to killing processes, it allows for signaling, tracing, and errno spoofing. As de Raadt mentions, Pledge could be implemented with seccomp very easily: libseccomp would just categorize syscalls.

I don’t really understand the presentation’s mention of “Optional Security”, though. Pledge, like seccomp, is an opt-in feature. Nothing in the kernel refuses to run “unpledged” programs. I assume his point was that when it gets ubiquitously built into programs (like stack protector), it’s effectively not optional (which is alluded to later as “comprehensive applicability ~= mandatory mitigation”). Regardless, this sensible (though optional) design gets me back to his slide on seccomp, which seems to have a number of misunderstandings:

• A Turing complete eBPF program watches your program Strictly speaking, seccomp is implemented using a subset of BPF, not eBPF. And since BPF (and eBPF) programs are guaranteed to halt, it makes seccomp filters not Turing complete.
• Who watches the watcher? I don’t even understand this. It’s in the kernel. The kernel watches your program. Just like always. If this is a question of BPF program verification, there is literally a program verifier that checks various properties of the BPF program.
• seccomp program is stored elsewhere This, with the next statement, is just totally misunderstood. Programs using seccomp define their program in their own code. It’s used the same way as the Pledge examples are shown doing.
• Easy to get desyncronized either program is updated As above, this just isn’t the case. The only place where this might be true is when using seccomp on programs that were not written natively with seccomp. In that case, yes, desync is possible. But that’s one of the advantages of seccomp’s design: a program launcher (like minijail or systemd) can declare a seccomp filter for a program that hasn’t yet been ported to use one natively.
• eBPF watcher has no real idea what the program under observation is doing… I don’t understand this statement. I don’t see how Pledge would “have a real idea” either: they’re both doing filtering. If we get AI out of our syscall filters, we’re in serious trouble. :)

OpenBSD has some interesting advantages in the syscall filtering department, especially around sockets. Right now, it’s hard for Linux syscall filtering to understand why a given socket is being used. Something like SOCK_DNS seems like it could be quite handy.

Another nice feature of Pledge is the path whitelist feature. As it’s still under development, I hope they expand this to include more things than just paths. Argument inspection is a weak point for seccomp, but under Linux, most of the arguments are ultimately exposed to the LSM layer. Last year I experimented with creating a “seccomp LSM” for path matching where programs could declare whitelists, similar to standard LSMs.

So, yes, Linux “could match this API on seccomp”. It’d just take some extensions to libseccomp to implement pledge(), as I described at the top. With OpenBSD doing a bunch of analysis work on common programs, it’d be excellent to see this usable on Linux too. So far on Linux, only a few programs (e.g. Chrome, vsftpd) have bothered to do this using seccomp, and it could be argued that this is ultimately due to how fine grained it is.

© 2015, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

November 11, 2015 06:01 PM

The Software Freedom Conservancy (SFC), a not-for-profit organization founded to promote, improve, develop, and defend Free, Libre, and Open Source Software (FLOSS) projects, has been providing an organizational backing to manage Inkscape's funds and other assets since 2006. The lawyers and experienced developers from the SFC have given the project their invaluable support, helping us devise a trademark policy, registering our trademarks, defending Inkscape's free software licence, managing our finances, and being the go-to place for our Board and developers for all legal and financial matters.

To clarify project procedures and account for SFC's continued commitment to our project, a new Fiscal Sponsorship Agreement has been devised and adopted. The main changes consist of the document now accounting for the fact that the SFC is holding Inkscape's trademark rights, to clarify how Inkscape Board elections work, when the Inkscape Board can be considered quorate and what should be done when a board member is unresponsive for a longer period of time. Inkscape now also supports the SFC's work by donating 10% of our income to them.

The Inkscape project is looking forward to continue our good collaboration with the Software Freedom Conservancy, and is happy to be a part of the member list of the organization. The new FSA document can be found on our website.

November 08, 2015 08:10 PM

Corebird 1.1 was recently released and it is now available in the official Fedora repos.

Major changes that this new version of corebird includes are:

• The behavior in corebird on how tweets get hidden and shown is now more consistent.
• Corebird now provides snippets that you are used to insert common phrases or emoticons. Simply type the keyword for the snippet, and press tab to autocomplete. Settings for adding and configuring snippets is found in the application settings in the “Snippets” tab.
• Corebird now supports showing Twitter quote tweets in timelines as well as creating quote tweets. This replaces the old “Quote” item for tweets which would simply copy the original tweet’s text.
• Twitter removed the 140 char limit on Direct Messages, so this limit is also removed in Corebird

Update via the Software application in Fedora, or on the command line with yum or dnf.

October 21, 2015 04:43 AM

Creating and editing PDFs in Inkscape is pretty simple. This quick tip will cover the basics of saving your Inkscape SVG to a PDF, as well as using Inkscape’s PDF import functionality. Saving to PDF Once you have your document... Continue Reading →

September 19, 2015 05:00 AM

The developers of the Inkscape project (everyone who is listed in Inkscape's 'AUTHORS' file) have been invited to cast their vote in the Inkscape Board Elections.

These had become necessary because two valued board members had resigned this spring for personal reasons, leaving two empty seats on the Board.

Seven active contributors have been nominated by other project members, and four of them accepted candidacy. Preceding the voting period, these four patiently answered questions about how to leverage their position on the Inkscape Board to further the growth of the Inkscape community. If you would like to read the questions and the candidate's replies, you can do so here and here.

The election period started on August, 27th and ended on September 10th. The election mode was the 'Single Transferable Vote' system, which is also used by several other Free Software projects, as well as for political elections in several countries of the world.

The platform for the election was kindly created and hosted by the Software Freedom Conservancy. It is based on the GNOME Elections software. The source code for the web service is available here.

Krzysztof Kosiński and Martin Owens gathered the most votes, and are now the Inkscape project's newest Board members.

We would like to thank everyone involved in the elections, be it by voting, making a nomination, organizing the election, helping with the voting platform, asking questions or volunteering as a candidate, and we wish Krzysztof and Martin all the best for their new tasks!

September 17, 2015 10:14 AM

div.figure { padding: 5px; margin-bottom: 20px; text-align: center; background: #cccccc; } div.figure img { } div.figure p { font-size: 14px; } pre { font-size: 14px; } ol.circled { list-style: symbols("\2776" "\2777" "\2778" "\2779" "\277A" "\277B" ); font-family: "Inconsolata"; font-size: 14px; }

Part 1 introduces SVG filter primitives and demonstrates the creation of a Fabric filter effect. Part 2 shows various ways to colorize the fabric.

Introduction

SVG filters allow bitmap-type manipulations inside a vector format. Scalability is preserved by pushing the bitmap processing to the SVG renderer at the point when the final screen resolution is known. SVG filters are very powerful, so powerful in fact that they have been moved out of SVG and into a separate CSS specification so that they can also be applied to HTML content. This power comes with a price: SVG filters can be difficult to construct. For example, a simple drop shadow filter consists of three connected filter primitives as shown in this SVG code:

<filter id="DropShadow">
  <feOffset in="SourceAlpha" dx="2" dy="2" result="offset"/>  ❶
  <feGaussianBlur in="offset" stdDeviation="2" result="blur"/>  ❷
  <feBlend in="SourceGraphic" in2="blur" mode="normal"/>  ❸
 </filter>

1. Offset filter primtive: Create an image using the text alpha (SourceAlpha) and shift it down and right two pixels. Results in shifted black text.
2. Gaussian Blur filter primitive: Blur result of previous step (“offset”).
3. Blend filter primtive: Render the original image (SourceGraphic) over the result of the previous step (“blur”).

Inkscape contains a Filter Dialog that can be used to construct filters. Here is the dialog showing the above drop-shadow filter effect:

There can be more than one way to construct the same filter effect. For example, the order of the offset and blur primitives can be swapped without changing the result:

Inkscape contains over 200 canned filters effects, many of which have adjustable parameters. But sometimes none of them will do exactly what you want. In that case you can construct your own filter effect. It’s not as hard as it first seems once you understand some of the basic filter primitives.

A Fabric Filter

This tutorial creates a basic filter that can be applied to a pattern to create realistic fabric. It will introduce several very useful filter primitives that are fundamental to most of Inkscape’s canned filter effects.

Creating a Pattern

To begin with, we need a pattern that is the basis of the weave of the fabric. I’ve constructed a simple pattern consisting of four rectangles, two for the horizontal threads and two for the vertical threads. I’ve applied a linear gradient to give them a 3D look. One can certainly do better but as the pattern tile is quite small, one need not go overboard. Once you have drawn all the pattern parts, select them and then use Objects->Pattern to convert to a pattern. The new pattern will then be available in the Pattern drop-down menu that appears when the Pattern icon is highlighted on the Fill tab of the Fill and Stroke dialog.

Next, apply the fabric pattern to the an object to create simple fabric.

Adding Blur

The pattern looks like a brick wall. It’s too harsh for fabric. We can soften the edges by applying a little blur. This is done through the Gaussian Blur filter primitive. Open the Filter Editor dialog (Filters->Filter Editor). Click on the New button to create a new, empty filter. A new filter with the name “filter1″ should be created. You can double click on the name to give the filter a custom name. Apply the filter to the fabric piece by selecting the piece and then checking the box next to the filter name. Your piece of fabric will disappear; don’t worry. We need to add a filter primitive to get it to show back up. To add a blur filter primitive select Gaussian Blur in the drop-down menu next to Add Effect and then clicking the Add Effect button. The fabric should now be visible with the blur effect applied. You can change the amount of blur by using the slider next to Standard Deviation; a value of 0.5 seems to be about right.

Note how the input to the Gaussian Blur primitive (triangle next to “Gaussian Blur”) is linked (under Connections) to the Source Graphic.

Distorting the Threads

The pattern is still too rigid. The threads in real fabric are not so regular looking. We need to add some random distortions. To do so, we’ll link up two different filter primitives. The first filter primitive, Turbulence, will generate random noise. This noise will be used as an input to a Displacement Map filter primitive where pixels are shifted based on the value of the input.

The Turbulence Filter Primitive

Add a Turbulence filter primitive to the filter chain by selecting Turbulence from the drop-down menu next to Add Effect button, the click on the button. You should see a rectangle region filled with small random dots. There are a couple of things to note: The first is that the rectangle will be bigger than you initial object. This is normal. The filter region is enlarged by 10% on each side and the Turbulence filter fills this region. This is done on purpose as some filter primitives draw outside the object (e.g. the Gaussian Blur and Offset primitives). You can set the boundary of the filter region under the Filter General Settings tab. The default 10% works for most filters. You don’t want the region to be too large as it effects the time to render the filter. The second thing to note is that the Turbulence filter primitive has no inputs despite what is shown in the Filter Editor dialog.

There are a number of parameters to control the generation of the noise:

Type

There are two values: Turbulence and Fractal Noise. The difference between the two is somewhat technical so I won’t go into it here. (See the Turbulence Filter Primitive section in my guide book.)

Base Frequency

This parameter controls the granularity of the noise. The value roughly corresponds to the inverse of the length in pixels of the fluctuations. (Note that the default value of ‘0’ is a special case and doesn’t follow this rule.)

Octaves

The number of octaves used in creating the turbulence. For each additional octave, a new contribution is added to the turbulence with the frequency doubled and the contribution halved compared to the proceeding octave. It is usually not useful to use a value above three or four.

Seed

The seed for the pseudo-random number generator used to create the turbulence. Normally one doesn’t need to change this value.

One can guess that variations in the threads are about on the order of the distance between adjacent threads. For the pattern used here, the vertical threads are 6 pixels apart. This gives a base frequency of about 0.17 (i.e. 1/6). The value of Type should be changed to Fractal Noise. (Both Type values give good visual results but the Turbulence value leads to a shift of the image down and to the right for technical reasons.) Here is the resulting dialog:

And here is the resulting image:

The Displacement Map Filter Primitive

Now we need to add the Displacement Map filter primitive which will take both the output of the Gaussian Blur and the Turbulence filter primitives as inputs. Select Dispacement Map from the drop-down menu and then click on the Add Effect button. Note that both inputs to the Dispacement Map filter primitive are set to the last filter primitive in the filter chain. We’ll need to drag the top one to the Gaussian Blur filter primitive. (Start the drag in the little triangle at the right of the filter primitive in the list.) Again, the image doesn’t change. We’ll need to make one more change but first here are the parameters for the Displacement Map filter primitive:

Scale

The scale factor is used to determine how far pixels should be shifted. The magnitude of the shift is the value of the displacement map (on a scale of 0 to 1) multiplied by this value.

X displacment

Determines which component (red, green, blue, alpha) should be used from the input map to control the x displacement.

Y displacement

Determines which component (red, green, blue, alpha) should be used from the input map to control the y displacement.

For our purpose, any values of X displacement and Y displacement are equally valid as all channels contain the same type of pseudo-random noise. To actually see a shift, one must set a non-zero scale factor. A value of about six seems to give a good effect.

And here is the resulting image:

Distorting the Fabric

Fabric rarely lies flat unless stretched and even then it is hard to make the threads lie straight and parallel. We can add a random wave to the fabric by adding another Turbulence and Displacement Map pair, but this time using a lower Base Frequency. Repeat the instructions above to add the two filter primitives but this time connect the top input to the Displacement Map to the previous Displacement Map. Set the Base Frequency to a value of 0.01. Set the Type to Fractal Noise. Set the Scale to ten.

And here is the resulting image:

Of course, the pattern and filter can be applied to an arbitrary shape:

Conclusion

We have constructed a basic Fabric filter but there is plenty of room for improvement. In the next part we’ll look at ways to add color to the fabric.

---

September 16, 2015 01:19 PM

div.figure { padding: 5px; margin-bottom: 20px; text-align: center; background: #cccccc; } div.figure img { } div.figure p { font-size: 14px; } pre { font-size: 14px; } ol.circled { list-style: symbols("\2776" "\2777" "\2778" "\2779" "\277A" "\277B" ); font-family: "Inconsolata"; font-size: 14px; }

Part 1 introduced SVG filter primitives and demonstrated the creation of a Fabric filter effect. Part 2 shows various ways to colorize the fabric. It ends with an example of using the techniques learned here to draw part of a bag of coffee beans.

Dying the Fabric

Our fabric at this point is white. We can give it color a variety of ways. We could have started off with a colorized pattern but that would not allow us to change the color so easily. And as this is a tutorial on using filters, lets look at ways the color can be changed utilizing filter primitives.

Coloring with the Flood, Blend, and Composite Primitives

We can use the Flood filter primitive to create a sheet of solid color and then use the Blend filter primitive to combine it with the fabric. The resulting image bleeds into the background. We’ll use the Composite filter primitive to auto-clip the background.

The Flood Filter Primitive

Add the Flood filter primitive to the filter chain by selecting Flood and clicking on the Add Effect button. The fabric will turn a solid black. Like the Turbulence filter primitive, the Flood filter primitive takes no inputs but simply fills the filter region with a solid color Black is the default flood color. You can change the color by clicking on the color sample next to Flood Color: in the dialog. Change the color however you wish. Leave the Opacity at one.

The Blend Filter Primitive.

Next add the Blend filter primitive. The drawing will be unchanged. Connect the Blend input to the last Displacement Map. The fabric should appear on top of the flood fill. This is expected as the default blending mode is Normal which simply draws the second image over the first. Use the drop-down menu to change the Mode to Multiply. This results in the lighter areas of the fabric taking on the flood color.

Try experimenting with the other blending modes.

The Composite Filter Primitive

The flood fill leaks into the background. This can be removed by clipping the image to fabric area using the Composite filter primitive. Add the Composite filter primitive to the filter chain. The resulting image is again unchanged. Connect the second input to the composite filter to the last Displacement Map filter primitive. Still the image remains unchanged. Now change the Operator type to In. This dictates that the image should be clipped to the area that is “In” the image created by the second Displacement Map filter primitive.

Coloring the Fabric with the Component Transfer Filter Primitive

The Component Transfer filter primitive maps, pixel by pixel, the colors from an input image to different colors in an output image. Each “component” (Red, Green, Blue, and Alpha) is mapped independently. The method for mapping is determined by the Type; each Type has its own attributes. We’ll use the Linear and Identity mappings.

Identity

The output component has the same value as the input component.

Linear

The output component is equal to: intercept + input × slope. This is identical to the Identity type if the intercept is zero and the slope is one.

Replace the Flood Fill, Blend, and Composite filter primitives in the above filter chain by the Composite Transfer filter primitive. (To delete a filter primitive, right-click on the filter primitive name and select Delete in the menu that appears.) The just removed three-primitive filter chain mapped black to black and white to the flood color. We can duplicate this by setting the Red, Green, and Blue component transfer types to Linear (keeping the Alpha component type set to Identity). The condition that black maps to black requires that the Intercept values all be set to zero. The condition that white maps to the flood color dictates the slopes. The RGB values for the flood color used above are 205, 185, 107 on a scale where 255 is the maximum value. These values translate to 0.80, 0.73, 0.42 on a scale where the maximum value is one. Since an input value of 1.0 for the red component must result in a value of 0.80 we can see that these values are the required slopes.

Now suppose we want the fabric to be more subtle. We can change the mapping so that for each component, zero is mapped to half the maximum value. In this case we have the following values (RGB): Intercepts: 0.40, 0.36, 0.21 and Slopes: 0.40, 0.37, 0.21. See the following figure:

Coloring the Fabric with the Color Matrix Filter Primitive

This filter primitive, unlike the Component Transfer, can intermix the color components. It does not, however, have the fine control over the transfer curves like in the Component Transfer filter primitive. There are several Types in this filter primitive. The Saturate, Hue Rotate, and Luminous to Alpha types are shortcuts for the more generic Matrix type. We need to use the Matrix type to match the results of the previous filters.

First replace the Component Transfer filter primitive by the Color Matrix filter primitive. After adding the new primitive, the fabric may disappear; that is a bug in Inkscape. Click on the matrix in the Filter Dialog and the fabric should reappear. The initial matrix is the Identity matrix (consisting of ones on the diagonal) which does not change the image.

The rows in the matrix control the output of, from top to bottom, the Red, Green, Blue, and Alpha channels. The columns correspond to the input, again in the same Red, Green, Blue, and Alpha order. The last column allows one to enter a constant offset for the row. For example, one can make a green object red by changing the top row to “0 1 0 0 0″ which means that the Red channel output is 0×R + 1×G + 0×B + 0×A + 0, where R, G, B, and A are the input values for the Red, Green, Blue, and Alpha channels respectively (on a scale of zero to one).

To change the values in the matrix, click first on a row of numbers to select the row and then click on a numeric entry in the row. The following figures show the values needed to match the fabric samples above.

Coloring the Fabric Using the Fill Color and the Tile Filter Primitive

In an ideal world, a fabric filter would just take as input the color of an object and use that to blend with a pattern. SVG filters do have the ability to do this. One would read in a pattern tile using the Image filter primitive and then tile the pattern using the Tile filter primitive. But the Tile filter primitive is the one filter primitive that Inkscape hasn’t implemented. While more convenient, this method would still lack the fine control over color that the above methods have.

Putting it All Together

Let’s do something with the fabric! We could stencil some text on the fabric to make it look like part of a bag of coffee beans. The best way to do this is to break the filter up into two separate filters. The first will distort the weave (using the first Turbulence and Displacement Map pair and color the fabric while the second will add a gentle wave to both the fabric and text (using the second Turbulence and Displacement Map pair). The text is given its own filter to take away the sharp edges and to also give it a bit of irregularity independent of the weave. The text could be blended on top of the fabric by giving it an opacity of less than one. A better effect can be achieved, however, by using the new mix-blend-mode property. Inkscape can render this property but does not yet have a GUI to set it. Firefox supports this property and Chrome should soon (if it doesn’t already). I’ve used the mix-blend-mode value of multiply by adding the property to the text style attribute with the XML editor. The fabric and text are then grouped together before applying the “wave” filter to the group.

Note, it is possible to put the text in the “defs” section and use the Image filter primitive to import the text into a filter so that the blending can be done with the Blend filter primitive. This isn’t easy to do in Inkscape and Firefox seems to have problems rendering it.

I hope you enjoyed this tutorial. Please leave comments and questions!

---

September 16, 2015 12:54 PM

Ever needed to design a space ship for a game project or some other reason? Look no further than this two-part tutorial from the 2D art for game programmers blog. The first part of the tutorial focuses on designing the... Continue Reading →

September 16, 2015 09:51 AM

I helped print this statue of Edgar Allan Poe, through “We the Builders“, who coordinate large-scale crowd-sourced 3D print jobs:

You can see one of my parts here on top, with “-Kees” on the piece with the funky hair strand:

The MakerWare I run on Ubuntu works well. I wish they were correctly signing their repositories. Even if I use non-SSL to fetch their key, as their Ubuntu/Debian instructions recommend, it still doesn’t match the packages:

W: GPG error: http://downloads.makerbot.com trusty Release: The following signatures were invalid: BADSIG 3D019B838FB1487F MakerBot Industries dev team <[email protected]>

And it’s not just my APT configuration:

$ wget http://downloads.makerbot.com/makerware/ubuntu/dists/trusty/Release.gpg
$ wget http://downloads.makerbot.com/makerware/ubuntu/dists/trusty/Release
$ gpg --verify Release.gpg Release
gpg: Signature made Wed 11 Mar 2015 12:43:07 PM PDT using RSA key ID 8FB1487F
gpg: requesting key 8FB1487F from hkp server pgp.mit.edu
gpg: key 8FB1487F: public key "MakerBot Industries LLC (Software development team) <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: BAD signature from "MakerBot Industries LLC (Software development team) <[email protected]>"
$ grep ^Date Release
Date: Tue, 09 Jun 2015 19:41:02 UTC

Looks like they’re updating their Release file without updating the signature file. (The signature is from March, but the Release file is from June. Oops!)

© 2015, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

July 27, 2015 11:08 PM

div.figure { padding: 5px; margin-bottom: 20px; text-align: center; background: #cccccc; } div.figure img { } div.figure p { font-size: 10px; } I’ve just landed basic font features support in the development version of Inkscape. What are font features and why should you be excited? (And maybe why should you not be too excited.)

Font Features

Font features support allows one to enable (or disable) the OpenType tables within a given font, allowing you to select alternative glyphs for rendering text. The new CSS Fonts Module Level 3 adds a variety of CSS properties for defining which OpenType tables to enable/disable (as well as having nice examples of each property’s use — this is one of the more readable W3C specifications). Inkscape trunk supports the ‘font-variants-liguatures’, ‘font-variant-caps’, ‘font-variant-numeric’, ‘font-variant-position’, and ‘font-feature-settings’ properties. The properties can be set under the Variants tab in the Text and Font dialog.

Why you shouldn’t be too excited

Being able to enable various font features within a font is quite exciting but there are quite a few caveats at the moment:

• One must use a trunk build of Inkscape linked with the latest unstable version of Pango (1.37.1 or greater).
• Font feature support in fonts is usually minimal and often buggy. It’s hard to know what OpenType tables are available in which fonts.
• Browser support is sparse. Firefox has rather good support. Chrome support seems limited to ligatures.
• Correct display of alternative glyphs requires that the same font as used in content creation is used for rendering. On the Web the best way to do this is to use WOFF but Inkscape has no support for using User fonts (this is a future goal of Inkscape but will require considerable work).

Thanks

I would like to thank: Behdad Esfahbod, maintainer of Pango for adding the code to Pango to make accessing the OpenType tables possible. Thanks as well to Matthias Clasen and Akira Togoh who are the source of the patch to Pango. Thanks also to all the people that supported the Inkscape Hackfest in Toronto where I was able to meet and discuss Pango issues with Behdad in person and also where the idea of adding font feature support to Inkscape germinated.

June 23, 2015 11:55 AM

Thanks to the generosity of those who have contributed to the Inkscape Fund, seven Inkscape developers pioneered the very first Inkscape Hackfest, during the last week in April. This was an opportunity for them to meet each other in person, in some cases for the first time, for 3 days of intense code-writing (hacking) and decision-making about the future of Inkscape.

Hacking tasks included work on older, existing code (such as fixing some bugs) as well as the creation of new code. Parts of the code that have to do with geometric calculations were updated to current standards, and some of that work will help make the path operations more precise. Some new code was written that will improve how Inkscape is packaged. ("Packaging" is getting the Inkscape source code ready to work on the three different operating systems which Inkscape supports - Linux, Windows and OS X.) It will allow developers to build and test new versions faster.

As a result of these discussions, the Roadmap was agreed upon, and extended through version 1.0 and even a little beyond. (The Roadmap is just a guide which developers make, to keep work progressing in the best way possible. It's like the developers' "to do" list, but it's not "set in stone" and does change over time.) Decisions were made about the best development tools, programming language features, and software libraries (certain sets of code which perform particular tasks) to use, which together will result in more reliable software and faster bug fixes, as well as improved support for the OS X operating system.

Considering the bounty of new code and de-bugged or fixed code that was hacked, along with a slew of important topics that were discussed, and together with the work that has been completed since it ended, it seems the first Inkscape Hackfest was a resounding success! Timed to coincide with the start of the annual Libre Graphics Meeting, attendees were able to also meet and confer with programmers and developers of other free and open source projects, (such as GIMP, Blender, Scribus, and Pango) for the next four days following Inkscape Hackfest. (This is one of the benefits of the Open Source development paradigm -- sharing of ideas, resources, and even some code, with other open source projects.)

That collaboration resulted in more new decisions, and code as well. A commitment was made to improve Inkscape's accessibility. New code was written, which is already included in the upcoming new version, and which makes it possible for screen readers to read text, even if the text was converted to paths. And work has been started on supporting multi-language files for internet use (which helps the website run more efficiently).

June 17, 2015 06:53 PM

div.figure { padding: 5px; margin-bottom: 20px; text-align: center; background: #cccccc; } div.figure img { } div.figure p { font-size: 10px; } Google has recently announced their intention to drop SMIL support in Blink, the rendering engine for Chrome. SMIL is a way to animate SVG’s in a declarative way. Google’s argument is that SMIL animation has not become hugely popular and that Web Animations will provide the same functionality. As a result of this announcement, the SVG working group decided to move SMIL from SVG 2 and into its own specification. One could say that SMIL is on life support at the moment. SMIL’s lack of use is most likely due to its lack of support in IE. Microsoft has declared they will not implement SMIL in IE but they have hinted in the past that they are open to a native JS implementation built on top of Web Animations. So why would losing SMIL be a great loss?

1. SMIL declarative animations are easier to write compared to JavaScript or CSS/Web Animations.
2. SMIL animations are in general more performant.
3. With SMIL animations one can independently animate different attributes and properties.
4. JavaScript is not allowed to run inside SVGs in many situations due to security issues so it is not a viable alternative in many cases.
5. Web Animations don’t replace all the functionality of SMIL. For example, one cannot animate attributes including paths. In particular you won’t be able to do this:

Ironically, YouTube is planning on using SMIL to animate buttons. 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. (For more on animating paths, see my blog post on path animations.) You can read about Google’s intention and the debate that is going at the chromium.org Google group. If you use SMIL or plan to, let Google know that it is important to you.

---

A figure just to have a nice image in Google+ (which doesn’t do SVG… another reason to frown):

May 22, 2015 11:20 AM

Learn how to use basic shapes and manipulate them to illustrate the rings around the planet Saturn

April 29, 2015 10:11 AM

Between April 26th and 28th, Inkscape developers meet in Toronto for a hackfest to work on features and bugs and make technical decisions to move the project forward.

The issues addressed include 2Geom sync (Krzysztof), better GTK3 compatibility and work on the screen flickering issue (Alex), and reviewing and merging patches. We looked at some potential upstream Cairo work for projective transformation and path effects like Gaussian blur. We are also discussing and deliberating the testing framework and build system to use in the future, and how to incorporate SVG 2 and C++-11 features with an eye to preserving backwards compatibility. We're solidifying roadmap plans, and in particular starting work on a 0.91.1 bugfix release, and kicking off a new 0.92 release.

April 28, 2015 03:34 PM

div.figure { padding: 5px; margin-bottom: 20px; text-align: center; background: #cccccc; } div.figure img { width: 80%; } div.figure p { font-size: 10px; } Path stroking and offsetting are two intertwined topics; stroking is often implemented by path offsetting. This post explores some of the problems encountered with these path operations.

Stroking: It’s not as easy as it looks.

What could be easier that stroking a path? It’s a fundamental concept in all graphics libraries. You construct a path: in PostScript:

newpath
100 100 moveto
150 100 lineto
10 setlinewidth
stroke

in SVG:

<path d="M 100,100 150,100" stroke-width="10"/>

and voila, you have a horizontal path, 50 pixels long, that is 10 pixels wide. Hmm, if only it were that easy. It turns out that stroking an arbitrary path can be quite complicated. Different graphics libraries can give quite different results. There are two different ways to stroke a path. The first method is to pass a line segment of length ‘stroke-width’, centered on and perpendicular to the path, from one end to the other. Any pixels the line crosses are part of the stroke. This seems to be what Firefox does. (An equivalent method is to pass a circle of diameter ‘stroke-width’ centered on the path and then clip the semi-circles at the ends.) The second method is to construct two paths, offset by half the ‘stroke-width’ on each side of the original path and then fill the area between the two paths. This seems to be what Chrome does. Rendering engines appear to fall into one of these two camps:

Sweep a line:

Firefox, Adobe Reader

Offset paths:

Chrome, Inkscape (Cairo), Opera (Presto), Evince, Batik, rsvg

The difference can be also be seen in circular paths. When using the Offset paths method, an inner path is always created. As the direction of this path is the same regardless of the stroke width, one cannot differentiate between the case where the stroke width is less than one-half the radius and the case where it is not. This can be seen in the animation below: Interestingly, some renderers draw a filled circle when one-half the ‘stroke-width’ is greater than the radius for an SVG <circle> (i.e. not a circular <path>) while others still draw a doughnut. However, for the SVG <rect> element, the rectangles are always drawn filled if the ‘stroke-width’ is greater than either the ‘width’ or ‘height’ (at least in the renderers I tested). So what does the SVG specification say about how to stroke a path? Nothing…! One can look to PostScript and PDF on which SVG is partially based for a hint on what it should say. The PostScript and PDF specifications say the same thing. From the PDF 1.7 reference:

The S operator paints a line along the current path. The stroked line follows each straight or curved segment in the path, centered on the segment with sides parallel to it. Each of the path’s subpaths is treated separately…

This seems to indicate that the sweeping the line technique is what is expected and indeed, Adobe’s own product, Adobe Reader, appears to do just that.

Stroke Alignment

Designers often want more control over how a stroke is positioned: only on the inside, only on the outside, or some arbitrary ratio of the two. The new SVG ‘stroke-alignment‘ property offers this control. For a closed path, it is relatively easy to figure out how this property should behave: For an open path, it is not quite so easy. What is inside, what is outside? One can define the terms by looking at what is filled: inside is in the fill, outside is not in the fill. With this definition, a single straight line segment would render nothing for an ‘inside’ stroke and a stroke on both sides for an ‘outside’ stroke. The SVG specification has a slightly different definition for ‘outside’ (see figure). For an open path it may make more sense to talk about left/right rather than inside/outside. Handling line joins is fairly straight forward. End caps, at least ’round’ ones, are another matter. Does one draw half an end cap? Or does the radius of the end cap match the width of the (shifted) stroke? The ‘stroke-alignment’ property was recently removed from the SVG 2 specification draft and moved into a separate SVG Strokes module, partly due to the difficulty in specifying exactly how it should behave. The ‘stroke-alignment’ ‘inside’/’outside’ values can be simulated via other methods. The new ‘paint-order‘ property allows one to paint the stroke before the fill and thus simulating stroking only the outside of the path (this only works for opaque fill). A mask can also be used to simulate stroking the outside of path. A clip path can be used to simulate stroking the inside of a path.

Offset Paths

We’ve seen that offsetting a path can be used for constructing strokes. What about offsetting a path for the purpose of creating a new path? This is quite useful in mapping. For example you might want to show multiple bus routes going along a road with different offsets for each route. More stylistically, you could produce the shadowing seen around land masses in older, hand-drawn maps. Offsetting paths is in practice extremely tricky! Here are a few of the problems:

1. Offsets of Bezier segments are not Beziers; in fact they are 10^th-order polynomials. In practice, one can do a pretty good job of estimating the offset by breaking up a Bezier path into smaller segments.
2. Offset paths can have loops at cusps.
3. Offset paths may require breaking apart left and right offset paths and recombining to form outset and inset paths. It can be difficult to get this right.

Entire scientific papers are written on this topic.[1] Here is a simple example path with offsets both inside and outside: In this case, the outsets correspond to the outer edge of a stroked path with appropriate width when the ‘stroke-linejoin’ type is ’round’. The insets correspond to the inner edge of such strokes. Taking a closer look at the offset paths shows a number of cusp loops: Determining what is outset or inset becomes more difficult as a path loops back on itself. Both the outset and inset paths can consist of parts of both the right-offset and left-offset paths as shown below: Here’s an example where Inkscape’s Linked Offset function gets it wrong: The previous examples assumed that the line joins for outside joins are rounded. It would be desirable to be able to specify the type of join to use. This can maintain the feel of the original path. Allowing more freedom to define stroke position and being able to offset strokes are highly desirable features for designers, but as this post shows, they are not so simple to implement. Before we can add such features to SVG, we need to define robust algorithms for generating proper offset paths.

References

1. An offset algorithm for polyline curves Xu-Zheng Liu, Jun-Hai Yong, Guo-Qin Zheng, Jia-Guang Sun.

An image for the sole purpose of having a good PNG image to show in Google+ which doesn’t support SVG images, bad Google+.

April 13, 2015 12:30 PM

This April, developers of Inkscape are meeting up to hold a hackfest, where they will spend 3 solid days planning for the future of Inkscape, fixing bugs, and adding new features to Inkscape. How can you help? Donate to help... Continue Reading →

February 27, 2015 08:00 PM

Our volunteer Inkscape developers are spread across the globe and rarely have the chance to meet face-to-face. Thanks to technology, we are able to work remotely on most things, but we've noticed that in-person meetings bring about stronger relationships, quicker solutions, and more creative results.

Being together in one room also allows us to work on things that are harder to do on-line: designing a new plugin/extension system, teaming up to squash particularly nasty bugs, authoring better user documentation, and planning where to take Inkscape development in the future.

We will be meeting at the end of April 2015, before the Libre Graphics Meeting in Toronto, for three days of intense work and discussion.

You can help us to improve Inkscape by donating to help cover travel, room, and board so our international volunteer developers can attend the hackfest in person.

Donate now

We are also looking for a local contact too. If you are an Inkscape enthusast in the Toronto area, please send a message to us.

February 25, 2015 11:05 PM

After a 6-month hiatus, I have finally gotten the GIMP 2.9.1 development builds working again for Fedora 21. These development builds are built from the upstream git master branch of what will be GIMP 2.10 when it is released.

Check out the COPR page for these builds for futher details on enabling and installing from this repo, but also note that this is an experimental repo of unstable software, so tread cautiously.

The one major feature that is of most interest is the ability to do image manipulations with 32bit float precision; which is possible in version 2.9.1 of GIMP via the power of GEGL.

 

February 24, 2015 08:11 PM

Corebird 0.9 was released a few months ago, and it is now finally available in the official Fedora repos. Check out my previous post for details on some of the new features in this update.

Update via the Software application in Fedora, or on the command line with yum or dnf.

 

 

February 06, 2015 09:33 PM

Here is a neat written tutorial (with a bonus video tutorial too) on creating a cartoony style scroll with Inkscape. The result of this tutorial would make a great image for your asset library or as a video game element.

February 04, 2015 04:18 AM

Now that Inkscape 0.91 is now released, I have done a bit of housecleaning and moved the Inkscape Development builds for Fedora into a new COPR called inkscape-devel.

The version numbers for these builds are a little different from what I have done in the past, and now are more in line with the upstream way of naming these builds. The development versions now have a version number of 0.91+devel. This may mean that you have to remove older versions of devel builds from the older repos I did before using these repos.

 

February 03, 2015 05:37 PM

One of the new features in Inkscape 0.91 is the new Trace Pixel Art feature that allows you to take a PNG or some other bitmap of pixel art and trace it neatly into vector objects. Inkscape 0.91 has only... Continue Reading →

February 03, 2015 07:53 AM

Learn how to create simple isometric blocks and create a scene. Here is workflow tutorial on creating a simple isometric block using inkscape, and then using that block to make a little landscape scene. AS with most of the tutorials... Continue Reading →

February 03, 2015 05:58 AM

So excited that the new version of Inkscape is now finally out! I have been using development versions of Inkscape 0.91 for over a year now, and it is packed full of useful new features and improvements.

The updated package for Fedora should be hitting the repos soon, but the builds are available in koji if you can’t wait and want to install directly from there. I also did a writeup about the release for Fedora Magazine outlining some of the features that I use on a daily basis in Inkscape 0.91.

 

 

January 30, 2015 10:49 PM

This is a little render I recently did of the GNOME Builder robot by Jimmac using the Blender Freestyle renderer.

January 30, 2015 07:35 PM

Earlier this week, the Inkscape upstream made the final tarballs available for the long-awaited new 0.91 version of Inkscape. This version has not been announced by upstream yet, but thanks to the awesome Fedora Inkscape package maintainer Limb, this version is now available for testing on Fedora 21. Please try it out, and give karma to the package in Bodhi.

This updated package is the next major release of Inkscape after the 0.49 version of Inkscape that was released several years ago.

This major update provides many additional features and enhancements as well as hundreds of bug fixes and stability improvements. A detailed list of the new features in this version of Inkscape is available in the upstream release notes

Some of the notable new features in Inscape 0.91 include:

• A new measurement tool that allows the artist to measure distances and angles in their drawing in realtime.
• Updates to the text tool including the ability to customise the unit of measurement for text size, and support for choosing font style variants in the text toolbar.
• The align and distribute dialog now features a new set of features that allow the user to exchange position of selected objects.
• A new “Select Same” that allows an artist to select objects that have the same properties as the currently selected object. For example, you could select an object that has a fill of blue. Then, using the new feature select all other objects in the drawing with a fill set to that same shade of blue.
• A new path effect, Power Stroke that allows you to easily create variable width strokes.
• The Gradient view in the fill and stroke dialog now displays a list of all the gradients in the document. The list displays the gradient, the gradient name, and number of uses of that gradient in the document.
• The new greyscale display mode that shows a preview of your drawing in greyscale.
• Improved rendering performance with the new Cairo-based renderer, and the addition of multi-threaded rendering of SVG filters
• A new feature in the node tool (targeted at type designers) that allows you to insert new nodes at the selected segments extreme values.

January 30, 2015 07:10 PM

Version 0.9 of Corebird is now in the updates-testing repo for Fedora 21 and Rawhide.

Please check it out, test and give karma!

This update makes this already awesome twitter client much better, with a bunch of updates, including:

• Mentions, hashtags and links now get highlighted directly in the dialog where tweets are composed.
• The avatar icon in the top left of the main Corebird window is now clickable. When clicked, every account configured in Corebird is displayed in a list, allowing a quicker way of switching accounts.
• The dark theme setting in the Corebird user preferences is now removed. If you previously set the dark theme, it will continue to work, but is not really a supported feature of corebird, so the theme may render strangely. It is also still possible to turn the dark theme on or off using the GNOME dconf editor.
• The arrow keys on the keyboard can now be used to navigate between images if a tweet has multiple images or videos attached.
• Avatars in tweets and profiles now show if the user is a Twitter verified account.
• Corebird now has a back button in the main window to easily navigate between panes.
• Many tweaks to the user interface, including better spacing of elements in the user interface, and updated icons.

January 30, 2015 03:47 PM

The Inkscape project just announced the availability of the next major version of Inkscape, version 0.91. It has been several years since the last major update of inkscape and version 0.91 comes packed with a bunch of new and exciting... Continue Reading →

January 30, 2015 07:21 AM

I had a mess of loyalty cards filling my wallet. It kind of looked like this:

They took up too much room, and I used them infrequently. The only thing of value on them are the barcodes they carry that identify my account with whatever organization they’re tied to. Other folks have talked about doing consolidation in various ways like just scanning images of the cards and printing them all together. There was a site where you typed in card details and they generated barcodes for you, too. I didn’t want to hand my identifiers to a third party, and image scanning wasn’t flexible enough. I wanted to actually have the raw numbers, so I ended up using barcode. I didn’t use the Debian nor Ubuntu package, though, since it lacked SVG support, which was added in the latest (cough March 2013) version.

I used the Android Barcode Scanner app, and just saved all the barcodes and their encoding details to a text file, noting which was which. For example:

Albertsons "035576322436","UPC_A"
Multnomah County Library "01237035218482","CODABAR"
Supportland "!0000005341632030145420","CODE_128"
...

I measured the barcode area, since some scanners can’t handle their expected barcodes being resized, (that’s another project: find out which CAN handle it), and then spat out SVG files. I compared the results to my actual cards, since some times encodings have different options (like dropping checksum characters, “-c” below):

barcode-svg -S -u in -g 1.5x0.5 -e upc-a      -b '035576322436' > albertsons.svg
barcode-svg -S -u in -g   2x0.5 -e codabar -c -b '01237035218482' > library.svg
barcode-svg -S -u cm -g 4.5x1   -e code128    -b '!0000005341632030145420' > supportland.svg
...

With Inkscape, I opened them all and organized them onto a wallet-card-sized area, printed it, and laminated it. Now my wallet is 7 cards lighter. More room for HID cards or other stuff:

© 2015, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

January 14, 2015 01:33 AM

div.figure { padding: 5px; margin-bottom: 20px; text-align: center; background: #cccccc; } div.figure img { } div.figure p { font-size: 10px; } This post got delayed due to work on ‘units’ for the 0.91 Inkscape release followed by the holidays. The SVG Working Group had a two day meeting in Santa Clara as part of TPAC (the yearly meeting of all W3C working groups) at the end of October. This is an occasion to meet in person with other groups who have some shared interests in your group’s work. I would like to thank the Inkscape board for partially funding my attendance and W3C for waiving the conference fee. Here are some highlights of the meeting:

Day 1, Morning

Minutes The morning session was divided into two parts: the first part was an SVG only meeting while the second part was a joint meeting with the Task Force for Accessibility.

• SVG blending when embedded via <img>:

  This is probably not a real interesting topic to readers of this blog other than it can give one a flavor of the types if discussions that go on inside the SVG working group. We spent considerable time debating if elements inside an SVG that are included into a web page by the HTML <img> tag should blend with elements outside the SVG (other than following the simple “painters model” where transparency is allowed). Recall that in SVG 2 (and CSS) it is possible to select blend modes using the ‘mix-blend-mode’ CSS property (see my blog post about blending). So the question becomes should objects like a rectangle (inside the SVG referenced by an <img> element) with a ‘mix-blend-mode’ value of say ‘screen’ blend with an image in the HTML page behind? We finally concluded that an author would expect an external SVG to be isolated and not blend with other objects in the HTML page.

• Accessibility:

  The Accessibility Task Force asked to meet with us to discuss accessibility issues in graphics. Work has begun on SVG2 Accessibility API Mappings. An example of how accessibility can work with graphics can be found in a Surfin’ Safari blog post.

Day 1, Afternoon

Minutes The afternoon session was a joint meeting with the CSS working group.

• Text Decoration

  CSS has expanded the possibilities of how text is decorated (underlines, over-lines, etc.) by adding three new properties in CSS Text Decorations Module Level 3. The new properties ‘text-decoration-line’ and ‘text-decoration-style’ are easy to adopt into SVG (and in fact are already read and rendered by Inkscape 0.91). The new property ‘text-decoration-color’ is more problematic. SVG has long supported separate ‘fill’ and ‘stroke’ properties on text which also applies to text decoration. By careful nesting of <tspan>’s one can have a different underline color from the text color. Furthermore, SVG allows various paints to be applied to the text decoration, like a gradent or pattern fill. The ‘text-decoration-color’ property allows the color of the text decoration to be set directly, without the need for nested <tspan>’s so it is a quite attractive idea but how to support the richness found in SVG?

  I proposed a number of solutions (see my presentation). The CSS group agreed that my favorite solution, that adding ‘text-decoration-fill’ and ‘text-decoration-stroke’ was the proper way to move forward. (BTW, the CSS working would like to eventually allow fill and stroke on HTML text.)

• Fitting Text in a Box

  We’ve had numerous requests for the ability to adjust the size of text to fit it inside a given box (note, this is not the same as wrapping text into a shape). SVG has the attribute ‘textLength’ which allows a renderer to adjust the spacing or glyph width to match text to a given length. It was intended to allow renderers to adjust the length of a given text string to account for differences in font metrics if a the specified font wasn’t available; it was never intended to be an overall solution to fitting text inside a box, in fact the SVG 2 spec currently warns against using it in this way. I received a proposal from another Inkscape developer on expanding ‘textLength’ to be more useful in fitting text in a box. It seems to me that finding a solution to this problem would be of more general interest than just for SVG so I added this topic to the SVG/CSS agenda. I prepared a presentation to provide a starting point for the discussion.

  We had quite a lengthy discussion. The consensus seemed to be that CSS could use a set of simple knobs to make small adjustments to text, mostly for the purpose of labels. This would satisfy most use cases. Large adjustments could (should?) be the domain of script libraries. It was decided to solicit more feedback from users.

• Image Rendering

  CSS Images 3 has co-opted the SVG ‘image-rendering‘ property and redefined in to specify what about an image is important to preserve when scaling as compared to a speed/accuracy trade off as in SVG 1.1. I prepared a short report on a couple of issues I found. The first is that the specification does not describe very well the meaning of the new ‘crisp-edges’ value. Tab Atkins, one of the spec’s authors has agreed to elaborate and add some figures to demonstrate what is intended. I found the Wikipedia section Pixel art scaling algorithms to be particularly enlightening on the subject.

  The second issue is that some browsers and Inkscape use the now deprecated ‘optimizeSpeed’ value to indicate that the nearest neighbor algorithm should be used for scaling. This is important when scaling line art. I asked, and Tab agreed, that ‘optimizeSpeed’ value should correspond to the new ‘pixelated’ value to not break existing content (and not ‘auto’ as is currently in the spec).

• Connectors

  I’ve been working on a connectors proposal for SVG. There is renewed interest as being able to show relationships between elements would greatly aid accessibility. We even had a brief meeting with the HTML working group where it was suggested that connectors (possibly without visual links) may be of interest to aid accessibility of HTML. One problem I’ve had is how to reference ports inside a <symbol> element. I asked the CSS group for suggestions (this is obviously not a styling issue but the CSS group members are experts at syntax). Tab Atkins suggested: url(#AndGate1) Out, Mid1, Mid2, url(#AndGate2) InA, where, for example, Out is the point defined inside the symbol with the ‘id’ AndGate1.

Day 2

Minutes The SVG working group met for entire day covering a real hodge-podge of topics, some not well minuted. Here are a few highlights:

• NVidia presentation.

  NVidia gave a quite impressive demonstration of their OpenGL extensions for rendering 2D vectors, (think SVG), showing an entire HTML web page from the New York Times being rotated and scaled in real time on their Tegra based Shield tablet with all the text rendered as vectors (they can render 700,000 paths per second). They are trying to get other vendors interested in the extensions but it doesn’t seem to be a high priority for them.

• CTM Calculations

  For mapping applications, a precision of greater than single precision is necessary for calculating the Current Transformation Matrix (CTM) due to rounding errors. It was proposed and accepted that SVG dictate that such calculations be done as double precision (as Inkscape already does). (Note: single precision is sufficient for actual rendering.)

• Going to Last Call Working Draft

  We discussed when we’ll get SVG 2 out the door. It is a very large specification with various parts in various stages of readiness. We decided to target the February face-to-face meeting in Sydney as the date we move to the next stage in the specification process… where no new features can be added and incomplete ones removed.

• HTML in SVG

  There has been a desire by some for quite awhile to allow HTML directly inside SVG (not wrapped by a <foriegnElement> tag). I personally am quite hesitant to see this happen. SVG as at the moment a nice stand-alone graphics specification that doesn’t necessarily have to be rendered in a Web browser. Incorporating HTML would threaten this.

• SVG in HTML

  This is the opposite of the previous topic, allowing SVG to be directly embedded in HTML without using a name space.

• Non-scaling Patterns

  Just as it often useful to have non-scaling stroke widths (especially for technical drawings), it would also be useful to have non-scaling patterns and hatches. We agreed that this should be added to the specification.

• Minimum Stroke Width

  It would be useful to have a minimum stroke-width so that certain strokes do not disappear when a drawing is scaled down. It was claimed that this will be handled by vector-effect but I don’t see how.

• SVG in Industry

  It was mentioned that Boeing is moving all their 787 docs to SVG so they can be viewed in browsers.

Unfortunately, we ran out of time before we could cover some of my other topics: stroke-miterlimit, text on a shape, and auto-path closing.

January 08, 2015 01:59 PM

Blender 2.73 was released today, and it contains an awesome new feature that allows you to export Blender Freestyle renders into SVG format that can be further edited in Inkscape. Blender is a free and open source 3D computer graphics... Continue Reading →

January 07, 2015 07:57 PM