text:
# Chapter 13: Painting: Filling, Stroking and Marker Symbols

## 13.1. Introduction

### 13.1.1. Definitions

fill
The operation of painting the interior of a shape or the interior of the character glyphs in a text string.
stroke
The operation of painting the outline of a shape or the outline of character glyphs in a text string.

Graphical elements that define a shape – path elements, basic shapes, and text content elements – are rendered by being filled, which is painting the interior of the object, and stroked, which is painting along the outline of the object. Filling and stroking are both painting operations. SVG 2 supports a number of different paints that the fill and stroke of a graphical element can be painted with:

• a single color,
• a pattern (vector or raster, possibly tiled),
• a hatch,
• other images as specified using CSS Image Value syntax [css3-images].

The paint to use for filling and stroking an element is specified using the fill and stroke properties. The following section describes the different values that can be used for these properties.

Other properties, such as fill-opacity and stroke-width, also have an effect on the way fill and stroke paint is applied to the canvas. The Fill properties and Stroke properties sections below describe these properties.

Some graphics elements – path elements and basic shapes – can also have marker symbols drawn at their vertices or at other positions along the path that they describe. The Markers section below describes how markers can be defined and used.

SVG 2 adds markers on shapes. Resolved at Tokyo F2F.

## 13.2. Specifying paint

SVG 2 Requirement: Add new paint values for referencing current fill paint, stroke paint, etc. We will add new paint values currentFillPaint, currentStrokePaint etc. to SVG 2 Among other things, to provide an easy way to match marker color to stroke color. Chris (ACTION-3094)
SVG 2 Addition: Allow multiple paints in fill and stroke. We will allow multiple paints in the fill and stroke properties in SVG 2. Useful for creating cross hatchings, putting a partially transparent pattern on top of a solid fill, etc. Tav (ACTION-3500) This was dropped for SVG 2, but will be added later in sync with CSS Fill and Stroke Level 3

The fill and stroke properties, defined below, are used to specify the paint used to render the interior of and the stroke around shapes and text. A paint specification describes a way of putting color values on to the canvas and is composed of one or more paint layers. Four types of paints within these paint layers are supported: solid colors, gradients, patterns, and hatches.

A <paint> value is defined as follows:

<paint> = none | child | child(<integer>) | <color> | <url> [none | currentColor | <color>]? | context-fill | context-stroke

With the possible values:

none
No paint is applied in this layer.
child
A reference to the last child paint server element of the element being painted.
child(n)
A reference to the nth child paint server element of the element being painted.
<url> [none | <color>]?
A URL reference to a paint server element, which is an element that defines a paint server: hatch, , , pattern, and , optionally followed by a fall-back value that is used if the paint server reference cannot be resolved.
<color>
A solid color paint.
context-fill
Use the paint value of fill from a context element.
context-stroke
Use the paint value of stroke from a context element.

The child keyword value references the last child paint server element and the child(n) function references the nth child paint server element (where the first has index 1). A value for n less than 1 is invalid and causes the entire property value to be invalid.

<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
<rect width="50" height="50" x="25" y="25" fill="child" stroke="grey">
<pattern viewBox="0 0 100 100" width="20%" height="20%">
<path d="M0,0 h40 L100,60 v40 z m 0,60 v40 h40 z" fill="red" />
</pattern>
<pattern viewBox="0 0 100 100" width="20%" height="20%">
<path d="M0,0 h40 L100,60 v40 z m 0,60 v40 h40 z" fill="grey" />
</pattern>
</rect>
</svg>

A <paint> allows a paint server reference, to be optionally followed by a <color> or the keyword none. When this optional value is given, the <color> value or the value none is a fallback value to use if the paint server reference in the layer is invalid (due to pointing to an element that does not exist or which is not a valid paint server).

Note that this is slightly different from CSS background syntax, where a background image and color specified in the final layer of a background value will result in both the image and color being rendered.

If a paint server reference in a <paint> is invalid, and no fall-back value is given, no paint is rendered for that layer.

This is changed from SVG 1.1 behavior where the document is in error if a paint server reference is invalid and there is no fallback color specified.

<rect width="100" height="100" fill="url(#MyHatch) powderblue">

For any <color> value, all color syntaxes defined in CSS Color Module Level 3 must be supported, including rgb(), rgba(), hsl(), hsla(), the extended color keywords and the currentColor value.

The context-fill and context-stroke values are a reference to the paint layers generated for the fill or stroke property, respectively, of the context element of the element being painted. The context element of an element is defined as follows:

• If the element is within a marker, and is being rendered as part of that marker due to being referenced via a marker property, then the context element is the element referencing that marker.
• If the element is within a sub-tree that is instantiated with a use element, then the context element is that use element.
• Otherwise, there is no context element.

If there is no context element and these keywords are used, then no paint is applied.

When the context paint layers include paint server references, then the coordinate space and the bounding box used to scale the paint server elements and content are those of the context element. In other words, any gradients and patterns referenced with these keywords should be continuous from the main shape to the markers, or from one element within a use-element shadow tree to another.

If the referenced value of fill or stroke is a context-fill and context-stroke value, then those contextual referencing is recursive.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
<style>
path {
fill: none;
stroke-width: 4px;
marker: url(#diamond);
}
</style>
<path d="M 10,50 v -20 h 40 v -20" stroke="red"/>
<path d="M 30,70 v -20 h 40 v -20" stroke="green"/>
<path d="M 50,90 v -20 h 40 v -20" stroke="blue"/>
<marker id="diamond" markerWidth="12" markerHeight="12" refX="6" refY="6"
markerUnits="userSpaceOnUse">
<circle cx="6" cy="6" r="3"
fill="white" stroke="context-stroke" stroke-width="2"/>
</marker>
</svg>

## 13.3. The effect of the ‘color’ property

See the CSS Color Module Level 3 specification for the definition of color. [css3-color]

The color property is used to provide a potential indirect value, currentColor, for the fill, stroke, solid-color, stop-color, flood-color and lighting-color properties. The property has no other effect on SVG elements.

The following example shows how the inherited value of the color property from an HTML document can be used to set the color of SVG text in an inline SVG fragment.

<!DOCTYPE html>
<style>
body { color: #468; font: 16px sans-serif }
svg { border: 1px solid #888; background-color: #eee }
</style>
<svg width="200" height="100">
<g fill="currentColor">
<text x="70" y="55" text-anchor="end">START</text>
<text x="130" y="55">STOP</text>
<path d="M 85,45 h 25 v -5 l 10,10 -10,10 v -5 h -25 z"/>
</g>
</svg>

The text and arrow in the SVG fragment are filled with the same color as the inherited color property.

## 13.4. Fill properties

### 13.4.1. Specifying fill paint: the ‘fill’ property

Name: fill black shapes and text content elements yes N/A visual as specified, but with values computed and values made absolute yes

The fill property paints the interior of the given graphical element. The area to be painted consists of any areas inside the outline of the shape. To determine the inside of the shape, all subpaths are considered, and the interior is determined according to the rules associated with the current value of the fill-rule property. The zero-width geometric outline of a shape is included in the area to be painted.

The fill operation fills open subpaths by performing the fill operation as if an additional "closepath" command were added to the path to connect the last point of the subpath with the first point of the subpath. Thus, fill operations apply to both open subpaths within path elements (i.e., subpaths without a closepath command) and polyline elements.

### 13.4.2. Winding rule: the ‘fill-rule’ property

Name: fill-rule nonzero | evenodd nonzero shapes and text content elements yes N/A visual as specified yes

The fill-rule property indicates the algorithm (or winding rule) which is to be used to determine what parts of the canvas are included inside the shape. For a simple, non-intersecting path, it is intuitively clear what region lies "inside"; however, for a more complex path, such as a path that intersects itself or where one subpath encloses another, the interpretation of "inside" is not so obvious.

The fill-rule property provides two options for how the inside of a shape is determined:

nonzero

This rule determines the "insideness" of a point on the canvas by drawing a ray from that point to infinity in any direction and then examining the places where a segment of the shape crosses the ray. Starting with a count of zero, add one each time a path segment crosses the ray from left to right and subtract one each time a path segment crosses the ray from right to left. After counting the crossings, if the result is zero then the point is outside the path. Otherwise, it is inside. The following drawing illustrates the nonzero rule:

evenodd

This rule determines the "insideness" of a point on the canvas by drawing a ray from that point to infinity in any direction and counting the number of path segments from the given shape that the ray crosses. If this number is odd, the point is inside; if even, the point is outside. The following drawing illustrates the evenodd rule:

The above descriptions do not specify what to do if a path segment coincides with or is tangent to the ray. Since any ray will do, one may simply choose a different ray that does not have such problem intersections.

### 13.4.3. Fill paint opacity: the ‘fill-opacity’ property

Name: fill-opacity | 1 shapes and text content elements yes N/A visual number clamped to the range [0, 1], or percentage yes

fill-opacity specifies the opacity of the painting operation used to paint the fill the current object. (See Painting shapes and text).

<number>
The opacity of the fill. Any values outside the range 0 (fully transparent) to 1 (fully opaque) must be clamped to this range.
<percentage>
The opacity of the fill expressed as a percentage of the range 0 to 1.

## 13.5. Stroke properties

SVG 2 Requirement: Support non-scaling stroke. SVG 2 will include non-scaling stroke. SVG 2 will have the ‘vector-effect’ property. To support strokes whose width does not change when zooming a page, as common for example in maps. Chris or Erik (no action) Note that this could be part of more generic non-scaling features.

In this section, we define a number of properties that allow the author to control different aspects of a stroke, including its paint, thickness, use of dashing, and joining and capping of path segments.

In all cases, all stroking properties which are affected by directionality, such as those having to do with dash patterns, must be rendered such that the stroke operation starts at the same point at which the graphics element starts. In particular, for path elements, the start of the path is the first point of the initial "moveto" command.

For stroking properties such as dash patterns whose computations are dependent on progress along the outline of the graphics element, distance calculations are required to utilize the SVG user agent's standard Distance along a path algorithms.

When stroking is performed using a complex paint server, such as a gradient or a pattern, the stroke operation must be identical to the result that would have occurred if the geometric shape defined by the geometry of the current graphics element and its associated stroking properties were converted to an equivalent path element and then filled using the given paint server.

### 13.5.1. Specifying stroke paint: the ‘stroke’ property

Name: stroke none shapes and text content elements yes N/A visual as specified, but with values computed and values made absolute yes

The stroke property paints along the outline of the given graphical element.

Note that when stroking a path element, any subpath consisting of a moveto but no following line drawing command will not be stroked. Any other type of zero-length subpath, such as 'M 10,10 L 10,10' or 'M 30,30 Z' will also not be stroked if the stroke-linecap property has a value of butt. See the definition of the stroke shape below for the details of computing the stroke of a path.

SVG 2 Requirement: Include a way to specify stroke position. SVG 2 shall include a way to specify stroke position. To allow a stroke to be inside or outside the path. Cameron (ACTION-3162) See proposal page.

### 13.5.2. Stroke paint opacity: the ‘stroke-opacity’ property

Name: stroke-opacity | 1 shapes and text content elements yes N/A visual number clamped to the range [0, 1], or percentage yes

The stroke-opacity property specifies the opacity of the painting operation used to stroke the current object. (See Painting shapes and text.) As with fill-opacity.

<number>
The opacity of the stroke. Any values outside the range 0 (fully transparent) to 1 (fully opaque) must be clamped to this range.
<percentage>
The opacity of the stroke expressed as a percentage of the range 0 to 1.

### 13.5.3. Stroke width: the ‘stroke-width’ property

Name: stroke-width | 1 shapes and text content elements yes refer to the size of the current SVG viewport (see Units) visual absolute length or percentage yes

This property specifies the width of the stroke on the current object. A zero value causes no stroke to be painted. A negative value is invalid.

### 13.5.4. Drawing caps at the ends of strokes: the ‘stroke-linecap’ property

Name: stroke-linecap butt | round | square butt shapes and text content elements yes N/A visual as specified yes

stroke-linecap specifies the shape to be used at the end of open subpaths when they are stroked, and the shape to be drawn for zero length subpaths whether they are open or closed. The possible values are:

butt
This value indicates that the stroke for each subpath does not extend beyond its two endpoints. A zero length subpath will therefore not have any stroke.
round

This value indicates that at each end of each subpath, the shape representing the stroke will be extended by a half circle with a diameter equal to the stroke width. If a subpath, whether open or closed, has zero length, then the resulting effect is that the stroke for that subpath consists solely of a full circle centered at the subpath's point.

square

This value indicates that at the end of each subpath, the shape representing the stroke will be extended by a rectangle with the same width as the stroke width and whose length is half of the stroke width. If a subpath, whether open or closed, has zero length, then the resulting effect is that the stroke for that subpath consists solely of a square with side length equal to the stroke width, centered at the subpath's point, and oriented such that two of its sides are parallel to the effective tangent at that subpath's point. See ‘path’ element implementation notes for details on how to determine the tangent at a zero-length subpath.

See the definition of the cap shape below for a more precise description of the shape a line cap will have.

### 13.5.5. Controlling line joins: the ‘stroke-linejoin’ and ‘stroke-miterlimit’ properties

Name: stroke-linejoin miter | miter-clip | round | bevel | arcs miter shapes and text content elements yes N/A visual as specified yes

stroke-linejoin specifies the shape to be used at the corners of paths or basic shapes when they are stroked. For further details see the path implementation notes.

miter
This value indicates that a sharp corner is to be used to join path segments. The corner is formed by extending the outer edges of the stroke at the tangents of the path segments until they intersect. If the stroke-miterlimit is exceeded, the line join falls back to bevel (see below).
miter-clip
This value is the same as miter but if the stroke-miterlimit is exceeded, the miter is clipped at a distance equal to half the stroke-miterlimit value multiplied by the stroke width from the intersection of the path segments (see below).
round
This value indicates that a round corner is to be used to join path segments. The corner is a circular sector centered on the join point.
bevel
This value indicates that a bevelled corner is to be used to join path segments. The bevel shape is a triangle that fills the area between the two stroked segments.
arcs
This value indicates that an arcs corner is to be used to join path segments. The arcs shape is formed by extending the outer edges of the stroke at the join point with arcs that have the same curvature as the outer edges at the join point.

The miter-clip and arcs values are new in SVG 2. The miter-clip value offers a more consistent presentation for a path with multiple joins as well as better behavior when a path is animated. The arcs value provides a better looking join when the path segments at the join are curved.

Adding 'arcs' line join was resolved at the Rigi Kaltbad group meeting.

Adding 'miter-clip' line join was resolved at the Sydney (2015) group meeting.

Name: stroke-miterlimit 4 shapes and text content elements yes N/A visual as specified yes

When two line segments meet at a sharp angle and a value of miter, miter-clip, or arcs has been specified for stroke-linejoin, it is possible for the join to extend far beyond the thickness of the line stroking the path. The stroke-miterlimit imposes a limit on the extent of the line join.

<number>
The limit on the extent of a miter, miter-clip, or arcs line join as a multiple of the stroke-width value. The value of stroke-miterlimit must be a <number> greater than or equal to 1. Any other value is an error (see Error processing).

For the miter or the miter-clip values, given the angle θ between the segments in local coordinate system, the miter length is calculated by:

$\mathrm{miter length}=\frac{\mathrm{‘stroke-width’}}{\mathrm{sin}\frac{\theta }{2}}$
miter length = stroke-width / sin(theta / 2)

Historically, the miter length is defined as the distance from the inside stroke edge of the intersecting path segments to the tip of the miter. In practice, this is followed only for straight path segments. The above definition of miter length based on angles depends only on the tangents to the path segments at the join and thus gives consistent results independent of the curvature of the path segments. To be consistent with this definition, the clipping point of the miter-clip and arcs line joins is at a distance or arc length equal to half the stroke-miterlimit times the stroke width from the point the two path segments join.

If the miter length divided by the stroke width exceeds the stroke-miterlimit then for the value:

miter
the join is converted to a bevel;
miter-clip
the miter is clipped by a line perpendicular to the line bisecting the angle between the two path segments at a distance of half the value of miter length from the intersection of the two path segments.

For the arcs value, the miter length is calculated along a circular arc that is tangent to the line bisecting the angle between the two segments at the point the two segments intersect and passes through the end point of the join. The line join is clipped, if necessary, by a line perpendicular to this arc at an arc length from the intersection point equal to half the value of the stroke-miterlimit value multiplied by the stroke width.

The effect of 'stroke-miterlimit' on an 'arcs' line join was resolved at Sydney (2015) group meeting.

See the definition of the line join shape below for a more precise description of the shape a line join will have.

### 13.5.6. Dashing strokes: the ‘stroke-dasharray’ and ‘stroke-dashoffset’ properties

Name: stroke-dasharray none | none shapes and text content elements yes refer to the size of the current SVG viewport (see Units) visual absolute lengths or percentages for , or keyword specified yes (non-additive)

where:

<dasharray> = [ <length> | <percentage> | <number> ]#*

The stroke-dasharray property controls the pattern of dashes and gaps used to form the shape of a path's stroke.

none
Indicates that no dashing is used.
<dasharray>

Specifies a dashing pattern to use. A <dasharray> is a list of comma and/or white space separated lengths or percentages. Each value specifies a length along the path for which the stroke is to be painted (a dash) and not painted (a gap). The first value and every second value in the list after it specifies the length of a dash, and every other value specifies the length of a gap between the dashes. If the list has an odd number of values, then it is repeated to yield an even number of values. (Thus, the rendering behavior of stroke-dasharray: 5,3,2 is equivalent to stroke-dasharray: 5,3,2,5,3,2.)

The resulting even-length dashing pattern is repeated along each subpath. The dashing pattern is reset and begins again at the start of each subpath.

If any value in the list is negative, the <dasharray> value is invalid. If all of the values in the list are zero, then the stroke is rendered as a solid line without any dashing.

The attribute on a path element affects stroke-dasharray: each dash and gap length is interpreted relative to the author's path length as specified by .

Name: stroke-dashoffset | 0 shapes and text content elements yes refer to the size of the current SVG viewport (see Units) visual absolute length or percentage yes

The stroke-dashoffset property specifies the distance into the repeated dash pattern to start the stroke dashing at the beginning of the path. If the value is negative, then the effect is the same as dash offset d:

$d=s-\left|\mathrm{‘stroke-dashoffset’}\right|mods$
d = s - (abs(stroke-dashoffset) mod s)

where s is the sum of the dash array values.

Like stroke-dasharray, stroke-dashoffset is interpreted relative to the author's path length as specified by the attribute on a path element.

The example below shows how a that is greatly different from the actual path length can be used to control stroke dashing more easily.

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
width="300" height="150">
<defs>
<path id="p" d="M -50,0 A 50,50 0 0 0 50,0 A 50,50 0 0 0 -50,0 z"
pathLength="80"/>
<g id="chip" stroke-width="10">
<circle cy="5" r="55" fill="#000" fill-opacity="0.15" stroke="none"/>
stroke-dasharray="10 10" stroke-dashoffset="5"/>
<g fill="none" stroke-width="5" stroke-dasharray="0 20" stroke-linecap="round">
</g>
<circle r="40" fill="#000" fill-opacity="0.15"
stroke-width="2" stroke="white"/>
</g>
</defs>
<rect width="100%" height="100%" fill="#063"/>
<use xlink:href="#chip" x="140" y="75" fill="#00c" stroke="#00c"/>
<use xlink:href="#chip" x="160" y="85" fill="#000" stroke="#000"/>
<use xlink:href="#chip" x="170" y="65" fill="#c00" stroke="#c00"/>
</svg>

See the definition of dash positions below for a more precise description of positions along a path that dashes will be placed.

### 13.5.7. Computing the shape of the stroke

SVG 2 Requirement: Specify stroke dashing more precisely. SVG 2 shall specify stroke dashing more precisely. To define dash starting point on basic shapes and path segments. Cameron (no action)

The stroke shape of an element is the shape that is filled by the stroke property. Since text elements can be rendered in multiple chunks, each chunk has its own stroke shape. The following algorithm describes the ideal stroke shape of a path, basic shape or individual text chunk is, taking into account the stroking properties above. The ideal stroke shape described defines a best case implementation, but implementations are given some leeway to deviate from this description for performance reasons.

Authors should be aware that the shape of a stroke may in some cases, such as at extremely tight curves, differ across platforms. The above example shows the possible rendered results for the following two SVG paths:
<svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">
<path d="M 1,3 C 8,2 8,6 7,6" stroke-width="4" fill="none" stroke="skyblue"/>
<path d="M 1,3 C 8,2 8,6 7,6" stroke-width="0.075" fill="none" stroke="black"/>
</svg>
The ideal stroke shape is determined as follows:
1. Let shape be an empty shape.
2. If stroke-width > 0, then:
1. Let scale be a scale factor for the dash pattern. If we are computing the stroke shape of a text chunk, or if the attribute is not present on the element, then scale is 1. Otherwise, it is determined as follows:
1. Let length be the user agent's computed length of the path or equivalent path for a basic shape.
2. Let authorlength be the value of the attribute on the shape.
3. scale is authorlength / length.
2. Let path be the equivalent path of the element (or the individual chunk of a text element).
3. For each subpath of path:
1. Let positions be the dash positions for the subpath.
2. For each pair <start, end> in positions:
1. Scale start and end by scale.
2. Let dash be the shape that includes, for all distances between start and end along the subpath, all points that lie on the line perpendicular to the subpath at that distance and which are within distance stroke-width of the point on the subpath at that position.
3. Set dash to be the union of dash and the starting cap shape for the subpath at position start.
4. Set dash to be the union of dash and the ending cap shape for the subpath at position end.
5. Let index and last be the indexes of the path segments in the subpath at distance start and end along the subpath.

It does not matter whether any zero length segments are included when choosing index and last.

6. While index < last:
1. Set dash to be the union of dash and the line join shape for the subpath at segment index index.
2. Set index to index + 1.
7. Set shape to be the union of shape and stroke.
3. Return shape.

The dash positions for a given subpath of the equivalent path of a path or basic shape is a sequence of pairs of values, which represent the starting and ending distance along the subpath for each of the dashes that form the subpath's stroke. It is determined as follows:

1. Let pathlength be the length of the subpath.
2. Let dashes be the list of values of stroke-dasharray on the element, converted to user units, repeated if necessary so that it has an even number of elements; if the property has the value none, then the list has a single value 0.
3. Let count be the number of values in dashes.
4. Let sum be the sum of the values in dashes.
5. If sum = 0, then return a sequence with the single pair <0, pathlength>.
6. Let positions be an empty sequence.
7. Let offset be the value of the stroke-dashoffset property on the element.
8. If offset is negative, then set offset to sum − abs(offset).
9. Set offset to offset mod sum.
10. Let index be the smallest integer such that sum(dashesi, 0 ≤ iindex) ≥ offset.
11. Let dashlength be min(sum(dashesi, 0 ≤ iindex) − offset, pathlength).
12. If index mod 2 = 0, then append to positions the pair <0, dashlength>.
13. Let position be dashlength.
14. While position < pathlength:
1. Set index to (index + 1) mod count.
2. Let dashlength be min(dashesindex, pathlengthposition).
3. If index mod 2 = 0, then append to positions the pair <position, position + dashlength>.
4. Set position to position + dashlength.
15. Return positions.

The starting and ending cap shapes at a given position along a subpath are determined as follows:

1. If stroke-linecap is butt, then return an empty shape.
2. Otherwise, if stroke-linecap is round, then:
1. If this is a starting cap, then return a semicircle of diameter stroke-width positioned such that:
• The subpath that the semicircle is relative to is the subpath starting at distance position.
• Its straight edge is parallel to the line perpendicular to the subpath at distance position along it.
• The midpoint of its straight edge is at the point that is along the subpath at distance position.
• The direction from the midpoint of its arc to the midpoint of its straight edge is the same as the direction of the subpath at distance position.
2. Otherwise, this is an ending cap. Return a semicircle of diameter stroke-width positioned such that:
• The subpath that the semicircle is relative to is the subpath ending at distance position.
• Its straight edge is parallel to the line perpendicular to the subpath at distance position along it.
• The midpoint of its straight edge is at the point that is along the subpath at distance position.
• The direction from the midpoint of its straight edge to the midpoint of its arc is the same as the direction of the subpath.
3. Otherwise, stroke-linecap is square:
1. If this is a starting cap, then return a rectangle with side lengths stroke-width and stroke-width / 2 positioned such that:
• Its longer edges, A and B, are parallel to the line perpendicular to the subpath at distance position along it.
• The midpoint of A is at start.
• The direction from the midpoint of B to the midpoint of A is the same as the direction of the subpath at distance position along it.
2. Otherwise, this is an ending cap. Return a rectangle with side lengths stroke-width and stroke-width / 2 positioned such that:
• Its longer edges, A and B, are parallel to the line perpendicular to the subpath at distance position along it.
• The midpoint of A is at end.
• The direction from the midpoint of A to the midpoint of B is the same as the direction of the subpath at distance position along it.

The line join shape for a given segment of a subpath is determined as follows:

1. Let P be the point at the end of the segment.
2. If the unit tangent vector at the end of the segment and the unit tangent vector at the start of the following segment are equal, then return an empty shape.

This means for example that 'M 100,100 h 100 h 100' would not produce a line join shape between the two straight line segment, but 'M 100,100 h 100 h -100' would.

3. Let A be the line parallel to the tangent at the end of the segment.
4. Let B be the line parallel to the tangent at the start of the following segment.
5. Let Aleft and Aright be lines parallel to A at a distance of stroke-width / 2 to the left and to the right of A relative to the subpath direction, respectively.
6. Let Bleft and Bright be lines parallel to B at a distance of stroke-width / 2 to the left and to the right of B, relative to the subpath direction, respectively.
7. Let P1, P2 and P3 be points determined as follows:
1. If the smaller angle between A and B is on the right of these lines, considering the direction of the subpath, then P1 and P2 are the points on Aleft and Bleft closest to P, and P3 is the intersection of Aleft and Bleft.
2. Otherwise, P1 and P2 are the points on Aright and Bright closest to P, and P3 is the intersection of Aright and Bright.
8. Let bevel be the triangle formed from the three points P, P1 and P2.
9. If stroke-linejoin is round, then return the union of bevel and a circular sector of diameter stroke-width, centered on P, and which has P1 and P2 as the two endpoints of the arc.
10. If stroke-linejoin is arcs, then find the circles that are tangent to the stroke edges at P1 and P2 with the same curvature as the edges at those points (see below). If both curvatures are zero fall through to miter-clip. If either curvature is greater than 2/(stroke width), fallback to round. Extend the stroke edges using these circles (or a line, in the case of zero curvature). If the two circles (or circle and line) do not intersect, adjust the radii of the two circles by an equal amount (or just the circle in case of a circle and line) until they do intersect (see below). The line join region is defined by the lines that connect P with P1 and P2 and the arcs defined by the circles (or arc and line) between the closest intersection point to P, and P1 and P2. Next calculate the miter limit as defined in the stroke-miterlimit section. Clip any part of the line join region that extends past the miter limit. Return the resulting region. Note that the curvatures are calculated in user-space before any transforms are applied.
11. If stroke-linejoin is miter or miter-clip then the line join region is the union of bevel and the triangle formed from the three points P1, P2 and P3.
12. Let θ be the angle between A and B. If 1 / sin(θ / 2) ≤ stroke-miterlimit, then return the line join region.
13. If stroke-linejoin is miter-clip, then clip any part of the line join region that extends past the miter limit and return this region.
14. Return bevel.

### 13.5.8. Computing the circles for the arcs 'stroke-linejoin'

The arcs stroke-linejoin requires finding circles that are both tangent to and have the same curvatures as the outer stroke edges at the ends of path segments. To find one of these circles, first calculate the curvature κ of the path segment at its end (see below). Next, find the radius of a circle corresponding to this curvature: r = 1/κ. Increase or decrease the radius by one half of the stroke width to account for the stroke: rc = r ± ½ stroke-width. The center of the circle will be on a line normal to the path end a distance of rc away from the outer stroke edge at the end.

For a line: the curvature is zero. Extend the outer stroke edge by a line.

For an elliptical arc:

$\kappa \left(t\right)=\frac{{r}_{x}{r}_{y}}{\left({r}_{x}^{2}{\mathrm{sin}}^{2}t+{r}_{y}^{2}{\mathrm{cos}}^{2}t{\right)}^{3/2}}$
$$\kappa(t) = {{r_x r_y}\over{(r_x^2 \sin^2 t + r_y^2 \cos^2 t)^{3/2}}}$$

where:

$t=\mathrm{arctan}\left(\frac{{r}_{y}}{{r}_{x}}\mathrm{tan}\theta \right)$
$$t = \arctan ( {r_y \over r_x} \tan \theta )$$

The parameter θ at the beginning or end of an arc segment can be found by using the formulas in the Elliptical arc implementation notes. (Note, some renderers convert elliptical arcs to cubic Béziers prior to rendering so the equations here may not be needed.)

$\kappa \left(0\right)=\frac{1}{2}\frac{\left({P}_{1}-{P}_{0}\right)×\left({P}_{2}-{P}_{1}\right)}{|{P}_{1}-{P}_{0}{|}^{3}}$
$$\kappa(0) = {2\over3}{(P_1-P_0)\times((P_0-P_1)+(P_2-P_1))\over|P_1-P_0|^3}$$
$\kappa \left(1\right)=\frac{1}{2}\frac{\left({P}_{2}-{P}_{1}\right)×\left({P}_{0}-{P}_{1}\right)}{|{P}_{2}-{P}_{1}{|}^{3}}$
$$\kappa(0) = {2\over3}{(P_1-P_0)\times((P_0-P_1)+(P_2-P_1))\over|P_1-P_0|^3}$$

Where κ(0) and κ(1) are the signed curvatures at the start and end of the path segment respectively, and the P's are the three points that define the quadratic Bézier.

For a cubic Bézier:

$\kappa \left(0\right)=\frac{2}{3}\frac{\left({P}_{1}-{P}_{0}\right)×\left({P}_{2}-{P}_{1}\right)}{|{P}_{1}-{P}_{0}{|}^{3}}$
$$\kappa(0) = {2\over3}{(P_1-P_0)\times((P_0-P_1)+(P_2-P_1))\over|P_1-P_0|^3}$$
$\kappa \left(1\right)=\frac{2}{3}\frac{\left({P}_{3}-{P}_{2}\right)×\left({P}_{1}-{P}_{2}\right)}{|{P}_{3}-{P}_{2}{|}^{3}}$
$$\kappa(1) = {2\over3}{(P_3-P_2)\times((P_1-P_2)+(P_3-P_2))\over|P_3-P_2|^3}$$

Where κ(0) and κ(1) are the signed curvatures at the start and end of the path segment respectively, and the P's are the four points that define the cubic Bézier. Note, if P0 and P1, or P2 and P3 are degenerate, the curvature will be infinite and a line should be used in constructing the join.

### 13.5.9. Adjusting the circles for the arcs 'stroke-linejoin' when the initial circles do not intersect

The fallback behavior was resolved at the Sydney 2016 F2F. It gives a smooth transition between the fallback and non-fallback states.

When the initial circles calculated for the arcs stroke-linejoin do not intersect, they need to be adjusted by changing both radii by the same magnitude (moving the circle centers to keep the circles tangent to the offset paths) until the circles just touch. There are two cases to consider. The first is when one circle encloses the other circle. In this case the larger circle is reduced in size while the smaller circle is increased in size:

The second case is when there is no overlap between the circles. In this case the radii of both circles are increased by the same amount:

If in this latter case, the tangents of the offset paths at the line join are parallel, the circles cannot be adjusted so that they touch. The line join should then be constructed as a rectangle whose width is the stroke width and whose length is the stroke width times one half of the value of the stroke-miterlimit:

There are a couple of ways to implement the fallback algorithm. The first way is by recursive trial and error on the magnitude of the radius change. The second is by an exact calculation utilizing the touching circle condition and the constraints that the centers of the circles must remain on lines normal to the path segments at the join. This leads to a quadratic equation where one solution is the required radius change.

## 13.6. Vector effects

This chapter explains vector-effect related to Painting. Please refer to this for the perspective of vector-effect.

non-scaling-stroke
Modifies the way an object is stroked. Normally stroking involves calculating stroke outline of the shape's path in current local coordinate system and filling that outline with the stroke paint (color or gradient). With the non-scaling-stroke vector effect, stroke outline shall be calculated in the "host" coordinate space instead of local coordinate system. More precisely: a user agent establishes a host coordinate space which in SVG Tiny 1.2 is always the same as "screen coordinate space". The stroke outline is calculated in the following manner: first, the shape's path is transformed into the host coordinate space. Stroke outline is calculated in the host coordinate space. The resulting outline is transformed back to the local coordinate system. (Stroke outline is always filled with stroke paint in the current local coordinate system). The resulting visual effect of this modification is that stroke width is not dependant on the transformations of the element (including non-uniform scaling and shear transformations) and zoom level.

## 13.7. Markers

SVG 2 Requirement: Improve markers. We will improve markers for SVG 2. To solve the common problems authors have with SVG markers. Cameron (ACTION-3286)

A marker is a graphical object that is painted at particular positions along any shape element.

The marker-start and marker-end properties can be used to place markers at the first and last vertex of a shape, and the marker-mid property can be used to place markers at all other vertices (aside from the first and last). The marker-start and marker-end can be used for example to add arrowheads to paths. Markers placed using these properties are known as vertex markers.

In SVG 2, vertex markers are the only kind of markers available. Other specifications will add new types of markers.

The graphics for a marker are defined by a marker element. The marker-start, marker-end and marker-mid properties, together known as the marker properties, reference marker elements.

Markers can be animated, and as with use elements, the animated effects will show on all current uses of the markers within the document.

Markers on a given element are painted in the following order, from bottom to top:

### 13.7.1. The ‘marker’ element

marker
Categories:
Container element, never-rendered element
Content model:
Any number of the following elements, in any order:
a, audio, canvas, clipPath, cursor, filter, foreignObject, iframe, image, marker, mask, script, style, switch, text, video, view
Attributes:
DOM Interfaces:

The marker element defines the graphics that are to be used for drawing markers on a shape.

Attribute definitions:

Name Value Initial value Animatable
markerUnits strokeWidth | userSpaceOnUse strokeWidth yes

The attribute defines the coordinate system for attributes , and the contents of the marker. Values have the following meanings:

strokeWidth
, and the contents of the marker have values in a coordinate system which has a single unit equal to the size in user units of the painted stroke width of the element referencing the marker.
userSpaceOnUse
, and the contents of the marker have values in the current user coordinate system in place for the element referencing the marker.

When has the value strokeWidth, the size of the marker is relative to the stroke-width after it has had any transforms applied that affect the width of the stroke in the local coordinate system for the stroke. This means that, for example, the vector-effect attribute with a value of non-scaling-stroke will result in the markers also being non scaling.

Name Value Initial value Animatable
markerWidth, markerHeight <length> | <percentage> | <number> 3 yes

The and attributes represent the size of the SVG viewport into which the marker is to be fitted according to the viewBox and attributes. A value of zero for either attribute results in nothing being rendered for the marker. A negative value for either attribute is an error (see Error processing).

Name Value Initial value Animatable
refX <length> | <percentage> | <number> | left | center | right 0 yes
refY <length> | <percentage> | <number> | top | center | bottom 0 yes

New in SVG 2: geometric keywords (matches use in symbol).

We will add top/center/bottom, left/center/right keywords to refX/refY on marker/symbol. Resolved at London F2F. Values inspired by 'background-position'.

The refX and refY attributes define the reference point of the marker, which is to be placed exactly at the marker's position on the shape. Lengths and numbers must be interpreted as being in the coordinate system of the marker contents, after application of the viewBox and attributes. Percentage values must be interpreted as being a percentage of the viewBox width for refX or a percentage of the viewBox height for refY.

The keyword values must evaluate to the following percentages:

Mapping of refX and refY keywords to percentages.
keywordpercentage equivalent
left0%
center50%
right100%
top0%
bottom100%
Name Value Initial value Animatable
orient auto | auto-start-reverse | <angle> | <number> 0 yes (non-additive)

The orient attribute indicates how the marker is rotated when it is placed at its position on the shape. Values have the following meanings:

'auto'

The marker is oriented such that its positive x-axis is pointing in a direction relative to the path at the position the marker is placed (See Rendering Markers).

'auto-start-reverse'

If placed by marker-start, the marker is oriented 180° different from the orientation that would be used if 'auto' where specified. For all other markers, 'auto-start-reverse' means the same as 'auto'.

This allows a single arrowhead marker to be defined that can be used for both the start and end of a path, i.e. which points outwards from both ends.

<angle>
<number>

The marker is oriented such that the specified angle is that measured between the shape's positive x-axis and the marker's positive x-axis. A <number> value specifies an angle in degrees.

For example, if a value of '45' is given, then the marker's positive x-axis would be pointing down and right in the shape's coordinate system.

### 13.7.2. Vertex markers: the ‘marker-start’, ‘marker-mid’ and ‘marker-end’ properties

Name: marker-start, marker-mid, marker-end none | none shapes yes N/A visual as specified, but with values (that are part of a ) made absolute yes

where:

<marker-ref> = <url>

The marker-start and marker-end properties are used to specify the marker that will be drawn at the first and last vertices of the given shape, respectively. marker-mid is used to specify the marker that will be drawn at all other vertices (i.e., every vertex except the first and last). Possible values for marker-start, marker-mid and marker-end are:

none
Indicates that no marker symbol will be drawn at the given vertex or vertices.
<marker-ref>
Indicates that the marker element referenced by the <marker-ref> value will be drawn at the given vertex or vertices. If the reference is not valid, then no marker will be drawn at the given vertex or vertices.

For all shapes, the path that must be used when calculating marker positions is the equivalent path.

For all shape elements, except polyline and path, the last vertex is the same as the first vertex. In this case, if the value of marker-start and marker-end are both not none, then two markers will be rendered on that final vertex. For path elements, for each closed subpath, the last vertex is the same as the first vertex. marker-start must only be rendered on the first vertex of the path data. marker-end must only be rendered on the final vertex of the path data. marker-mid must be rendered on every vertex other than the first vertex of the path data and the last vertex of the path data.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 30">
<defs>
<marker id="m1" viewBox="0 0 10 10" refX="5" refY="5"
markerWidth="8" markerHeight="8">
<circle cx="5" cy="5" r="5" fill="green"/>
</marker>
<marker id="m2" viewBox="0 0 10 10" refX="5" refY="5"
markerWidth="6.5" markerHeight="6.5">
<circle cx="5" cy="5" r="5" fill="skyblue" opacity="0.9"/>
</marker>
<marker id="m3" viewBox="0 0 10 10" refX="5" refY="5"
markerWidth="5" markerHeight="5">
<circle cx="5" cy="5" r="5" fill="maroon" opacity="0.85"/>
</marker>
</defs>

<path d="M10,10 h10 v10 z m20,0 h10 v10 z m20,0 h10 v10 z"
fill="none" stroke="black"
marker-start="url(#m1)"
marker-mid="url(#m2)"
marker-end="url(#m3)"
/>
</svg>

Note that marker-start and marker-end refer to the first and last vertex of the entire path, not each subpath.

The following example shows a triangular marker symbol used as a vertex marker to form an arrowhead at the end of two paths.

<svg xmlns="http://www.w3.org/2000/svg"
width="275" height="200" viewBox="0 0 275 200">
<defs>
<marker id="Triangle" viewBox="0 0 10 10" refX="1" refY="5"
markerUnits="strokeWidth" markerWidth="4" markerHeight="3"
orient="auto">
<path d="M 0 0 L 10 5 L 0 10 z" fill="context-stroke"/>
</marker>
</defs>

<g fill="none" stroke-width="10" marker-end="url(#Triangle)">
<path stroke="crimson" d="M 100,75 C 125,50 150,50 175,75"/>
<path stroke="olivedrab" d="M 175,125 C 150,150 125,150 100,125"/>
</g>
</svg>

### 13.7.3. Marker shorthand: the ‘marker’ property

Name: marker none | not defined for shorthand properties shapes yes N/A visual see individual properties yes

The marker property sets values for the marker-start, marker-mid and marker-end properties. The value of the marker is used directly for all three of the corresponding longhand properties.

### 13.7.4. Rendering markers

When orienting a marker automatically, due to specifying orient as 'auto', the following rules are used:

For each marker that is drawn, a temporary new user coordinate system is established so that the marker will be positioned and sized correctly, as follows:

• The axes of the temporary new user coordinate system are aligned according to the orient attribute on the marker element.
• A temporary new coordinate system is established by attribute . If equals 'strokeWidth', then the temporary new user coordinate system is the result of scaling the current user coordinate system by the current value of property stroke-width. If equals 'userSpaceOnUse', then no extra scale transformation is applied.
• An additional set of transformations might occur if the marker element includes a viewBox attribute, in which case additional transformations are set up to produce the necessary result due to attributes viewBox and .
• If the overflow property on the marker element indicates that the marker needs to be clipped to its SVG viewport, then an implicit clipping path is established at the bounds of the SVG viewport.

Note that the user agent style sheet sets the overflow property for marker elements to hidden, which causes a rectangular clipping path to be created at the bounds of marker's SVG viewport by default.

Properties do not inherit from the element referencing the marker into the contents of the marker. However, by using the context-stroke value for the fill or stroke on elements in its definition, a single marker can be designed to match the style of the element referencing the marker.

Markers cannot be interacted with. Events such as click or mouseover, for example, are not dispatched to a marker or its children when the mouse is clicked or moved over a rendered marker.

Markers are not rendered directly and must be referenced by one of the marker properties to be rendered. The display value for the marker element must always be set to none by the user agent style sheet, and this declaration must have importance over any other CSS rule or presentation attribute. marker elements are available for referencing even when the display property on the marker element or any of its ancestors is set to none.

The rendering effect of a marker is as if the contents of the referenced marker element were deeply cloned into a separate non-exposed DOM tree for each instance of the marker. Because the cloned DOM tree is non-exposed, the SVG DOM does not show the cloned instance of the marker.

The conceptual deep cloning of the referenced marker element into a non-exposed DOM tree also copies any property values resulting from the CSS cascade ([CSS2], chapter 6) and property inheritance on the referenced element and its contents. CSS selectors can be applied to the original (i.e., referenced) elements because they are part of the formal document structure. CSS selectors cannot be applied to the (conceptually) cloned DOM tree because its contents are not part of the formal document structure.

For illustrative purposes, we'll repeat the marker example shown earlier:

<?xml version="1.0" standalone="no"?>
<svg width="4in" height="2in"
viewBox="0 0 4000 2000"
xmlns="http://www.w3.org/2000/svg">
<defs>
<marker id="Triangle"
viewBox="0 0 10 10" refX="0" refY="5"
markerUnits="strokeWidth"
markerWidth="4" markerHeight="3"
orient="auto">
<path d="M 0 0 L 10 5 L 0 10 z" />
</marker>
</defs>
<rect x="10" y="10" width="3980" height="1980"
fill="none" stroke="blue" stroke-width="10" />
<desc>Placing an arrowhead at the end of a path.
</desc>
<path d="M 1000 750 L 2000 750 L 2500 1250"
fill="none" stroke="black" stroke-width="100"
marker-end="url(#Triangle)"  />
</svg>

The rendering effect of the above file will be visually identical to the following:

<?xml version="1.0" standalone="no"?>
<svg width="4in" height="2in"
viewBox="0 0 4000 2000"
xmlns="http://www.w3.org/2000/svg">
<desc>File which produces the same effect
as the marker example file, but without
using markers.
</desc>
<rect x="10" y="10" width="3980" height="1980"
fill="none" stroke="blue" stroke-width="10" />
<!-- The path draws as before, but without the marker properties -->
<path d="M 1000 750 L 2000 750 L 2500 1250"
fill="none" stroke="black" stroke-width="100"  />
<!-- The following logic simulates drawing a marker
at final vertex of the path. -->
<!-- First off, move the origin of the user coordinate system
so that the origin is now aligned with the end point of the path. -->
<g transform="translate(2500,1250)" >
<!-- Rotate the coordinate system 45 degrees because
the marker specified orient="auto" and the final segment
of the path is going in the direction of 45 degrees. -->
<g transform="rotate(45)" >
<!-- Scale the coordinate system to match the coordinate system
indicated by the 'markerUnits' attributes, which in this case has
a value of 'strokeWidth'. Therefore, scale the coordinate system
by the current value of the 'stroke-width' property, which is 100. -->
<g transform="scale(100)" >
<!-- Translate the coordinate system by
(-refX*viewBoxToMarkerUnitsScaleX, -refY*viewBoxToMarkerUnitsScaleY)
in order that (refX,refY) within the marker will align with the vertex.
In this case, we use the default value for preserveAspectRatio
('xMidYMid meet'), which means find a uniform scale factor
(i.e., viewBoxToMarkerUnitsScaleX=viewBoxToMarkerUnitsScaleY)
such that the viewBox fits entirely within the SVG viewport ('meet') and
is center-aligned ('xMidYMid'). In this case, the uniform scale factor
is markerHeight/viewBoxHeight=3/10=.3. Therefore, translate by
(-refX*.3,-refY*.3)=(0*.3,-5*.3)=(0,-1.5). -->
<g transform="translate(0,-1.5)" >
<!-- There is an implicit clipping path because the user agent style
sheet says that the 'overflow' property for markers has the value
'hidden'. To achieve this, create a clipping path at the bounds
of the SVG viewport. Note that in this case the SVG viewport extends
0.5 units to the left and right of the viewBox due to
a uniform scale factor, different ratios for markerWidth/viewBoxWidth
and markerHeight/viewBoxHeight, and 'xMidYMid' alignment -->
<clipPath id="cp1" >
<rect x="-0.5" y="0" width="4" height="3" />
</clipPath>
<g clip-path="url(#cp1)" >
<!-- Scale the coordinate system by the uniform scale factor
markerHeight/viewBoxHeight=3/10=.3 to set the coordinate
system to viewBox units. -->
<g transform="scale(.3)" >
<!-- This 'g' element carries all property values that result from
cascading and inheritance of properties on the original 'marker' element.
In this example, neither fill nor stroke was specified on the 'marker'
element or any ancestors of the 'marker', so the initial values of
"black" and "none" are used, respectively. -->
<g fill="black" stroke="none" >
<!-- Expand out the contents of the 'marker' element. -->
<path d="M 0 0 L 10 5 L 0 10 z" />
</g>
</g>
</g>
</g>
</g>
</g>
</g>
</svg>

View this example as SVG (SVG-enabled browsers only)

## 13.8. Controlling paint operation order: the ‘paint-order’ property

SVG 2 Requirement: Support control of the order of filling, stroke and painting markers on shapes. SVG 2 will adopt the ‘paint-order’ property proposal, though possibly with a different name. The property name is now resolved, see 15 Nov 2013 minutes. To address the common desire to paint strokes below fills without having to duplicate an element. Cameron (ACTION-3285)
Name: paint-order normal | [ fill || stroke || markers ] normal shapes and text content elements yes N/A visual as specified yes

New in SVG 2. Added primarily to allow painting the stroke of text below its fill without needing to duplicate the text element.

The paint-order property controls the order that the three paint operations that shapes and text are rendered with: their fill, their stroke and any markers they might have.

When the value of this property is normal, the element is painted with the standard order of painting operations: the fill is painted first, then its stroke and finally its markers.

When any of the other keywords are used, the order of the paint operations for painting the element is as given, from left to right. If any of the three keywords are omitted, they are painted last, in the order they would be painted with paint-order: normal.

This mean that, for example, paint-order: stroke has the same rendering behavior as paint-order: stroke fill markers.

The following example shows how the paint-order property can be used to render stroked text in a more aesthetically pleasing manner.

<svg xmlns="http://www.w3.org/2000/svg"
width="600" height="150" viewBox="0 0 600 150">

<style>
text {
font: 80px bold sans-serif; stroke-linejoin: round;
text-anchor: middle; fill: peachpuff; stroke: crimson;
}
</style>

<text x="150" y="100" style="stroke-width: 6px;">pizazz</text>
<text x="450" y="100" style="stroke-width: 12px; paint-order: stroke;">pizazz</text>
</svg>

## 13.9. Color space for interpolation: the ‘color-interpolation’ property

Name: color-interpolation auto | sRGB | linearRGB sRGB container elements, graphics elements, gradient elements, ‘use’ and ‘animate’ yes N/A visual as specified yes

The SVG user agent performs color interpolations and compositing at various points as it processes SVG content. The color-interpolation property controls which color space is used for the following graphics operations:

For filter effects, the color-interpolation-filters property controls which color space is used. [filter-effects-1]

The color-interpolation property chooses between color operations occurring in the sRGB color space or in a (light energy linear) linearized RGB color space. Having chosen the appropriate color space, component-wise linear interpolation is used. Values for color-interpolation have the following meanings:

auto
Indicates that the user agent can choose either the sRGB or linearRGB spaces for color interpolation. This option indicates that the author doesn't require that color interpolation occur in a particular color space.
sRGB
Indicates that color interpolation occurs in the sRGB color space.
linearRGB
Indicates that color interpolation occurs in the linearized RGB color space as described below.

The conversion formulas between the sRGB color space (i.e., nonlinear with 2.2 gamma curve) and the linearized RGB color space (i.e., color values expressed as sRGB tristimulus values without a gamma curve) can be found in the sRGB specification [SRGB]. For illustrative purposes, the following formula shows the conversion from sRGB to linearized RGB, where Csrgb is one of the three sRGB color components, Clinear is the corresponding linearized RGB color component, and all color values are between 0 and 1:

if C_srgb <= 0.04045
C_linear = C_srgb / 12.92
else if c_srgb > 0.04045
C_linear = ((C_srgb + 0.055) / 1.055) ^ 2.4

Out-of-range color values, if supported by the user agent, also are converted using the above formulas. (See Clamping values which are restricted to a particular range.)

When a child element is blended into a background, the value of the color-interpolation property on the child determines the type of blending, not the value of the color-interpolation on the parent. For gradients which make use of the ‘href’ attribute to reference another gradient, the gradient uses the color-interpolation property value from the gradient element which is directly referenced by the fill or stroke property. When animating colors, color interpolation is performed according to the value of the color-interpolation property on the element being animated.

## 13.10. Rendering hints

### 13.10.1. The ‘color-rendering’ property

Name: color-rendering auto | optimizeSpeed | optimizeQuality auto container elements, graphics elements, gradient elements, ‘use’ and ‘animate’ yes N/A visual as specified yes

The color-rendering property provides a hint to the SVG user agent about how to optimize its color interpolation and compositing operations. Values have the following meanings:

auto
Indicates that the user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed.
optimizeSpeed
Indicates that the user agent shall emphasize rendering speed over quality. For RGB display devices, this option will sometimes cause the user agent to perform color interpolation and compositing in the device RGB color space.
optimizeQuality
Indicates that the user agent shall emphasize quality over rendering speed.

color-rendering takes precedence over color-interpolation-filters. For example, assume color-rendering: optimizeSpeed and color-interpolation-filters: linearRGB. In this case, the SVG user agent should perform color operations in a way that optimizes performance, which might mean sacrificing the color interpolation precision as specified by color-interpolation-filters: linearRGB.

### 13.10.2. The ‘shape-rendering’ property

Name: shape-rendering auto | optimizeSpeed | crispEdges | geometricPrecision auto shapes yes N/A visual as specified yes

The shape-rendering property provides a hint to the implementation about what tradeoffs to make as it renders vector graphics elements such as path elements and basic shapes such as circles and rectangles. Values have the following meanings:

auto
Indicates that the user agent shall make appropriate tradeoffs to balance speed, crisp edges and geometric precision, but with geometric precision given more importance than speed and crisp edges.
optimizeSpeed
Indicates that the user agent shall emphasize rendering speed over geometric precision and crisp edges. This option will sometimes cause the user agent to turn off shape anti-aliasing.
crispEdges
Indicates that the user agent shall attempt to emphasize the contrast between clean edges of artwork over rendering speed and geometric precision. To achieve crisp edges, the user agent might turn off anti-aliasing for all lines and curves or possibly just for straight lines which are close to vertical or horizontal. Also, the user agent might adjust line positions and line widths to align edges with device pixels.
geometricPrecision
Indicates that the user agent shall emphasize geometric precision over speed and crisp edges.

### 13.10.3. The ‘text-rendering’ property

Name: text-rendering auto | optimizeSpeed | optimizeLegibility | geometricPrecision auto ‘text’ yes N/A visual as specified yes

The text-rendering property provides a hint to the implementation about what tradeoffs to make as it renders text. Values have the following meanings:

auto
Indicates that the user agent shall make appropriate tradeoffs to balance speed, legibility and geometric precision, but with legibility given more importance than speed and geometric precision.
optimizeSpeed
Indicates that the user agent shall emphasize rendering speed over legibility and geometric precision. This option will sometimes cause the user agent to turn off text anti-aliasing.
optimizeLegibility
Indicates that the user agent shall emphasize legibility over rendering speed and geometric precision. The user agent will often choose whether to apply anti-aliasing techniques, built-in font hinting or both to produce the most legible text.
geometricPrecision
Indicates that the user agent shall emphasize geometric precision over legibility and rendering speed. This option will usually cause the user agent to suspend the use of hinting so that glyph outlines are drawn with comparable geometric precision to the rendering of path data.

### 13.10.4. The ‘image-rendering’ property

Name: image-rendering auto | optimizeQuality | optimizeSpeed auto images yes N/A visual as specified yes

The CSS Image Values and Replacement Conent Module Level 4 may in the future redefine this property. In particular it should allow the choice between smoothing and keeping a pixelated look when upscaling.

The image-rendering property provides a hint to the implementation about how to make speed vs. quality tradeoffs as it performs image processing. Values have the following meanings:

auto
Indicates that the user agent shall make appropriate tradeoffs to balance speed and quality, but quality shall be given more importance than speed. The user agent shall employ a resampling algorithm at least as good as nearest neighbor resampling, but bilinear resampling is strongly preferred. For conforming high-quality SVG viewers, the user agent shall employ a resampling algorithm at least as good as bilinear resampling.
optimizeQuality
Indicates that the user agent shall emphasize quality over rendering speed. The user agent shall employ a resampling algorithm at least as good as bilinear resampling.
optimizeSpeed
Indicates that the user agent shall emphasize rendering speed over quality. The user agent should use a resampling algorithm which achieves the goal of fast rendering, with the requirement that the resampling algorithm shall be at least as good as nearest neighbor resampling. If performance goals can be achieved with higher quality algorithms, then the user agent should use the higher quality algorithms instead of nearest neighbor resampling.

In all cases, resampling must be done in a truecolor (e.g., 24-bit) color space even if the original data and/or the target device is indexed color. High quality SVG viewers should perform image resampling using a linear color space.

## 13.11. The effect of the ‘will-change’ property

See the CSS Will Change Module Level 1 specification for the definition of will-change.

The will-change property is used to provide a hint to the user agent as to the types of changes that will be made to content, giving the user agent a better chance at performing rendering optimizations for a given element.

The will-change property applies to all SVG graphics elements, however since SVG elements do not support scrolling, the scroll-position value will have no effect on them.

The following example demonstrates how will-change can be used to forewarn the user agent that an element will have its transform property changed, with the potential result of the user agent rendering the element into its own GPU layer so that the scripted transform changes appear smooth.

<svg xmlns="http://www.w3.org/2000/svg">
<style>
#background { fill: lemonchiffon; }
#star {
fill: cornflowerblue;
stroke: navy; stroke-width: 5px; stroke-linejoin: round;
paint-order: stroke fill;
will-change: transform;
}
text { font: 24px sans-serif; user-select: none; }
</style>
<g onmousemove="drag(evt.clientX, evt.clientY);"
onmouseup="dragging = false;">
<rect id="background" width="100%" height="100%"/>
<text x="10" y="30">Drag the star!</text>
<path id="star" transform="translate(200,150)"
d="M 0.00,-40.00 -11.76,-16.18 -38.04,-12.36 -19.02,6.18 -23.51,32.36
0.00,20.00 23.51,32.36 19.02,6.18 38.04,-12.36 11.76,-16.18 z"
onmousedown="dragging = true;"/>
</g>
<script>
var dragging = false;
var star = document.getElementById("star");
function drag(x, y) {
if (dragging) {
star.setAttribute("transform", "translate(" + x + "," + y + ")");
}
}
</script>
</svg>

The will-change property replaces the ‘buffered-rendering’ property defined in SVG Tiny 1.2.

## 13.12. DOM interfaces

### 13.12.1. Interface SVGMarkerElement

An SVGMarkerElement object represents a marker element in the DOM.

interface SVGMarkerElement : SVGElement {

// Marker Unit Types
const unsigned short SVG_MARKERUNITS_UNKNOWN = 0;
const unsigned short SVG_MARKERUNITS_USERSPACEONUSE = 1;
const unsigned short SVG_MARKERUNITS_STROKEWIDTH = 2;

// Marker Orientation Types
const unsigned short SVG_MARKER_ORIENT_UNKNOWN = 0;
const unsigned short SVG_MARKER_ORIENT_AUTO = 1;
const unsigned short SVG_MARKER_ORIENT_ANGLE = 2;

attribute DOMString orient;

void setOrientToAuto();
void setOrientToAngle(SVGAngle angle);
};

SVGMarkerElement implements SVGFitToViewBox;

The numeric marker unit type constants defined on SVGMarkerElement are used to represent the keyword values that the attribute can take. Their meanings are as follows:

ConstantMeaning
SVG_MARKERUNITS_USERSPACEONUSEThe userSpaceOnUse keyword.
SVG_MARKERUNITS_STROKEWIDTHThe strokeWidth keyword.
SVG_MARKERUNITS_UNKNOWNSome other value.

The numeric marker orientation type constants defined on SVGMarkerElement are used to represent the types of values that the orient attribute can take. Their meanings are as follows:

ConstantMeaning
SVG_MARKER_ORIENT_AUTOThe auto keyword.
SVG_MARKER_ORIENT_ANGLEAn <angle> or <number> value indicating the orientation angle.
SVG_MARKER_ORIENT_UNKNOWNSome other value.

The markerUnits IDL attribute reflects the content attribute. The numeric type values for are as described above in the numeric marker unit type constant table.

The orientType, orientAngle and orient IDL attributes all reflect the orient content attribute. The numeric type values for orient are as follows:

ValueNumeric type value
auto SVG_MARKER_ORIENT_AUTO
auto-start-reverse SVG_MARKER_ORIENT_UNKNOWN
<angle> | <number> SVG_MARKER_ORIENT_ANGLE

The refX, refY, markerWidth and markerHeight IDL attributes reflect the refX, refY, and content attributes, respectively.

The setOrientToAuto method is used to set the value of the orient attribute to 'auto'. When setOrientToAuto() is called, the orient attribute is simply set to 'auto'.

The setOrientToAngle method is used to set the value of the orient attribute to a specific angle value. When setOrientToAngle(angle) is called, the orient attribute is reserialized using angle as the value.


text:
## CryptoDB

#### Publications

Year
Venue
Title
2022
EUROCRYPT
A recent line of work, Stacked Garbled Circuit (SGC), showed that Garbled Circuit (GC) can be improved for functions that include conditional behavior. SGC relieves the communication bottleneck of 2PC by only sending enough garbled material for a single branch out of the $b$ total branches. Hence, communication is sublinear in the circuit size. However, both the evaluator and the generator pay in computation and perform at least factor $\log b$ extra work as compared to standard GC evaluation. We extend the sublinearity of SGC to also include the work performed by the GC Evaluator E; thus we achieve a fully sublinear E, which is essential when optimizing for the online phase. We formalize our approach as a garbling scheme called GCWise: GC WIth Sublinear Evaluator. We show one attractive and immediate application, Garbled PIR, a primitive that marries GC with Private Information Retrieval. Garbled PIR allows the GC to non-interactively and sublinearly access a privately indexed element from a publicly known database, and then use this element in continued GC evaluation.
2022
EUROCRYPT
Garbled RAM (GRAM) is a powerful technique introduced by Lu and Ostrovsky that equips Garbled Circuit (GC) with a sublinear cost RAM without adding rounds of interaction. While multiple GRAM constructions are known, none are suitable for practice, due to costs that have high constants and poor scaling. We present the first GRAM suitable for practice. For computational security parameter $\kappa$ and for a size-$n$ RAM that stores blocks of size $w = \Omega(\log^2 n)$ bits, our GRAM incurs only amortized $O(w \cdot \log^2 n \cdot \kappa)$ communication and computation per access. We evaluate the concrete cost of our GRAM; our approach outperforms trivial linear-scan-based RAM for as few as $512$ $128$-bit elements.
2022
TCC
The recently proposed YOSO model is a groundbreaking approach to MPC, executable on a public blockchain, circumventing adaptive player corruption by hiding the corruption targets until they are worthless. Players are selected unpredictably from a large pool to perform MPC sub-tasks, in which each selected player sends a single message (and reveals their identity). While YOSO MPC has attractive asymptotic complexity, unfortunately, it is concretely prohibitively expensive due to the cost of its building blocks. We propose a modification to the YOSO model that preserves resilience to adaptive server corruption, but allows for much more efficient protocols. In SCALES (Small Clients And Larger Ephemeral Servers) only the servers facilitating the MPC computation are ephemeral (unpredictably selected and speak once''). Input providers (clients) publish problem instance and collect the output, but do not otherwise participate in computation. SCALES offers attractive features, and improves over YOSO in outsourcing MPC to a large pool of servers under adaptive corruption. We build SCALES from rerandomizable garbling schemes, which is a contribution of independent interest, with additional applications.
2021
EUROCRYPT
Secure two party computation (2PC) of arbitrary programs can be efficiently achieved using garbled circuits (GC). Until recently, it was widely believed that a GC proportional to the entire program, including parts of the program that are entirely discarded due to conditional branching, must be transmitted over a network. Recent work shows that this belief is false, and that communication proportional only to the longest program execution path suffices (Heath and Kolesnikov, CRYPTO 20, [HK20a]). Although this recent work reduces needed communication, it increases computation. For a conditional with b branches, the players use O(b^2) computation (traditional GC uses only O(b)). Our scheme LogStack reduces stacked garbling computation from O(b^2) to O(b log b) with no increase in communication over [HK20a]. The cause of [HK20a]'s increased computation is the oblivious collection of garbage labels that emerge during the evaluation of inactive branches. Garbage is collected by a multiplexer that is costly to generate. At a high level, we redesign stacking and garbage collection to avoid quadratic scaling. Our construction is also more space efficient: [HK20a] algorithms require O(b) space, while ours use only O(log b) space. This space efficiency allows even modest setups to handle large numbers of branches. [HK20a] assumes a random oracle (RO). We track the source of this need, formalize a simple and natural added assumption on the base garbling scheme, and remove reliance on RO: LogStack is secure in the standard model. Nevertheless, LogStack can be instantiated with typical GC tricks based on non-standard assumptions, such as free XOR and half-gates, and hence can be implemented with high efficiency. We implemented LogStack (in the RO model, based on half-gates garbling) and report performance. In terms of wall-clock time and for fewer than 16 branches, our performance is comparable to [HK20a]'s; for larger branching factors, our approach clearly outperforms [HK20a]. For example, given 1024 branches, our approach is 31x faster.
2021
PKC
A classic approach to MPC uses preprocessed multiplication triples to evaluate arbitrary Boolean circuits. If the target circuit features conditional branching, e.g. as the result of a IF program statement, then triples are wasted: one triple is consumed per AND gate, even if the output of the gate is entirely discarded by the circuit’s conditional behavior. In this work, we show that multiplication triples can be re-used across conditional branches. For a circuit with b branches, each having n AND gates, we need only a total of n triples, rather than the typically required bn. Because preprocessing triples is often the most expensive step in protocols that use them, this significantly improves performance. Prior work similarly amortized oblivious transfers across branches in the classic GMW protocol (Heath et al., Asiacrypt 2020, [HKP20]). In addition to demonstrating conditional improvements are possible for a different class of protocols, we also concretely improve over [HKP20]: their maximum improvement is bounded by the topology of the circuit. Our protocol yields improvement independent of topology: we need triples proportional to the size of the program’s longest execution path, regardless of the structure of the program branches. We implemented our approach in C++. Our experiments show that we significantly improve over a "naive" protocol and over prior work: for a circuit with 16 branches and in terms of total communication, we improved over naive by 12x and over [HKP20] by an average of 2.6x. Our protocol is secure against the semi-honest corruption of p-1 parties.
2021
ASIACRYPT
Stacked Garbling (SGC) is a Garbled Circuit (GC) improvement that efficiently and securely evaluates programs with conditional branching. SGC reduces bandwidth consumption such that communication is proportional to the size of the single longest program execution path, rather than to the size of the entire program. Crucially, the parties expend increased computational effort compared to classic GC. Motivated by procuring a subset in a menu of computational services or tasks, we consider GC evaluation of k-out-of-n branches, whose indices are known (or eventually revealed) to the GC evaluator E. Our stack-and-stagger technique amortizes GC computation in this setting. We retain the communication advantage of SGC, while significantly improving computation and wall-clock time. Namely, each GC party garbles (or evaluates) the total of n branches, a significant improvement over the O(nk) garblings/evaluations needed by standard SGC. We present our construction as a garbling scheme. Our technique brings significant overall performance improvement in various settings, including those typically considered in the literature: e.g. on a 1Gbps LAN we evaluate 16-out-of-128 functions ~7.68x faster than standard stacked garbling.
2021
ASIACRYPT
We construct a concretely efficient Zero Knowledge (ZK) Oblivious RAM (ORAM) for ZK Proof (ZKP) systems based on authenticated sharings of arithmetic values. It consumes 2logn oblivious transfers (OTs) of length-2sigma secrets per access of an arithmetic value, for statistical security parameter sigma and array size n. This is an asymptotic and concrete improvement over previous best (concretely efficient) ZK ORAM BubbleRAM of Heath and Kolesnikov ([HK20a], CCS 2020), whose access cost is 1/2 log^2 n OTs of length-2sigma secrets. ZK ORAM is essential for proving statements that are best expressed as RAM programs, rather than Boolean or arithmetic circuits. Our construction is private-coin ZK. We integrate it with [HK20a]’s ZKP protocol and prove the resulting ZKP system secure. We implemented PrORAM in C++. Compared to the state-of-the-art BubbleRAM, our PrORAM is ~10x faster for arrays of size 2^20 of 40-bit values.
2020
EUROCRYPT
Zero-knowledge (ZK) proofs (ZKP) have received wide attention, focusing on non-interactivity, short proof size, and fast verification time. We focus on the fastest total proof time, in particular for large Boolean circuits. Under this metric, Garbled Circuit (GC)-based ZKP (Jawurek et al., [JKO], CCS 2013) remained the state-of-the-art technique due to the low-constant linear scaling of computing the garbling. We improve GC-ZKP for proof statements with conditional clauses. Our communication is proportional to the longest branch rather than to the entire proof statement. This is most useful when the number m of branches is large, resulting in up to factor m× improvement over JKO. In our proof-of-concept illustrative application, prover P demonstrates knowledge of a bug in a codebase consisting of any number of snippets of actual C code. Our computation cost is linear in the size of the code- base and communication is constant in the number of snippets. That is, we require only enough communication for a single largest snippet! Our conceptual contribution is stacked garbling for ZK, a privacy-free circuit garbling scheme that can be used with the JKO GC-ZKP protocol to construct more efficient ZKP. Given a Boolean circuit C and computational security parameter k, our garbling is L · k bits long, where L is the length of the longest execution path in C. All prior concretely efficient garbling schemes produce garblings of size |C| · k. The computational cost of our scheme is not increased over prior state-of-the-art. We implement our GC-ZKP and demonstrate significantly improved (m× over JKO) ZK performance for functions with branching factor m. Compared with recent ZKP (STARK, Libra, KKW, Ligero, Aurora, Bulletproofs), our scheme offers much better proof times for larger circuits (35-1000× or more, depending on circuit size and compared scheme). For our illustrative application, we consider four C code snippets, each of about 30-50 LOC; one snippet allows an invalid memory dereference. The entire proof takes 0.15 seconds and communication is 1.5 MB.
2020
CRYPTO
Secure two party computation (2PC) of arbitrary programs can be efficiently achieved using garbled circuits (GC). The bottleneck of GC efficiency is communication. It is widely believed that it is necessary to transmit the entire GC during 2PC, even for conditional branches that are not taken. This folklore belief is false. We propose a novel GC technique, stacked garbling, that eliminates the communication cost of inactive conditional branches. We extend the ideas of conditional GC evaluation explored in (Kolesnikov, Asiacrypt 18) and (Heath and Kolesnikov, Eurocrypt 20). Unlike these works, ours is for general 2PC where no player knows which conditional branch is taken. Our garbling scheme, Stack, requires communication proportional to the longest execution path rather than to the entire circuit. Stack is compatible with state-of-the-art techniques, such as free XOR and half-gates. Stack is a garbling scheme. As such, it can be plugged into a variety of existing protocols, and the resulting round complexity is the same as that of standard GC. The approach does incur computation cost quadratic in the conditional branching factor vs linear in standard schemes, but the tradeoff is beneficial for most programs: GC computation even on weak hardware is faster than GC transmission on fast channels. We implemented Stack in C++. Stack reduces communication cost by approximately the branching factor: for 16 branches, communication is reduced by 10.5x. In terms of wall-clock time for circuits with branching factor 16 over a 50 Mbps WAN on a laptop, Stack outperforms state-of- the-art half-gates-based 2PC by more than 4x.
2020
ASIACRYPT
MPC functionalities are increasingly specified in high-level languages, where control-flow constructions such as conditional statements are extensively used. Today, concretely efficient MPC protocols are circuit-based and must evaluate all conditional branches at high cost to hide the taken branch. The Goldreich-Micali-Wigderson, or GMW, protocol is a foundational circuit-based technique that realizes MPC for p players and is secure against up to p-1 semi-honest corruptions. While GMW requires communication rounds proportional to the computed circuit’s depth, it is effective in many natural settings. Our main contribution is MOTIF (Minimizing OTs for IFs), a novel GMW extension that evaluates conditional branches almost for free by amortizing Oblivious Transfers (OTs) across branches. That is, we simultaneously evaluate multiple independent AND gates, one gate from each mutually exclusive branch, by representing them as a single cheap vector-scalar multiplication (VS) gate. For 2PC with b branches, we simultaneously evaluate up to b AND gates using only two 1-out-of-2 OTs of b-bit secrets. This is a factor ~b improvement over the state-of-the-art 2b 1-out-of-2 OTs of 1-bit secrets. Our factor b improvement generalizes to the multiparty setting as well: b AND gates consume only p(p ? 1) 1-out-of-2 OTs of b-bit secrets. We implemented our approach and report its performance. For 2PC and a circuit with 16 branches, each comparing two length-65000 bitstrings, MOTIF outperforms standard GMW in terms of communication by ~9.4x. Total wall-clock time is improved by 4.1 - 9.2x depending on network settings. Our work is in the semi-honest model, tolerating all-but-one corruptions.
2019
EUROCRYPT
The notion of covert security for secure two-party computation serves as a compromise between the traditional semi-honest and malicious security definitions. Roughly, covert security ensures that cheating behavior is detected by the honest party with reasonable probability (say, 1/2). It provides more realistic guarantees than semi-honest security with significantly less overhead than is required by malicious security.The rationale for covert security is that it dissuades cheating by parties that care about their reputation and do not want to risk being caught. But a much stronger disincentive is obtained if the honest party can generate a publicly verifiable certificate when cheating is detected. While the corresponding notion of publicly verifiable covert (PVC) security has been explored, existing PVC protocols are complex and less efficient than the best covert protocols, and have impractically large certificates.We propose a novel PVC protocol that significantly improves on prior work. Our protocol uses only “off-the-shelf” primitives (in particular, it avoids signed oblivious transfer) and, for deterrence factor 1/2, has only 20–40% overhead compared to state-of-the-art semi-honest protocols. Our protocol also has, for the first time, constant-size certificates of cheating (e.g., 354 bytes long at the 128-bit security level).As our protocol offers strong security guarantees with low overhead, we suggest that it is the best choice for many practical applications of secure two-party computation.
2019
ASIACRYPT
We present a new efficient protocol for computing private set union (PSU). Here two semi-honest parties, each holding a dataset of known size (or of a known upper bound), wish to compute the union of their sets without revealing anything else to either party. Our protocol is in the OT hybrid model. Beyond OT extension, it is fully based on symmetric-key primitives. We motivate the PSU primitive by its direct application to network security and other areas.At the technical core of our PSU construction is the reverse private membership test (RPMT) protocol. In RPMT, the sender with input $x^*$ interacts with a receiver holding a set X. As a result, the receiver learns (only) the bit indicating whether $x^* \in X$, while the sender learns nothing about the set X. (Previous similar protocols provide output to the opposite party, hence the term “reverse” private membership.) We believe our RPMT abstraction and constructions may be a building block in other applications as well.We demonstrate the practicality of our proposed protocol with an implementation. For input sets of size $2^{20}$ and using a single thread, our protocol requires 238 s to securely compute the set union, regardless of the bit length of the items. Our protocol is amenable to parallelization. Increasing the number of threads from 1 to 32, our protocol requires only 13.1 s, a factor of $18.25{\times }$ improvement.To the best of our knowledge, ours is the first protocol that reports on large-size experiments, makes code available, and avoids extensive use of computationally expensive public-key operations. (No PSU code is publicly available for prior work, and the only prior symmetric-key-based work reports on small experiments and focuses on the simpler 3-party, 1-corruption setting.) Our work improves reported PSU state of the art by factor up to $7,600{\times }$ for large instances.
2018
ASIACRYPT
Two-party Secure Function Evaluation (SFE) allows two parties to evaluate a function known to both parties on their private inputs. In some settings, the input of one of the parties is the definition of the computed function, and requires protection as well. The standard solution for SFE of private functions (PF-SFE) is to rely on Universal Circuits (UC), which can be programmed to implement any circuit of size $s$ . Recent UC optimizations report the cost of UC for $s$ -gate Boolean circuits is $\approx 5 s \log s$ .Instead, we consider garbling that allows evaluating one of a given set $\mathcal {S}$ of circuits. We show how to evaluate one of the circuits in $\mathcal {S}$ at the communication cost comparable to that of evaluating the largest circuit in $\mathcal {S}$ . In other words, we show how to omit generating and sending inactive GC branches. Our main insight is that a garbled circuit is just a collection of garbled tables, and as such can be reused to emulate the throw-away computation of an inactive execution branch without revealing to the Evaluator whether it evaluates active or inactive branch.This cannot be proven within the standard BHR garbled circuits framework because the function description is inseparable from the garbling by definition. We carefully extend BHR in a general way, introducing topology-decoupling circuit garbling. We preserve all existing constructions and proofs of the BHR framework, while allowing this and other future constructions which may treat garbled tables separately from function description.Our construction is presented in the semi-honest model.
2017
EUROCRYPT
2017
ASIACRYPT
2015
TCC
2015
ASIACRYPT
2015
ASIACRYPT
2014
CRYPTO
2014
CRYPTO
2013
CRYPTO
2010
TCC
2010
CHES
2006
TCC
2005
ASIACRYPT
2004
ASIACRYPT

Crypto 2022
Crypto 2019
Eurocrypt 2017
PKC 2014

format: plain