Problem with height of table in header

[Patrick]

Hello,

I'm doing some experiments with WordsProcessing and found an annoying problem.

In a docx document, I have a table in the header. The table height is 2.48cm.
In a test application, I've just opened the document and save it, using your library.
After that, I've opened the document in Word and the table height is not correct as it is only 1.46cm (that's the height of the text inside the table).

Looking at the in-memory data of the document, the height of the table row is set to "Auto".

Unfortunately, there is also a border on this table and it now looks ugly, not counting that the image in the header "crosses" the table border

I also have the same problem in the footer, that also contains a table. In this part, this is more annoying because the height of the footer is not respected and the whole document formatting is not correct.

[Patrick]

Hello,

As I continue testing, I have found this information: WordsProcessing: Table row which has defined only 'val' attribute of the 'trHeight' is imported as row with auto height (telerik.com)

I find it incredible that you cannot provide a solution to this problem more than 4 years after it was first reported!

And why is it not documented in your documentation and we must loose hours to find a solution?

It should not be difficult to add import options in order to process the table headers correctly...

[Patrick]

Now, I'm trying to export the document in PDF and:

1. The border over the header is not displayed.
2. The vertical alignment of the cells in the header table are not right.
3. The footer height is not correct.
4. Your example for font embedding (.NET Core) is not correct: it doesn't take into account bold fonts for example...

Your library is really unusable for this simple case. I'm really disappointed.

[Martin]

Hello Patrick,

I understand your frustration and I want to apologize for the inconvenience this missing functionality might be causing you.

The discrepancy in the behavior (of the setting the row height) between WordsProcessing and MS Word comes from that the MS Word exports table rows with "At least" height value differently than stated in the specification (Ecma Office Open XML). That causes these files to be imported with row height set to "auto" in WordsProcessing. I updated the internal item with your suggestions for documenting the discrepancy in the behavior and for implementing an import option and they will be reviewed when the development process starts. Until then, I could suggest checking the suggested it in the public item workaround.

The export of the vertical alignment of table cells when exporting to PDF is currently not supported by the WordsProcessing library. We have an item logged in our backlog: Export VerticalAlignment property of the table cells to PDF. You can cast your vote for the implementation as well as subscribe to the task by clicking the Follow button so you can receive updates when its status changes.

I am not sure which example for font embedding you mean. We have a .NET Core example (using Telerik Document Processing .NET Standard assemblies) in our GitHub repository (ConvertDocuments) demonstrating the conversion from RadFlowDocument to the supported by the WordsProcessing library formats (including PDF) where you can find a sample implementation of FontsProviderBase class that respects the bold fonts. More information about FontsProviderBase you find in the PdfProcessing`s Cross-Platform Support help topic.

As for the other points, In order to deeper investigate the case, I would like to ask you to send us the document causing this behavior. For confidentiality reasons, this could be done in a private support ticket. I must assure you we treat all client files in a strictly confidential manner and for testing purposes only.

I hope you find this information helpful. Looking forward to hearing from you.

Regards,
Martin
Progress Telerik

[Patrick]

Hello Martin,

Thanks for the answer.

For the row height, there is hopefully a solution, even if it must be implemented manually.

For the export of vertical alignment of table cells, this is reported almost 5 years ago and still unplanned. So I think you will never implement it... Making this work should not be this difficult.

For font embedding, I'm talking about the example in your documentation, at Cross-Platform Support | Telerik Document Processing. Your example in GitHub is more correct but is working only for two fonts and must be corrected manually for other ones.

Another bug I found is that the "all caps" char format is not taken into account: reading the docx file and writing it without modification loses this setting.

For the example file, how can I create a support ticket connected to this thread?

Regards

[Martin]

Hello Patrick,

I am happy the suggested workaround could be a solution for your case.

As for the export to PDF of the vertical alignment of the table cells, this feature is still not scheduled for implementation and I am afraid I cannot provide you with a timeframe for implementing it because our development team is working on more demanded tasks.

The FixedExtensibilityManager.FontsProvider property provides an extensibility point for custom providing the fonts data when using the .NET Standard version of the Document Processing assemblies. Both the examples of providing the font data are just exemplary and they need to be developed in accordance with your needs.

For the mentioned behavior with the "all caps" char format, could I ask you to send us a sample project or step-by-step walkthrough in order to reproduce it on our side? If you decide to provide a sample runnable project/document with the problematic behavior, you can be certain that it will be used only for investigation purposes of this case and your privacy will be respected. Confidentiality is also described in our product EULA - See Section 11 of the EULA and Article V Section 11 of the DevCraft Complete EULA.

I would like to ask you to submit different support tickets for the different questions you might have. This will guarantee that the questions will be handled by the most appropriate person and helps us in providing you with the best service. Separating the questions also helps in keeping the support history organized - for future reference for you and for us. If you need to reference this (or any other) public thread you can paste a link to it into the newly created support ticket. Thank you for understanding.

Regards,
Martin
Progress Telerik

[Patrick]

Hi Martin,

I created a support ticket with the Word document I need to process.

As all the problems are for the same document, I've created a single ticket for all the problems.

[Martin]

Hello Patrick,

Thank you for understanding and separating the questions. I saw your ticket and we are going to investigate the case.

Meanwhile, do not hesitate to contact us if any additional questions arise.

Regards,
Martin
Progress Telerik