DIN-Light font not preserved

s.lueck · July 13, 2022, 1:25pm

Dear Aspose-team!
Using Aspose.Words 9.1.0.0, one of our customer ran into a problem.
Although the original font DIN-Light is installed on the system, text inserted with Aspose.Words is changed to DIN-Regular.
Please find attached the template TMP.doc and the text module TXT.doc.
The text module is inserted into the template’s bookmark C5194Mod000000010000323R0000000006 by using the following insertion logic:

foreach (Node txmNode in txmSection.Body.ChildNodes)
{
...

Node tempTextModuleNode = wordDoc.ImportNode(txmNode, true,
ImportFormatMode.KeepSourceFormatting);
...
if (tempTextModuleNode is Paragraph)
{
Paragraph tempTextModuleParagraph = (Paragraph)tempTextModuleNode;
...
while (tempTextModuleParagraph.HasChildNodes)
{
currentInsertionNode = tempTextModuleParagraph.FirstChild;
documentBuilder.InsertNode(currentInsertionNode);
...
}
...
}

One idea:
Please take a detailed look at TMP.doc:

Zoom it to 400%
move to bookmark C5164Mod000000010000320R0000000005

Directly above the bookmark, you’ll find a section that is just 1 pt. high. It has custom style “fmtStd” while the TXM has style Standard.

Perhaps these different styles are in conflict and cause inconsistent documents (just an idea).

Please let me know if you require further information. Unfortunately, I cannot pass the original rendered document because it contains customer data.
Thank you very much for your help,
cheers,
Stephan

AndreyN · July 13, 2022, 1:24pm

Hi

Thank you for reporting this problem to us. I managed to reproduce the problem on my side. Your request has been linked to the appropriate issue. You will be notified as soon as it is resolved.
Best regards,

s.lueck · July 13, 2022, 1:24pm

Hi Andrey!
Thanks a lot for your immediate reply.
Could we expect this issue to be fixed in the next Aspose.Words for .NET release?
Thanks again,
cheers,
Stephan

s.lueck · July 13, 2022, 1:24pm

Hi Andrey!
And additionally, is there a stable workaround which we can temporarily use to help our customers?
Thank you very much for your help,
cheers,
Stephan

AndreyN · July 13, 2022, 1:24pm

Hi
Thanks for your inquiry. Unfortunately, I cannot suggest any workaround of this issue.
We will let you know one the problem is resolved.
Best regards,

joachim.ritter · July 13, 2022, 1:24pm

Hi Andrey, I’m the development lead of the solution Stephan is working on.
Unfortunately our customers require an urgent correction on that issue, since it really impacts their business.
How can we increase the priority for this bugfix?
Is it something that is dependent on a Priority Support agreement with Aspose?
Thank you,
Joachim

AndreyN · July 13, 2022, 1:24pm

Hi Joachim,
Thanks for your request. Could you please share your code you use to insert one document into another? I will check it and try to find a temporary solution for you.
Best regards,

s.lueck · July 13, 2022, 1:24pm

Dear Andrey!
Thank you so much for offering additional help!!
Please find attached
- AsposeTextModuleDemo.zip
This contains a Visual Studio 2008 solution of a demo tool. This demo uses our original insertion
logic for text modules, see method WordUtils#InjectTextModules().
Please use this tool for debugging our code.
- HOWTO_use_AsposeTextModuleDemo.docx
This is a short description how to use the demo tool
If you require additional information, please let me know.
Again, thank you very, very much for your efforts!
Cheers,
Stephan

AndreyN · July 13, 2022, 1:26pm

Hi Stephan,

Thank you for additional information. It seems the problem occurs because there is a some collision with standard fonts. So to work around this problem you can try using the following method:

public static void ResetStandardFont(Node node)
{
    // Get all Run nodes.
    NodeCollection runs = node.ParentNode.GetChildNodes(NodeType.Run, true);
    foreach (Run run in runs)
    {
        if (run.Font.Style.Styles["Standard"] != null)
            run.Font.Name = run.Font.Style.Styles["Standard"].Font.Name;
    }
}

Please try calling this method before import nodes:

bool isFirstNodeInModule = txmSection.Body.IndexOf(txmNode) == 0;
ResetStandardFont(txmNode);
Node tempTextModuleNode = wordDoc.ImportNode(txmNode, true, ImportFormatMode.KeepSourceFormatting);

Hope this helps.
Best regards,

s.lueck · July 13, 2022, 1:24pm

Dear Andrey!
Great! Thank you very much for your immediate reply and for the proposed workaround!
I tested this and it works fine for our current document rendering scenarios! Thank you!
For our customer requires it for the creation of ‘critical’ documents (contracts etc.), we would like to know the limitations of the workaround (if there are ones).
The basic question would be: Are there scenarios that are not covered by the workaround?
The following questions remain:
I currently don’t understand the composite structure of Style instances
(Aspose.Words.Style#Styles)
According to your docs, this is “the collection of styles this style belongs to”.
Is it a special grouping or is it all styles available within the document?
What happens if the style “Standard” is missing (e.g. excluded by the user)?
I know the workaround would not be executed in this case for “null” is returned.
But would this mean that the correct font will be rendered? (DIN-Light in our case)?
What happens in international environments, especially with different characters e.g. Russia, China etc.?
Will the “Standard”-style also be accessed as desired?
Please get me right:
We’re absolutely glad that you helped us and your help is excellent. So please don’t consider my questions as doubting your capabilities. We just would like to know for which customer scenarios we could provide this workaround.
Thanks a lot for your efforts and your great support!
Please feel free to ask if there are further questions.
Cheers,
Stephan

AndreyN · July 13, 2022, 1:26pm

Hi Stephan,

Thanks for your request. Yes, you are right doc.Styles and Style.Styles is the same collection of style. In this case this code will be more correct:

// Get all Run nodes.
NodeCollection runs = node.ParentNode.GetChildNodes(NodeType.Run, true);
if (node.Document.Styles["Standard"] != null)
{
    foreach (Run run in runs)
    {
        run.Font.Name = run.Document.Styles["Standard"].Font.Name;
    }
}

The root cause of this problem is using default formatting in the document. It seems in some documents default formatting is stored inside Standard style. That is why setting the default font explicitly in the run fixes the problem.
Best regards,

s.lueck · July 13, 2022, 1:24pm

Hi Andrey!
Thank you!
Yes, this workaround works as well as the first one does but looks more like what one would intend to do.
We’re currently checking if there are side effects on special rendering scenarios.
If some questions occur, we would like to ask you.
Thanks a lot,
cheers,
Stephan

AndreyN · July 13, 2022, 1:24pm

Hi Stephan,

Thanks for your inquiry. Please let me know in case of any issues, I will be glad to help you.
Best regards,

s.lueck · July 13, 2022, 1:24pm

Dear Andrey!
Unfortunately, I discovered an undesired effect. If I change the font in the text module in some words only, the changed font is adopted correctly but the remaining unchanged words are again changed to DIN-Regular (although the workaround is implemented).
Please find attached font_changed_in_TXM.zip. It contains TMP.doc (the template), TXM.doc (the text module with the changed fonts) and rendered.doc (the rendering result).
Am I doing something wrong? Do you now if/how I can prevent from DIN-Light being turned to DIN-Regular in this case?
Please let me know if you require further information or assistance.
Thank you very much for your efforts and your great support!
Cheers,
Stephan

AndreyN · July 13, 2022, 1:26pm

Hi Stephan,

Thanks for your request. The only way to work this problem around in this case, is using the code like the following:

public static void ResetStandardFont(Node node)
{
    // Get all Run nodes.
    NodeCollection runs = node.ParentNode.GetChildNodes(NodeType.Run, true);
    if (node.Document.Styles["Standard"] != null)
    {
        foreach (Run run in runs)
        {
            run.Font.Name = run.Document.Styles["Standard"].Font.Name;
        }
    }
    if (node.Document.Styles["Normal"] != null)
    {
        foreach (Run run in runs)
        {
            run.Font.Name = run.Document.Styles["Normal"].Font.Name;
        }
    }
}

Best regards,

s.lueck · July 13, 2022, 1:27pm

Hi Andrey!
Great, this works as desired for the current problem!!!
But unfortunately, it raises another problem:
Nearly all of our unit tests that compare documents fail by messages like this one:
Assert.AreEqual failed. Expected:<>. Actual:<>.
For your information: in our gold standard tests, we unzip expected and actual DOCX, perform pretty prints on all XML documents and then perform line-by-line comparisons between expected and actual.
As you can see by our example, your workaround sets a font that is not set in our expected document.
If I got my failing testing results right, then if no fonts are set for style “Normal” in the expected, a default value is implicitly set by Word when opening the document.
In the docs XML, the font information is appended after
<w:rStyle w:val=“DefaultParagraphFont” />
This font seems to be the same as the one explictly set by your workaround (in the example above: “Times New Roman”).
By a small addition to your code, I tried to set the fonts only if they differ:

public static void ResetFont(Node node)
{
    ResetFont(node, "Standard");
    ResetFont(node, "Normal");
}
        
private static void ResetFont(Node node, string fontName)
{
    var runs = node.ParentNode.GetChildNodes(NodeType.Run, true);
    if (node.Document.Styles[fontName] != null)
    {
        foreach (Run run in runs)
        {
            var runFontName = run.Font.Name;
            var styleFontName = run.Document.Styles[fontName].Font.Name;
            var fontsDiffer = (runFontName != null && !runFontName.Equals(styleFontName)) || runFontName == null;
            if (fontsDiffer)
            {
                run.Font.Name = styleFontName;
            }
        }
    }
}

This helped a little bit: only half of our tests failed.
The ones who fail raise messages like
Assert.AreEqual failed. Expected:<>. Actual:<>.
So now, we have real font differences (could this have something to do with themes? Calibri -> body theme?). Another font that differs is Univers45Light.
Could you please let me know if you have additional ideas?
I hope that I don’t cause too much trouble or confusion with this long post Please let me know if I see some things wrong or if there is some information missing.
Thank you so much for your help!
Cheers,
Stephan

AndreyN · July 13, 2022, 1:24pm

Hi Stephan,

Thanks for your inquiry. Could you please attach your input and output DOCX documents here for testing? I will check the problem on my side and provide you more information.
Also do you use the same code as previously?
Best regards,

s.lueck · July 13, 2022, 1:24pm

Hi Andrey!
Thanks for your quick help!
Yes, sure, please find attached failed_test.zip.
This contains
TMP/10000296.docx, which is the template
TXM/10000291.docx and TXM/10000295.docx which are the text modules
actual.docx which is the rendered document after the workaround
expected.docx which is the expected document, created before the workaround
The actual and the expected document have been created by inserting the textmodules into the templates bookmarks as follows:
inserting text module 10000291 into the bookmarks C5804Mod000000010000291R0000000002 and C9052Tsr000000010000295R0000000001
inserting textmodule 10000295 into bookmark C4792Phd111111111111111R0000000003
As you can see, the expected font of the inserted text is Calibri while the actual font is Times New Roman.
Probably, my afore mentioned guess that themes have something to do with that problem is wrong: Calibri is not set by Body theme.
Please let me know if you need further information or documents.
Thank you very much for your efforts!
Cheers,
Stephan

s.lueck · July 13, 2022, 1:24pm

Hi Andrey!
Sorry, I forgot to answer your last question:
Yes, I’m using our rendering logic which I passed to you as Visual Studio project.
I modified your workaround as posted above, with the “do the fonts differ”-check.
The expected document has been created without any workaround code.
I hope that helps,
cheers,
Stephan

s.lueck · July 13, 2022, 1:24pm

Hi Andrey!
Additional remark:
The attached sample templates and text modules contain table data which is not inserted by our demo tool. Hence if you insert the data with that tool, your document rendering results will look different from the documents that I attached: the tables will contain no data.
But this should have no influences on the font problem.
Cheers,
Stephan