One of my customers has reported seeing the following message when working in documents created from templates that I provided:
This file has Custom XML elements that are no longer supported in Word. Saving the file will remove these elements permanently.
I understand that this message relates to Custom XML Markup (https://learn.microsoft.com/en-us/office/troubleshoot/word/custom-xml-elements-not-supported). I can confirm that there is no Custom XML Markup in the document.
Any idea what could be causing this error to display?
Related
I have been using the excellent python-docx package to read, modify, and write Microsoft Word files. The package supports extracting the text from each paragraph. It also allows accessing a paragraph a "run" at a time, where the run is a set of characters that have the same font information. Unfortunately, when you access a paragraph by runs, you lose the links, because the package does not support links. The package also does not support accessing change tracking information.
My problem is that I need to access change tracking information. Or, more specifically, I need to copy paragraphs that have change tracking indicated from one document to another.
I've tried doing this at the XML level. For example, this code snippet appends the contents of file1.docx to file2.docx:
from docx import Document
doc1 = Document("file1.docx")
doc2 = Document("file2.docx")
doc2.element.body.append(doc1.element.body)
doc2.save("file2-appended.docx")
When I try to open the file on my Mac for complicated files, I get this error:
But if I click OK, the contents are there. The manipulation also works without problem for very simple files.
What am I missing?
The .element attribute is really an "internal" interface and should be named ._element. In most other places I have named it that. What you're getting there is the root element of the document part. You can see what it is by calling:
print(doc2.element.xml)
That element has one and only one w:body element below it, which is what you get when with doc2.element.body (.xml will work on that too, btw, if you want to inspect that element).
What your code is doing is appending one body element at the end of another w:body element and thereby forming invalid XML. The WordprocessingML vocabulary is quite strict about what element can follow another and how many and so forth. The only surprise for me is that it actually sometimes works for you, I take it :)
If you want to manipulate the XML directly, which is what the ._element attribute is there for, you need to do it carefully, in view of the (complex) WordprocessingML XML Schema.
Unlike when you stick to the published API, there's no safety net once ._element (or .element) appears in your code.
Inside the body XML can be relationships to external document parts, like images and hyperlinks. These will only be valid within the document in which they appear. This might explain why some files can be repaired.
I have created a document template (Test1.docx file) which has several MERGEFields in it. When I open the template in xml, I see some of the fields as SimpleFields and some as FieldCodes. Now, if I make some changes to the template (like adding some new template fields) and save it as Test2.docx and now when I open Test2.docx as an xml file, the field which came as SimpleField in the Test1.docx file's xml comes as FieldCode in the Test2.docx file's xml, even though I have not made any changes to that specific field.
When is a mergefield be recognized by openxml as simple field and fieldcode?
I am working with adobe LiveCycle ES4 and I am attempting to make a custom LiveCycle component (in java) that counts references to a specified form fragment. However I am having some difficulty finding documentation on form fragments in pdf files. So my question is how would I go about reading form fragment references from a pdf document?
Also any documentation, API, or library that may help me with this task would be greatly appreciated.
--Form Fragments--
A form fragment is a collection of form objects (fields, buttons, shapes, tables, etc) as well as related style/formatting that is saved as a separate .xsd file in a form fragment library (usually a directory on the livecycle server that holds the .xsd files). References to form fragments can be inserted into a form when working in LiveCycle Designer.This is particularly useful for creating many similar forms (such as a form fragment with fields for contact information). When a form fragment is edited the changes are reflected across all forms that hold a reference to that fragment (when the pdf is opened and has access to the form fragment library.
The PDF specification currently is an official ISO standard - ISO 32000. You should be able to get the document from the ISO organisation or from your country's standards organisation.
However, before being an ISO standard, PDF was developed and maintained by Adobe and they still have the specification available on their site: http://www.adobe.com/devnet/pdf/pdf_reference.html
There are differences between this specification and the ISO 32000 specification document, but they are largely from an editorial manner so for your purpose I'd look at the Adobe document.
Using the additional information in the comments, your test file and a low level PDF document browser (pdfToolbox in this case - attention, I'm affiliated with this product), I found following information:
In the "Catalog" object for your test PDF, you'll find a key named "AcroForm" that points to a dictionary with information about your form.
In that "AcroForm" dictionary you'll find a key called "XFA" that contains what appears to be almost all information about the XFA form that LifeCycle designer generated.
That "XFA" key points to an array which seems to consist of pairs of information. Element 0 is a string called "preamble", element 1 seems to be the data belonging to that string. So each pair of elements is a bit of information.
The information in that array consists of "preamble", "config", "template", "localeset", "xmpmeta" and "postamble". If you look at the element for "template" (the 6th element in the array if you calculate 1-based), you'll find the data you are looking for. The data is stored as a FlateDecoded stream that you'll have to uncompress - then it's just XML data that should be fairly easy to parse. In it are three lines that for you should be of particular interest:
<subform x="6.35mm" y="6.35mm" name="TestFragment1"
<subform x="3.175mm" y="34.925mm" name="TestFragment2"
<subform x="0.125in" y="2.75in" name="TestFragment2"
I'm assuming the XFA specification pointed to by mkl contains more information about these things, but it seems like simply looking for "subform" elements in the XML should get you the references to the form fragments pretty easily.
In the XFA xml data in the sample PDF you provided there are processing instructions like this:
<?templateDesigner expand 1?><?designerFragmentSource CjxzdWJmb3JtIHVzZWhyZWY9Ii4uXC4uXC4uXEFkb2JlXEFkb2JlIExpdmVDeWNsZSBFUzRcZm9y
bV9mcmFnbWVudHNcVGVzdEZyYWdtZW50MS54ZHAjc29tKCR0ZW1wbGF0ZS5mb3JtMS5UZXN0RnJh
Z21lbnQxKSIgeD0iNi4zNW1tIiB5PSI2LjM1bW0iIHhtbG5zPSJodHRwOi8vd3d3LnhmYS5vcmcv
c2NoZW1hL3hmYS10ZW1wbGF0ZS8zLjMvIgo+PD90ZW1wbGF0ZURlc2lnbmVyIGV4cGFuZCAxPz48
L3N1YmZvcm0KPg==?>
Decoding the base64 encoded argument in there one gets:
<subform usehref="..\..\..\Adobe\Adobe LiveCycle ES4\form_fragments\TestFragment1.xdp#som($template.form1.TestFragment1)" x="6.35mm" y="6.35mm" xmlns="http://www.xfa.org/schema/xfa-template/3.3/"
><?templateDesigner expand 1?></subform
>
So it looks like your
custom LiveCycle component (in java) that counts references to a specified form fragment
should parse the XFA XML, look for these designerFragmentSource processing instructions, and analyze them.
Please be aware, though, that these processing instructions most likely are proprietary Adobe stuff (I at least did not find them in the current XFA specification). Thus, as soon some third party tool touches the XFA XML, the PIs might not be accurate anymore. You actually even cannot be sure what happens in different Adobe software versions.
I am stitching a couple of documents together with a requirement that each document should retain its header and footer information in the final document. Using AltChunk instead of raw OpenXml or DocumentBuilder saves a lot of effort with regards to styles, formatting, references, parts, etc.
Unfortunately, after a couple of days I can't seem to get a 100% working version due to a small and frustrating issue and I need some insight.
My code is loosly based on this article
I modify each sub document, prior to appending it (as an AltChunk) to a working document, by moving the last section properties into the last paragraph (in order to retain header and footer references), but Word seems to be adding a blank paragraph to each of these documents as it renders them in the final document. I end up with:
document 1 with correct header and footer
section properties/break
blank paragraph
document 2 with correct header and footer
section properties/break
blank paragraph
etc.
I cant remove the blank paragraphs afterwards, as I ideally don't want to use WAS to render the document first.
It seems as if you cannot have a next-page section break without a following paragraph?
After further investigation, it seems that will not be away around my usage scenario. I would need to place the last section properties in the body element, but due to my way of processing with nested AltChunk, it would not work.
I have changed my approach completely and went back to a more detailed append procedure using OpenXml Power Tools and some LINQ to Xml.
I'm using Document Builder and works perfectly for me!
var sources = new List<OpenXmlPowerTools.Source>();
sources.Add(new OpenXmlPowerTools.Source(new WmlDocument(#tempReportPart1)));
sources.Add(new OpenXmlPowerTools.Source(new WmlDocument(#tempReportPart2)));
var outputPath = #"C:\Users\xpto\Documents\TestFolder\myNewDocument.docx";
DocumentBuilder.BuildDocument(sources, outputPath);
I have the similar empty paragraph issue while importing HTML files.
My solution is,
After inserting HTML AltChunk, I add a GUID place holder. After processing the file, I will open the file again, locate the GUID and check if there is a empty paragraph before it, if so remove the empty paragraph and GUID. it seems work perfectly in my solution.
Hope it helps.
For word report generation, I am looking at binding XML to content controls to see if it is any easier than to use Word Interop and hardcode index reference to content controls to assign values to them.
However, I don't really understand how to do it.
My work flow is entering information in Excel and then generate an XML file to have content controls populated by XML, however, what I read is the other way round: Word Control Control Toolkit and descriptions where the XML is populated by user entering information in Word, and then programmer to unzip docx file to retrieve the XML file.
How can I populate content controls with XML?
There are samples on generating Word documents from Word templates, XML and data bound content controls # http://worddocgenerator.codeplex.com/
Set up the mapped content controls in the 'template' docx using the content control toolkit or similar. Do this using a sample XML file containing your Excel data.
Now you have that template document, at run time you can inject your XML file into it (ie replace the custom xml part it contains, with your instance data), in C# or Java or whatever.
When the user opens the document in Word 2007/2010, the information in the custom XML part will automatically be copied into the bound controls, and visible to the user.
Note that content control data binding doesn't easily support repeating data (eg populating table rows) in Word 2007/2010, though there are ways to do it.