- From: tatarize via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Aug 2020 08:25:24 +0000
- To: public-svg-issues@w3.org
Yeah, I'm kind of leaning towards not dismissing it out of hand. My primary objection was the idea of implicit moves. Since all my objects can well lack a move and have completely different meaning. If I have a Line object between (Null->1,1). I can affix this to the end of *any* path and it makes perfectly logical sense. After you do this shape, you line to 1,1. But, if my `Null` there is required to be 0,0. Then if I affixed that to the end of an object, it also makes perfectly logical sense, but different sense. It means I appended a subpath to this path that goes from 0,0 to 1,1. And, the original meaning is not possible to express. My line path fragments can have a start point or lack a start point. If they have one they are a drawable line, with an implicit move to the start point. Though concatenating them tends to require validation. Since the end point of the current path is not necessarily the start point of the appending fragment. I side with the original endpoint rather than fragment start point, unless the original endpoint is Null. Moissinac's (@moissinac) proposal provides a few concrete examples of the utility of this that were not previous offered or discussed. Namely that all holes in objects will always duplicate the path data. And if the programs knew these path-fragments were the same thing in both, you could edit one, while also editing the other. Now, clearly there are issues with the proposal, which likely they figured out and hence the new implementation they offer up. The textual code will often not include the start position. `L1,1` is alone ambiguous. This is why I print that as `M0,0L1,1` if it had a start position known, or `L1,1` if it does not (this too is kinda ambiguous since M0,0L1,1 could mean Move(0,0) Line(0,0->1,1) with an explicit rather than implicit move). You are simply given the line-to and the destination. Where you came from is not given. In the analysis they correctly gave the graph explanations that you could absolutely take sections of graph, give them a name and play them back in either forwards or backwards order. Since this section would be named and we'd know it's the same section, we could absolutely be able to edit it as a single unit. The problem here is that reversing a fragment is not always a stroll in the park. Take the fragment `L1,1` what is that reversed? Well, it's actually `M1,1L<Null>` sort of. If we only know where that line is going to and the operation, and we reverse it, we now only know where it came from. We do not know where it's going. Kind of strange things also happen when you reverse a path segment that is closed with a non-zero path close. You sort of have to draw that implied line segment, and float the Z back to the end in the reversed, or you get a weird shape which is cycled wrong (the line part of the Z goes at the front, but the actual Z command with no length remains at the end).  You'll notice in the discussion there that isn't really an svg path or really a set of them. It's actually a sort of graph in graph theory, of three loops. This would be really kind of useful, but kinda of impossible to represent. Since you're actually taking the destination of the previous segment. If we have the path, `M0,0 10,10 20,0 z`. If your shape was reusing the segment from z to M, you are clearly shooting yourself in the foot. But, also, if your path is reusing the segment from 20,0 to z, you're again shooting yourself in the foot. In the simple triangle, you can basically only use maybe 0,0 to 10,10. However in that case the command there is an M with the 0,0. So you'd either be forcing the new subpath, by demanding the M there, or interpreting it as the method of connection between the two points. And if you're copying the 10,10 to 20,0, it's not specified but it's an L command there. But, you can only kinda do this if the operation is between the two different points. The second implementation of superpath has a nicer and easier syntax. Basically you id a bit of path, and you can reuse it. It's basically just string based compression thing, except that you can modify the object and it would modify both copies. Though there's likely some ambiguity there too. ---- While I absolutely think discussions of path fragments is worthwhile, and they are nice enough things at the low programming level, but some of this stuff seems like it's kinda trying to build graph theory into SVG. I'd love a good SVG-esque way to represent graphs but the need for some path fragments to go backwards and the oddities that come with reversing that. I'm not sure there'd be any way to easily fragmentize a path on the fly. Since the thing we really want is <Node><Segment><Node><Segment><Node> starting and ending with nodes (with segments having the implied operations). SVG offers us <Operation><Stuff><Endpoint>. And it's a little hard to cut and paste that into being a proper graph. It takes a lot of work. And you'd kinda have to modify points into nodes, since you can kinda reuse them. And it seems to spiral into something useful but ultimately not SVG. -- GitHub Notification of comment by tatarize Please view or discuss this issue at https://github.com/w3c/svgwg/issues/780#issuecomment-669788494 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 6 August 2020 08:25:26 UTC