Converting a DOCX after merge to a PDF is not keeping some of the merged fields.

[Paul]

I have a DOCX that undergoes a merge leaving me with 3 text fields after merge. All 3 fields are Times New Roman 12. I'm not using any custom font provider.

After export to PDF, 2 of the fields remain intact but one of them is always blank. 

I've attached screenshots showing the 3 fields plus the DOCX and PDF.

Can you tell me what the issue is? There are no special characters around the text and it's using the same font as the other fields? Printing it to PDF from Word locally works fine, giving me the 3 fields.

Here's the code that the export happens in -

        private async Task<Tuple<int, bool>> MakePDFFromWordDocxBytes(string pdfFilePath, byte[] bytes, string traceInfo, bool isSecondaryMergeNeeded)
        {
            int result = 0;
            byte[] pdfBytes = null;
            bool isError = false;
            try
            {
                RadFlowDocument document = ReplaceSignatureFieldsAndEmptyTables(bytes);

                // Create a new list with the data to avoid enumeration issues
                RadFlowDocument merged = PartialMailMerge(document, isSecondaryMergeNeeded); //   document.MailMerge(dataSource);

                if (isSecondaryMergeNeeded)
                {
                    DocxFormatProvider docProvider = new DocxFormatProvider();
                    string docxFileName = pdfFilePath.Replace(".pdf", ".docx");
                    using (IFileManager fileMan = FileCommon.GetFileInstance(docxFileName))
                    {
                        var docxBytes = docProvider.Export(merged, TimeSpan.FromSeconds(docLoadTimeoutSeconds));
                        fileMan.SaveFile(docxFileName, docxBytes);
                    }
                }
                TelPDFFlow.PdfFormatProvider pdfProvider = new TelPDFFlow.PdfFormatProvider();
                pdfProvider.ExportSettings = new TelPDFFlow.Export.PdfExportSettings()
                {
                    ComplianceLevel = TelPDFFixed.Export.PdfComplianceLevel.PdfA1B,
                    FontEmbeddingType = TelPDFFixed.Export.FontEmbeddingType.Full
                };
                pdfBytes = pdfProvider.Export(merged, TimeSpan.FromSeconds(docLoadTimeoutSeconds));
            }
            catch (Exception ex)
            {
                EventLogger.WriteError(traceInfo, ex);
                pdfBytes = ExceptionPDFAsBytes(ex, $"ERROR {traceInfo}");
                isError = true;
            }

            using (IFileManager fileManager = FileCommon.GetFileInstance(pdfFilePath))
            {
                fileManager.SaveFile(pdfFilePath, pdfBytes);
            }
            result = GetPDFPageCountFromPDFBytes(pdfBytes);
            return new Tuple<int, bool>(result, isError);
        }

[Yoan]

Hello Paul,

Thank you for reaching out and for the provided resources. I was able to reproduce the same results on my end.
It appears that you are encountering an issue on our part, which we already have reported and logged in our Feedback Portal - WordsProcessing: PdfFormatProvider: Table cells are exported with the wrong width when the table is nested in another table and the cells of the nested one have preferred width set to 100%.

For example, in this case, the nested table (with value "1") has its width set in "%" (90%). Usually, the width of that table should be set to 90% of the width of the parent cell. However, due to this issue, the width is calculated as 90% of the page width instead. This makes the cell too wide and crops the content inside.

I would like to apologize for the inconvenience and setbacks this might be causing you. If you are interested in this task please know that you can subscribe to it so you can track its progress and receive notifications about potential status updates in the future.

If it fits your scenario, as a workaround, I can suggest identifying the table that has its width set in percentages "%", and setting its size to a specific value (the same as the parent cell width). In the following example identifies the table by its "1" content:

I am also attaching a sample project for your disposal that implements this approach. Let me know if you have any further questions or feedback.

I hope this helps.

Regards,
Yoan
Progress Telerik

[Paul]

Thanks for the update Yoan.

I'll come back to this to see the workaround when I've cleared my current workload (I've been on leave for a week so things have been stacking up!)

[Yoan]

Hi Paul,

Thanks for writing back! Please take your time. We remain at your disposal.

Regards,

Yoan

[Paul]

The workaround as presented for the specific document works OK.

It iterates through all the tables in the document until it finds table containing the text '1'.

Then it takes that table and changes its width from a 'Percent' based one to an 'Actual' one which it sets to its parent's width.

In reality - where we have users creating these DOCXs themselves - we can't control which sizing metric the user sets for every table they create. And if they're using percentage-based ones, we can't just set a nested table's width to that of its parent as -

• The parent table's width may also be a percentage, and
• The user may have asked for the nested table to be 10%, 20% etc. of the parent's width.

So I'm accepting that we've identified the issue as relating to the bug in the feedback portal, but I'm only the second person who has voted for that bug to be progressed, and it was first raised 20 months ago.

But - that aside - thanks for the clarification Yoan!

[Yoan]

 Hi Paul,

Thank you for writing back.

I’m glad to hear that the suggested workaround fits your current scenario, and thank you for confirming that the approach works.

That said, it is true that the suggested workaround is not flexible enough to fit all the different documents and scenarios, especially if you have no control over them. Unfortunately, as of now, that is all we can offer.

As for the reported issue, we understand its importance and the impact it can have on our customers, and we would like to apologize for any inconvenience or setbacks it may be causing you. As a company, we are constantly trying to improve and keep our high standards consistent, so any form of feedback is always welcome and does not go unnoticed.

That said, we have a system that prioritizes the logged tasks in our Feedback Portal by considering various factors like demand, complexity, capacity, etc. We are doing everything in our power to address customer requests and needs by resolving these tasks as quickly as possible, but some receive less attention than others, which is why they can sometimes be delayed, as in this case.

Currently, this task is not on our roadmap, and there is no estimate or deadline for its completion. I also don’t want to mislead you by giving incorrect information just for the sake of it. Once any item is resolved, we immediately update its public feedback page to notify our clients, so please make sure you are keeping track of it by subscribing if you haven’t already.

Thank you in advance for your patience and understanding.

Regards,

Yoan