Re: Does PATH need a new attribute?

The problem with these situations is solvable, isn't it?  You just need to
circularly shuffle the points in the path so that no connected sub-path
isn't split across a Move.

http://jsfiddle.net/30raz1r4/2/

I am not familiar with the CGM format, so perhaps there are cases where
this solution wouldn't work. But in general we are not using any nasty
hacks and it seems to me the integrity of the shape/diagram is maintained.

Paul


On 17 April 2015 at 09:46, Smailus, Thomas O <Thomas.O.Smailus@boeing.com>
wrote:

> First, apologies for sending the message to the wrong list.  I'm blaming
> autocomplete. I'm sending this reply to the correct list as well to get
> broader discussion.
>
> I'm restating the problem and illustrations here for the benefit of the
> www-svg list readers:
>
> In working a project converting paths drawn in the CGM format to SVG, I've
> encountered a problem where there is no easy or direct conversion from
> CGM's path description to SVG's path description, because of the fact that
> SVG always moves the 'region closure point' at each move-to operation (M).
>
> Trying to render this CGM (as bitmap): http://i.imgur.com/2vK2Kmy.png
> The best I can do is this SVG (as bitmap): http://i.imgur.com/nAZzrxX.png
>
> This is the SVG (as SVG), decorated with some additional info about the
> nature of the path:  http://jsfiddle.net/thomassmailus/30raz1r4/
>
> The polygon starts at P1.  Then the drawn edge goes to P2, drawn edge to
> P3, non-drawn edge to P4, and drawn closure of the region back to P1.
>
> > -----Original Message-----
> > From: Doug Schepers [mailto:schepers@w3.org]
> > Sent: Wednesday, April 15, 2015 20:30
> > To: Smailus, Thomas O; w3c-svg-wg@w3.org
> > Subject: Re: Does PATH need a new attribute?
> >
> > Hi, Thomas-
> >
> > Forgive me, I'm just trying to understand more clearly...
> >
> > On 4/15/15 7:21 PM, Smailus, Thomas O wrote:
> > > In working a project converting paths drawn in the CGM format to SVG,
> > > I've encountered a problem where there is no easy or direct conversion
> > > from CGM's path description to SVG's path description, because of the
> > > fact that SVG always moves the 'region closure point' at each move-to
> > > operation (M).
> > >
> > > Trying to render this CGM (as bitmap): http://i.imgur.com/2vK2Kmy.png
> > >
> > > The best I can do is this SVG (as bitmap):
> > > http://i.imgur.com/nAZzrxX.png
> > >
> > > This is the SVG (as SVG), decorated with some additional info about
> > > the nature of the path: http://jsfiddle.net/thomassmailus/30raz1r4/
> > >
> > > The polygon starts at P1.  Then the drawn edge goes to P2, drawn edge
> > > to P3, non-drawn edge to P4, and drawn closure of the region back to
> P1.
> > >
> > > Because SVG's Moveto operation resets the closure point, I cannot put
> > > a simple Moveto in to get from P3 to P4 (to get a non-drawn edge),
> > > because while I do that in the SVG, this starts a new shape.
> >
> > Why doesn't it go from P4 to P1, P2, P3?
> >
> > Is there some semantic I'm missing?
> >
>
> It goes from P1->P2->P3->P4 because that is how the shape was authored and
> exported by the CAD system using its CGM export capabilities.
> Hence my latter comments attempting to short-circuit discussions of 'well
> why isn't it just authored this way...'.  Assume we cannot change the way
> it is authored.
>
> >
> > > So the Lineto closing in SVG (without a Z) gets me back to my actual
> > > closure point - it doesn't close the shape - hence the line-join at P1
> > > is 2 points with butt ends - no mitre join.
> >
> > Really, this isn't a closed shape at all. A closed shape ends at the same
> > coordinates as the origin, and has no intervening movetos, (Arguably,
> it's
> > more complicated even than that, but your shape doesn't even satisfy that
> > simpler criteria.)
>
> Under the SVG paradigm of a move-to starting a new shape,  that is true.
> What we have is a closed shape that has some edges that are not stroked
> and some that are.  The current solution I have is the best way to
> implement in SVG what CGM can do, without doing it fully natively in SVG,
> because SVG doesn't have the ability to 'not stroke' a particular shape
> edge.
>
> >
> >
> > > So my current SVG version of the path of stroking: "M200,750 L500,900
> > > L700,800 M450,400 L200,750" doesn't make a closed shape, because I
> > > need the segment from 700,800 to  450,400 to be a non-stroked edge on
> > > the closed shape.
> > >
> > > How can we create non-stroked edges on closed shapes?  (my current
> > > solution is to draw the shape with stroke=none and lineto all points,
> > > to give me the proper shape to fill, then repeat the path but use
> > > moveto/lineto combinations that get strokes on only the correct edges.
> > > The problem is this doesn't allow for the correct line-joins in all
> > > cases (such as this example illustrates).
> > >
> > > Yes, one could draw this particular shape a different way and be able
> > > to do it-
> >
> > For example:
> >   <path stroke-width="50" fill="none"  d="M450,400 L200,750 L200,750
> > L500,900 L700,800" />
> >
> >
> > In this case, you can also roughly approximate it with the
> > 'stroke-linecap:square' property value, but that's also not a silver
> > bullet and adds other problems.
> >
> >
> > > but that isn't a general solution that works - because the source
> > > is a CGM that is authored the way it is, and doing complex analysis to
> > > "find a way to rearrange the points and stroking such that one can
> > > stroke it correctly in SVG" would be too complex and may not be
> > > solvable.  We need an SVG way that walks the same points as other
> > > drawing formats, and lets us stroke or not stroke the edges as we go.
> >
> > So, what you're identifying is not so much a deficiency of SVG, but a
> > authoring/conversion problem.
>
> It is an SVG deficiency, because SVG has no mechanism to directly describe
> the effect.
> What I've done is a 'work-around' to get a near-good-enough result, but
> it's a kludge.
>
> What is missing from SVG is the ability to define a closed path section,
> and turn off/on the stroking of the edge without interrupting the
> definition of the closed shapes filled area.
>
> In CGM you can, as you proceed around the shape, describe the geometry of
> each shape edge and indicate if that segment is stroked or not.
> In SVG you can stroke or not stroke the entire shape, but not on a
> path-section by path-section basis.
>
> My work-around is to set stroke="none" and then draw the whole shape
> (lines as Lineto) such that I get the filled area when I close it with a Z
> to get the closed shape.
>
> I'm then repeating the path a 2nd time with fill=none, stroke=<color>, and
> using Moveto in order to get passed the path-sections that are not to be
> stroked.
>
> But as we see, the problem is, the line-joins at the path-section
> boundaries don't get done correctly, because Moveto resets the
> closure-point, and the points that are on a non-stroked path-section are
> not line-join, but rather line-cap sort of points.
>
> In the case of the example I'd provided, the effect is that there is no
> mitred line-join, because SVG doesn't/cannot know the points at that
> locations are connected.
>
>
> >
> > I'm not downplaying it; I think it's important that SVG is able to
> > represent the same graphics as WebCGM. But we need to understand the
> > problem domain before we come up with a solution.
> >
> > Can you show us the syntax for the WebCGM shape?
> >
> >
> >
> > > I'm thinking, if I had a time machine,  Moveto should not reset the
> > > closure point, but some other primitive would designate a non-stroked
> > > closure.  But that's water past the bridge, SVG 1.1 is long out and
> > > things would break.
> >
> > When I was first learning path syntax, I thought that "Z" (uppercase)
> > might indicate the first origin/closure point, and "z" (lowercase) might
> > be the proximal origin/closure point, in a parallel with other
> > upper/lowercase path command distinctions; I still think that might have
> > made sense, but you're right that it's too late.
> >
> >
> > > So what can we do in PATH definition that allows one to move the pen to
> > > designate a non-stroked edge, but NOT move the closure point?  U for
> > > 'unstroked line-to' ?
> > >
> > > But that only works for straight line path segments.  What if the
> > > segment of the polygon definition is not a line but one of the other
> > > types (arc, Bezier, etc). What we really need is an ability to turn
> > > stroking ON/OFF along the path definition.
> > >
> > > So maybe S for stroke on, s for stroke off?
> >
> > I'm not strictly opposed to some solution like that, but it is pretty
> > different than anything we've done with path syntax before, and I wonder
> > how much change this use-case merits.
> >
> > Is that how WebCGM solves this case?
> >
> > How common is this in WebCGM?
> >
> > Have you considered using a stroke-dasharray to achieve the same visual
> > effect? This works in Chrome, though it's kinda brittle.
> >
> > <path stroke-width="50" fill="none" d="M200,750 L500,900 L700,800
> > L450,400 Z" stroke-dasharray="558 473 1000" />
> >
>
> If we were authoring something from scratch and trying to figure out "how
> do I author the diagram to get this effect" that would make sense, but I
> don't see that is the way anyone will author large quantities of diagrams,
> in a CAD system,  and especially as there are thousands and thousands of
> legacy diagrams out there that exist in CGM and won't likely get
> re-authored.
>
> The folks that defined the original CGM spec had thought about this and
> argued and decided CGM needed the ability to turn edge stroking off/on
> (pick up the pen/put down the pen) so you can define a path that completes
> a closed-path, with not all of the segments having stroked edges.
>
> A simple example: draw a glass of water - the interior is filled with
> blue, but only 3 of the 4 sides of the polygon are stroked with the black
> of the glass, but the top is open.  You won't want to require for such a
> shape you always must start at a given point to author it.
>
> >
> > I'm inclined this suggest that this is an authoring-tool issue, because
> > you can actually represent the shape you're going for, but if this is
> > really common occurrence in WebCGM, we may need to find some way to
> > address it formally.
> >
> > Regards-
> > -Doug
>
> Fundamentally its not about "can we find some combination of SVG to
> create a visual effect that looks like what the CGM produced", because that
> isn't compatible with utilizing a large base of existing diagrams in CAD or
> CGM format that just need to be converted to SVG.
>
> It's a case of CGM had a reason to have this capability in the format -
> and SVG does not have this capability.  Rather than using a hack - which
> doesn't always work- can we add something to the spec of SVG that gives SVG
> the same capabilities: allow specification of a path in segments and
> controlling the stroking/non-stroking of the path on a segment by segment
> basis (or just a way to say: stroke on, stroke off)?
>
> If we had that, the whole discussion of "if you start at point x, or if
> you draw it this way, etc" goes away.
>
>