25716 2014-05-14 18:28:46 +0000 <canvas>: path merging should not be part of addText() or addPathByStrokingText() 2016-04-21 17:38:28 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#path2d-objects blocked awaiting response from joe to comment 6 (please remove this when replying) P3 normal Unsorted 1 contributor ian annevk cabanier d ian joe junov mike contributor oldest_to_newest 105984 0 contributor 2014-05-14 18:28:46 +0000 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 105985 1 joe 2014-05-14 18:35:38 +0000 Sorry, I wasn't logged in when I reported this. 105998 2 ian 2014-05-14 21:15:55 +0000 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. 106388 3 cabanier 2014-05-19 21:48:08 +0000 (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? 106560 4 joe 2014-05-21 13:40:11 +0000 (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. 106587 5 cabanier 2014-05-21 16:50:41 +0000 (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. 109902 6 ian 2014-08-04 23:28:13 +0000 > 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. 111406 7 ian 2014-09-11 23:01:26 +0000 (I spoke with Joe offline, he said he'd get back to us here.) 125781 8 d 2016-04-08 23:06:43 +0000 Joe, any updates on this? 126008 9 junov 2016-04-21 17:38:28 +0000 Closing issue since it is no longer relevant: addText and addPathByStrokingText() were removed from the spec.