W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2014

svg2: Back to ED.

From: SVG Working Group repository <cam+svgwgrepo@mcc.id.au>
Date: Tue, 11 Feb 2014 22:42:19 -0800
Message-Id: <hg.d2c14c71ea93.1392187339.3034738116371802840@ps58493.dreamhostps.com>
To: public-svg-wg@w3.org
details:   https://svgwg.org/hg/svg2/rev/d2c14c71ea93
branches:  
changeset: 637:d2c14c71ea93
user:      Cameron McCormack <cam@mcc.id.au>
date:      Wed Feb 12 17:38:50 2014 +1100
description:
Back to ED.

diffstat:

 master/coords.html   |   2 +-
 master/painting.html |   2 +-
 master/paths.html    |  18 +++++++++---------
 master/publish.xml   |   4 +++-
 master/types.html    |   2 +-
 5 files changed, 15 insertions(+), 13 deletions(-)

diffs (271 lines):

diff --git a/master/coords.html b/master/coords.html
--- a/master/coords.html
+++ b/master/coords.html
@@ -1026,17 +1026,17 @@ size as the middle rectangle, which is s
 user units. In particular, note that the <a>'stroke-width'</a> property in the
 middle rectangle is set to 1% of the
 <code>sqrt((<em>actual-width</em>)**2 +
 (<em>actual-height</em>)**2) / sqrt(2)</code>, which in this
 case is .01*sqrt(4000*4000+2000*2000)/sqrt(2), or 31.62. The
 bottom rectangle of the group illustrates what happens when
 values specified in percentage units are scaled.</p>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <h2 id="BoundingBoxes">Bounding boxes</h2>
 
 <p>The bounding box (or "bbox") of an element is the tightest fitting rectangle
 aligned with the axes of that element's user coordinate system that entirely
 encloses it and its descendants.</p>
 
 <p>Three kinds of bounding boxes can be computed for an element:</p>
diff --git a/master/painting.html b/master/painting.html
--- a/master/painting.html
+++ b/master/painting.html
@@ -2189,17 +2189,17 @@ Values have the following meaning:</p>
       <li>the first path segment of the <em>current</em> subpath,
       if the following subpath does begin with a
       <a href="paths.html#PathDataMovetoCommands">'moveto'</a> command
       or if there is no following subpath.</li>
     </ul>
   </dd>
 </dl>
 
-<dl class="ready-for-wg-review">
+<dl class="ready-for-wider-review">
   <dt><span class="attr-value">'auto-start-reverse'</span></dt>
   <dd>
     <p>A value of <span class="attr-value">'auto-start-reverse'</span>
     means the same as <span class="attr-value">'auto'</span> except that
     for a marker placed by <a>'marker-start'</a>, the orientation is 180°
     different from the orientation as determined by <span class="attr-value">'auto'</span>.</p>
 
     <p class="note">This allows a single arrowhead marker to be defined
diff --git a/master/paths.html b/master/paths.html
--- a/master/paths.html
+++ b/master/paths.html
@@ -260,17 +260,17 @@ characters are allowed [<a href='refs.ht
 (For example, the following is an
 invalid numeric value in a path data stream: "13,000.56".
 Instead, say: "13000.56".)</p>
 
 <p>For the relative versions of the commands, all coordinate
 values are relative to the current point at the start of the
 command.</p>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <p>Relative path commands are also influenced by the
 current bearing, which is an angle set by the <em>bearing</em>
 commands.  This allows for paths to be specified using a
 style of "turtle graphics", where straight line and curved
 path segments are placed with their starting point at a
 tangent (or at some other angle) to the current bearing.</p>
 
@@ -279,17 +279,17 @@ tangent (or at some other angle) to the 
 <p>In the tables below, the following notation is used to
 describe the syntax of a given path command:</p>
 
 <ul>
   <li>(): grouping of parameters</li>
   <li>+: 1 or more of the given parameter(s) is required</li>
 </ul>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <p>In the description of the path commands, <var>cpx</var> and
 <var>cpy</var> represent the coordinates of the current point,
 and <var>cb</var> represents the current bearing.</p>
 
 </div>
 
 <p>The following sections list the commands.</p>
@@ -328,17 +328,17 @@ is not the first command) represent the 
       (<strong>m</strong>) appears as the first element of the path,
       then it is treated as a pair of absolute coordinates. In this
       case, subsequent pairs of coordinates are treated as relative
       even though the initial moveto is interpreted as an absolute moveto.
     </td>
   </tr>
 </table>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <p>When a relative <strong>m</strong> command is used, the
 position moved to is (<var>cpx</var> + <var>x</var> cos <var>cb</var>
 + <var>y</var> sin <var>cb</var>, <var>cpy</var> +
 <var>x</var> sin <var>cb</var> + <var>y</var> cos <var>cb</var>).</p>
 
 </div>
 
@@ -361,17 +361,17 @@ of the subpath is "joined" with the star
 segment of the subpath using the current value of <a>'stroke-linejoin'</a>.
 If you instead "manually" close the subpath via a "lineto"
 command, the start of the first segment and the end of the last
 segment are not joined but instead are each capped using the
 current value of <a>'stroke-linecap'</a>.
 At the end of the command, the new current point is set to the
 initial point of the current subpath.</p>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <p>The current bearing does not affect a <strong>z</strong> command.</p>
 
 </div>
 
 <table  class="PathDataTable">
   <tr>
     <th>Command</th>
@@ -446,17 +446,17 @@ current point to a new point:</p>
     this doesn't make sense).  A <strong>V</strong> or <strong>v</strong>
     command is equivalent to an <strong>L</strong> or <strong>l</strong>
     command with 0 specified for the x coordinate.
     At the end of the command, the new current point is
     taken from the final coordinate value.</td>
   </tr>
 </table>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <p>When a relative <strong>l</strong> command is used, the
 end point of the line is (<var>cpx</var> + <var>x</var> cos <var>cb</var>
 + <var>y</var> sin <var>cb</var>, <var>cpy</var> +
 <var>x</var> sin <var>cb</var> + <var>y</var> cos <var>cb</var>).</p>
 
 <p>When a relative <strong>h</strong> command is used,
 the end point of the line is (<var>cpx</var> + <var>x</var> cos <var>cb</var>,
@@ -548,17 +548,17 @@ the end point of the line is (<var>cpx</
     indicates that relative coordinates will follow. Multiple
     sets of coordinates may be specified to draw a
     polybézier. At the end of the command, the new
     current point becomes the final (x,y) coordinate pair used
     in the polybézier.</td>
   </tr>
 </table>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <p>When a relative <strong>c</strong> or <strong>s</strong>
 command is used, each of the relative coordinate pairs
 is computed as for those in an <strong>m</strong> command.
 For example, the final control point of the curve of
 both commands is (<var>cpx</var> + <var>x</var> cos <var>cb</var>
 + <var>y</var> sin <var>cb</var>, <var>cpy</var> +
 <var>x</var> sin <var>cb</var> + <var>y</var> cos <var>cb</var>).</p>
@@ -628,17 +628,17 @@ this example as SVG (SVG-enabled browser
     absolute coordinates will follow; <strong>t</strong>
     (lowercase) indicates that relative coordinates will
     follow. At the end of the command, the new current point
     becomes the final (x,y) coordinate pair used in the
     polybézier.</td>
   </tr>
 </table>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <p>When a relative <strong>q</strong> or <strong>t</strong>
 command is used, each of the relative coordinate pairs
 is computed as for those in an <strong>m</strong> command.
 For example, the final control point of the curve of
 both commands is (<var>cpx</var> + <var>x</var> cos <var>cb</var>
 + <var>y</var> sin <var>cb</var>, <var>cpy</var> +
 <var>x</var> sin <var>cb</var> + <var>y</var> cos <var>cb</var>).</p>
@@ -702,17 +702,17 @@ command.</p>
     <strong>cy</strong>) of the ellipse is calculated
     automatically to satisfy the constraints imposed by the
     other parameters. <strong>large-arc-flag</strong> and
     <strong>sweep-flag</strong> contribute to the automatic
     calculations and help determine how the arc is drawn.</td>
   </tr>
 </table>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <p>When a relative <strong>a</strong> command is used, the end point
 of the arc is (<var>cpx</var> + <var>x</var> cos <var>cb</var>
 + <var>y</var> sin <var>cb</var>, <var>cpy</var> +
 <var>x</var> sin <var>cb</var> + <var>y</var> cos <var>cb</var>).
 The effective value of the x-axis-rotation parameter is
 also affected by the current bearing: it is computed as
 <var>x-axis-rotation</var> + <var>cb</var>.</p>
@@ -785,17 +785,17 @@ src="images/paths/arcs02.png" width="426
 <p class="view-as-svg"><a href="images/paths/arcs02.svg">View
 this example as SVG (SVG-enabled browsers only)</a></p>
 
 <p>Refer to <a
 href="implnote.html#ArcImplementationNotes">Elliptical arc
 implementation notes</a> for detailed implementation notes for
 the path data elliptical arc commands.</p>
 
-<div class="ready-for-wg-review">
+<div class="ready-for-wider-review">
 
 <h3 id="PathDataBearingCommands">The bearing commands</h3>
 
 <p>The bearing commands (<strong>B</strong> or <strong>b</strong>)
 set the current bearing, which influences the orientation of
 subsequent relative path commands:</p>
 
 <table class="PathDataTable">
diff --git a/master/publish.xml b/master/publish.xml
--- a/master/publish.xml
+++ b/master/publish.xml
@@ -1,24 +1,26 @@
 <!-- Publication script configuration for SVG 2. -->
 
 <publish-conf xmlns='http://mcc.id.au/ns/local'>
   <title>Scalable Vector Graphics (SVG) 2</title>
   <short-title>SVG 2</short-title>
-  <maturity>WD</maturity>
+  <maturity>ED</maturity>
   <output use-publish-directory='true' publish-directory='build/publish'/>
 
   <!--
     Uncomment the publication date when it is time to publish on
     http://www.w3.org/TR/.  While an Editor's Draft, leave this
     commented out and the last commit date will be used as the
     document's date.
     -->
   
+  <!--
   <publication-date>2014-02-11</publication-date>
+  -->
 
   <versions>
     <cvs href='https://svgwg.org/svg2-draft/'/>
     <cvs-single href='https://svgwg.org/svg2-draft/single-page.html'/>
     <this href='http://www.w3.org/TR/2014/WD-SVG2-20140211/'/>
     <this-single href='http://www.w3.org/TR/2014/WD-SVG2-20140211/single-page.html'/>
     <previous href='http://www.w3.org/TR/2013/WD-SVG2-20130618/'/>
     <latest href='http://www.w3.org/TR/SVG2/'/>
diff --git a/master/types.html b/master/types.html
--- a/master/types.html
+++ b/master/types.html
@@ -4064,17 +4064,17 @@ interface <b>SVGGraphicsElement</b> : <a
           The farthest ancestor <a>'svg'</a> element. Null if the current element
           is the <a>outermost svg element</a>.
         </div>
       </dd>
     </dl>
   </dd>
   <dt class="operations-header">Operations:</dt>
   <dd>
-    <div class="ready-for-wg-review">
+    <div class="ready-for-wider-review">
     <dl class="attributes">
       <dt id="__svg__SVGGraphicsElement__getBBox" class="operation first-child"><a class="idlinterface" href="types.html#InterfaceSVGRect">SVGRect</a> <b>getBBox</b>(optional <a href="#SVGBoundingBoxOptions">SVGBoundingBoxOptions</a> <var>options</var>)</dt>
       <dd class="operation">
         <div>
           <p>Returns the result of invoking the <a href="coords.html#BoundingBoxes">bounding box algorithm</a>
           for the element, with <var>fill</var>, <var>stroke</var>, <var>markers</var>
           and <var>clipped</var> members of the <var>options</var> dictionary argument
           used to control which parts of the element are included in the bounding box,
Received on Wednesday, 12 February 2014 06:42:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:55 UTC