This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html Multipage: http://www.whatwg.org/C#path2d-objects Complete: http://www.whatwg.org/c#path2d-objects Referrer: https://www.google.com/ Comment: Path merging should not be part of addText() or addPathByStrokingText(), it is very expensive computationally. Also, it may not be what the user wants. For example, in the given example of the Q and p overlapping, what if the user *wants* a knockout where the glyphs overlap? Instead I believe path merging should be removed from these two functions. Instead I believe a simplify() function should be added to Path2D which. The simplify() function performs the merge path algorithm as you've described it here, but can perform that operation on any set of paths. That way the user of the API gets to decide when to call the expensive operation Path2D.simplify(), and simplify() can be applied to more than glyph paths. For reference see the SkPathOps simplify(): https://github.com/google/skia/blob/master/include/pathops/SkPathOps.h Posted from: 2620:0:1013:0:2e44:fdff:fe2d:922d User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 Safari/537.36
Sorry, I wasn't logged in when I reported this.
If we don't do the path merging, we have to define what the result will be, which means defining font path handling, which seems like WAY more work.
(In reply to contributor from comment #0) > Specification: > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas- > element.html > Multipage: http://www.whatwg.org/C#path2d-objects > Complete: http://www.whatwg.org/c#path2d-objects > Referrer: https://www.google.com/ > > Comment: > Path merging should not be part of addText() or addPathByStrokingText(), it > is > very expensive computationally. Also, it may not be what the user wants. For > example, in the given example of the Q and p overlapping, what if the user > *wants* a knockout where the glyphs overlap? Would it make more sense that the functionality of addText is replace with a function that returns a list of paths (each representing a glyph that can be filled with any winding rule) along with an offset? > Instead I believe path merging should be removed from these two functions. > Instead I believe a simplify() function should be added to Path2D which. The > simplify() function performs the merge path algorithm as you've described it > here, but can perform that operation on any set of paths. That way the user > of > the API gets to decide when to call the expensive operation > Path2D.simplify(), > and simplify() can be applied to more than glyph paths. Would simplify take a winding rule then?
(In reply to rcabanie from comment #3) > Would it make more sense that the functionality of addText is replace with a > function that returns a list of paths (each representing a glyph that can be > filled with any winding rule) along with an offset? That would work too, do you see an advantage of the list-of-paths over addText? > > Would simplify take a winding rule then? Yes, it should take a winding rule.
(In reply to Joe Gregorio from comment #4) > (In reply to rcabanie from comment #3) > > Would it make more sense that the functionality of addText is replace with a > > function that returns a list of paths (each representing a glyph that can be > > filled with any winding rule) along with an offset? > > That would work too, do you see an advantage of the list-of-paths over > addText? The advantage is that you don't need to resolve overlapping path segments. You would just need to make sure that the winding of the paths for each glyph are oriented so that any winding rule can apply.
> Also, it may not be what the user wants. For example, in the given example > of the Q and p overlapping, what if the user *wants* a knockout where the > glyphs overlap? Then you'd create two paths and add them together manually using future Path APIs for path manipulation. That isn't the common case (by a very wide margin), so it's not the easier case either. I don't really understand how you want addText() to work if it doesn't do path merging.
(I spoke with Joe offline, he said he'd get back to us here.)
Joe, any updates on this?
Closing issue since it is no longer relevant: addText and addPathByStrokingText() were removed from the spec.