Mike Swanson

March, 2006

  • Mike Swanson's Blog

    MIX06 Session Recordings

    • 9 Comments

    The MIX06 conference in Las Vegas is over, and it was an outstanding event. Feedback has been almost universally positive, and attendees are encouraging us to do this again. MIX06 was a smaller, more intimate conference, and many of our presentations and panels were driven by our customers and partners. Personally, I loved the one-on-one engagement that I had with attendees. It's a fantastic way to get a lot of great product feedback and actually meet the people who are building on top of and extending our technology.

    If you weren't able to join us in Vegas, don't worry. We're working to get around 50 sessions of content across nearly three days prepped and published for your online enjoyment. We expect to finish the post production process in the next three to four weeks. Then, we'll be hosting everything for six full months, for free, for anyone (not just attendees). In addition to watching the video for each presentation, you'll be able to download each session for offline viewing.

    Since MIX06 is a web conference, we're delivering all of the post show content online. We won't be producing DVD sets like we did for PDC05. I've grabbed a screen shot of the current web interface, although I'm sure it'll change a little bit before we launch.

  • Mike Swanson's Blog

    Miter Limits in Illustrator and WPF

    • 9 Comments

    Continuing my series of posts on "gee, that's obscure," I thought I'd document the difference between miter limits in both Adobe Illustrator and the Windows Presentation Foundation (WPF). I ran into these differences while building my export plug-in, and they caused me a bit of pain.

    Both Illustrator and WPF support miter limits for connected line segments. Miter limits control how "pointy" your segments look where they're joined. Because miter limits in both Illustrator and WPF are relative to the thickness of the line, they are naturally more noticeable with larger stroke widths. For thick line segments that meet at very acute angles, the join can be very pointy...so much that it can look quite ridiculous. Miter limits allow you to control when Illustrator and WPF decide to trim—or bevel—the join.

    The two illustrations below show example miter limits and how they're handled by both systems. The actual content that is rendered to the screen is shown in black. Blue represents the line centers.

    Before we talk about limits, we need to understand the miter length. Miter lengths are measured differently between Illustrator and WPF. In Illustrator, the miter length is measured from the inside of the join to its outside point. In WPF, it's measured from the center of the join to its outside point. This effectively means that a miter length in WPF is half of what it would be in Illustrator.

    Miter limits are represented by ratios. In Illustrator, the default miter limit is 4, and the limit specifies a threshold. Essentially, a miter limit of 4 says: "if the miter length of this join is greater than 4 times my line thickness, bevel it; otherwise, allow the mitered join." In the left diagram, the dashed horizontal lines are each one line thickness away from each other. Notice that the miter length of the first join exceeds 4 times the thickness of the line. Because of this, Illustrator will bevel the join. The miter length of the second join falls below 4, so it is mitered (pointy). So, miter limits in Illustrator represent an either/or situation; either the line is beveled at the center of the join, or it is mitered. There is no in between.

    In WPF, the miter limit is used to clamp the miter length. The miter limit represents a ratio of the miter length to half of the line's thickness. In the right diagram, the dashed horizontal lines are each one half line thickness away from each other. The first join has a miter limit of 3, so it is beveled (trimmed) at 3 times one half of the line thickness. The second join is beveled at 2 times one half of the line thickness. Notice that—unlike Illustrator—miter limits in WPF are not treated as a threshold; they simply specify where to limit the miter.

    It's certainly possible to mathematically determine an equivalent miter limit between a single join in Illustrator and WPF. But, because most figures are made up of many joined line segments, and miter limits in WPF are set on the figure, there is no way to specify different miter limits for each join. This is precisely why my Illustrator to XAML Export Plug-In takes a conservative approach and specifies a miter limit of 1, thereby preventing the extremely pointy miters that would result for very acute angles. In retrospect, I suppose that setting a miter limit that is half that of Illustrator's might be a reasonable alternative.

    So, if you do notice some extra beveled lines in your exported artwork, you should first try removing the miter limit setting from your XAML. If the results are unsatisfactory, you'll need to play with the setting until you achieve visually desirable results.

    Special thanks to fellow Microsoft employee, Anthony Hodsdon, for his help in clarifying the WPF behavior.

  • Mike Swanson's Blog

    New IE7 Build and Developer Toolbar Update

    • 0 Comments

    The IE team released the Internet Explorer 7 Beta 2 Preview build to coincide with the MIX06 conference. You can find more details about the release on the team's blog post.

    They've also released an updated beta 2 version of their Internet Explorer Developer Toolbar (more). I've posted about this very handy toolbar before, and if you do web development, this is definitely something you'll want to add to your toolbox.

  • Mike Swanson's Blog

    Managed Code on Xbox 360

    • 1 Comments

    Yes, you read that correctly. In case you missed the announcement at the Game Developers Conference earlier this week, be sure to read about Microsoft XNA, specifically the XNA Framework. Here's the juicy part:

    A custom version of the Common Language Runtime is being built to enable the execution of managed code on an Xbox 360, and at GDC the XNA team showcased some exciting demonstrations of games which were built on an early version of this technology.

    More information from Brian Keller. Awesome!

  • Mike Swanson's Blog

    Improved Gradient Conversion from Illustrator to WPF (and DrawingBrush)

    • 0 Comments

    I put my Flash experimentation on hold this past weekend and decided to add a little bit of functionality to my Adobe Illustrator to WPF/XAML Export Plug-In. The current version is still 0.14, and it works well with the February CTP of WPF. However, if you're interested in gradients or DrawingBrushes, read on.

    First, I'd like to mention the mental retching that I experience by moving between these two projects. The Illustrator plug-in is written in C/C++, a language that I mostly forgot about nearly six years ago. Additionally, the Illustrator object model is different enough from WPF that it takes some cognitive gymnastics to recall how an element in Illustrator maps to another element (or elements) in WPF. The plug-in has no WPF dependencies, and it essentially spits out XML strings.

    The Flash stuff, on the other hand, is a completely different world. It's all written in C#, has an actual WinFX dependency, uses the WPF object model, and serializes out to XAML. The managed code development environment of C# and WinFX is so much more productive as to be almost ridiculous; I make a lot more progress in a shorter period of time. The Flash file format is interesting, and the data storage formats can be tricky, but it's nothing that a little thinking can't overcome. But I digress...

    The Illustrator plug-in has converted gradients since its first version. However, as soon as you transformed the artwork from its original location on the page, the artwork would transform properly during export, but the gradients most definitely wouldn't. If you had a bunch of small gradients, this might not have been noticeable, but for anything significant, it would look very ugly. Due to differences between the Illustrator and WPF coordinate systems, I could never find a way to make an accurate conversion. You'll be happy to know that gradient transformations are now fully supported, and in my initial testing, they work as-expected. I'd still like to simplify the resulting XAML a bit, but it's good enough for now.

    I've also added support for Illustrator's gradient midpoints. If you look at the gradient tab in Illustrator (diagram to the right), you'll see that in addition to the five colors I've defined along the bottom, there are also small diamond-like sliders above the gradient. You can adjust these sliders by dragging them, and they represent the point where the color is a 50/50 mix of its adjacent colors. Illustrator allows these midpoints to fall anywhere between 13 and 87 percent of the distance between the two colors, and by manipulating them, you can achieve some nice effects.

    Well, WPF doesn't support this midpoint concept for gradients. So, to achieve a similar result, the export plug-in looks at the midpoint value, and if it isn't exactly 50% (the default), it adds another WPF gradient stop at the correct location with a color that is computed to be a 50/50 mix of the colors to either side. If you look at the sample gradients in the diagram, version 0.14 shows "blurrier" yellow and blue bands, where the test version of 0.15 looks much more like the gradient as defined in Illustrator. The improvement is due entirely to the additional gradient stops.

    If you were to compare the exported XAML between version 0.14 and version 0.15 for this same gradient definition, version 0.14 would have five colors. Version 0.15 outputs eight. Why eight instead of nine? After all, if you add the five colors and the four midpoints, shouldn't there be nine unique color stops? There would be, except that the third midpoint between red and blue happens to lie at exactly 50%. Since the normal WPF color blending works just fine for a midpoint of 50%, the plug-in simply skips it.

    The last little improvement is to add support for exporting artwork to a DrawingBrush. If you're not creating a collection of interactive shapes, there's no reason to pay the penalty of full UI elements. Drawings are smaller and faster than shape objects, because they offer fewer features. If you're going to use your Illustrator artwork to define the look of a single UI element (like an icon), then it probably makes sense to use the DrawingBrush format to fill the icon with the exported XAML. If you're unclear about the differences, it's worth reading the Drawing Objects Overview and Shapes and Basic Drawing in the Windows Presentation Foundation from the Windows SDK documentation.

    Since I don't want to pop-up a dialog box during my testing, version 0.15 of the plug-in currently exports to DrawingBrush format if you hold down the right shift key during export. Note that I haven't added clipping support to the DrawingBrush export, so that won't work at all. There are probably other DrawingBrush bugs that I haven't encountered yet, so please let me know if you find anything.

    So, after all of that, if you're willing to put up with possible DrawingBrush and/or gradient bugs, feel free to help test version 0.15 of the plug-in.

    Enjoy!

Page 1 of 2 (6 items) 12