Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

XPS Issues - Ecma International

VIEWS: 8 PAGES: 51

									                 A                     B                 C                                               D                                               E              F
     Reference (major)        Reference           Issue Type Comment                                                                                   Status     Change
                              (clause)            (Editorial/                                                                                                     Applied
                                                  Technical/
                                                  Other
1
     Editorial                Throughout          Technical    Change ―may‖ to ―can‖ or ―might‖, as appropriate. ―may‖ is a particularly              Accepted    WD1.1
                                                               problematic term when used in the negative. Of course, if the use of "may" is
                                                               intended to be normative, "COULD" or "SHOULD" should be used instead.

2
     Editorial                Throughout          Editorial    Various on-going editorial tasks:                                                      Accepted    WD1.2

                                                               Add non-breaking spaces, as appropriate, so that certain line breaks look better.

                                                               Add forward references, as appropriate.

3
     Editorial                Throughout          Editorial    Mark all defining entries in the cross-reference index so they appear in bold in the   Withdrawn   N/A
                                                               index.
4
     Normative References &   Throughout          Editorial    Check all RFCs and other specs referenced in the text to see if they are in the        Accepted    WD1.1
     Bibliography                                              normative references list or bibliography, as appropriate.
5
     Normative References &   Electronic annexes Editorial     Add text mentioning the electronic versions of schemas and their normative status.     Accepted    WD1.1
     Bibliography
6
     Editorial                Throughout          Editorial    Consider replacing cross-references of the form ‗see §s, ―xxx,‖ on page pp‘ with       Accepted    WD1.1
                                                               ‗see §s‘. Page number references are not really relevant in an electronic document,
                                                               and it's not clear that having the clause name as well as number is useful.

7
     Normative References &   Draft 1.0.1, 9.3    Technical    Resolve references to .NET and Windows Presentation Foundation.                        Accepted    WD1.2.5
8 Bibliography
     Colour                   Draft 1.0.1, 15.1.8- Technical   Decide what, if anything, to do about private Microsoft ICC and ―MS00‖ signature.      Accepted    WD1.3
                              15.1.9, I, MS00
9                             signature                        Spun off scRGB gamut definition into new issue 211.
     Conformance              Draft 1.0.1, 2,      Technical   Clause 2, page 3, Software Conformance clause beginning line 20 should explicitly      Accepted    WD1.2.5
                              page 3, line 20                  note that consumers are not required to consume XPS documents that have been
                                                               externally compressed, encrypted or wrapped in any other way such that the
                                                               resulting file does not directly conform to the XPS specification.
10
     Normative References &   Draft 1.0.1, 3,     Editorial    Clause 3, page 5, ISO/IEC 10646:2003 has been added as a normative reference.          Accepted    WD1.2
     Bibliography             page 5                           It was not referenced in the original 1.0 XPS Specification.
11
     Editorial                Draft 1.0.1, 8.1,   Editorial    8.1, page 17, first item, Common Properties clause number appears outside              Accepted    WD1.1
                              page 17                          parentheses.
12
     Editorial                Draft 1.0.1, 8.1,   Editorial    8.1, page 17, Description for Document Structure and Interactivity – ―in order‖ no     Accepted    WD1.1
                              page 17                          longer required at end of 1st sentence now that example has been extracted.

13
               A                 B                 C                                              D                                              E           F
     Reference (major)   Reference           Issue Type Comment                                                                               Status     Change
                         (clause)            (Editorial/                                                                                                 Applied
                                             Technical/
                                             Other
1
     Package             Draft 1.0.1, 9.1,   Technical   9.1, page 19, lines 21 and 22. It seems to say that it is possible to have two or    Accepted   WD1.1
                         page 19, lines 21               more fixed payloads in an XPS document but only one is discoverable through the
                         and 22                          XPS Document start part relationship. Is the intent that the relationship could be
                                                         changed to a different fixed payload? How? And how does this work with the
                                                         DiscardControl part which is not fixed payload qualified but discovered through a
                                                         package relationship.




14
                 A                B                 C                                             D                                           E           F
     Reference (major)   Reference           Issue Type Comment                                                                            Status     Change
                         (clause)            (Editorial/                                                                                              Applied
                                             Technical/
                                             Other
1
     Editorial           Throughout          Editorial   The conformance numbers are the same as they were in the original XPS 1.0         Accepted   WD1.2
                                                         document. There the numbers were based on the chapters in which they originally
                                                         appeared - should they be updated to reflect the clause where they are defined?

                                                         2007-09-26: Reference column in App I is all incorrect as well.




15
     Editorial           Draft 1.0.1, 9.1,   Editorial   9.1, page 20, Thumbnail and StoryFragments parts - the clause number references   Accepted   WD1.1
                         page 20                         appear outside the parentheses. Also need clause references for ICC profile and
                                                         DiscardControl parts.
16
               A                 B                 C                                              D                                                   E               F
     Reference (major)   Reference          Issue Type Comment                                                                                     Status       Change
                         (clause)           (Editorial/                                                                                                         Applied
                                            Technical/
                                            Other
1
     Package             Draft 1.0.1, 9.1.2, Technical   9.1.2, page 23, lines 19-20. States that the reference from the                          Accepted      WD1.1
                         page 23, lines 19-              DocumentReference to a FixedDocument should be a relative URI. Should means
                         20                              optional, and the only alternative is that the URI is absolute, and absolute URIs are
                                                         not allowed in XPS documents. The SHOULD should be a MUST. Technically,
                                                         relative URIs are resolved to a pack URI, and there is no pack URI format that
                                                         refers to the containing OPC container. Also applies to 9.1.3, lines 6-7, and 9.1.4,
                                                         lines 20-21.




17
     Images              Draft 1.0.1,       Technical    9.1.5.1, page 25. APP13 marker (PhotoShop) - this marker is not a reliable source       Out of scope   N/A
                         9.1.5.1, page 25                of information. We have seen JPEG files where all the useful information stored
                                                         under this marker had been removed. While a consumer could use information
                                                         held by this marker, a fallback should be defined if no such information is present,
                                                         or an error might be raised.



18
     Images              Draft 1.0.1,       Technical    9.1.5.1, page 25. For the case of JPEG images with inconsistent resolution data in       Accepted      WD1.2
                         9.1.5.1, page 25                different markers the correct behaviour for a consumer is not clear.




19
              A                   B                C                                             D                                                E           F
     Reference (major)   Reference           Issue Type Comment                                                                                Status     Change
                         (clause)            (Editorial/                                                                                                  Applied
                                             Technical/
                                             Other
1
     Images              Draft 1.0.1,        Technical   9.1.5.3. The sections for RGB and CMYK images both include "ExtraSamples (0, 1        Accepted   WD1.2
                         9.1.5.3                         or 2)", but the BitsPerSample and SamplesPerPixel lines imply a confusion between
                                                         the count of entries in ExtraSamples and the value of each entry. The text for
                                                         BitsPerSample and SamplesPerPixel implies that only ExtraSamples with N=1 need
                                                         be supported. They also imply that a value of 0 for that 1 entry is not allowed,
                                                         because the supported BitsPerSample and SamplesPerPixel values quoted are not
                                                         legal if ExtraSamples is [0]. This conclusion is supported by the fact that correct
                                                         behaviour for ExtraSamples = [1] and [2] are defined elsewhere (e.g. at the top of
                                                         p29), but not correct behaviour when ExtraSamples = [0].
20
     Colour              Draft 1.0.1,        Technical   9.1.5.3. There is a statement of how colour spaces for TIFF data should be treated    Accepted   WD1.1
                         9.1.5.3                         in the absence of a profile (on page 27). Why is this statement not repeated for
                                                         JPEG and PNG images?




21
     Images              Draft 1.0.1,        Technical   9.1.5.3, page 29, line 9. JPEG compression for TIFF images (compression=6) is         Accepted   WD1.2
                         9.1.5.3, page 29,               set as a requirement. That model is widely held to be fundamentally broken and
                         line 9                          not implementable. Compression=7, as first published in the Draft TIFF Technical
                                                         Note #2, 17 March 95, (by Tom Lane, the Independent JPEG Group) and then
                                                         adopted by Adobe (as Adobe Photoshop® TIFF Technical Notes, March 22 2002) is
                                                         actually usable.
22
                 A                    B                  C                                              D                                             E              F
     Reference (major)        Reference           Issue Type Comment                                                                               Status      Change
                              (clause)            (Editorial/                                                                                                  Applied
                                                  Technical/
                                                  Other
1
     Normative References &   Draft 1.0.1,        Technical   9.1.5.4, page 29. Should Windows Media Photo be replaced with HD Photo               Duplicate   N/A
     Bibliography             9.1.5.4, page 29                throughout?




23
     Fonts & Glyphs           Draft 1.0.1, 9.1.7, Technical   9.1.7, page 31, lines 19-20. States that the font fragment must be an integer but    Accepted    WD1.1
                              page 31, lines 19-              defines no syntax for its representation. For example, is the fragment #+2.0 valid
                              20                              to select the third face (indexes being zero based)?




24
     Editorial                Draft 1.0.1,        Editorial   9.1.7.3, page 33, line 8. Incorrect numbering of list items (starts at 4).           Accepted    WD1.1
                              9.1.7.3, page 33,
25                            line 8
     Editorial                Draft 1.0.1,        Editorial   9.1.7.3, page 33, line 21. The S2.19 needs to be outside the Note. Also question     Accepted    WD1.1
                              9.1.7.3, page 33,               how useful the note is.
26                            line 21
                 A                     B                 C                                             D                                               E              F
     Reference (major)        Reference           Issue Type Comment                                                                                Status      Change
                              (clause)            (Editorial/                                                                                                   Applied
                                                  Technical/
                                                  Other
1
     Fonts & Glyphs           Draft 1.0.1,        Technical   Page 35-36. Paragraph 6 of section 9.1.7.5 mentions that when using the               Accepted    WD1.5(2)
                              9.1.7.5, page 35-               compatibility encoding where the font has a cmap (3,0) encoding, that character
                              36                              codes in the range 0x80-0x9F should not be considered as non-printable Unicode
                                                              control characters. This is no longer relevant following changes to section 12.1.4
                                                              removing a requirement on a consumer to treat non-printable Unicode control
                                                              characters in a special way.
27
     Fonts & Glyphs           Draft 1.0.1,        Technical   9.1.7.5, page 35. This clause has added a requirement to support fonts containing     Accepted    WD1.3
                              9.1.7.5, page 35                other than Unicode/Symbol cmaps, by using mapping tables from the Unicode
                                                              codepoints to alternate character sets that can be used with the other cmap
                                                              encodings. There are a couple of issues with this.

                                                              o Firstly, including additional mapping tables increases the memory footprint for
                                                              embedded consumers.
                                                              o Secondly, for each encoding there are multiple mapping tables available
                                                              depending on the generating environment. This leads to the likely scenario of
                                                              differences in mapping behaviour between consumers using alternate tables, as
                                                              well as to the producer. It would be better to define or specify a single mapping
                                                              table to be used to ensure consistency of output between all producers and
28                                                            consumers.
     Normative References &   Draft 1.0.1, 9.3,   Editorial   9.3, page 42. In order to standardise XPS as a cross-platform format the              Duplicate   N/A
     Bibliography             page 42                         comments about the relationship between XPS, WPF, XAML and .Net 3.0 should be
29                                                            removed.
     Normative References &   Draft 1.0.1, 9.3.1, Editorial   9.3.1, page 43, lines 14-16. The Markup Compatibility specification is part of        Accepted    WD1.1
     Bibliography             page 43, lines 14-              OOXML, not OPC - OPC is but a section of OOXML along with MC.
30                            16
     Editorial                Draft 1.0.1, 9.3.1, Editorial   9.3.1, page 43, lines 32-35. The non-normative note specifies that MC mechanisms      Accepted    WD1.1
                              page 43, lines 32-              do not carry through to any resolved URIs. If this is a functional requirement then
                              35                              it should be normative text.
31
     Normative References &   Draft 1.0.1, 9.3.2, Technical   9.3.2, page 43-44. There is no statement on which XML version is supported.           Accepted    WD1.1
     Bibliography             page 43-44




32
                 A                B                  C                                              D                                                  E             F
     Reference (major)   Reference            Issue Type Comment                                                                                    Status     Change
                         (clause)             (Editorial/                                                                                                      Applied
                                              Technical/
                                              Other
1
     Editorial           Draft 1.0.1,         Editorial   9.3.3.2.1, page 45, line 25. The forward reference at the end is not particularly         Accepted   WD1.1
                         9.3.3.2.1, page                  helpful, since it points to such a very small part of the subject matter of the clause.
                         45, line 25                      More general references to some of the clauses in 18 might be more helpful.




33
     Syntax              Draft 1.0.1, 10.4,   Technical   10.4, page 62 and page 64 lines 8-11. The EdgeMode attribute is the first attribute       Deferred   N/A
                         page 62 and page                 which may select a behaviour based upon the absence of the attribute, with no
                         64 lines 8-11                    other way of selecting that behaviour. Consequently, there does not appear to be a
                                                          way to request default rendering of path edges in a Canvas that is itself inside a
                                                          Canvas with EdgeMode set to Aliased. The description of which child elements are
                                                          affected by EdgeMode could be made a little clearer, e.g. by explicitly stating that
                                                          Glyphs are not affected, only Path elements.
34
     Opacity             Draft 1.0.1, 11.1,   Technical   11.1, page 74, line 20. The OpacityMask does not just affect the fill, it affects the     Accepted   WD1.1
                         page 74, line 20                 stroke as well.




35
     Geometry            Draft 1.0.1,       Technical     11.2.2.1, page 82, lines 6-8. The 2nd sentence of the last paragraph contradicts          Accepted   WD1.2
                         11.2.2.1, page 82,               18.6.8 for some line caps.
36                       lines 6-8
     Geometry            Draft 1.0.1,       Technical     11.2.2.3, page 86, line 8. The text states that the Points attribute contains a           Accepted   WD1.5(1)
                         11.2.2.3, page 86,               multiple of 3 x,y values, but the XSD does not enforce this. A similar situation
                         line 8                           exists for PolyQuadraticBezier segment in section 11.2.2.5. We noted that the XPS
                                                          Viewer accepted incorrect numbers of control points, and MS confirmed that this
                                                          was an error. This could perhaps be addressed in the XSD?
37
                 A               B                  C                                             D                                                 E             F
     Reference (major)   Reference           Issue Type Comment                                                                                  Status     Change
                         (clause)            (Editorial/                                                                                                    Applied
                                             Technical/
                                             Other
1
     Fonts & Glyphs      Draft 1.0.1, 12.1   Technical   12.1. CFF fonts where the hmtx table widths do not match the CFF table widths           Rejected   N/A
                                                         can result in different output between consumers. Should one of the two tables
                                                         always be used? Or should an error be raised? We suggest that a recommendation
38                                                       to use the CFF widths is added.
     Fonts & Glyphs      Draft 1.0.1,        Technical   12.1.5, page 112. We have noted that the XPS Viewer makes an origin shift for           Accepted   WD1.5(2)
                         12.1.5, page 112                bold simulation, moving the glyph up and right, such that the bottom left-hand
                                                         corner of a glyph such as ―L‖ will still appear to be in the same place. There is no
39                                                       mention of this in the spec.
     Editorial           Draft 1.0.1,        Editorial   12.1.6, page 112, line 45. IsSideway should be IsSideways.                              Accepted   WD1.1
                         12.1.6, page 112,
40                       line 45
     Fonts & Glyphs      Draft 1.0.1,        Technical   12.1.6.1, page 113. The calculation of advance width for sideways text does not         Accepted   WD1.2.5
                         12.1.6.1, page                  say to use the vmtx table if present, just goes on to describe how to get the data
                         113                             from os/2 or hhea if it isn‘t. It also does not say what to do if the os/2 table is
                                                         present but is of the older Apple format which omits ascender and descender. [The
                                                         viewer's behaviour (inherited from Windows presumably) is to invent ascender and
                                                         descender values and NOT use the hhea table as the spec describes.]




41
     Fonts & Glyphs      Draft 1.0.1,      Technical     12.1.6, page 117-118, example 12-7. The Japanese text looks poor - while the            Accepted   WD1.1
                         12.1.6, page 117-               example is syntactically correct, the rendered mark-up is typographically incorrect -
                         118, example 12-7               the ideographic comma and full stop are incorrectly positioned.


42
                 A                B                  C                                             D                                              E           F
     Reference (major)   Reference            Issue Type Comment                                                                               Status     Change
                         (clause)             (Editorial/                                                                                                 Applied
                                              Technical/
                                              Other
1
     Fonts & Glyphs      Draft 1.0.1,         Technical   12.1.7, page 118, line 19. Suggest change from ―exactly one Indices glyph per        Accepted   WD1.1
                         12.1.7, page 118,                character in the UnicodeString‖ to ―exactly one Indices glyph per code unit in the
                         line 19                          UnicodeString‖




43
     Editorial           Draft 1.0.1,         Editorial   12.1.10.2, page 121, lines 5 & 10. Each bullet has an instance of a ―section nnn‖    Accepted   WD1.1
                         12.1.10.2, page                  reference that has not been changed to a clause symbol.
                         121, lines 5 & 10
44
     Editorial           Draft 1.0.1, 13.5,   Editorial   13.5, page 153, line 2. Another ―section nnn‖ reference that has not been changed    Accepted   WD1.1
                         page 153, line 2                 to a clause symbol.
45
     Geometry            Draft 1.0.1,         Editorial   14.4.3, page 190, example 14-19. This is actually an example of a                    Accepted   WD1.1
                         14.4.3, page 190,                RenderTransform attribute, not the Path.RenderTransform element, as the title
                         example 14-19                    states. Same applies to example 14-20 for Glyphs, example 14-21 for
                                                          PathGeometry, example 14-22 for ImageBrush, examples 14-23, 24 for
                                                          VisualBrush, example 14-25 for LinearGradientBrush, example 14-26 for
                                                          RadialGradientBrush. It would be better to title these examples something like
                                                          "<element> transform property usage".




46
                A                B                  C                                              D                                                 E           F
     Reference (major)   Reference           Issue Type Comment                                                                                   Status     Change
                         (clause)            (Editorial/                                                                                                     Applied
                                             Technical/
                                             Other
1
     Geometry            Draft 1.0.1,        Editorial   14.5.2, page 201, example 14-28, lines 7-8. The introductory text for the example        Accepted   WD1.1
                         14.5.2, page 201,               says that both the opacity mask and the fill have linear gradient brushes. The fill is
                         example 14-28,                  in fact a SolidColorBrush.
                         lines 7-8




47
              A                  B                 C                                               D                                            E           F
     Reference (major)   Reference           Issue Type Comment                                                                              Status     Change
                         (clause)            (Editorial/                                                                                                Applied
                                             Technical/
                                             Other
1
     Colour              Draft 1.0.1,        Technical   15.1.7, page 206, lines 20-23. Is the use of the PageDeviceColorSpaceProfileURI     Accepted   WD1.1
                         15.1.7, page 206,               PT setting meant to control whether colour management happens at all?
                         lines 20-23




48
     Colour              Draft 1.0.1,        Technical   15.1.7, page 206, lines 24-25. The last paragraph requires the consumer to          Accepted   WD1.1
                         15.1.7, page 206,               ‗identify‘ the profile as matching the device. Is the intention that the consumer
                         lines 24-25                     validate that a suitable profile has been selected?




49
              A                  B                 C                                             D                                               E           F
     Reference (major)   Reference           Issue Type Comment                                                                               Status     Change
                         (clause)            (Editorial/                                                                                                 Applied
                                             Technical/
                                             Other
1
     Colour              Draft 1.0.1,        Technical   15.1.8, page 206, line 28. Only version 3.4 of the ICC spec is supported, which      Accepted   WD1.1
                         15.1.8, page 206,               defines profiles which are identified as v2.0. Some of the most common profile
                         line 28                         creation applications, such as Gretag Macbeth‘s ProfileMaker can no longer make
                                                         v2.0 profiles, but create v2.4 instead. The European Color Initiative has recently
                                                         concluded that consumers of files following specifications that require a specific
                                                         version of ICC profile should be expected to be able to consume all profiles with
                                                         the same major version number, but later minor versions. Looking at what actually
                                                         changes between minor versions of the ICC spec, it‘s: clarifications, new optional
                                                         tags, new examples (for example with regard to C source code), none of which
                                                         should prevent an older reader handling the new minor version correctly. Other
                                                         groups, such as the Ghent PDF Workgroup seem to be planning to adopt the same
                                                         approach. Would it be appropriate to update the ICC profile version reference to
                                                         ICC.1:2001-4 (for v2.4 profiles)?




50
              A                  B               C                                            D                                            E           F
     Reference (major)   Reference         Issue Type Comment                                                                           Status     Change
                         (clause)          (Editorial/                                                                                             Applied
                                           Technical/
                                           Other
1
     Colour              Draft 1.0.1,      Technical   15.1.8, page 206-207. It is unclear whether a monochrome (grayTRCTag) profile    Accepted   WD1.1
                         15.1.8, page 206-             must be supported by the consumer. These are not N-component LUT-based
                         207                           profiles, and are not, therefore, covered by the statement on channel count in
                                                       paragraph 2 of this section.




51
              A                  B               C                                             D                                               E           F
     Reference (major)   Reference         Issue Type Comment                                                                               Status     Change
                         (clause)          (Editorial/                                                                                                 Applied
                                           Technical/
                                           Other
1
     Colour              Draft 1.0.1,      Technical   15.1.8, page 206-207. When processing ICC profiles with invalid tag element type     Accepted   WD1.1
                         15.1.8, page 206-             signatures, should they raise errors or not? How about falling back on the default
                         207                           colorspace for the pixel format?




52
                  A                B                 C                                             D                                               E              F
     Reference (major)    Reference            Issue Type Comment                                                                                Status     Change
                          (clause)             (Editorial/                                                                                                  Applied
                                               Technical/
                                               Other
1
     Colour               Draft 1.0.1,         Technical   15.1.14 - 15.1.16. The whole area of distinguishing between CMYK, N-color, and       Duplicate   N/A
                          15.1.14 - 15.1.16                named color is wordy and confusing (interpretation is dependent on type and
                                                           values of tags in the ICC profile) We would hope this area could be tidied up.




53
     Colour               Draft 1.0.1,         Technical   15.2.4.3, page 215, lines 18-19. Is it correct to say that a consumer MUST support   No change   N/A
                          15.2.4.3, page                   CMYK JPEG images?
                          215, lines 18-19


54
     Colour               Draft 1.0.1,         Technical   15.2.9, page 216, Table 15-2 lists integer RGB, but does not make any distinction    Withdrawn   N/A
                          15.2.9, page 216                 between signed and unsigned integer. We have seen a sample image that is signed
                                                           integer, and the XPS Viewer appears to treat that as scRGB. Need to clarify the
                                                           correct treatment of such an image. We note that the HDPhoto Specification
                                                           (1.4.3) also does not make this clear.
55
     Colour               Draft 1.0.1,         Technical   15.2.9, page 216. It would be useful to clarify whether an sRGB profile is           No change   N/A
                          15.2.9, page 216                 considered compatible with an scRGB image, and what should be done in this case.
                                                           We suspect that the Viewer converts scRGB to sRGB and then applies the profile,
                                                           but the intended behaviour is not clear in the spec. We note that the HDPhoto
                                                           Specification (1.4.3.2) also does not make this clear.


56
     Colour               Draft 1.0.1, 15.5,   Technical   15.5, page 221. The description for the Print Ticket setting                         Accepted    WD1.2
                          page 221                         PageICMRenderingIntent says that "This value SHOULD be ignored for elements
                                                           using a profile that specifies the rendering intent in the profile [S8.13]." ICC
                                                           profiles always specify a rendering intent in their header. This means that the
                                                           setting will only apply to elements not using a profile.
57
     Streaming            Draft 1.0.1, 17.1,   Technical   17.1, page 249. Add a note that streaming and handling of discard control are        Accepted    WD1.2
                          page 249                         significantly complicated by any requirement for out-of-order page handling, e.g.
58                                                         to produce booklets.
     Digital Signatures   Draft 1.0.1,         Technical   17.2.1.1, page 260, lines 4-10. Since this is a rather complex area, we suggest      Accepted    WD1.2
                          17.2.1.1, page                   further explanation or example of steps for producer and consumer of signed
59                        260, lines 4-10                  content using Markup Compatibility.
                  A               B                 C                                              D                                                 E             F
     Reference (major)    Reference           Issue Type Comment                                                                                  Status     Change
                          (clause)            (Editorial/                                                                                                    Applied
                                              Technical/
                                              Other
1
     Digital Signatures   Draft 1.0.1,        Technical   17.2.2. In example 17-4 (on page 262) the SignBy value is invalid according to          Accepted   WD1.1
                          17.2.2, page 262,               the text in 17.2.2.5 (on page 265, lines 5-6), although the format used in the
                          example 17-4                    example is valid according to the quoted document. There is also a typo, "or" for
                                                          "for" on line 7 on page 265.




60
     Digital Signatures   Draft 1.0.1,        Technical   17.2.2.3, page 263-264. The behaviour of signature spot location in the presence        Rejected   N/A
                          17.2.2.3, page                  of page transformations is not defined.
61                        263-264
     Digital Signatures   Draft 1.0.1,        Technical   17.2.2.4, page 264. The DigitalSignature Intent element is defined to be just a         Accepted   WD1.2.5
                          17.2.2.4, page                  string. Must the string be in NFC form? Can a consumer convert the string to any
                          264                             form it wants to help with displaying the intent? What font should be used? Must all
                                                          consumers have a least one font available to it in order to render the intent string?
                                                          What should happen for Unicode noncharacters? Or should the string only use a
                                                          restricted character set? Otherwise a consumer will need to implement a full
                                                          Unicode character renderer, just for the intent string. We note that this has been
                                                          made implementation-specific.
62                                                        2007-09-27: does "string" adequately define character encoding?
                 A               B                  C                                              D                                                  E           F
     Reference (major)   Reference           Issue Type Comment                                                                                    Status     Change
                         (clause)            (Editorial/                                                                                                      Applied
                                             Technical/
                                             Other
1
     Scan conversion     Draft 1.0.1,        Technical   18.1.4, page 269. The intention of the bullets at the end of this section is unclear.     Accepted   WD1.1
                         18.1.4, page 269                The second bullet (for a bi-tonal implementation) states that the renderer may
                                                         choose to print either half-tone or not. If the renderer is not half-toning, the
                                                         ―printer MAY draw thin lines with or without drop-outs‖. Is this intended to mean
                                                         that:
                                                         a) the printer draws fine lines according to the rendering rules, and that those will
                                                         either appear fully, or partially, or not at all depending on exact placement on the
                                                         page, angle of the line etc; or
                                                         b) the printer MAY choose to apply some alternative rendering rules specifically for
                                                         fine lines to ensure that such fine lines do not drop out, but always appear with a
                                                         thickness of at least one pixel (possibly with a special case for a zero-width rule, as
                                                         noted just above the bullets).




63
     Editorial           Draft 1.0.1,        Editorial   18.1.4, page 269, line 23. The reference should be to clause 18.6.12.                     Accepted   WD1.1
                         18.1.4, page 269,
64                       line 23
     Editorial           Draft 1.0.1,        Editorial   18.4.1, page 281, line 21. Typo: "mulitplied"                                             Accepted   WD1.1
                         18.4.1, page 281,
65                       line 21
     Colour              Draft 1.0.1,        Technical   18.4.1, page 281. The description of super-luminous colors does not seem to deal          Accepted   WD1.2.5
                         18.4.1, page 281                with sub-luminous colors, that is colors with negative color values. Also query
                                                         behaviour for CMYK.
66
     Geometry            Draft 1.0.1,        Technical   18.6.6, page 292. It is not clear whether line caps should be drawn for the case of       Accepted   WD1.2
                         18.6.6, page 292                a dashed line with StrokeDashArray = ―0 0‖ We note that the XPS Viewer exhibits
                                                         inconsistent behaviour, depanding on whether a non-Flat dash cap is set.
                                                         It is also not made clear what would be the intended behaviour if a non-Flat
                                                         dashcap were to be used in the example in Figure 18-12.
                                                         As a more general point on this section, the precision to which the calculation of
                                                         the start and end points of dashes is carried out could lead to differing output
67                                                       between XPS consumers.
     Geometry            Draft 1.0.1,        Technical   18.6.10, page 298, lines 10-12. This paragraph does not cover all cases clearly. It       Accepted   WD1.2
                         18.6.10, page                   needs to be made clear which type of cap (start/end/dash) needs to be added for
                         298, lines 10-12                cases where it is the first segment, a middle segment or the final segment that is
                                                         unstroked, and also depending on whether or not the Path is closed.
68
                  A                    B                 C                                             D                                                E             F
     Reference (major)        Reference           Issue Type Comment                                                                                 Status     Change
                              (clause)            (Editorial/                                                                                                   Applied
                                                  Technical/
                                                  Other
1
     Schemas                  Draft 1.0.1, B,     Technical   B, page 361. There are three patterns used in the schema to represent real             Rejected   N/A
                              page 361                        numbers:
                                                              1) a general fractional value of the form m.nEp with signs on the mantissa and
                                                              exponent,
                                                              2) a positive fractional value which does not allow for a leading negative sign, and
                                                              3) a decimal, which is a fractional value of the form m.n, i.e. no exponent, and it
                                                              cannot have a leading positive sign.
                                                              The third form is used for scRGB and ContextColor values. To simplify the job for
                                                              implementers, and prevent application incompatibility, we suggest removing the
                                                              third form in favour of the general exponent form.
69
     Schemas                  Draft 1.0.1, B,     Technical   B, page 361. Related to the above, there is a second point about representing the      Accepted   WD1.4
                              page 361                        range restriction through syntactic patterns, which is that implementers may feel
                                                              bound to report the error as a parse error (syntactic level) rather than a range
                                                              error (semantic error). We understand why this is done, there is apparently no way
                                                              in XSD to put a range restriction on a complex type, however we would like to
                                                              confirm that this is not prescriptive about how implementations report limitations.
70
     Geometry                 Draft 1.0.1, B,     Technical   B, page 376-377. A case of a degenerate Path in abbreviated geometry consisting        Accepted   WD1.5(1)
                              page 376-377                    only of a Move command appears to be valid according to the XSD but not
                                                              according to the rules for generating abbreviated geometry (in F). It is unclear
                                                              how this should be rendered, if at all.
71
     Editorial                Draft 1.0.1, F,     Editorial   F, page 397, line 66. There is a ―Left‖ that should be ―Let‖                           Accepted   WD1.1
                              page 397, line 66
72
     Normative References &   Draft 1.0.1, J,     Editorial   J, page 455, line 6. The reference for WMPhoto is just a link to the XPS page on       Accepted   WD1.5(1)
73 Bibliography               page 455, line 6                MS website.
                 A                B                C                                             D                                              E           F
     Reference (major)   Reference           Issue Type Comment                                                                              Status     Change
                         (clause)            (Editorial/                                                                                                Applied
                                             Technical/
                                             Other
1
     Package             Draft 1.0.1, 9.2,   Technical   On page 40, line 38, the description says that a Font part name SHOULD append       Accepted   WD1.1
                         page 40                         the segment "Fonts/" to the resource part name prefix specified above. This is
                                                         reflected in the font example for an individual document (i.e.
                                                         "/Documents/1/Resources/Fonts/Arial.ttf"), but not in the example for fonts to be
                                                         shared between documents (i.e. "/Resources/R2ABC7B7-C60D-4FB9-AAE4-
                                                         2CA0F6C7038A.odttf"). The same problem applies to the examples for resource
                                                         dictionaries, although not to the examples for images.




74
     Fonts & Glyphs      Draft 1.0.1,        Technical   On page 107, Example 12-3, the graphic example lists the Unicode for the            Accepted   WD1.2
                         12.1.2.3, page                  characters as being 0e20, 0e31, 0e33, 0021. On the second line of the text
                         107                             example (line 15) the UnicodeString is described as
                                                         "&#xe20;&#xe49;&#xe33;&#x21;". The second entry doesn't match and I
75                                                       suspect that it should.
     Fonts & Glyphs      Draft 1.0.1,        Technical   On page 108, Example 12-4, the GlyphIndices in the image are numbered 0099,         Accepted   WD1.2
                         12.1.2.4, page                  006A, 007c, 00a2. In the Indices parameter of the code example (line 19) they
                         108                             are 94,76,88,162, not matching the diagram. (A GGS developer took a look at this
                                                         one, and believes that it is the diagram that is incorrect.)
76
              A                  B                C                                               D                                                E             F
     Reference (major)   Reference          Issue Type Comment                                                                                  Status     Change
                         (clause)           (Editorial/                                                                                                    Applied
                                            Technical/
                                            Other
1
     Colour              Rendering Intent   Technical   Mechanism to specify output [destination] rendering intent on a per object basis.       Deferred   N/A

                                                        Color management improvement:
                                                        Print tickets are inadequate to specify the rendering intent to use in the ‗output‘
                                                        [i.e., destination] profile. Rendering intent should be a function of object type and
                                                        in some cases also the source color encoding. Pages with multiple kinds of objects
                                                        can need different output rendering intent selection for different objects.
                                                        Recommend to allow using per object ‗object output RI‘ and if ‗object output RI‘ is
                                                        not present then page level ‗output RI‘ in print ticket is used.




77
     Colour              Rendering Intent   Technical   Mechanism to specify source [input] rendering intent on a per object basis.             Accepted   WD1.4

                                                        Color management improvement:
                                                        Current concept to use rendering intent bit in the source profile to indicate the
                                                        source rendering intent is not adequate. Profiles are built to handle conversion
                                                        from / to a particular color space and are not typically modified when they are
                                                        associated with a particular object. For example, a graphic object can be sRGB and
                                                        an image can be sRGB. In the default case, for typical color management, these
                                                        two objects should use different rendering intents. Recommend to allow using per
                                                        object ‗object source RI‘, and if ‗object source RI‘ is not present then page level
                                                        ‗source RI‘ in print ticket is used.




78
                 A              B            C                                              D                                                  E             F
     Reference (major)   Reference     Issue Type Comment                                                                                   Status     Change
                         (clause)      (Editorial/                                                                                                     Applied
                                       Technical/
                                       Other
1
     Streaming           Performance   Technical   Add a rule to require packages to contain a relationship part for each                   Deferred   N/A
                                                   FixedDocumentSequence, FixedDocument, and FixedPage part.

                                                   Performance and memory improvement:
                                                   Discussion: Currently printing consumers must search for a print ticket part for
                                                   each FixedDocumentSequence, FixedDocument, and FixedPage part. However, a
                                                   consumer cannot know that there is no print ticket unless it reads the appropriate
                                                   relationship part. If that relationship part is missing, the consumer must buffer the
                                                   whole package in local storage looking for the non-existent relationship part – i.e.,
                                                   the non-existent print ticket. The practical effect is that nearly every document
                                                   printed from Vista must be buffered entirely in RAM within the printer before the
                                                   first page can be processed. This concern is partially addressed in Section 17.1,
                                                   describing the rules for interleaving optimizations. However, we believe that if each
                                                   relationship part were required, jobs that have not had interleaving optimizations
                                                   applied will print faster because the first page can be typically be printed without
                                                   buffering the whole package. This minimal provision for printing consumers would
                                                   benefit the printing of XPS documents that have not gone through a vendor's
                                                   driver (such as "Save As XPS" from an application).
                                                   Summary issue: Basic requirement must be to enable XPS consumers to begin
                                                   processing pages before the entire package is available in local storage. To do that -
                                                   - printers need to know in the relationship parts whether a print ticket is going to
                                                   be present. Recommend to require a relationship part at or near the beginning of
                                                   every FixedDocumentSequence part, FixedDocument part, and FixedPage part to
                                                   specify the presence/absence of a print ticket. Require the relationship part to be
                                                   present even when there is no print ticket so that the consumer knows not to
                                                   search for the print ticket. This recommendation would enable half of streaming
                                                   consumption (printing pages as they arrive on the port) for typical MS driver-
                                                   generated jobs, even when a vendor's DiscardControl filter is not present in the
                                                   XPS filter pipeline.
                                                   Note: central directory of the zip container [which indicates the presence of the
                                                   relationship parts] is located at the end [per longstanding zip definition] and so is
                                                   not useful for streaming situations.




79
     Opacity             Performance   Technical   Add a mechanism for specifying whether transparency is present.

                                                   Performance and memory utilization improvement.
                                                   Rendering of pages requires searching for transparency – unnecessarily slowing
                                                   the rendering of pages that do not have transparency.
                                                   Recommend page level –―transparency on this page‖ attribute. This could be done
                                                   as an attribute of the FixedPage start tag. Consumers need this to be required of
                                                   the producers. [e.g., PDF makes it trivial to determine transparency – all
                                                   transparency is noted in the PDF resource dictionary of each page.]




80
                A                     B                  C                                              D                                                    E               F
     Reference (major)        Reference           Issue Type Comment                                                                                      Status       Change
                              (clause)            (Editorial/                                                                                                          Applied
                                                  Technical/
                                                  Other
1
     Images                   Draft 1.0.1,        Technical   Clarify consumer support for JPEG APP1, APP13 and APP14 markers                           Out of scope   N/A
                              9.1.5.1, page 27,
                              APP markers                     Clarify consumer expectations for all externally defined constructs:

                                                              It is unclear exactly what a consumer must do for these markers. Which fields are
                                                              relevant? Where are the authoritative specifications for the markers?

                                                              In creating the standard – all items that are defined or ‗spec‘d‘ outside of XPS itself
                                                              must be fully specified. That means each must have a normative reference that
81                                                            provides a complete unambiguous definition.
     Normative References &                       Editorial   Update references to ICC profile specification.                                            Accepted      WD1.2
     Bibliography
                                                              ICC.1:2004-10 (Profile version 4.2.0.0) was published in 2004 and is freely
                                                              available [with errata incorporated, 5/22/2006].
                                                              OR:
                                                              ISO 15076-1, Image technology colour management —
                                                              Architecture, profile format, and data structure — Part 1: Based on ICC.1:2004-10
82
     Scan conversion          Sub-pixel           Technical   Change requirements concerning low level sub-pixel rendering to informative notes         Withdrawn      N/A
                                                              only, e.g., S11.5 requirement pertaining to abutting shapes can be stated without
                                                              specifying the sub-pixel rendering.

                                                              Change requirements to informative notes on how to do the low level sub-pixel
                                                              rendering. E.g., S11.2, S11.3, S11.5, S11.6, S11.7. Specific sub-pixel rendering
                                                              ‗should‘ statements are not applicable to some printing technologies. For this
83                                                            reason they are preferably stated as informative notes rather than as ―should‖
                                                              requirements.
     Colour                   Draft 1.0.1,       Technical    Clarify 15.1.14, 15.1.15, and 15.1.16 using scaled values                                  Accepted      WD1.3
                              15.1.14, 15.1.15,
                              and 15.1.16, Color              ―If the value is used as input for an ICC profile color transformation, it MUST
                              code value scaling              subsequently be linearly scaled to the range from 0 to 255 or from 0 to 65535,
                                                              depending on whether the profile uses 8-bit or 16-bit input tables [M8.31].‖
                                                              Clarify such as:
                                                              ―If the value is used as input for an ICC profile color transformation, it MUST be
                                                              linearly scaled [with specified rounding/clipping] to the range from 0 to 255 or
                                                              from 0 to 65535, depending on whether the profile uses 8-bit or 16-bit input tables
84                                                            [M8.31] before input to the profile.‖
     Colour                   N-channel           Technical   Enable use of N-Channel 2-channel data [15.1.15] and clarify the use of N-channel          Accepted      WD1.3
                                                              profiles.

                                                              Remove the restriction to have a N-channel profile with a minimum of 3-channels
                                                              (which also requires that the unused ones are set to zero).
                                                              ICC profile spec supports 2 channel minimum [Section 7.2.6 Table 15].

                                                              Clarify as follows:
                                                              ―N-channel color is defined using a N-component LUT-based output profile with a
                                                              colorantTableTag. The colorimetric values for the N-Channel colors can be
                                                              determined from the profile and then color managed to the intended color output
                                                              encoding, if the N-Channel profile does not pertain to the intended output device.
                                                              An XPS consumer that is aware of N-Channel colors looks for the colorantTableTag
                                                              to find out if a specific ContextColor designates a N-Channel color description.‖

85
              A                 B             C                                               D                                                  E           F
     Reference (major)   Reference      Issue Type Comment                                                                                    Status     Change
                         (clause)       (Editorial/                                                                                                      Applied
                                        Technical/
                                        Other
1
     Colour              Named colors   Technical   Correct the definition of named colors and the use of ICC profiles for named colors.      Accepted   WD1.3
                                                    [15.1.16]. Allow use of 2 color named color profiles.

                                                    ―A named color is expressed as a combination of an ink name stored in the ICC
                                                    profile and a tint level (percentage ink dilution). The ink name for the tint is
                                                    contained in the colorantTable clrt tag. This tag is not defined for ICC Version 3.4
                                                    profiles, and its presence is benignly ignored by ICM V2 implementations.
                                                    Therefore, it is used in XPS Documents to specify the names of named colors.‖

                                                    Clarify as follows:
                                                    ―A named color is expressed as a combination of an ink name stored in the ICC
                                                    profile and a tint level (percentage ink dilution) given in TintFloat. The ink name for
                                                    the named color is contained in the colorantTableTag and namedColor2Tag of the
                                                    profile. The colorimetric value for the required tint of the named color can be
                                                    determined from the profile and then color managed to the intended target output
                                                    encoding, if the particular named colorant is not installed in the intended output
                                                    device.‖

                                                    Also:
                                                    ―An XPS consumer that is aware of named colors looks
                                                    for the clrt tag to find out if a specific ContextColor
                                                    designates a named color description.‖
                                                    Should be:
                                                    ―An XPS consumer that is aware of named colors looks
                                                    for the namedColor2Tag to find out if a specific
                                                    ContextColor designates a named color description.‖




86
                   A              B                C                                              D                                                E             F
     Reference (major)    Reference          Issue Type Comment                                                                                 Status     Change
                          (clause)           (Editorial/                                                                                                   Applied
                                             Technical/
                                             Other
1
     Digital Signatures   Performance        Technical   Our interpretation of the XPS 1.0 specification is that direct consumption device      Deferred   N/A
                                                         support of the JobDigitialSignatureProcessing feature is optional. Clarify required
                                                         aspects.

                                                         17.1.5 Interleaving Optimizations and Digital Signatures states:

                                                         "In general, it is not feasible to produce well-ordered, interleaved ZIP packages
                                                         and apply digital signatures in a way that enables reasonable consumption
                                                         scenarios for the following reasons:

                                                         * Producers cannot create the digital signature parts before producing the signed
                                                         packages.

                                                         * There are cyclic dependencies with signed relationship parts containing the
                                                         relationship to the signature parts themselves.

                                                         * Therefore, when adding a digital signature to an interleaved package, producers
                                                         of digitally signed documents that are intended for streaming consumption
                                                         SHOULD add all digital signature parts and the package relationship to the digital
                                                         signature parts at the beginning of the package, before adding any other part
                                                         [S10.10]."

                                                         Summary: Although the discussion indicates that digital signature parts have to be
                                                         organized properly for
                                                         streaming consumption – the requirement is only stated
                                                         as a should for producers. Change to ―must‖ for producers.
                                                         Optimize files for reading rather than for writing.




87
     PrintTicket          Normative subset   Technical   Need to distinguish Print Schema normative vs. informative                             Accepted   WD1.4

                                                         Print Ticket [Print Schema] is used in two ways

                                                         1) defining essential aspects of XPS file interpretation, e.g., blending space,
                                                         2) conventions that can be optionally used among implementers [tray selection,
                                                         media selection]

                                                         Aspects of the Print Schema that are essential for XPS interpretation must be
                                                         incorporated as normative, either by reference or by direct inclusion.
                                                         E.G.
                                                         a. Page scaling refers to Print Schema
                                                         b. Printing Signed Documents [17.2.1.5]
                                                         E.g., Producers MAY include the JobDigitalSignatureProcessing setting in the job-
                                                         level PrintTicket within the XPS Document content [O10.11]. Consumers SHOULD
                                                         process this PrintTicket setting, if present [S10.12]. For more information, see the
                                                         Print Schema specification [print ticket schema].


88
                  A               B                C                                               D                                                  E              F
     Reference (major)    Reference          Issue Type Comment                                                                                     Status     Change
                          (clause)           (Editorial/                                                                                                       Applied
                                             Technical/
                                             Other
1
     Streaming            Performance        Technical   Improve DiscardControl                                                                    Withdrawn   N/A

                                                         Currently the DiscardControl part in package – indicates that on page N the
                                                         consumer can discard specific objects on pages N-1 through page 1.

                                                         Recommend that DiscardControl part on page N also indicate that object x on page
                                                         N is used only on page N [not further on pages N+1 etc] and is used exactly T
                                                         times on page N if that is the case. This could be optional – however should be
                                                         recommended to optimize for streaming.

                                                         For example, this would enable a consumer to incrementally discard a large part
                                                         that it knows will only be used once in the document.
89
     Opacity              Alpha Channel      Technical   Image Opacity and Alpha Channel                                                           Accepted    WD1.4

                                                         Avoid creating images with alpha channel unless the alpha channel is meaningful.

                                                         Create a ‗should‘ recommendation for producers to use the Opacity attribute in
                                                         ImageBrush elements to indicate constant opacity. This method is much preferred
                                                         over creating a constant alpha channel in the image raster itself. If the pixel data is
                                                         interleaved a constant alpha channel value can make image files significantly
                                                         larger. Also an alpha channel with constant value makes unnecessary overhead for
                                                         consumers.
90
     Digital Signatures   Draft 1.0.1,       Technical   17.2.1, p.258, line 21-22.                                                                Accepted    WD1.1
                          17.2.1, p.258,                 This sentence is complicated and not clear, we request adding further explanation.
                          Signature Policy




91
                    A                   B                C                                                D                                                   E              F
      Reference (major)        Reference           Issue Type Comment                                                                                      Status      Change
                               (clause)            (Editorial/                                                                                                         Applied
                                                   Technical/
                                                   Other
1
      Normative References &   HD Photo            Technical   Section 9.1.5 (Image Parts) covers the inclusion of Windows Media Photo (aka HD             Accepted    WD1.5(1)
      Bibliography                                             Photo). HD Photo is currently proposed for standardization with SC29 (JPEG). The
                                                               normative reference for 'HD Photo' needs to be updated to reflect activities within
                                                               SC29.

92                                                             [Page 24 in WD 1.0]
      Conformance              Namespace           Technical   Table H-2 describes namespace URIs that use a Microsoft domain.                             Accepted    WD1.5(2)

93                                                             [Page 405 in WD 1.0]
      PrintTicket                                  Technical   From the Cambridge meeting I understood that TC46's standard will not include               Accepted    WD1.4
                                                               PrintSchema(PrintTicket). However, the current working draft mentions PrintTicket
                                                               many times.




94
      Normative References &   Draft 1.0.1, 9.1.5, Technical   Windows Media Photo should be replaced with HD Photo.                                       Duplicate   N/A
      Bibliography             9.1.5.4, Table H-4
95
      Images                   Draft 1.0.1,        Technical   Method to calculate resolution of JPEG image should be clarified.                           Duplicate   N/A
                               9.1.5.1                         The relation between resolution of JPEG image and that of EXIF image should also
                                                               be clarified (ex. which resolution is valid when resolutions of JPEG image and EXIF
                                                               image both exist).
96
      Images                   Draft 1.0.1,        Technical   The features listed in Table 9-6 is a subset of HD Photo. Shouldn't all of the              Accepted    WD1.5(1)
97                             9.1.5.4, Table9-6               features of HD Photo be listed in this table?
      PrintTicket              Draft 1.0.1, 9.1.9; Technical   Description concerning PrintTicket should be revised. See TC45 committee                    Accepted    WD1.4
                               9.2, p41, line 37-              document 2007/020, "Print Ticket in XPS", for details.
                               46;
                               10.3.4, p56, line
                               24;
                               15.1.7;
                               15.4;
                               15.5;
                               17;
98                             18.3.1.2
      Normative References &   Draft 1.0.1, 9.3,   Technical   Is specification proprietary to Microsoft suitable to this specification?                   Duplicate   N/A
      Bibliography             p42, line 26-41
99
      Fonts & Glyphs           Draft 1.0.1,        Technical   We agree with GGS's comment in issue 41.                                                    Duplicate   N/A
100                            12.1.6.1
      Fonts & Glyphs           Draft 1.0.1,        Technical   Conforming to the XPS specification, the poor example shown in Example 12-7 is              Duplicate   N/A
                               12.1.6.2, page                  correct. However, a sample that is correct in terms of Japanese should also be
101                            119, Example 12-7               shown and described in this specification.
      Package                  Draft 1.0.1, 12.1.7 Technical   DeviceFontName seems unsuitable in a specification to be standardized.                      Duplicate   N/A
102
      Geometry                 Draft 1.0.1, 14.3   Technical   This specification could be read that Clip applies to fill only, but Clip should apply to   Accepted    WD1.1
103                                                            stroke also.
                  A                B                  C                                             D                                                E              F
      Reference (major)   Reference            Issue Type Comment                                                                                  Status     Change
                          (clause)             (Editorial/                                                                                                    Applied
                                               Technical/
                                               Other
1
      Colour              Draft 1.0.1,         Technical   WCS is proprietary to Microsoft, so specification that includes WCS should be          Duplicate   N/A
104                       15.1.9, 15.1.10                  deleted.
      Conformance         Draft 1.0.1, 18.2,   Technical   The requirements listed in Table 18-1 seem unrealistic. The expression "at least       Accepted    WD1.1
                          page 272, Table                  16" is ambiguous to creators. Requirements that are 32-bit based altogether is
                          18-1                             desirable.
105
      Geometry            Draft 1.0.1,         Technical   Figure 18-7 does not match its description. The dotted lines in the figure should be   Accepted    WD1.1
                          18.6.4.5, page                   solid lines.
106                       293, Figure 18-7
      Editorial                                Editorial   This Working Draft is provided in Word format, so the page numbers differ              No change   N/A
107                                                        depending on the environment this document is viewed in.
      Page Geometry       Draft 1.0.1, 10.3    Technical   We feel that some guidance on clipping of page content, for example to the             Accepted    WD1.4
                                                           ContentBox or page width/height area in the absence of a BleedBox, would be a
                                                           useful addition to this section.




108
      Fonts & Glyphs      Draft 1.0.1,         Technical   The use of the word "typically" is somewhat ambiguous. XPS depends on an               Accepted    WD1.5(1)
                          12.1.2, page 105,                implementation treating the UnicodeString attribute value "as if" it was UTF-16
                          lines 19-20                      encoded. Subsequent clauses (e.g. 12.1.3.1, lines 9-11 and table 12-2) define
                                                           functionality that can only be satisfied with this requirement in effect. We cannot
                                                           find any other statement in the document making this clear.
109
                  A                B                  C                                             D                                                 E              F
      Reference (major)   Reference            Issue Type Comment                                                                                  Status      Change
                          (clause)             (Editorial/                                                                                                     Applied
                                               Technical/
                                               Other
1
      Editorial           Draft 1.0.1, 13.6,   Editorial   The example text flows around the example output, and the page line numbers are         Accepted    WD1.1
                          Example 13-24,                   obscured.
110                       page 163
      Colour              Draft 1.0.1, 13.7,   Technical   The annotation for Color attribute states that a sRGB color can be specified with a     Accepted    WD1.3
                          page 166                         6-digit hexadecimal number. It should be 6- or 8-digit hexadecimal to allow for
                                                           sRGB with transparency. Also applies to the Color attribute annotation in Clause
111                                                        13.1.
      Editorial           Draft 1.0.1,         Editorial   The matrix brackets do not span the contents.                                           Accepted    WD1.1
                          14.4.1, page 186,
                          example 14-10
112
      Colour              Draft 1.0.1,         Technical   The initial content is described as the MS10-type signature, but lines 12 and 22 on     Duplicate   N/A
                          15.1.9, page 207,                the same page talk of the MS00 signture. Which is it?
                          table 15-3


113
      Colour              Draft 1.0.1, 15.2.2 Technical    We could not find the following formats from the list in 15.2.2:                        Accepted    WD1.5(1)
                                                           WICPixelFormat64bppRGBFixedPoint, WICPixelFormat128bppRGBFixedPoint and
                                                           WICPixelFormat64bppRGBHalf listed in the HDPhoto spec.




114
      Colour              Draft 1.0.1, 15.2.3 Technical    Is the final item in the list of HDPhoto pixel formats,                                 Accepted    WD1.5(1)
                                                           WICPixelFormat32bppGrayFloat, supposed to have "(scRGB range)" indicated?



115
      Schemas             Draft 1.0.1, B,      Technical   The pattern used to validate ContextColor specifications is not ideal. Currently it     Accepted    WD1.5(2)
                          page 376                         is:
                                                           ContextColor +[\S]+ ?[dec]([scs][dec]){3,8}
                                                           which allows for one or more spaces between ContextColor and the start of the
                                                           profile URI, and one optional space between the profile URI and the alpha value.
                                                           Two points:
                                                           1. The XSD type ST_Color has a whitespace facet of collapse, which will result in all
                                                           runs of two or more spaces in the attribute value being
                                                           replaced with a single space, allowing multiple spaces is redundant.
                                                           2. The space after the profile URI is optional, which means it could not end with a
                                                           digit as it would be impossible to distinguish between the
                                                           end of the URI and the start of the alpha value. Making the space required solves
                                                           this.
116                                                        A better pattern to use would be the following:
      Metadata            Draft 1.0.1,         Technical   ContextColor [\S]+ [dec]([scs][dec]){3,8} generating apps put their names in
                                                           What has been nice for years is how markup                                              Accepted    WD1.5(2)
                                                           the PDF and PS they output. You get to know what to expect, and if a problem has
                                                           been seen before with the apps. It would be helpful if XPS generating apps did the
                                                           same. Perhaps the CorePropeties part and the creator element could be
                                                           recommended for XPS creators.
117
                   A                    B                 C                                              D                                                 E             F
      Reference (major)         Reference           Issue Type Comment                                                                                  Status     Change
                                (clause)            (Editorial/                                                                                                    Applied
                                                    Technical/
                                                    Other
1
      Normative References &    Draft 1.0.1,        General     Note that the "Reference (section)" entry incorrectly refers to table 9-13; it should   Accepted   WD1.1
      Bibliography              9.1.5.1, Table 9-               be 9-3.
                                13                              APP0       JFIF specification        Available from
                                                                http://www.w3.org/Graphics/JPEG/jfif3.pdf, referenced from
                                                                http://www.w3.org/Graphics/JPEG/, but not (as far as I can see) an official W3C
                                                                document. As Wikipedia says "The standard appears to have lost ownership, since
                                                                C-Cube Microsystems are now defunct, and further development of the standard is
                                                                dead." The official SPIFF standard (see part 3 of the JPEG standard itself) is
                                                                similar, but not widely used; the point of supporting JFIF is because many, many
                                                                files conform to it. There does not seem to be a reference that fully matches the
                                                                ISO normative reference requirements.
                                                                APP1       EXIF extension defined by JEIDA/JEITA Exif 2.1 (JEIDA-49-1998) is
                                                                available at
                                                                http://it.jeita.or.jp/document/publica/standard/exif/english/jeida49e.htm Exif 2.2
                                                                (JEITA CP-3451, also known as Exif Print) and the 2.21 amendment (CP-3451-1)
                                                                are available for order at
                                                                http://www.jeita.or.jp/english/standard/list/list.asp?cateid=1&subcateid=4. It
                                                                seems to be possible to download them for free elsewhere (e.g. exif.org), but the
                                                                official copies must be bought.
                                                                APP2       ICC profile marker defined by the ICC specification Defined in
                                                                section B.5 of ISO 15076-1 (Image technology
                                                                colour management — Architecture, profile format, and data structure — Part 1:
                                                                Based on ICC.1:2004-10)
                                                                APP13 Photoshop 3.0 extension Partial definition in "PhotoShop File Formats"
                                                                tech note for PhotoShop versions 5 and 6. Later versions require registration as a
                                                                CS3 developer, which I have not done, but I am told that they are similar.
                                                                Adobe colleagues report that the rest of the data (a couple of lines of instructions
                                                                on how an APP13 table is created from the data format described in "file formats")
                                                                is not currently formally available anywhere. So this is a partial, proprietary,
                                                                vendor-specific specification (although it is widely implemented).
                                                                APP14 Adobe DCT Filters in PostScript Level 2 extension The specification
                                                                is available for download from
                                                                http://partners.adobe.com/public/developer/en/ps/sdk/5116.DCT_Filter.pdf, and
                                                                APP14 (referred to in hex as APPE) is described in section 18. This is a proprietary,
                                                                vendor-specific specification (even though it is widely implemented, including in
                                                                Sun's Java SDK). Of the five references required, we therefore have two (APP1 and
                                                                APP2) that are described in standards meeting the ISO requirements, and three
118
                                                                that are not. The remaining three are very widely implemented, by very many
      Normative References &    Throughout          General     How do we refer to specifications that are not accredited or formal standards? This
      Bibliography                                              includes JFIF, PhotoShop APP13 specification, ZIP etc. List of referenced
                                                                specifications will be generated by Rex under issue 5.
119
      Digital Signatures        Draft 1.0.1,       Editorial    Optional requirement is labeled as [M2.72], should be [O###]                            Accepted   WD1.2.5
                                17.2.2.3, p264,
120                             line 1.
      Parts and Relationships   Performance / File Technical    Lack of templating syntax and support for the <Path> element‘s attributes. Results      Deferred   N/A
                                size                            in bloated file size when dealing with lots of rendition changes.

                                                                difficult to use the resource dictionary mechanism to fake such templates. Need to
                                                                re-use styles, similar to css, to simply content.
121
      Discard Control / Print   Large Format /      Technical   Streaming and discard control to improve performance.                                   Deferred   N/A
      Ticket                    Performance
                                                                Need additional elements to address plot optimization for discard control and byte
122                                                             streaming settings
                   A                    B              C                                               D                                            E              F
      Reference (major)         Reference        Issue Type Comment                                                                               Status     Change
                                (clause)         (Editorial/                                                                                                 Applied
                                                 Technical/
                                                 Other
1
      Rendering Rules           Large Format     Technical   lack of double precision support in the MS XPS consuming software, resulting in     Rejected    N/A
                                                             rendering artifacts for most AutoCAD published drawings.

                                                             This is an consumer implementation problem, not a spec problem. Requires
                                                             convoluted code in software to re-transform coordinates so that they don‘t need a
123
                                                             translation component when projected.
      Images / Print Ticket     Large Format /   Technical   Banding / streaming on images during large format printing/plotting.                Deferred    N/A
                                Performance
                                                             Need streaming/optimization information to optimize plot. Add optional tags to
124                                                          identify the algorithm to use.
      Brushes / Print Ticket    Large Format     Technical   Lack of plotter pen support                                                         Deferred    N/A

125                                                          Large format customers need this capability
      Colour                    Alpha Channel    Technical   color profile should support pantone standard                                       Withdrawn   N/A




126
      Rendering Rules / Print   Large Format     Technical   Blending and line merge control                                                     Deferred    N/A
      Ticket
127                                                          Need rules on alpha blending and line merge control
      Rendering Rules / Print                    Technical   Define hairline / minimal width of lines                                            Accepted    WD1.5(2)
      Ticket
                                                             Units need to be relative (as percent of page size) or absolute measurement
128
      Rendering Rules / Print   Large Format     Technical   Define relative and absolute units for line widths                                  Deferred    N/A
      Ticket
                                                             Units need to be relative (as percent of page size) or absolute measurement
129
                   A                    B           C                                               D                                                 E           F
      Reference (major)           Reference   Issue Type Comment                                                                                   Status     Change
                                  (clause)    (Editorial/                                                                                                     Applied
                                              Technical/
                                              Other
1
      Parts and Relationships /   3D          Technical   Optional: Define optimized 3D content stream for use in documents and pages.             Accepted
      Document Content                                    Content mimetype to be determined.

                                                          optimized 3D content to includes basic 3D visulation requirements such as 3d
                                                          points, faces, face groups (or objects/object groups), textures, texture mappings,
                                                          and animation control

                                                          2007-12-14: Nathan Crews

                                                          Proposal: Add OPTIONAL XPS X3D image type with mime content types of
                                                          ―model/x3d+xml‖ and ―model/x3d+binary‖

                                                          In order to provide truly functional ―electronic paper‖ in engineering design XPS
                                                          documents, Autodesk proposes that an established 3D format known as X3D (ISO
                                                          standards 19775 & 199776 defined by web3d.org) with both XML and binary
                                                          encodings be allowed as optional content for ecmaXPS. This additional and well-
                                                          known 3D content type will enable millions of Autodesk product users to fully
                                                          realize ―electronic paper‖ and provide government agencies a comprehensive
                                                          single file format for design submittal and review. This additional will provide basic
                                                          3D model graphics with texture maps and simple animation useful for mechanical
                                                          parts assembly instruction.

                                                          Specifically this proposal would add optional 3D content treated as an image type
                                                          in the <ImageBrush> element with the following specific file and mime (as defined
                                                          in RFC 2077) stream content types:

                                                          X3D Encoding File Extension MIME Type
                                                          XML    .x3d                model/x3d+xml
                                                          Binary .x3db                model/x3d+binary

                                                          This will allow for the widest variety of 3D content streams that may be encoded as
                                                          XML or W3C compliant binary XML encoding defined in ISO/IEC 24824-1. Color and
                                                          display control will be defined in the X3D stream.
                                                          This proposal EXCLUDES the ―classic VRML‖ encoding specified in ISO/IEC 19776-
                                                          2:2005 InformJ130J131J132J131ation technology — Computer graphics and image
                                                          processing — Extensible 3D (X3D) encodings — Part 2: Classic VRML encoding.
                                                          The X3D image part would also contain an XPS compliant PNG image for 2D display
130
                                                          and print purposes for consumers that do not need to display the full 3D model.
               A                   B                 C                                            D                                             E           F
      Reference (major)   Reference            Issue Type Comment                                                                            Status     Change
                          (clause)             (Editorial/                                                                                              Applied
                                               Technical/
                                               Other
1
      Colour              Draft 1.0.1, 15.5,   Technical   The color control statements for PageDeviceColorSpaceUsage are ambiguous. Need    Accepted   WD1.4
                          Table 15.3                       to clarify.




131
      Colour              Draft 1.0.1,         Technical   Table 9-3 identifies APP2 marker as containing an ICC profile. This is correct,   Accepted   WD1.3
                          9.1.5.1, Table 9.3               however the EXIF spec (support of which is stated as a must in the paragraph
132                                                        above) also uses APP2.
      Colour              Draft 1.0.1,         Technical   Second paragraph below Table 9-3 states: "Therefore, the use of CMYK images is    Accepted   WD1.1
                          9.1.5.1                          NOT RECOMMENDED in XPS Documents because rendering results can differ
                                                           significantly between implementations."




133
                  A                B                 C                                              D                                                E             F
      Reference (major)   Reference            Issue Type Comment                                                                                 Status     Change
                          (clause)             (Editorial/                                                                                                   Applied
                                               Technical/
                                               Other
1
      Colour              Draft 1.0.1, 15.3, Technical     15.3, page 217, lines 3-5 sentence does not make sense. Suggest change to "A           Accepted   WD1.4
                          page 217, lines 3-               named color used for markings that are intended to be rendered on every layer
                          5                                when separating can be specified with the DocumentImpositionColor PrintTicket
134                                                        setting."
      Streaming           Draft 1.0.1,         Technical   17.1.4.1, page 256, lines 7-9 states that "DiscardControl parts are stored in XPS      Accepted   WD1.5(2)
                          17.1.4.1, page                   Documents in an interleaved fashion, allowing a resource-constrained consumer to
                          256, lines 7-9                   discard a part as soon as it appears in the DiscardControl part." This isn't really
                                                           true, as later clauses explain that a part can be discarded according to the rules
                                                           found in the Discard elements.
135
      Streaming           Draft 1.0.1,         Technical   17.1.4.1, page 256, lines 14-15 states that "DiscardControl parts that are not well-   Accepted   WD1.5(2)
                          17.1.4.1, page                   formed SHOULD NOT be processed and an error SHOULD NOT be reported
                          256, lines 14-15                 [S10.8]." However, the spec does not define the term well-formed. In XML this
                                                           relates to the XML syntax but does not say anything about attribute values or
                                                           character data. In light of this, where lines 12-13 say "The DiscardControl part
                                                           MUST NOT reference itself [M10.6]; doing so is considered an error." and the
                                                           DiscardControl part is well-formed XML but references itself, should the consumer
                                                           report an error? The suggestion is that lines 14-15 should be rewritten to be more
                                                           general to cover both invalid XML structure (i.e. not well-formed XML) as well as
                                                           invalid content should not result in an error being reported.
136
      Streaming           Draft 1.0.1,         Technical   17.1.4.1.2, page 257 There is no explicit restriction on the parts referenced by       Rejected   N/A
                          17.1.4.1.2, page                 SentinelPage or Target attributes. Suggest making clear the part types that are
                          257                              allowed (or not allowed) for these attributes, and what should be done if they are
                                                           not valid.




137
      Streaming           Draft 1.0.1, 17.1,   Technical   17.1, page 249 Suggest that the list of interleaving optimizations should include an   Accepted   WD1.2.5
                          page 249                         entry to help with the location of DiscardControl parts, e.g.
                                                           The relationship for the DiscardControl part SHOULD be written in the same portion
                                                           of the relationship part as the start part relationship, and the portion of the
                                                           DiscardControl part that targets a FixedPage part SHOULD be written to the
                                                           package before that part.




138
                   A                B                 C                                             D                                                E              F
      Reference (major)    Reference           Issue Type Comment                                                                                  Status     Change
                           (clause)            (Editorial/                                                                                                    Applied
                                               Technical/
                                               Other
1
      Package              Draft 1.0.1, 9.1.7, Technical   9.1.7, page 31, lines 15-16 The statement that font references must be internal to     Rejected    N/A
                           page 31, lines 15-              the package is redundant - clause 9.1.1 has already said that XPS documents must
                           16                              not reference external resources. There is a similar statement for image parts in
                                                           9.1.5, but not for other types of part.




139
      Conformance          Draft 1.0.1, I      Technical   There is information in Annex I that is not stated clearly in the normative parts of   Withdrawn   N/A
                                                           the spec. Examples:
                                                           a) M2.13 Exactly one StartPart relationship is REQUIRED.
                                                           The "exactly one" part of this does not appear to be stated explicitly in the main
                                                           body of the document.
                                                           b) M2.36 and M2.37 thumbnail requirements in the annex have annotations to
                                                           indicate that they are not required for consumers that don't use thumbnails.
                                                           Where these requirements are stated in the main body of the text, the limitation to
                                                           consumers that use thumbnails is not mentioned.




140
      Editorial            Draft 1.0.1,        Editorial   The numbering of the figures, tables and examples needs checking (plus any             Accepted    WD1.1
                           Figures, Tables                 references to them in the text). In particular:
                           Examples                        - The tables for clause 11 start at 11-9
                                                           - The examples in the Glyphs clause start again at 12-1 after 12-4
                                                           - The tables in clause 15 are labelled 15-3, 15-1, 15-2, 15-3
                                                           - The figures for clause 18 start at 18-2

141
      Digital Signatures   Draft 1.0.1,        Technical   From issue 60: We should also consider an addition to the text for the SpotId          Accepted    WD1.5(2)
                           17.2.2, page 262,               attribute
                           example 17-4                    (clause 17.2.2.1) to explain the format requirements, if we agree that the XPS
                                                           Viewer is correct in its error report. I was unable to find the appropriate
142                                                        information in the OPC spec.
      Editorial            Draft 1.0.1, I      Editorial   The tables in Annex I each have a Reference column. Unfortunately, all the             Accepted    WD1.1
                                                           references listed are hard-coded, so they are off by 7 because of the addition of
                                                           the 7 front-matter clauses to WD1.0. These all need to be turned into electronic
                                                           links, so they get updated correctly.
143
                   A                        B                 C                                               D                                                 E              F
      Reference (major)            Reference            Issue Type Comment                                                                                   Status      Change
                                   (clause)             (Editorial/                                                                                                      Applied
                                                        Technical/
                                                        Other
1
      Streaming                    Draft 1.0.1, 9.3.1, Technical    Request is to add DiscardControl to this list so that XPS consumers can extend           Accepted    WD1.5(2)
                                   page 43                          DiscardControl functionality to provide better streaming support than is possible
                                                                    without extending the DiscardControl markup. This change would be consistent
                                                                    with the extension intent in the current spec.
144
      Colour                       Draft 1.0.1, 15      Technical   Clause 15.1 starts off with information that appears to apply to both vector and         Duplicate   N/A
                                                                    image data - 15.1.1 to 15.1.10 discuss color spaces and profiles in a way that
                                                                    seems to apply to both, but then from 15.1.11 onwards the focus switches to
                                                                    vector data. We then have 15.2 for image data. A re-grouping of the sub-clauses
                                                                    might make things clearer, for example:
                                                                    15.1.x for information that applies to both vector and raster data
                                                                    15.2.x for information specific to vector data
                                                                    15.3.x for information specific to raster data
                                                                    The thing that highlighted this issue for us was the proposal under item 52 to
                                                                    clarify error handling. The proposed change is to a clause that appeared to apply to
                                                                    both vector and raster data, but the proposed forward reference is to a clause that
                                                                    applies specifically to raster data. We should clarify which bits apply to which types
                                                                    of object, and it would be useful to know what the original intent was.
145
      Digital Signatures           Draft 1.0.1, 17.2,   Technical   Detailed behavior of how valid and invalid digital signatures is provided in this        Accepted    WD1.4
                                   pp. 258                          section for consumers that implement digital signature handling. However, this is
                                                                    not a requirement. The result is that consumers that do not implement digital
                                                                    signatures will print all documents as though they were valid, regardless of
                                                                    whether the signature is valid or invalid.
146
      PrintTicket Color Settings   Draft 1.0.1, 15.5,   Technical   This section defines a PrintTicket parameter PageBlackGenerationProcessing which         Accepted    WD1.3
                                   pp. 221                          described details of black generation and undercolor removal. However, it is not
                                                                    clear how this parameter is supposed to be introduced into the color model. I
                                                                    believe the intent is to describe a conversion step between device CMY and device
                                                                    CMYK, but there is no definition of how to get to device CMY in XPS. We need
                                                                    more specific definition of how this parameter is intended to affect color conversion
                                                                    in XPS.
147
      Colour                       Draft 1.0.1, 15.1    Technical   From 145 (which was merged in here): Clause 15.1 starts off with information that        Accepted    WD1.2
                                                                    appears to apply to both vector and image data - 15.1.1 to 15.1.10 discuss color
                                                                    spaces and profiles in a way that seems to apply to both, but then from 15.1.11
                                                                    onwards the focus switches to vector data. We then have 15.2 for image data. A re-
                                                                    grouping of the sub-clauses might make things clearer, for example:
                                                                    15.1.x for information that applies to both vector and raster data
                                                                    15.2.x for information specific to vector data
                                                                    15.3.x for information specific to raster data
                                                                    The thing that highlighted this issue for us was the proposal under item 52 to
                                                                    clarify error handling. The proposed change is to a clause that appeared to apply to
                                                                    both vector and raster data, but the proposed forward reference is to a clause that
                                                                    applies specifically to raster data. We should clarify which bits apply to which types
                                                                    of object, and it would be useful to know what the original intent was.

148                                                                 Clarification of application of clauses to vector and image content
               A                   B                C                                              D                                               E           F
      Reference (major)   Reference           Issue Type Comment                                                                                Status     Change
                          (clause)            (Editorial/                                                                                                  Applied
                                              Technical/
                                              Other
1
                          Draft 1.0.1, 15.2   Technical   15.2 and 15.4 – ambiguous term ‗rich‘ colors – meaning assoc with scRGB or ‗ICC       Accepted   WD1.2
                          15.4                            profile‘. ‗Rich color‘ – intended to indicate color beyond sRGB gamut.
                                                          Color Ad Hoc agrees: Eliminate term ―rich color‖ and keep technical content that it
                                                          referred to.




149
                          Draft 1.0.1, 9.5    Technical   9.1.5 is a SHOULD for consumer using an embedded profile supplied by the              Accepted   WD1.2
                                                          producer. On the other hand in 15.2.9 and 15.1.11 the fallback cases for missing
                                                          or broken profiles are MUST. This seems backwards – consider whether if the
                                                          producer puts in a profile the consumer MUST use it. If decide to make it a must –
                                                          include clarify statement that device colors are still controlled by print ticket
                                                          settings and there is still path to not re-render device colors.
150
                    A              B                 C                                             D                                                 E              F
      Reference (major)   Reference           Issue Type Comment                                                                                   Status     Change
                          (clause)            (Editorial/                                                                                                     Applied
                                              Technical/
                                              Other
1
                          Draft 1.0.1, 15.2.9 Technical   CMYK default for raster specifically when no profile is present document:               Accepted    WD1.2.5
                                                          Three choices – further discussion to select one of these:
                                                          1. State that default CMYK should be ‗determined by the consumer‘. A consumer
                                                          may choose to abort the job. – Downside to this approach is inconsistent output
                                                          worldwide. Note that in a region and for a particular set of users this would
                                                          produce results consistent with user expectation.
                                                          2. Use a MUST single default CMYK – worldwide print results may not match
                                                          expectation in a region –but would be more likely to match worldwide. Producers
                                                          will have to be sure to tag the images if they want a result other than the default
                                                          CMYK.
                                                          3. Use a SHOULD single default CMYK – worldwide print results may not match
                                                          expectation in a region. Producers will have to be sure to tag the images if they
                                                          want a result other than the default CMYK.

151
                          Draft 1.0.1, 15.2.9 Technical   CMYK default for raster specifically when a profile is present but cannot be used:      Accepted    WD1.2.5
                                                          In 15.2.9 Add new clause dealing with present but broken CMYK profiles.




152
153                       Draft 1.0.1, 15.2.9 Technical   Dealing with grayscale/monochrome profile missing and broken.
                          Draft 1.0.1, 15.2.8 Technical   ―An associated color profile overrides an embedded color profile and is processed       Accepted    WD1.3
                                                          instead of any embedded color profile.‖ Does not clarify whether it is a MUST or a
                                                          SHOULD. Adrian thinks this is meant to be a MUST in terms of prioritizing the
                                                          associated profile over the embedded – and deferring to the logic of 9.1.5 and
                                                          15.2.9 as far as what ‗processed‘ means.
154
                          Draft 1.0.1, 15.2.8 Technical   If both embedded and associated profiles for an object and the associated profile       Duplicate   N/A
                                                          that should be used is broken – need to explicitly state consumer MUST { a}if
                                                          associated profile is not usable then use embedded – then if embedded is not
                                                          usable use default OR b) if associated profile is present but not usable – then do
                                                          not use embedded profile - rather use default directly}.
155
      Package             Draft 1.0.1, 9.1,   Technical   At the Las Vegas meeting, this issue was spun-off from issue 14.                        Accepted    WD1.2.5
                          page 19, lines 21
                          and 22                          Add text (in 8.1?) explicitly saying that a package may carry additional parts, that
                                                          an editing application is not required to maintain those, and a consumer may
156                                                       ignore them.
                          Throughout          Editorial   Change ―schema‖ to ―W3C schema‖ throughout. Watch out for ―print schema‖.               Accepted    WD1.1
                                                          Approved.
157
      Schemas                                 Editorial   Consider providing Relax NG schema alongside W3C schema (as an informative
                                                          annex). Editor to discuss with Murata-san (JP).
158
      Schemas                                 Technical   Test schemas through a variety of parsers. Avoid import feature. Committee              Withdrawn   N/A
                                                          members should validate proposed changes to schemas through parsers used in
                                                          their own products before approving those changes.
159
      Page Geometry       Draft 1.0.1, 10.3   Technical   Spun off from issue #108. We feel that some guidance on clipping of page content,       Accepted    WD1.4
                                                          for example to the ContentBox or page width/height area in the absence of a
160                                                       BleedBox, would be a useful addition to this section.
      Definitions         Draft 1.0.1, 4      Technical   Add use of ―compliant digital signature‖ in text. Check dig sig states and ensure       Accepted    WD1.5(2)
                                                          that all are used appropriately. Also review ―or similar problems‖ in ―broken digital
161                                                       signature‖ definition.
      Schemas                                 Technical   Decide on the final names for the schema files, which are currently called              Accepted    WD1.5(2)

162                                                       DiscardControl.xsd
                   A                B                C                                               D                                                  E           F
      Reference (major)    Reference          Issue Type Comment                                                                                     Status     Change
                           (clause)           (Editorial/                                                                                                       Applied
                                              Technical/
                                              Other
1
      Geometry             Draft 1.0.1, 18.6.4 Technical   The sub-clauses of 18.6.4 for the various dash cap shapes all specify the shape to        Accepted   WD1.4
                                                           be drawn for a zero-length dash. They do not, however, specify the orientation of
                                                           that shape if it appears at a join in the path. Should it be aligned with the direction
                                                           of the segment before the join or the one after the join, for example?

163
      Conformance          Draft 1.1, I.5     Technical    In section "Example 12-5. Sideways text", [M5.15] sentence was modified from              Accepted   WD1.2
                                                           MUST to must as follows.

                                                           "This example shows the IsSideways attribute set to true. The BidiLevel mustMUST
                                                           be even when the IsSidways attribute is set to true [M5.15]"

                                                           When [M5.15] is placed, it should be "MUST". Or remove [M5.15] reference?

164
      Conformance          Draft 1.1, I.5     Technical    Conformance Requirements I.5 Text                                                         Accepted   WD1.2

                                                           M5.9 just relates to the consumer, not to the producer.
                                                           We recommend that x mark reference of the producer should be removed.

                                                           Comparing with M5.1 or M5.10 which reference only to the consumer.
165
      Conformance          Draft 1.1, I.5     Technical    Conformance Requirements I.5 Text                                                         Accepted   WD1.4

                                                           Regarding M5.2 and M5.4, both of them says "the consumer MUST generate an
                                                           error" in case of error. Which means throw away whole document.

                                                           Do we have to use MUST? This seems to be depending upon vendor
                                                           implementation.

166
      Conformance          Draft 1.1, I.5     Technical    Conformance Requirements I.5 Text                                                         Accepted   WD1.2

                                                           Regarding M5.17 and M5.18, currently the consumer mark is X with note "P".

                                                           It is recommended that note "F" should be added, results in "X FP", like M5.19.

                                                           Because the consumer which does not support the device fonts comply with M5.16,
                                                           then the consumer always use the embedded version of the font.




167
      Digital Signatures   Draft 1.1, 17.2.1.1 Technical   S 17.2.1.1 includes FixedDocument as one of the thumbnail relationships that              Accepted   WD1.5(2)
                                                           should be signed. This contradicts with S 9.1.6 where the spec states that
                                                           thumbnails should be attached to the package root and fixedpage parts only.

                                                           Proposed Fix is to change 17.2.1.1 to:

                                                           1. remove FixedDocument from item 1.i (page 260)
                                                           2. remove FixedDocument from item 3.g (page 261)



168
                   A               B                 C                                                D                                            E           F
      Reference (major)    Reference          Issue Type Comment                                                                                Status     Change
                           (clause)           (Editorial/                                                                                                  Applied
                                              Technical/
                                              Other
1
      Digital Signatures   Draft 1.1, 17.2.2.6 Technical   S 17.2.2.6 states that "The <SigningLocation> element MAY be set by the original     Accepted   WD1.5(2)
                                                           producer of the XPS Document or by the signing party at the time of signing
                                                           [O10.14]"

                                                           As specified, setting the SigningLocation would break existing signatures. The
                                                           intent of the specification is that SigningLocation can be set at the time of
                                                           requesting the signature.

                                                           Proposed Fix is to change S 17.2.2.6 to:

                                                           "The <SigningLocation> element MAY be set by the original producer of the XPS
                                                           Document or by the signing party at the time of requesting a signature [O10.14]"

                                                           In addition, the text for O10.14 would be changed to match the new text in
169                                                        17.2.2.6
      Conformance          Draft 1.1, Annex I Technical    While reviewing my section in Appendix I, I read the front-matter to that appendix   Accepted   WD1.4
                                                           and had some trouble understanding the 4th paragraph:

                                                            "Consumers must support the usage of conformance rules marked as "OPTIONAL"
                                                           and "SHOULD" only for producers if the consumer accesses the referenced feature.
                                                           If a consumer or producer does not access the referenced feature it must ignore
                                                           the manifestation of the rule without error."

                                                           Should that be:

                                                            "A consumer or producer must support the usage of conformance rules marked as
                                                           "OPTIONAL" and "SHOULD" only if it accesses the referenced feature. If a
                                                           consumer or producer does not access the referenced feature it must ignore the
                                                           manifestation of the rule without error."
170
                           WD1.1, M12.7       Technical    Currently this requirement requires a consumer to treat the presence of              Accepted   WD1.4
                                                           parameters on these content types as an error when the affected part is accessed.
                                                           However, in certain situations a consumer can remediate and process the XPS
                                                           document successfully, e.g., determine the content type of the required document
                                                           parts by opening each part and examining within. Consider allowing this
                                                           remediation as the error response. Such a 'validation function only' type of error
                                                           can damage the perceived reliability and value of XPS systems.
171
                           WD1.1, M2.71       Technical    Currently this requirement requires a consumer to treat the presence of DTD          Accepted   WD1.4
                                                           content as an error. However, in certain situations a consumer can remediate and
                                                           process the XPS document successfully by discarding, and not using, the DTD
                                                           content. Consider allowing this remediation as the error response. Such a
                                                           'validation function only' type of error can damage the perceived reliability and
172                                                        value of XPS systems.
                           WD1.1, M2.78       Editorial    Update wording to be clarified as was done in 9.1.5.1. Change reference to 9.1.5.1   Accepted   WD1.2.5
                                                           .
173
                           WD1.1, Annex I     Technical    Section I is defined as informative. In the intro paragraphs, consumer/producer      Accepted   WD1.4
                                                           responsibilities to enforce or support each requirement / validate format content
                                                           are stated as a requirements. These consumer/producer responsibilities are not
                                                           defined normatively in the standard. Words such as 'required' and 'must' cannot be
                                                           used in an informative section. Assignment of MUST responses such as enforce or
                                                           validate are implied as normative which is not consistent with an informative
                                                           section.
174
               A                  B               C                                              D                                                E              F
      Reference (major)   Reference        Issue Type Comment                                                                                   Status     Change
                          (clause)         (Editorial/                                                                                                     Applied
                                           Technical/
                                           Other
1
                          All              Technical   Several different terms are used throughout the text with regard to error               Accepted    WD1.4
                                                       responsibilities. Is there an intended difference between 'report an error',
                                                       'generate an error', and 'treat as an error', 'it is considered an error', 'an error
                                                       occurs if', 'resulted in the error', 'indicate an error condition ', 'cause an error
175                                                    condition ', etc.?
                          WD1.1, Annex I   Technical   Section I discusses validation and enforcing the standard. No definition is given of    Accepted    WD1.4
                                                       any required 'validate' response behavior. Similarly the behavior requirement for
                                                       reporting an error in response to an enforcement responsibility is not clear.
176
                          WD1.1, 9.1.9.3   Technical   Change print ticket discussion to Rendering Ticket. Clarify the requirement level of    Withdrawn   N/A
                                                       the 'validate' statements under the "To determine the print settings in the XPS
                                                       Document the following algorithm should be applied:" clause.
177
                          WD1.1, 2.2       Technical   This section states that "Most requirements are expressed as format or package          Accepted    WD1.4
                                                       requirements rather than implementation requirements." This can be taken to
                                                       mean that the requirements of the standard may not apply to implementations that
                                                       do not instantiate format or package. This impression is further supported by "It (a
                                                       consumer) SHOULD report errors when processing non-conforming instances of the
                                                       documented formats when doing so does not pose an undue processing or
                                                       performance burden.'
178
                          All              Technical   Consider defining 'raising an error' with attention to differences that might pertain   Accepted    WD1.4
                                                       to different types of consumers such as: verification tool, printer, workflow tool,
                                                       editing consumer, viewer consumer.
                                                       A standards committee is a good place to reach consensus on appropriate
                                                       responses to error conditions. Document an extensible 'philosophy of error
179                                                    response'.
                          WD1.1, Annex H   Editorial   Annex H contains requirements statements. Is this Annex normative? If so add an         No change   N/A
                                                       'is normative' statement at the start of Annex H.
180
                          WD1.1, 9.3.5.1   Technical   The requirements for the xml:lang attribute [defined in the W3C XML                     Accepted    WD1.4
                                                       specification]:
                                                       "REQUIRED for <FixedPage> elements and MAY be used with <Canvas>, <Path>,
                                                       and <Glyphs> elements; it is not valid on any other fixed page markup element"
                                                       AND
                                                       "REQUIRED for the <DocumentOutline> element for document structure and
                                                       OPTIONAL for the <OutlineEntry> element"
                                                       are not directly indicated in the referenced [M2.72].
                                                       9.3.5.1 pertains to the producer and constructing an XPS document. As a result of
                                                       the indirectness of M2.72, the consumer responsibilities are not clear.
181
                          WD1.1, M2.10     Technical   The requirement for a consumer to raise an error when a producer has improperly         Accepted    WD1.4
                                                       handled the references for indirect resources can result in an error condition in the
                                                       consumer even though the consumer (in the case of a printer) may produce a
                                                       correct output. Such a 'validation function only' type of error can damage the
                                                       perceived reliability and value of XPS systems.
182
                          WD1.1, M2.3      Technical   The requirement for a consumer to raise an error when a producer has improperly         Accepted    WD1.4
                                                       included more than one FixedDocumentSequence part can result in an error
                                                       condition in the consumer even though the consumer (in the case of a printer) may
                                                       produce a correct output by rendering a single FixedDocumentSequence part. Such
                                                       a 'validation function only' type of error can damage the perceived reliability and
                                                       value of XPS systems.
183
               A                 B              C                                               D                                               E             F
      Reference (major)   Reference       Issue Type Comment                                                                                 Status     Change
                          (clause)        (Editorial/                                                                                                   Applied
                                          Technical/
                                          Other
1
                          WD1.1, M2.75    Technical   The requirement for a consumer to raise an error when a producer has improperly        Accepted   WD1.4
                                                      used the xml:space attribute can result in an error condition in the consumer even
                                                      though the consumer (in the case of a printer) may produce a correct output. Such
                                                      a 'validation function only' type of error can damage the perceived reliability and
184                                                   value of XPS systems.
                          WD1.1, M2.73    Technical   The requirement for a consumer to raise an error when a producer has improperly        Accepted   WD1.4
                                                      included elements or attributes drawn from ―xml‖ or ―xsi‖ namespaces that are not
                                                      explicitly defined in the W3C XSD schema can result in an error condition in the
                                                      consumer even though the consumer (in the case of a printer) may be able to
                                                      produce a correct output. Such a 'validation function only' type of error can
                                                      damage the perceived reliability and value of XPS systems.
185
      Colour              WD1.1, 15.1     Technical   Current statements regarding color spaces OMIT mention of commonly used color          Accepted   WD1.4
                                                      spaces. 15.1 after the existing required color list add:

                                                      Producers and Consumers MAY support the following color features:

                                                      • ICC Version 2 profiles with ‗RGB ‘ and ‗GRAY‘ color space signatures using the
                                                      JPEG, PNG, TIFF image formats.

                                                      • ICC Version 4 profiles with ‗RGB ‘ and ‗GRAY‘ color space signatures using the
                                                      JPEG, PNG, TIFF image formats.

                                                      • ICC Version 4 profiles with the ‗CMYK‘ color space signature using the TIFF image
                                                      format.

                                                      • ICC Version 4 profiles for 3-, 4-, 5-, 6-, 7-, and 8-channel color using the TIFF
186                                                   image format.
                          WD1.1, 12.1.7   Technical   In XPS for printing in printing device using DeviceFont, font data does not have to    Deferred   N/A
                                                      be embedded in the XPS.

                                                      Backgroud)

                                                      In backbone system output, speed in print data generation and amount of data are
                                                      very important factors, and it is desirable that performance same or higher than
                                                      that of the conventional PDL is ensured.
187
                                          Technical   Spun-off from #10:                                                                     Accepted   WD1.5(2)

                                                      Standard does not state that ‗.xps‘. should be used as file extension, or a specific
                                                      MIME type be used etc. No specified way of identifying XPS file. Should add one,
                                                      but file extension must not be a significant part of that; must work in both
                                                      streaming and seekable environments. Must be defined in such a way that an
                                                      encrypted XPS file is not mistaken for ―XPS‖.

                                                      Add statement in new actor section (if we have one) that behaviour when
                                                      consuming files that are not XPS files is outside the scope of the standard.

                                                      Can add recommendation that .xps extension be used as well (this is in the hands
                                                      of the visibility WG).
188
                          WD1.1, 3        Technical   Spun-off from #11:                                                                     Accepted   WD1.4

                                                      Should we use Unicode 4 or 5? Potential compatibility issues with 5. Tag as
189                                                   potentially breaking change for later review.
                    A             B                 C                                            D                                               E           F
      Reference (major)   Reference         Issue Type Comment                                                                                Status     Change
                          (clause)          (Editorial/                                                                                                  Applied
                                            Technical/
                                            Other
1
                          WD 1.1, 9.1.5.1   Technical   Spun-off from #19:                                                                    Accepted   WD1.2

                                                        Precedence of APP2 and APP13 for colour in 9.1.5.1 is a note but it should be
                                                        normative. ―APP2‖ in this clause also needs to be described as ―ICC-specified‖ to
190                                                     distinguish from other APP2 tags.
                          WD 1.1, 9.1.5.3   Technical   Spun-off from #20:                                                                    Accepted   WD1.2

                                                        The "Should" at line 20 of page 31 is inside a note. Move the 1st para of the note
                                                        below the bullet list, immediately before its end-note; Replace the next para (line
                                                        20) with: ―XPS Document consumers should mitigate the effect of badly-formed
                                                        TIFF files in the following ways [S2.11]:‖

191                                                     APPROVED
      Conformance                                       Spun-off from #166:                                                                   Accepted   WD1.2

                                                        Split 5.4 between 1st 2 sentences and last one, and make into two rules.
192                                                     APPROVED.
                                            Other       The specification currently references version 1.4 of the Open Type specification,    Accepted   WD1.5(2)
                                                        not the equivalent ISO/IEC specification.

                                                        I propose we include a normative reference to ISO/IEC 14496-22 instead of Open
                                                        Type 1.4
193
                          WD1.2, 16.1.1.5   Technical   This clause defines the <Story> element and the StoryName attribute. However,         Accepted   WD1.2.5
                                                        examples 16-3 & 16-4 use the Name attribute within the Story element; it should
                                                        be using StoryName instead.

                                                        My proposal is to change the examples to use StoryName and not Name.
194
      PrintTicket         WD1.2, 9.1.9.2    Technical   A level-specific PrintTicket MUST contain only settings scoped to                     Accepted   WD1.4
                                                        the current level and child levels [M2.59]. Job-level PrintTicket
                                                        parts MUST contain only job-, document-, and page-scoped
                                                        settings; document-level PrintTicket parts MUST contain only
                                                        document-scoped and page-scoped settings; and page-level
                                                        PrintTicket parts MUST contain only page-scoped settings [M2.59].

                                                        If this is a must than why are there SHOULD‘s for the producer
                                                        about this (S2.22 and S2.23)?

                                                        E.g. Producers SHOULD only attach PrintTicket parts containing
                                                        only document-level and page-level settings with FixedDocument
                                                        parts [S2.22].

195                                                     Proposal is to change S2.22 and S.23 to must.
                    A             B              C                                       D                                          E             F
      Reference (major)   Reference        Issue Type Comment                                                                    Status     Change
                          (clause)         (Editorial/                                                                                      Applied
                                           Technical/
                                           Other
1
      PrintTicket         WD1.2, 9.1.9.3   Technical   When processing a PrintTicket, consumers MUST first remove all            Accepted   WD1.4
                                                       levels of PrintTicket content not applicable to the current element
                                                       [M2.63]

                                                       Why is this necessary? It seems to be implementation specific and
                                                       even specifying the internal workings of a xps consumer, while
                                                       M2.60 to M2.62 already state what to process of the ticket.

                                                       E.g. Consumers MUST process job-level, document-level and page-
                                                       level settings of PrintTicket parts associated with
                                                       FixedDocumentSequence parts [M2.60].

                                                       Proposal is to remove M2.63 as a must, remove the line
                                                       completely and remove from the next line the word "second,".
196
                                                       Following validation of a PrintTicket, the printing consumer MUST
      PrintTicket         WD1.2, 9.1.9.3   Technical                                                                             Accepted   WD1.4
                                                       properly interpret the print settings according to the rules for
                                                       merging two PrintTicket part [M2.65].

                                                       Since the merging rules are MUST (M2.66, M2.67), why is
                                                       following the rules a MUST as well? This seems to be a redundant
                                                       must.

                                                       Proposal is to remove the M2.65 must and change the line to:
                                                       After validation of a PrintTicket, the following rules apply for
197                                                    merging two PrintTicket part.
      Syntax              WD1.2, 9.3.3.2   Technical                                                                             Rejected   N/A
                                                       Consumers MUST treat properties that are specified in both ways
                                                       as an error [M2.74].

                                                       Does this mean that the property is entirely discarded? Even when
                                                       both property specifications are the same? I would prefer that the
                                                       property is still used, even if specified twice.

198                                                    Proposal is to give preference to the first specification of a property
      Images              WD1.2, 9.1.5.3   Technical   S2.11 (just above 9.1.5.4) is inside a ―note‖. I think all                Accepted   WD1.2.5
                                                       requirements (must, should, may) should be outside notes.

                                                       This was already fixed at Oxford meeting with issue 191 in tc46-
199                                                    2008-026.xls, but WD1.2 contains the old text.
                    A             B                 C                                     D                                       E              F
      Reference (major)   Reference          Issue Type Comment                                                                 Status     Change
                          (clause)           (Editorial/                                                                                   Applied
                                             Technical/
                                             Other
1
                                                         A <PathGeometry> element contains a set of path figures
      Geometry            WD1.2, 11.2.1.1    Technical                                                                         Withdrawn   N/A
                                                         specified either with the Figures attribute or with a child
                                                         <PathFigure> element. Producers MUST NOT specify the path
                                                         figures of a geometry with both the Figures attribute and a child
                                                         <PathFigure> element [M4.3].

                                                         What should a consumer do when a producer did use both Figures
                                                         and a child PathFigure element? Ignore or prefer one of the two?
                                                         In other cases we specified a preference

200                                                      Proposal is to give preference to the PathFigure child element.
      Definitions         WD1.2, 16.3        Technical   If selection is supported, consumers SHOULD provide a visual cue      Accepted    WD1.2.5
                                                         over or around selected elements [S9.12].

                                                         Do we really want to specify how an application represents its
                                                         selection mechanism? We do not do this in any other place in this
                                                         specification

201                                                      Proposal is to remove this should.
      Editorial           WD1.2, I2.1,       Editorial                                                                         Accepted    WD1.2.5
202                       M2.39                          TrueTyep (only in table I.2.1, not in main text)
      Editorial           WD1.2, I2.1,       Editorial                                                                         Accepted    WD1.4
                          M2.63 and M2.64                When processing a PrintTicket, consumers MUST first remove all
                                                         levels of PrintTicket content not applicable to the current
                                                         element.
                                                         When processing a PrintTicket, consumers MUST second validate
                                                         the PrintTicket according to the methods defined in the PrintTicket
                                                         Validation Checklist of the Print Schema documentation.

                                                         The use of the words ―first‖ and ―second‖ are a bit strange and
203                                                      may differ from the intended meaning in the original text.
      Editorial           WD1.2, I2.2,       Editorial                                                                         Accepted    WD1.2.5
                          S2.31                          Thumbnail parts SHOULD follow the part name recommendation
                                                         “/Documents /<n> /Metadata /<ThumbName> .<ThumbExt> ‖
                                                         where <n> is the fixed document that contains the profile

                                                         The word ―profile‖ is incorrectly copied and should be ―thumbnail‖.
204                                                      (only in table I2.2, not in main text)
      Editorial           WD1.2, I3.2, S3.3 Editorial    Invalid content box specifications SHOULD NOT be rendered and         Rejected    N/A
                                                         SHOULD generate an error.
                                                         This differs from the text (10.3.2) that indicate that the default
                                                         content box should be used:
                                                         Content boxes that do not satisfy the following conditions are
                                                         invalid and SHOULD be ignored in favor of the default content box
205                                                      [S3.3]
                   A                B                 C                                             D                                             E             F
      Reference (major)    Reference           Issue Type Comment                                                                              Status     Change
                           (clause)            (Editorial/                                                                                                Applied
                                               Technical/
                                               Other
1
      Editorial            WD1.2, I8.1,        Editorial    Consumers MUST support ICC Version 2 profiles with a Windows                       Accepted   WD1.2.5
                           M8.10                            Color System (WCS) profile embedded as a private tag, either by
                                                            handling or ignoring the WCS profile.
                                                            The last part (either by handling or ignoring the WCS profile ) is
                                                            not in the text (15.1). The text indicates that only handling of the
206                                                         embedded WCS profile is possible.
      Editorial            WD1.2, I8.1,        Editorial    Consumers MUST inspect the PageDeviceColorSpaceProfileURI                          Accepted   WD1.2.5
                           M8.11                            PrintTicket setting to determine that this particular color
                                                            specification is a native device color and MUST NOT be color-
                                                            managed according to the included profile unless forced to do so
                                                            for transparency effects.

                                                            The text mentions not only transparency effects, but also gradient
207                                                         blending.
      Editorial            WD1.2, I8.2, S8.1 Editorial                                                                                         Rejected   N/A
                                                            ICC profiles SHOULD be used when embedded in any image
                                                            format with any color space. Images with integer pixel formats are
                                                            assumed to have sRGB as the default color space and images with
                                                            floating point pixel formats are assumed to have scRGB as the
                                                            default color space; in these cases, an ICC profile is unnecessary.

                                                            However, the main text says:
                                                            ICC profiles SHOULD be used when embedded in any image
                                                            format with any color space, except the scRGB color space, for
                                                            which the gamut boundary described in G is assumed

208                                                         I don't think this is the same.
                                               Technical    Spun-off from #188:                                                                Accepted   WD1.5(2)

                                                            Standard does not state that a specific MIME type be used. No specified way of
                                                            identifying XPS file.

209
                                               Technical    Spun-off from #188:                                                                Accepted   WD1.4

                                                            How can we test against different versions of the spec? MS vs.

210
      Colour               Draft 1.0.1, 15.1.8- Technical   Define scRGB gamut (spun off from issue #9)                                        Accepted   WD1.4
                           15.1.9, I, MS00
211                        signature                        2008-09-16 Darren Merrill, with feedback from Ann McCarthy:
      Digital Signatures   Draft 1.2.5, Table Technical     H.2 of working draft 1.2.5 does not include a Content Type for the                 Accepted   WD1.5(2)
                           H-3                              SignatureDefinitions part.

                                                            What content type should we use? Something like ‗application/vnd.ms-package.xps-
                                                            signaturedefinitions+xml‗ would be consistent with other definitions but
                                                            ‗application/xml‘ is likely to be compatible with existing implementations.
212
                   A                    B                 C                                              D                                                 E             F
      Reference (major)        Reference           Issue Type Comment                                                                                   Status     Change
                               (clause)            (Editorial/                                                                                                     Applied
                                                   Technical/
                                                   Other
1
      Profile Support                              Technical   This surfaced in a recent discussion in the color WG. The 1.2.5 draft includes the       Accepted   WD1.4
                                                               following in §15.1.8:

                                                               XPS Documents MAY include ICC profile parts [O2.3]. XPS producers and
                                                               consumers MUST provide color management using ICC profiles conforming to the
                                                               requirements of the ICC Color Profile specification, ICC.1:2001-04 [M8.12], for
                                                               color spaces other than sRGB and scRGB. Optionally, XPS producers and
                                                               consumers MAY provide color management using ICC profiles conforming to the
                                                               requirements of ISO 15076-1 [O8.9]. Producers SHOULD restrict ICC profiles to
                                                               conform to the requirements of the older ICC Color Profile specification,
                                                               ICC.1:2001-04, when consumer support of the newer ISO version cannot be
                                                               ascertained [S8.15].

                                                               With the text as currently phrased implementations are able to use v4 profiles
                                                               without any consideration for whether the consumer can support the profile,
                                                               making the modifying phrase ―when consumer support of the newer ISO version
                                                               cannot be ascertained [S8.15]‖ redundant. The current text is also a breaking
                                                               change, for Microsoft it may limit our ability to implement support in consumers to
                                                               Windows Vista and later.

                                                               The specification should be explicit on the circumstances where v4 profiles are
                                                               allowed, as written currently it is ambiguous.

                                                               Options:

                                                               1. Rewrite to make the SHOULD requirement a MUST (this was my understanding
                                                               of the agreement in the color WG). i.e. ―Producers MUST restrict ICC profiles to
                                                               conform to the requirements of the older ICC Color Profile specification,
                                                               ICC.1:2001-04, when consumer support of the newer ISO version cannot be
                                                               ascertained.‖. This retains the intention that XPS uses ICC v2 profiles (i.e. retains
                                                               compatibility with XPS v1.0) but enables v4 to be supported for closed-loop
213                                                            systems where the producer can guarantee that a specific consumer with specific
      Fonts & Glyphs           Draft 1.3, 12.1.5   Technical   Regarding the following paragraph:                                                       Accepted   WD1.5(2)

214                                                            "When the StyleSimulations value is specified as BoldSimulation, synthetic
      Page Geometry            Draft 1.3, 19.16    Technical   Regarding the bleedbox attribute: "Specifies the area including crop marks that          Accepted   WD1.5(2)
                                                               extends outside of the physical page." The area including the crop marks should
215                                                            not be included unless the graphic content extends outside of the physical page
      Common Properties        Draft 1.3, 14.2.4   Technical   Re the text "It is considered an error condition if a static resource reference cannot   Accepted   WD1.5(2)
                                                               be resolved, or if it can be resolved but the resource type does not match the
216                                                            usage at the location of reference."
      Content Type             Draft 1.3, H.2,     Technical   Re: "The content types in the tables below MUST NOT include parameters."                 Accepted   WD1.5(2)
                               Content Types
217                                                            These tables don't; this should be a producer requirement, not a requirement on
      Normative References &   OPC & MCE           Editorial   IS 29500 Part 2 (OPC) removed element contentType element from the Core                  Deferred   N/A
      Bibliography                                             Properties Part schema, but did not change the namespace for that schema. As a
                                                               result, there is no way to distinguish between ECMA-376:2006 and IS 29500 w.r.t
                                                               Part 2. So, at it's Geneva meeting, TC46 decided to refer to ECMA-376-2006
                                                               instead of IS 29500.

                                                               The status of IS 29500, especially w.r.t changes in the schema namepaces to
                                                               indicate breaking changes (possibly as a reult of the Defect Report filed by CH)
                                                               should be monitored, so the XPS spec can be changed to point to IS 29500 at
                                                               some future point.

                                                               Review the rest of OPC and MCE for other items that we may wish to raise with
218
                                                               TC45.
                  A               B                 C                                              D                                                  E           F
      Reference (major)   Reference          Issue Type Comment                                                                                    Status     Change
                          (clause)           (Editorial/                                                                                                      Applied
                                             Technical/
                                             Other
1
      Schemas                                Technical   Changes for named colour and mono support require schema changes for                      Accepted   WD1.5(2)
                                                         ST_Color.

219
                          WD1.3, 9.1, para   Editorial   Includes contradictory text: ―The payload for an XPS Document may include                 Accepted   WD1.5(2)
                          3                              additional parts not defined by this specification.‖ And ―Each part MUST use only
220                                                      the appropriate content type specified in §H [M2.2].‖
221                       WD1.3              Technical   Spot color text clarification                                                             Accepted   WD1.4
      Colour              WD1.3, 15.2 &      Technical   Lack of clarity around a consumer being able to use the name from a named colour          Accepted   WD1.4
                          15.3                           rather than any LUTs, and whether this is 'using' the profile for the purposes of the
                                                         MUST statements about using associated and embedded profiles.
222
      Rendering           WD1.3, 18.6.12     Technical   Consistent Nominal Stroke Width in WD 1.3 has the following text in the last              Accepted   WD1.5(2)
                                                         paragraph:

                                                         ―A stroke using the consistent nominal stroke width convention SHOULD be
                                                         rendered with a width consistent with other strokes using the convention that have
                                                         the same StrokeThickness attribute value, and consumers aware of this convention
                                                         SHOULD render such a stroke no thinner than the thinnest visible line that
                                                         consumer supports without dropouts [S11.31]. See §18.1.4, for further
                                                         considerations for rendering thin lines.‖

                                                         It has been pointed out that there is an ambiguity as to whether the convention is
                                                         applied based on StrokeThickness before or after application of appropriate
                                                         transforms. I therefore propose the following clarification with the addition of ‗after
                                                         application of relevant transforms‘ to the text:

                                                         ―A stroke using the consistent nominal stroke width convention SHOULD be
                                                         rendered with a width consistent with other strokes using the convention that
                                                         have, after application of relevant transforms, the same StrokeThickness attribute
                                                         value, and consumers aware of this convention SHOULD render such a stroke no
                                                         thinner than the thinnest visible line that consumer supports without dropouts
223                                                      [S11.31]. See section 11.1.4, ―Pixel Center Location, Pixel Placement, and Pixel
      Schemas                                Technical   In DocStructure.xsd / considerations for rendering thin lines.‖ following pattern
                                                         Inclusion‖, for further line 170 simpleType ST_Location is the                            Accepted   WD1.5(2)
                                                         value:

                                                         <xs:pattern value="([0-9][0-9]*)(\,[0-9][0-9]*)*"/>

                                                         Correct pattern value should be without backslash:

                                                         <xs:pattern value="([0-9][0-9]*)(,[0-9][0-9]*)*"/>

                                                         This should not change the validation rules and will make the schema valid per
224
                                                         W3C Schema
                  A               B                C                                              D                                                E              F
      Reference (major)   Reference         Issue Type Comment                                                                                   Status     Change
                          (clause)          (Editorial/                                                                                                     Applied
                                            Technical/
                                            Other
 1
      Fonts & Glyphs      WD 1.4 Table 12-3 Technical   Table 12-3 (copied below from WD 1.4 IR3) includes the statement:                       Withdrawn   N/A

                                                        ―The entry MAY be empty [M2.72], in which case the glyph index is determined by
                                                        looking up the UTF-16 code unit in the font character map table.‖

                                                        In fact, the entry may be empty or less than the length of the corresponding
                                                        UnicodeString attribute.

                                                        Therefore, we propose changing the above statement to the following:

                                                        ―The entry MAY be empty [M2.72] or less than the length of UnicodeString, in
                                                        which case the glyph index is determined by looking up the UTF-16 code unit in the
                                                        font character map table.‖
225
      Schemas                               Technical   In DocStructure.xsd / line 170 simpleType ST_Location is the following pattern          Duplicate   N/A
                                                        value:

                                                        <xs:pattern value="([0-9][0-9]*)(\,[0-9][0-9]*)*"/>

                                                        Correct pattern value should be without backslash:

                                                        <xs:pattern value="([0-9][0-9]*)(,[0-9][0-9]*)*"/>

                                                        This should not change the validation rules and will make the schema valid per
226
                                                        W3C Schema
      Fonts & Glyphs      WD1.4 IR4 §12.1, Technical    We have noticed an issue in the specification that we believe should be clarified.      Accepted    WD1.5(2)
                          §12.1.4, §19.18               In §12.1 in WD1.4 IR4, the Indices attribute is described:
                          and §F.6.1 (M5.2)
                                                        Specifies a series of glyph indices and their attributes used for rendering the glyph
                                                        run. If the UnicodeString attribute specifies an empty string (―‖ or ―{}‖) and the
                                                        Indices attribute is not specified or is also empty, a consumer MUST instantiate an
                                                        error condition [M5.2].

                                                        This does not specifically handle the case where the UnicodeString is simply not
                                                        provided. We propose the text be replaced with:

                                                        Specifies a series of glyph indices and their attributes used for rendering the glyph
                                                        run. If the UnicodeString attribute is not specified or specifies an empty string (―‖
                                                        or ―{}‖) and the Indices attribute is not specified or is empty, a consumer MUST
227                                                     instantiate an error condition [M5.2].
      Images                                Editorial   Section 9.1.5.4 needs a reference to the formal JPEG XR standard.                       Accepted    WD1.5(2)

                                                        "JPEG XR image parts MUST conform to the JPEG XR specification, (Formal ISO/ITU
228                                                     name) [M2.35]"
229 Images                                  Technical   Table 9-6 doesn't cover JPEG XR BlackWhite pixel format                                 Accepted    WD1.5(3)
                A               B           C                                               D                                               E           F
      Reference (major)   Reference   Issue Type Comment                                                                                 Status     Change
                          (clause)    (Editorial/                                                                                                   Applied
                                      Technical/
                                      Other
1
      Images                          Technical   15.3.5 N-channel Raster Images

                                                  N-channel images are stored in the JPEG XR image file format using an ICC profile.
                                                  The following format mnemonics are supported:

                                                  • 24bpp3Channels

                                                  To be consistent with the N-Channel change in which the named color tint LUT is
                                                  defined for 1 channel named color profiles, can we also include 1 channel JPEG XR
                                                  N-Channel images?
                                                  Note we could include accomplish this 1-channel N-color image in the JPEG XR
                                                  encoding of 8bppGray using the method described in 15.3.6 for a monochrome
                                                  profile with the tint LUT.

                                                  In the case of N-Chan > 1 then the profile can be the named color profile which
                                                  supports the multiple channel definition in the single profile so it is ok to have a
                                                  duotone, for example, in which one channel is white (blank) and the two channels
                                                  are used, using the three channel case.

230                                               We probably should put some words in about this.
      Schemas                         Technical   Section 12.1.4 of WD1.5 has the following text:                                        Accepted   WD1.5(2)

                                                  ―Producers MAY include Unicode control marks in the Unicode string [O5.1]. Such
                                                  marks include control codes, layout controls, invisible operators, deprecated format
                                                  characters, variation selectors, non-characters, and specials, according to their
                                                  definition within the Unicode Standard. If producers include control marks in the
                                                  Unicode string, they SHOULD include an Indices attribute to specify glyph indices
                                                  and/or character-to-glyph mapping information for the control marks [S5.2]. In the
                                                  absence of such information, consumers MUST treat Unicode control marks like
                                                  ordinary characters and render the glyphs to which the Unicode control marks are
                                                  mapped in the CMAP table [M5.10]. The resulting glyphs might produce an
                                                  inappropriate rendering of the original Unicode string.‖

                                                  The definition for ST_UnicodeString in the XSD is as follows:

                                                    <!-- UnicodeString grammar -->
                                                    <xs:simpleType name="ST_UnicodeString">
                                                       <xs:restriction base="xs:string">
                                                          <xs:pattern value="(([^\{]|(\{\})).*)?" />
                                                       </xs:restriction>
                                                    </xs:simpleType>

                                                  The XSD prevents e.g. &#10 (LF) from being used in the middle of a UnicodeString
                                                  (as opposed to being the first or last character) and therefore is, technically, in
                                                  contradiction with the specification. The proposed fix is to change the XSD to the
                                                  following definition for ST_UnicodeString:

                                                    <!-- UnicodeString grammar -->
                                                    <xs:simpleType name="ST_UnicodeString">
                                                       <xs:restriction base="xs:string">
                                                          <xs:pattern value="(([^\{]|(\{\}))(.|[\r\n])*)?" />
                                                       </xs:restriction>
231                                                 </xs:simpleType>
                   A                 B            C                                              D                                                 E           F
      Reference (major)        Reference   Issue Type Comment                                                                                   Status     Change
                               (clause)    (Editorial/                                                                                                     Applied
                                           Technical/
                                           Other
 1
                                           Editorial   We agreed to the schema name space change in Geneva on the condition that                Accepted
                                                       OpenXPS files be clearly differentiated from Microsoft XPS files. To that end we're
                                                       using 'OpenXPS' instead of 'XPS' in namespace URLs, we're recommending the use
                                                       of '.oxps' as a file extension and prohibiting '.xps' and several other things.

                                                       But one thing that we have not done is change the name that is used throughout
                                                       the text of the standard itself. The cover page, for instance, still says:

                                                                             XML Paper
                                                                            Specification
                                                               XPS Specification and Reference Guide

                                                       I propose that we make a global change:

                                                       From "XML Paper Specification" to "Open XML Paper Specification", and ;

                                                       From "XPS" to "OpenXPS".

                                                       Where 'XPS' is used in places that will technically affect the standard then it should
                                                       be left (as in the prohibited use of the '.XPS' file extension, for instance), so this
                                                       can't be a blind global change.

                                                       Under Issue 212 we agreed that the use of content types for OpenXPS component
                                                       files should follow the pattern "application/vnd.ms-package.xps-
                                                       signaturedefinitions+xml". I'd like to open a discussion as to whether that should
                                                       be amended to "application/vnd.ms-package.open xps-signaturedefinitions+xml"
                                                       or left as it is.

                                                       I've just worked through the standard and I don't see any other places where this
                                                       change would be problematic:

                                                       * It seems clear that the use of 'xps' in the URLs in 16.2.2 should be replaced by
                                                       'openxps'.

                                                       * The namespace URIs in many examples have not yet been updated for issue 93,
                                                       but will be fixed by that anyway.
232
                                                       * 'xps1' is used as a namespace prefix in A.6 (the 3D schema) and F.1 (the
      Normative References &               Editorial   Which JPEG XR standard will we use as the normative reference?
233 Bibliography

								
To top