We're sorry Aspose doesn't work properply without JavaScript enabled.

# Aspose.Words with WordML

I’m using the following code to open a Word document then save it. The file that gets saved is corrupt. I can provide a copy of the source document.

string path = @"c:\data\";
LoadFormat fileFormat = Document.DetectFileFormat(path + "test.doc");
Response.Write(fileFormat.ToString());
Document doc = new Document(path + "test.doc");
doc.Save(path + "aspose.doc");


This message was posted using Aspose.Live 2 Forum

Hi

Best regards.

I couldn’t upload both files. This one is the input file. I will reply again and upload the output.

Thank you

Output file is attached.

Hi

Thank you for additional information. I managed to reproduce the problem. I have created the issue # 4327 in our defect database. Please expect a reply before the next hotfix (within 2-3 weeks). We might just fix it by then or provide more information.

Best regards.

Do you have an expected date for a fix for this problem?

Thanks

Hi

Unfortunately at the moment I can’t tell you exact date when this will be fixed.

Best regards.

We have reached the point where this issue is holding up the release of my product. I’m being asked by my management for a date. Can you provide me with an estimated date?

This week.

The problem is in the xml file. In one place cell width is specified in tc/tcW, but should be in tc/tcPr/tcW. I’m not sure if MS Word is being resillient about this or how it reads it, but Aspose.Words picks up the problem and hence the difference in the output file. I will make Aspose.Words resillient on this one too, but you can easily move forward if you fix the xml file.

See the picture.

Hi

We have released a new version of Aspose.Words that contains a fix for your issue.

Issue # 4327 - A table is changed after open/save WML file.

Best regards.

It doesn’t appear to have fixed the issue. I used the new DLL and the same test files that I sent and the output document is different than the input document and the table is not correct.

Hi

Best regards.

Any news? This issue is holding up progress on a critical piece of a project. Can you suggest a work-around?

Hi

As workaround you can try using the following code.

Document doc = new Document(@"Test027\in.xml");
doc.UpdateTableLayout();
doc.Save(@"Test027\out.doc");


Best regards.

This workaround solved the original problem. Now I have a slightly different issue. See the attached files. The line that begins with AL has a colspan that works properly in the Before document but does not apply properly in the After document.

Thank you.

Hi

Thanks for your request. It seems this is known issue #1219. You can check if it is needed to call UpdateTableLayout().

Document doc = new Document(@"Test130\test.xml");
//Get collection of cells
NodeCollection cells = doc.GetChildNodes(NodeType.Cell, true);
bool isUpdateNeeded = false;
//Check if some cell has width = 0
foreach (Cell cell in cells)
{
if (cell.CellFormat.Width == 0)
{
isUpdateNeeded = true;
break;
}
}
//If width of some cell is 0 then we should update table layout.
if (isUpdateNeeded)
doc.UpdateTableLayout();
//Save output document
doc.Save(@"Test130\out.doc");


Best regards.

Thank you. The workaround solved that problem.

Now we are having two issues with conversion to PDF. I’ve attached samples. There is the original Word document and a PDF after the conversion using Aspose. There is also a PDF converted via Adobe.

1. The table should take up the full width of the page.
2. Page numbers are not being populated.

Thank you.

Hello!

I have reproduced the issues. First one is logged as #5011 and second as #5012 in our defect database. We’ll provide more information if we make any progress or fix them.

Regards,

Hello!

I’m investigating issue #5012 with lost page numbers. You can easily work-around this by re-saving the document with MS Word.

Technical reason of this issue is that PAGE and NUMPAGES fields are slightly different from how they usually appear to be. They have field separators but don’t have field values. I have to change our field parser, that doesn’t look difficult.

I hope you can use the workaround until it is fixed.

Regards,