Content control conversion .docx to .htm not respecting margins- text converted into placeholder

Aspose.Words Product Family
1

Hello,

I have a document with a content control that has a margin, seems like Aspose is not saving the margin when converting the document to html (so you can see there is no margin if you convert it back to .docx again either). There is also another complex table with an image that seems to have a different margin as well after converting to .html and back. Could you please have a look and confirm if this is a bug in Aspose?

There is another issue, which is the fact that the text inside the content control is converted into a placeholder, when this was not the case in the original file. I have found there might be a workaround transforming the placeholders on each content control to their actual content programmatically, but that would be too costly for us to do in every content control as we rely heavily on them. Maybe you could bump the issue or assign it a bit of a higher priority? I am not 100% sure if my issue is the same as in WORDSNET-14533 found in: Structured Document Tags and Placeholder texts?

The attached files are:

  • WordDocument.docx, the original document
  • WordDocument_converted.htm, the word document converted to.htm
  • WordDocument_converted_back.docx, which is the.htm document(WordDocument_converted.htm) converted back to.docx
  • Code.cs, the file with the code for conversion.

Aspose.Words version used is 16.12.0

Thank you so much for your time.

2

Hi John,

Thanks for your inquiry.

ServerSide527:
I have a document with a content control that has a margin, seems like Aspose is not saving the margin when converting the document to html (so you can see there is no margin if you convert it back to .docx again either). There is also another complex table with an image that seems to have a different margin as well after converting to .html and back. Could you please have a look and confirm if this is a bug in Aspose?

We have tested the scenario and have managed to reproduce the same issue at our side. For the sake of correction, we have logged this problem in our issue tracking system as WORDSNET-15004. You will be notified via this forum thread once this issue is resolved. We apologize for your inconvenience.

ServerSide527:
There is another issue, which is the fact that the text inside the content control is converted into a placeholder, when this was not the case in the original file. I have found there might be a workaround transforming the placeholders on each content control to their actual content programmatically, but that would be too costly for us to do in every content control as we rely heavily on them. Maybe you could bump the issue or assign it a bit of a higher priority? I am not 100% sure if my issue is the same as in WORDSNET-14533

Could you please share your input and expected output documents here for our reference? We will then provide you more information about your query.

3

Hi,

Thanks for your quick response.

Regarding the content controls placeholder, in the original document “WordDocument.docx” in the attachment I sent you, you can see that “TextTextText” inside the content control is text and can be modified as such. However, when you open “WordDocument_converted_back.docx” and click on “TextTextText” all of it is hihglighted and if you try to type something in the whole text will be replaced by whatever letter you typed. I have investigated why and the reason is that “TextTextText” is not text anymore after the conversion but it is a placeholder in the content control. I find this to be an important issue to have a look at.

4

Hi John,

Thanks for sharing the detail.

We have tested the scenario and have managed to reproduce the same issue at our side. For the sake of correction, we have logged this problem in our issue tracking system as WORDSNET-15016. You will be notified via this forum thread once this issue is resolved. We apologize for your inconvenience.

5

Hi,

We are still having issues with margins when converting to htm and back to docx here I am providing a simple version and some more details to see if we could help speeding things up, as it is starting to be blocking for our business.

Aspose is not saving the page margin neither the table margin, when converting a docx to htm and back to docx. However, doing this with Word keeps them both. Aspose is losing the table margin only when it is negative relative to the page margin. You can also see that the column width has been modified in the .htm generated by Aspose, when this does not happen with Word.

For some reason the width is corrected when converting back to .docx. But it is important that the .htm version has the correct values.

The table indentation property is also added to every row in the converted document while it was only in the first row in the original document.

Attached documents:

  • SimpleTest.docx -> Original document
  • SimpleTest - table from word.htm and .docx -> htm is converted from the original document using “saving as” in Word, then that document is translated back into .docx the same way.
  • SimpleTest - table with Aspose.htm and docx -> htm converted from the original document using the code provided in Code.txt and then converted into the .docx.
    The folders are the ones needed for the htm files, they have a slightly different name as I renamed the htm files, but it is working fine.
    Files.zip (37.9 KB)

PS: I can also confirm that the issue with the content of the content controls being converted to a placeholder (WORDSNET-15016) is still happening.

Thanks for your time.

6

@ServerSide527,

Thanks for your inquiry. We have tested the scenario and have managed to reproduce the same issue at our side. For the sake of correction, we have logged this problem in our issue tracking system as WORDSNET-16072. You will be notified via this forum thread once this issue is resolved.

We apologize for your inconvenience.

7

Hi @tahir.manzoor,

Could you please let us know when we can expect the fixes for the above-mentioned issues?
Like I said earlier WORDSNET-16072 and WORDSNET-15004 are show stoppers and we need a fix soon.

Thanks,

8

@ServerSide527,

Thanks for your inquiry. We try our best to deal with every customer request in a timely fashion, we unfortunately cannot guarantee a delivery date to every customer issue. Our developers work on issues on a first come, first served basis. We feel this is the fairest and most appropriate way to satisfy the needs of the majority of our customers.

Currently, your issues are under analysis phase. Once our product team completes the analysis of your issues, we will then be able to provide you an estimate.

You reported these issues in free support forum. So, these will be treated with normal priority. To speed up the progress of issue’s resolution, we suggest you please check our paid support policies from following link.
Paid Support Policies

9

The issues you have found earlier (filed as WORDSNET-16072,WORDSNET-15016) have been fixed in this Aspose.Words for .NET 18.4 update and this Aspose.Words for Java 18.4 update.

10

The issues you have found earlier (filed as WORDSNET-15004) have been fixed in this Aspose.Words for .NET 18.4 update and this Aspose.Words for Java 18.4 update.

11

The issues you have found earlier (filed as WORDSNET-16072,WORDSNET-15016,WORDSNET-15004) have been fixed in this Aspose.Words for .NET 18.4 update and this Aspose.Words for Java 18.4 update.

12

Hello,

I have downloaded the version 18.4 of Aspose and I can confirm that the WORDSNET-15016 issue is fixed. However, the other 2 issues are still present.

Could you please have a look at it?
Report to Aspose.zip (38.5 KB)

13

@ServerSide527,

Thanks for your inquiry. Please use the following code example to get the desired output.

Document doc = new Document("in.docx");
HtmlSaveOptions options = new HtmlSaveOptions
{
    AllowNegativeIndent = true,
    ExportPageSetup = true
};
doc.Save("out.html", options);
doc = new Document("out.html");
doc.Save("out.docx");
14

Thank you very much, it is working as expected with the code provided.