Title Image

Don Xml's Grok This

The home of Don Demsak
Welcome to Don Xml's Grok This Sign in | Help
in Search

This Blog

Syndication

Site Sponsors

DonXml's All Things Techie

Absolute Versus Relative Coordinates in PathSegments

I’m trying to convert some more complex SVG Paths to the equivalent XAML PathSegement elements, and have run into another major stumbling block that I can’t seem to find an easy way around.  In SVG, when describing a path, we can mix relative and absolute positioning when defining the path data.  All the XAML PathSegment examples I’ve found only use Absolute coordinates for their points.  I would think that there is some way to switch to relative coordinates in the PathSegment, but haven’t figured out a way to do this.

In SVG the data attribute of the path element would be something like this: d="M 0,40 c 10,25 0,50 100,100z".  This basically says start at coordinate 0,40, create a bezier segment using the following 4 points, the starting position (0,40),  Point1 is (10,25) relative to the starting position, Point 2 is (0,50) relative to the starting position, and the ending position (aka Point 3) is (100,100) relative to the starting position.  The z just closes the path.

Now in XAML I’d like to do the same:

        <PathGeometry>
          <PathGeometry.Figures>
            <PathFigureCollection>
              <PathFigure>
                <PathFigure.Segments>
                  <PathSegmentCollection>
                    <StartSegment Point="0,40"/>
                    <BezierSegment Point1="10,25" Point2="0,50" Point3="100,100"/>
                    <CloseSegment />
                  </PathSegmentCollection>
                </PathFigure.Segments>
              </PathFigure>
            </PathFigureCollection>
          </PathGeometry.Figures>
        </PathGeometry>

But this example is in Absolute Positioning.  Point1 is coordinate (10,25) instead of the desired coordinate of (10,65).  I could just do that math to translate the points, but I would think that there is some declarative way to get the BezierSegment to switch to relative positioning.

DonXML

Published Wednesday, November 05, 2003 8:18 PM by donxml
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

Joe Beda said:

Unfortunately, this is true, Don.

The way that we define a Geometry and a PathGeometry means that it would be difficult for us to parameterize it based on some parent viewport size.

In general you will find that relative units, where they are supported, are relative to the parent control size instead of some grandparent viewport size.

This was done to make size of a subtree more predictable. We wanted to be able to ask a Geometry, "How Big Are You?" without that geometry having to take in to account the viewport that it is hosted in.

We divereged from SVG wrt the releationship between pixel and inch for these very same reasons. Our pixel unit isn't really a physical pixel but is rather a "virtual" pixel that is locked forever at 1/96th of an inch.

Joe
November 6, 2003 9:14 AM

Drew Robbins said:

I'm not as far along as you are in groking XAML, but last night I was playing with the various Transforms. Can you use a TranslateTransform to achieve relative positioning?
November 6, 2003 9:24 AM

DonXML said:

I don't think you can use a TranslateTransform within a PathSegment (at least it would seem very strange to me if it did). I'll double check, but I doubt that you can apply it to a PathSegment. It is usually for complete graphical objects (like a shape or a complete path).

DonXML
November 6, 2003 9:37 AM

Jim Ley said:

The SVG pixel isn't a physical pixel either Joe, the pixel definition comes from the CSS spec, although it's more virtual than the the one described here. It's from the CSS2 definition of pixel http://www.w3.org/TR/REC-CSS2/syndata.html#length-units

November 6, 2003 9:49 AM

Joe Beda said:

I just realized that I misread your post! There are two types of relative support here we are talking about:
1) Relative units (%) to the viewport.
2) Relative segements in a path.

I was talking to the first and I think that you were talking to the second. I apologize for the confusion!

The reason that we didn't support #2 natively in the PathSegments is that mostly because we support animated points in a path. For example, you can animate the start point of your path. If we had relative pathe segment support, than this would imply that all relative segments after that animate segment would be aninated also, which might be strange to some. We decided to eliminate relative path segments in the core OM to step around this problem and to reduce the surface area of our object model (less to develop, test, doc, etc.)

Do you think that this is super limiting?

As for "virtual pixels", the reference that I'm talking to is here: http://www.w3.org/TR/SVG11/coords.html#Units. It is up to the user agent that is hosting SVG to decide the size of a pixel relative to an inch. That means that if that varies, your content will probably not work right if you mix px and inch units. CSS2 may recommend to use a virtual pixel here, but the SVG spec lets the user agent decide. We decide to lock this in a 1/96th of an inch because this is the resolution that most Windows machines think the monitor is running at right now. In other words, if the developer ignores inches and just uses px everywhere, then the result will be, by and large, the same as it has always been on the vast majority of systems. If however, the user uses a 204dpi device, the app will not break.

Joe
November 6, 2003 10:02 AM

Joe Beda said:

I left some stuff out!

We do handle relative path segments in our string->Geometry converter. Those are converted directly to absolute segments in the OM.

Wrt a TranslateTransform in a Path definition, we don't support this. However, we do support a transform on a Geometry object. You can create multiple PathGeometry objects, put a transform on those and then Union them via a GeometryCollection. This isn't exactly what you are asking for, but it is a cool capability that SVG doesn't have an equivalent for (I think).

Joe
November 6, 2003 10:04 AM

Jon Galloway said:

XAML and SVG, separated at birth? Windows Presentation Foundation introduced vector graphics as a first
June 5, 2007 2:11 AM

Leave a Comment

(required) 
(optional)
(required) 
Submit

About donxml

I’m an independent consultant, specializing in .Net solutions architecture, based out of New Jersey who also doubles as an evangelist for XML, Domain Driven Design, enterprise architecture and .Net. I do not work for Microsoft, the W3C or any other big company that you may know of (at least not yet). I’ve been an indie for over ten years, and although I’ve been tempted a couple times to take a job with companies like Microsoft, I’ve haven’t found something better than my current situation. I work mostly with the large pharmaceuticals that are based here in New Jersey, and usually find myself on long term contracts. Definitely not the prototypical indie consultant, but it lets me dedicate time to my non-income generating activities like the developer community stuff, plus financing open source projects like XPathmania and MVP-XML. If you would like to talk to me about doing some contract work, just contact me via the contact page. My rates vary widely, depending on lots of different variables, but mostly distance from Jersey, and type of work. Plus, I’ve been known to donate some of my code for various projects.
Powered by Community Server, by Telligent Systems