Issue (with Fonts) when copying Styles

[PraneethS]

We seem to be facing an issue when we use the addCopy() method of the style API for applying styles from one document to another. The primary issues that we see are with the fonts associated with some styles. The main issue is the code applies formatting on the Windows environment, but doesn’t do so on the Linux environment.
To give more context, we have created a style comparator which compares two style objects by comparing all the getter attributes (and recursively doing the same for associated objects). After using the addCopy() method to apply styles, when we call our comparator, we get differing results in the font associated with different cases, with the common difference reported in the getLocaleIdBi()
getSize()
getSizeBi()
API’s of the font object (in our case, mostly for the default paragraph font). Also, there are cases where we have found that there is a difference in the ParagraphFormat object associated with the style object, wherein the difference pops up in one or more of the
getFirstLineIndent()
getSpaceBefore()
getSpaceAfter()
getLineSpacing()
API’s of the former. To be even more specific, we noticed this discrepancy occurring with documents created across different versions of Word - we saw that only the attributes that were changed from the defaults were re-applied (for instance, the default spacing after is set to 10 pt in office 2010 docs, but it is 0pt in 2007 docs. When I apply styles from the 2010 doc to the 2007 doc, the 2007 doc still shows 0pt spacing after, possibly because in the 2010 doc, the spacing was not changed from its default).

To add on to this, we had another concern - when we were copying table styles, we were detecting difference in font - the issue I could pinpoint this to was that most of the differing table styles were actually based on the Table Normal style, whose attributes were different from one version of Word to another, and the style itself was unmodifiable. For your reference, I’m attaching a picture, the document on the left hand side reflects the document to which we want to apply the table styles applicable in the document on the right-hand side.

[tahir.manzoor]

Hi there,

Thanks for your inquiry. In case you are using an older version of Aspose.Words, I would suggest you please upgrade to the latest version (v13.10.0) from here and let us know how it goes on your side. If the problem still remains, please share
following detail for investigation purposes.

• Please attach your input Word document.
• Please

create a standalone/runnable simple application (for example a Console
Application Project) that demonstrates the code you used to generate
your output document

• Please attach the output Word document that shows the undesired behavior.

Unfortunately,
it is difficult to say what the problem is without the Document(s) and
simplified application. We need your Document(s) and simple project to
reproduce the problem. As soon as you get these pieces of information to
us we’ll start our investigation into your issue.

[PraneethS]

Hey Tahir,
I’d like to do this on a case-by-case basis.

1. When I apply styles from doc A to doc B, I see that the base font defined for doc B is persisted, and not overwritten from the base font in doc A.
2. Paragraph spacing for the normal style is different in doc A as compared to doc B, but on applying styles from A to B, these aren’t applied.

The code for applying styles is:

StyleCollection tempStyles = docA.getStyles();
StyleCollection docStyles = docB.getStyles();
Style stl1, newstyl;
for (int i = 0; i < tempStyles.getCount(); i++)
{
    stl1 = templ.getStyles().get(i);
    if (stl1.getName().endsWith("Char")) continue;
    newstyl = doc.getStyles().addCopy(stl1);
    newstyl.setName(stl1.getName());
}

I’m attaching the documents for both cases. I shall get back to you with more documents

[tahir.manzoor]

Hi there,

Thanks for sharing the detail. I
have tested the scenario and have managed to reproduce the same issues
at my side. For the sake of correction, I have logged these issues as
follow:

WORDSNET-9311 : Styles.AddCopy does not copy the style correctly (case 1)
WORDSNET-9312 : Styles.AddCopy does not copy paragraph spacing for the normal style (case 2)

I
have linked this forum thread to the same issues and you will be
notified via this forum thread once these issues are resolved. We
apologize for your inconvenience.

[PraneethS]

Hi Tahir,
Thanks for following up on this. I wanted to bring up another issue we found out when applying styles. We had an input document doc A (created on Windows), to which we tried applying styles from doc B (created by Aspose in Linux, but modified in Windows) in the Linux environment. What we found out when we compared the input doc A with doc B was that there was a difference in the Default Paragraph Font style:
locale identifier of formatted right-to-left characters differs, font size in points differs,font size in right-to-left document differs (as referred to by the Font object API’s
getLocaleIdBi()
getSize()
getSizeBi() of this style.
However, after running the same applyStyles code (with the addCopy()), the same difference was detected when we compared output doc C with the template doc B.

[tahir.manzoor]

Hi there,

Thanks for your inquiry.

I have tested the scenario while using following code example and have managed to reproduce the same issue at my side. For the sake of correction, I have logged this problem in our issue tracking system as WORDSNET-9317. I have linked this forum thread to the same issue and you will be notified via this forum thread once this issue is resolved. We apologize for your inconvenience.

*PraneethS:

However, after running the same applyStyles code (with the addCopy()), the same difference was detected when we compared output doc C with the template doc B.*

I have also found the same issue with doc C while using following code example.

Document docA = new Document(MyDir + "docA.docx");
Document docB = new Document(MyDir + "docB.docx");
StyleCollection tempStyles = docA.getStyles();
Style style, newstyl;
for (int i = 0; i < tempStyles.getCount(); i++)
{
    style = tempStyles.get(i);
    if (style.getName().equals("Default Paragraph Font"))
    {
        if (style.getName().endsWith("Char")) continue;
        newstyl = docB.getStyles().addCopy(style);
        newstyl.setName(style.getName());
        System.out.println(style.getFont().getSize() + " - " + newstyl.getFont().getSize());
        System.out.println(style.getFont().getSizeBi() + " - " + newstyl.getFont().getSizeBi());
    }
}

It would be great if you please share
following detail for investigation purposes.

• Please

create a standalone/runnable simple Java application that demonstrates the code you used to generate
your output document

• Please attach the output Word file that shows the undesired behavior.

[PraneethS]

Hey Tahir,
The code for generating the new document doc C, is essentially the same code I had provided in an earlier post, have, and has an additional line saving the document object of doc A into a target directory as doc C. That is,

StyleCollection tempStyles = docA.getStyles();
StyleCollection docStyles = docB.getStyles();
Style stl1, newstyl;
for (int i = 0; i < tempStyles.getCount(); i++)
{
    stl1 = templ.getStyles().get(i);
    if (stl1.getName().endsWith("Char")) continue;
    newstyl = doc.getStyles().addCopy(stl1);
    newstyl.setName(stl1.getName());
}
docA.save("…\doc C.docx");

The output word document that has been generated is in the attachment in the post to which you have made the reply above. (fontDiff.zip - output file doc C). Thanks.

[tahir.manzoor]

Hi there,

Thanks for your inquiry. Unfortunately, the shared code do not clear the shared scenario. Please check the following bold line of code. You are saving the document (docA). If you replace the doc variable with docA or docB, result will not according to your requirements.

StyleCollection tempStyles = docA.getStyles();
StyleCollection docStyles = docB.getStyles();
Style stl1, newstyl;
for (int i = 0; i < tempStyles.getCount(); i++)
{
    stl1 = templ.getStyles().get(i);
    if (stl1.getName().endsWith("Char")) continue;
    newstyl = doc.getStyles().addCopy(stl1);
    newstyl.setName(stl1.getName());
}
docA.save("…\\doc C.docx");

I suggest you please use the code shared at following post to test your scenario for doc C.
https://forum.aspose.com/t/48541

Please share code and some more detail about your last scenario (document c), I will investigate the issue on my side and provide you more information.

[PraneethS]

Hey Tahir,
I’m attaching the required files in the zip file. The scenario here is that the document doc B is our template, from which styles are copied and applied to the document object corresponding to doc A, which is then saved as doc C. Also, doc A was created manually in Windows, but doc B (the template) was created using Aspose in Linux, and some attributes of the normal style were modified manually in Windows, and then this apply code was run:

StyleCollection tempStyles = docA.getStyles();
StyleCollection docStyles = docB.getStyles();
Style stl1, newstyl;
for (int i = 0; i < tempStyles.getCount(); i++)
{
    stl1 = templ.getStyles().get(i);
    if (stl1.getName().endsWith("Char")) continue;
    newstyl = docA.getStyles().addCopy(stl1);
    newstyl.setName(stl1.getName());
}
docA.save("…\doc C.docx");

The issue then detected was the difference in the
getLocaleIdBi()
getSize()
getSizeBi()
API’s of the font associated with the Default Paragraph Font style when we were comparing doc C and doc B. Do let me know if you have queries this approach. Thanks.

[tahir.manzoor]

Hi there,

Thanks for sharing the detail. The shared code copy the styles in the same document again. So, this does not clear your issue. The value of getLocaleIdBi(), getSize(), getSizeBi() will be same. Please check my comments in the following code.

StyleCollection tempStyles = docA.getStyles();
StyleCollection docStyles = docB.getStyles(); //docStyles not used
Style stl1, newstyl;
for (int i = 0; i < tempStyles.getCount(); i++)
{
    stl1 = templ.getStyles().get(i); // This line give error
    if (stl1.getName().endsWith("Char")) continue;
    newstyl = docA.getStyles().addCopy(stl1); // same style is copied from docA again
    newstyl.setName(stl1.getName());
}
docA.save("…\\doc C.docx");

Please create a standalone/runnable simple Java application that demonstrates your issue. I have not found any issue with getLocaleIdBi. Please also include scenario in your code example. Unfortunately, it is difficult to say what the problem is without simplified application.

However, I already logged the issue with Font.Size/Font.SizeBi as WORDSNET-9317 (Styles.AddCopy does not copy Font.Size/Font.SizeBi).

[PraneethS]

Hey Tahir,
Sorry about the code. The templstyles is the style collection form doc B:

StyleCollection docStyles = docA.getStyles();
StyleCollection tempStyles = docB.getStyles();
Style stl1, newstyl;
for (int i = 0; i < tempStyles.getCount(); i++)
{
    stl1 = tempStyles.get(i);
    if (stl1.getName().endsWith("Char")) continue;
    newstyl = docStyles.addCopy(stl1); //copying to doc B from doc A
    newstyl.setName(stl1.getName());
}
docA.save("…\\doc C.docx");

Also, I ran into another issue with the same documents. It seems that the table normal style is not getting copied correctly from doc B to doc A. Could you look into this as well? Thanks.

[tahir.manzoor]

Hi there,

Thanks for sharing the detail. I have tested the scenario and have managed to reproduce the same issue at my side. I already logged this issue as WORDSNET-9317. We will update you via this forum thread once this issue is resolved.

We apologize for your inconvenience.

[tahir.manzoor]

Hi there,

It is to inform you that we have completed the analysis of issue WORDSNET-9311 (case 1) and has come to a conclusion that this issue and the
undesired behavior is actually not a bug in
Aspose.Words. So, we have closed this issue as ‘Not a Bug’.

The direct formatting is applied to text ‘DDD’ in docB.docx. The ‘Normal’ style is correctly copied to output document. Please clear the formatting of text ‘DDD’ in output Docx and apply the ‘Normal’ style. You will get the correct output.

Please note
that formatting is applied on a few different levels. For example, let’s
consider formatting of simple text. Text in documents is represented by
Run element and a Run can only be a child of a Paragraph. You can apply
formatting 1) to Run nodes by using Character Styles e.g. a Glyph
Style, 2) to the parent of those Run nodes i.e. a Paragraph node
(possibly via paragraph Styles) and 3) you can also apply direct
formatting to Run nodes by using Run attributes (Font). In this case the
Run will inherit formatting of Paragraph Style, a Glyph Style and then
direct formatting.

Please let us know if you have any more queries.

[tahir.manzoor]

Hi there,

It
is to inform you that we have completed the analysis of issue WORDSNET-9312 (case 2) and has come to a conclusion that this issue and
the
undesired behavior is actually not a bug in
Aspose.Words. So, we have closed this issue as ‘Not a Bug’.

Please note that Aspose.Words mimics the same behavior as MS Word does. If you copy the styles by using MS Word, you will get the same output. Please try to copy the ‘Normal’ style in MS Word (Manage Styles, Import/Export, select source file and confirm that style will be overwritten) and check the output (the ‘Normal’ style). The ‘Normal’ style in output document will be same as output.docx.

Please let us know if you have any more queries.

[tahir.manzoor]

Hi there,

It
is to inform you that we have completed the analysis of issue WORDSNET-9317 and has come to a conclusion that this issue and
the
undesired behavior is actually not a bug in
Aspose.Words. So, we have closed this issue as ‘Not a Bug’. I am quoting developer’s comments here:

The style was copied correctly, but if you unzip the document (docA) and check “Default Paragraph Font” style you will see, it does not contain FontSize property. That is why this property will be get by Aspose.Words from the next element in hierarchy chain (Normal style or styleDefaults). So when you copy this style to the other document these defaults can be different and that is why you observe this situation.

[PraneethS]

Hi Tahir,
What is the update on locale difference thing. As previously said Font.getLocaleId(), Font.getLocaleIdBi() and Font.getLocaleIdFarEast() are not getting applied.

Just for more clarity, we see this problem when generating new document via Aspose on Linux environment and applying the formatting options to this from the document that was generated on windows. The code we are using for applying is mentioned in this thread.

Please suggest if font locale id’s could not be applied.

Thanks.

[tahir.manzoor]

Hi Praneeth,

Thanks for your inquiry. The WORDSNET-9311, WORDSNET-9312 and WORDSNET-9317 were closed as ‘Not a Bug’. We have already shared the detail of these issues in this thread.

Could you please elaborate some more detail about your query? It would be great if you please share your code again or share the forum link which contains the code. We will then provide you more information about your query.

[PraneethS]

For WORDSNET-9317
Tahir:- The
style was copied correctly, but if you unzip the document (docA) and
check “Default Paragraph Font” style you will see, it does not contain
FontSize property. That is why this property will be get by Aspose.Words
from the next element in hierarchy chain (Normal style or
styleDefaults). So when you copy this style to the other document these
defaults can be different and that is why you observe this situation.

Hi Tahir,
It seems that the differences are appearing because in one doc the default font for Normal.dotm template is different than other document. When we are getting font properties these might be referring to Normal.dotm default formatting based on which document is created.

Is there a way to apply these default also to the document. If so, these differences might not appear.

Thanks.

[tahir.manzoor]

Hi Praneeth,

Thanks for your inquiry.

You can set character formatting of the style using Style.Font property according to your requirements. However, there is no other way to fix the missing font property.