Describes a “gfxdata” attribute for the “shape” elements, which “contains DrawingML content” that is “base-64 encoded”. However, the “contents of this package are application-defined”, so even though they “shall use the Parts defined by this Standard whenever possible” there is not sufficient information for an independent implementation to read this data or display the “DrawingML content” contained therein. If we’re going to have a new graphics markup language in XML, and ignore the existing SVG, let’s at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways.

Define this in an interoperable way.

pg. 4655, “gfxdata” Part 4, Section 6.1.2.19

te

Proposed Disposition of DIS 29500 Comment US-0155 (Modified: 2008-01-08) Agreed; this can be changed to improve interoperability. Additionally, in each location where VML is required, VML will be deprecated (but fully documented for legacy purposes) and replaced with an alternative in the DrawingML format. This is addressed in detail within the disposition of the following comments: CA-0076, CL-0025, CL-0206, CO-0076, CO-0223, CZ-0004, CZ-0011, DE-0018, DE-0020, DE-0021, DE-0115, DE-0116, DK-0058, DK-0095, DK-0150, DK-0155, FI-0008, GB-0177, GB-0190, GB-0476, GB-0477, GR-0087, IE-0009, JP-0030, KE-0047, KE-0064, MX-0006, US-0092, US-0152, UY-0002, VE-0013, and ZA-0016. The following changes will be made to Part 4, ยง6.1.2.19, page 4,655 to make it clear what format the data should be stored in: Attributes Description gfxdata (Encoded Package) Namespace: urn:schemas-microsoft-com:office:office Specifies a base-64 encoded package as de i fined in Part 2 of this Standard that contains DrawingML content as defined in Part 4 of this standard . The contents of this package are application-defined, but the contents of the package shall use the Parts defined by this Standard whenever possible. [Rationale: This attribute allows an application to use VML to represent graphical content for a legacy document while still persisting DrawingML for consuming applications that support DrawingML. For example, a diagram stored within this attribute would have the four parts defined for a DrawingML diagram, as well as any number of application-defined parts and relationships. end r ationale] [ Example: A DrawingML object is encoded in the gfxdata attribute, leaving VML to handle the visual display: <v:shape id="Diagram 1" o:spid="_x0000_i1025" type="#_x0000_t75" style="width:446.25pt;height:252pt; visibility:visible" o:gfxdata="UEsDBBQABgAIAAAAIQDIu8KcTQE..."> <v:imagedata r:id="rId4" o:title=""/> </v:shape> end example ] The possible values for this attribute are defined by the XML Schema base64Binary datatype. Similar Comments: BR-0056 , CL-0009 , CL-0208 , CO-0226 , CZ-0036 , DE-0112 , FR-0372 , GB-0484 , GR-0088 ,

Tag and Go

2 Comments

  1. hAl November 4, 2007 @ 2:44 pm

    Strangely enough this is very consistent with ISO 26300 behaviour which allowes binary base64encoded images/grpahics data in its XML as well (without info on the exact nature of that image data).
    This comment is therefore not consistent with existing ISO office document practise.

  2. Alan Bell November 12, 2007 @ 10:55 pm

    I added a new tag “Could apply to ODF” for issues like this which are fairly generic where the ODF spec might benefit from addressing the same issue.

Sorry, the comment form is closed at this time.

  • Argentina (1)
  • Australia (30)
  • Austria (1)
  • Belgium (1)
  • Brazil (64)
  • Bulgaria (3)
  • Canada (79)
  • Chile (217)
  • China (1)
  • Colombia (237)
  • Czech Republic (75)
  • Denmark (168)
  • Ecma (76)
  • Ecuador (1)
  • Finland (15)
  • France (592)
  • Germany (162)
  • Ghana (12)
  • Greece (113)
  • India (82)
  • Iran (58)
  • Ireland (12)
  • Israel (33)
  • Italy (2)
  • Japan (82)
  • Jordan (1)
  • Kenya (81)
  • Malaysia (23)
  • Malta (5)
  • Mexico (7)
  • New Zealand (54)
  • Norway (12)
  • Peru (10)
  • Philippines (7)
  • Poland (4)
  • Portugal (118)
  • Singapore (2)
  • South Africa (17)
  • South Korea (25)
  • Spain (1)
  • Switzerland (19)
  • Thailand (1)
  • Tunisia (3)
  • Turkey (1)
  • UK (635)
  • Uruguay (18)
  • USA (288)
  • Venezuela (73)