[whatwg] Canvas line styles comments

[Ian Hickson]

On Tue, 19 Jun 2007, Philip Taylor wrote:
> 
> For lineJoin, the term "joins" is used but not properly defined
> (except indirectly as "where two lines meet"). Given the
> implementations, this should be something like:
> """
> For each subpath, a join exists at the point shared by each
> consecutive pair of lines. If the subpath is closed, then a join also
> exists at its first point (equivalent to its last point) connecting
> the first and last lines in the subpath.
> """

Added something close to that.


> There are no conformance criteria for rendering lineCap.

Fixed, sort of.


> The definition of 'miter' is incorrect: it seems to say the miter gets 
> truncated into a more-sided polygon if it would exceed miterLimit, but 
> the behaviour of implementations is to revert to 'bevel' rendering 
> instead.
> The definition of 'round' for lineJoin is slightly incorrect, since it 
> talks about adding a filled arc when it needs to be a filled circle 
> sector (or an arc plus a triangle).

Fixed.


> The definition for 'stroke' says "The stroke() method must stroke each 
> subpath of the current path in turn, using the strokeStyle, lineWidth, 
> lineJoin, and (if appropriate) miterLimit attributes". That list should 
> include lineCap.

Fixed.


> "The lineWidth attribute gives the default width of lines, in coordinate 
> space units." - why "default"?

Removed.


> The expression "the point where the inside edges of the lines touch" 
> doesn't make sense to me. (Actually, it did make sense for a while, but 
> then I realised it was an incorrect sense).

Fixed.


> I think the problem is in being ambiguous about the distinction between 
> geometric lines (which are infinitely thin and just a description of a 
> path through space) and graphical lines (which are a thick filled shape, 
> defined by their edges (which are geometric lines)) - the rendering 
> details are describing how to convert the first sort of line into the 
> second sort of line, but that seems to be made unclear.
>
> I believe it would be clearer to use the term "line" only in the first 
> sense (so ctx.lineTo adds a line to the subpath, and ctx.fill fills the 
> area enclosed by the path's lines, etc), and the term "stroke" [or a 
> better name, since I don't really like this one, but I can't think of 
> anything else] for the second sense (so ctx.stroke calculates and 
> renders strokes, which are shapes that are based on the path's lines and 
> widths and caps and joins). There also seems to be a danger of confusion 
> between lines (like a single straight/arc/Bézier line segment) and 
> subpaths, like in the definition of what lineCap applies to.

Are there any bits that are really still confusing? I'd rather not make 
sweeping changes to the terminology like this, I'd almost certainly get it 
wrong and make matters worse.

(I agree that this section has suboptimal conformance requirements. It's 
one of the first sections I wrote for this spec, and it shows. However, 
I'd like to limit the fixes to blatent mistakes and areas where interop is 
failing due to the spec.)


> (Is it worth having diagrams (kind of like 
> http://canvex.lazyilluminati.com/misc/linejoin.png), so normal people 
> can tell what the interesting bits here actually mean? Or is that best 
> left for tutorials and user reference guides?)

Diagrams would be great. I plan on doing a pass with adding diagrams and 
examples much later, once the spec is stable, but feel free to provide 
unstylised diagrams in the meantime. :-)


> There are some other issues I'm currently aware of, possibly requiring 
> more complexity:
> 
> What happens when a stroked path has zero length, in terms of drawing 
> the line caps/joins? In particular, square caps are impossible because 
> the line does not have a defined direction (assuming we're not having 
> dashed paths for now). In Firefox 2 and Opera, nothing is drawn for 
> zero-length paths. In Firefox 3 and Safari, round caps/joins are drawn 
> (because the direction of the line doesn't matter in that case, so the 
> output is well-defined), and nothing else is drawn.

I've added a line that says that zero-length line segments and pruned 
before stroking, which as far as I can tell makes Firefox 2 and Opera's 
behaviour correct.


> What happens when a stroked path contains a line with zero length, 
> between non-zero-length lines? As far as I can tell, zero-length lines 
> never have any effect (e.g. line-joins get drawn between two 
> non-consecutive non-zero-length lines if they have only zero-length 
> lines between them, so the earlier suggestion for defining 'join' is 
> wrong) - except when the path has no non-zero-length lines in it, in 
> which case the presence of a zero-width line causes round caps to be 
> drawn in FF3/Safari. (...except in FF3 when it's a zero-length 
> quadratic/Bézier curve). Maybe it'd be best just to require that lines 
> with zero length are never added to the subpath - so if you don't add 
> any non-zero-length ones, the subpath will be empty and won't get drawn, 
> which is slightly incompatible with Safari/FF3 but hopefully easy to fix 
> in them, and compatible with Opera/FF2.

That's basically what the spec says now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'