Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some attributes of CTSignatureLine class missing namespace #121

jaeksmith opened this issue Jul 2, 2014 · 1 comment

Some attributes of CTSignatureLine class missing namespace #121

jaeksmith opened this issue Jul 2, 2014 · 1 comment


Copy link


In class CTSignatureLine, the fields { signinginstructions, addlxml, sigprovurl } should each have the namespace attribute set to urn:schemas-microsoft-com:office:office in the @XmlAttribute annotation, as follows:

@XmlAttribute(name = "signinginstructions", namespace = "urn:schemas-microsoft-com:office:office")
protected String signinginstructions;

@XmlAttribute(name = "addlxml", namespace = "urn:schemas-microsoft-com:office:office")
protected String addlxml;

@XmlAttribute(name = "sigprovurl", namespace = "urn:schemas-microsoft-com:office:office")
protected String sigprovurl;

Without this mod, then [ loading, accessing, then saving a docx file ] creates a document where these attributes are lost. (For the signature system we use, this causes system-specific signature block configuration to be lost).

Note: signinginstructionsset (of similar name to signinginstructions) does not need this namespace - it gets propagated properly.

Note: It might be worth checking on whether the attributes { allowcomments, showsigndate } need a namespace also - these did not appear in my files. (All others do appear (and propagate) in my files - so the rest, not mentioned here, don't appear to need modding).


''Attachments'' :anguished: available at:

Attached are four files:

  1. source.docx - manuallycreated / contains a single signature block.
  2. result-without-mod.docx - loaded, accessed, saved without the above modification.
  3. result-with-mod.docx - loaded, accessed, saved with the above modification.
  4. - a simple app used to generate docs (2) and (3) from doc (1). (You will, of course, need to create/use docx4j jars with and without the mod to test).

If you pull up the document.xml component file of each docx and look at the attributes of the o:signatureline tag, you'll find that the attributes { o:signinginstructions, o:addlxml, o:sigprovurl } in the source document (1) do not appear in result document (2), while they do appear in result document (3). (Note that o:suggestedsigner does appear in all three - this attribute is already annotated with the namespace).

Also attached is a simple app used to test the generate the 'result' docs from the 'source' doc.

Other info:

  • docx4j versions: Issue found in 3.0.1; Issue reproduced in current source (3.1.1-SNAPSHOT); Issue fix tested/worked in current source (3.1.1-SNAPSHOT).
  • OS: Windows 7.
  • IDE: Eclipse Kepler


Copy link

plutext commented Jul 31, 2014

Hi, and thanks for the comprehensive report :-)

It seems there is a disparity between Word's behaviour, and the standard!

vml-officeDrawing.xsd from ECMA-376 4ed contains:

  <xsd:complexType name="CT_SignatureLine">
    <xsd:attributeGroup ref="v:AG_Ext"/>
    <xsd:attribute name="issignatureline" type="s:ST_TrueFalse"/>
    <xsd:attribute name="id" type="s:ST_Guid"/>
    <xsd:attribute name="provid" type="s:ST_Guid"/>
    <xsd:attribute name="signinginstructionsset" type="s:ST_TrueFalse"/>
    <xsd:attribute name="allowcomments" type="s:ST_TrueFalse"/>
    <xsd:attribute name="showsigndate" type="s:ST_TrueFalse"/>
    <xsd:attribute name="suggestedsigner" type="xsd:string" form="qualified"/>
    <xsd:attribute name="suggestedsigner2" type="xsd:string" form="qualified"/>
    <xsd:attribute name="suggestedsigneremail" type="xsd:string" form="qualified"/>
    <xsd:attribute name="signinginstructions" type="xsd:string"/>
    <xsd:attribute name="addlxml" type="xsd:string"/>
    <xsd:attribute name="sigprovurl" type="xsd:string"/>

(note the 3 attributes in question are not qualified)

[MS-OI29500] is silent about this:

2.1.1815 Part 4 Section, signatureline (Digital Signature Line)
For additional notes that apply to this portion of the standard, please see the notes for pict, §; pict, §9.5.1(a); hdrShapeDefaults, §; shapeDefaults, §; group, §; background, §17.2.1(a).
a. The standard indicates the default value for the issignatureline attribute is true.
In Office, the default value or the issignatureline attribute is false.
b. The standard does not restrict the number of instances of this element.
Office allows at most only one instance of the signatureline element in each place where it can be used.

In my testing, Word 2010 x64 is happy to open a docx containing those attributes, whether they are namespace qualified or not. However, if they are not namespace qualified, it silently drops them on save.

So, your suggested fix looks like the right thing to do, irrespective of the standard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants