Partager via

XPS Specification v0.8 Changes

  • Article

Since the release of version 0.75 of the XPS Specification at PDC, we've continued the process of incorporating feedback, finalizing certain design details called out in the spec previously, and clarifying a number of areas that were not as clear as we intended. Our goal is to release a v0.8 update to the specification by the end of this calendar year, but we wanted to start posting about important changes that are happening in a more dynamic way. To that end, we're going to start blogging changes that we feel may be important to users of the XPS Specification (and Open Packaging Conventions) along the way.

To get that started, we wanted to summarize a number of those changes that have already been made to the XPS Specification for the next version. Questions are welcome at xpsinfo@microsoft.com.

CombinedGeometry & GeometryGroup

After a lot of thought and feedback, we've decided to remove these elements from the specification. CombinedGeometry provided a simpler mechanism of expressing complex geometries in markup, but proves to be a fairly high implementation burden for consumers. Since the same rendering effects can be achieved through the use of simple PathGeometry elements, we decided to remove this element. For GeometryGroup, it's primary reason for existence was to allow grouping of PathGeometry and CombinedGeometry elements into a single geometry. With the elimination of CombinedGeometry, it made sense to remove this element as well.

"Empty" Documents

We received a number of questions on whether it was legal to have a FixedDocumentSequence element containing no DocumentReference elements (and corresponding FixedDocument parts) or a FixedDocument element containing no PageContent elements (and corresponding FixedPage parts). We are updating the spec to state that one FixedDocument and one FixedPage are REQUIRED.

ResourceDictionary Forward References

Forward references (references to resources defined following the reference) are no longer allowed. Specifically:

  • Any reference to a resource will only be valid after the definition of the resource.

  • x:Key within a resource dictionary MUST be unique

  • A resource definition MAY reference a previously defined resource, either in an ancestor ResourceDictionary, or in the same ResourceDictionary (but MUST be before the referencing definition)

  • x:Key MAY redefine a previously defined x:Key for the local scope. In that redefinition, it is valid to refer to the previously defined x:Key, e.g.:

    <Canvas>
    <Canvas.Resources>
    <ResourceDictionary>
    <Path x:Key=”Foo” ... />
    </ResourceDictionary>
    </Canvas.Resources>
    <Canvas>
    <Canvas.Resources>
    <ResourceDictionary>
    <VisualBrush x:Key=”Foo” Visual=”{StaticResource Foo}” ... />
    </Canvas.Resources>
    </Canvas>
    </Canvas>

Canvas EdgeMode Attribute Rename

The attribute EdgeMode for Canvas element has been renamed RenderOptions.EdgeMode. This attribute forces rendering behavior for the contents of the Canvas to be aliased (value of "Aliased"). Normally rendering behavior is implementation-defined. In the Windows Presentation Foundation, anti-aliased rendering is the normal behavior.

Pixel Snapping

We've added a new attribute to the Path element to allow snapping to device pixels. The following text has been added to the specification:

Consumers or viewers that perform anti-aliasing MAY “snap” those control points of the path that are situated on the path bounding box to whole device pixels if the ignorable SnapsToDevicePixels attribute specifies the value ‘true’.

PrintTicket Under Color Processing Setting

We've added the following PrintTicket setting for under color processing:

Comments

  • Anonymous
    February 21, 2007
    The comment has been removed