Wrong pageNumbers in aspose

Good day,
when i load the document in aspose(108page) it has a different number of pages than in MS word (105page).
You can look at it for me why it has
wrong page count?

@benestom Could you please attach your problematic document here for testing? We will check the issue and provide you more information.

P001_3A.zip (944.3 KB)

@benestom In your document there is an error with STYLEREF field in header. Aspose.Words output different error message than MS Word which leads to different header size and thus different layout. You could lock the STYLEREF fields so they will not be updated by Aspose.Words and get the same layout as in MS Word. You could use following code:

foreach (Field field in doc.Range.Fields)
    if (field.Type == FieldType.FieldStyleRef)
        field.IsLocked = true;

Thank you for answering.
I have two questions for you:

  1. How did you come up with it? Is it possible to do some kind of analysis so that in such a case I am informed about a possible error? So that I know in advance that the number of pages does not match.

  2. STYLEREF fields are a problem for me due to language differences. I use the Czech language. The MS work application inserts the names of the styles in the Czech language. Can aspose be set to work with the same language set?


  1. I just compared the layout of MS Word and Aspose.Words output and noticed that the difference is caused by different header size which in turn is caused by different field update error message. Generally Aspose.Words issues warnings on potential problems. But unfortunately in case of field update error there are no warnings. Also it is not possible to determine that the number of pages will be different from MS Word output because the document itself do not store the number of pages and it is calculated only during the layout process.
  2. Aspose.Words uses Thread.CurrentThread.CurrentCulture culture settings. You could change them to get the desired result. Also there is Document.FieldOptions.FieldUpdateCultureSource property which allows to use the field formatting properties to select the culture for the field update.

good day,

Thank you for the explanation. But I ran into a problem. When I lock StylReff, the page numbers are correct though.

If I use the following code:

(Section)docClone.ImportNode(doc.ExtractPages(19, 1).Sections[0], true, ImportFormatMode.KeepSourceFormatting)

In the table, the table header will be doubled This will stretch the document by an extra page.

Diference page 20:

DiferenceHeadTable.jpg (105.9 KB)

@benestom Thank you for reporting this problem to us. For a sake of correctio nit has been logged as WORDSNET-24816. We will keep you posted and let you know once it is resolved or we have more information for you.

good day,
I’ll go back to the FieldStyleRef issue. I insert heading 1 which is saved as “Heading 1”, but the field formula is “STYLEREF “Nadpis 1” \* MERGEFORMAT”. LocaleId is set to CZ language. After saving the document as a PDF, this STYLEREF turns into an error for me: Error! No text of specified style in document

In order to get around the whole situation, I have to “STYLEREF “Nadpis 1” \* MERGEFORMAT” in the formula - I replace “Nadpis” with “heading” then the value will be correctly written after saving to PDF. But this solution does not seem conceptual to me, what would you advise me?

@benestom Thank you for additional information. I have inspected code and see that currently Czech localizes style names are not supported upon updating STYLEREF fields. So your workaround with changing the localized style names to invariant name is currently the only solution.

We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): WORDSNET-24881

You can obtain Paid Support services if you need support on a priority basis, along with the direct access to our Paid Support management team.

The issues you have found earlier (filed as WORDSNET-24816) have been fixed in this Aspose.Words for .NET 23.2 update also available on NuGet.

The issues you have found earlier (filed as WORDSNET-24881) have been fixed in this Aspose.Words for .NET 23.3 update also available on NuGet.

Thank you in advance.
While testing the document, I came across one more document where it makes sense to me. One page turns into 2. Could you take a look at it for me…

I am only sending the 1 page that I added to the new blank file.

tmp.AppendChild(tmp.ImportNode(doc.Sections[57], true));

the attachment should be on one page, but it is on 2

SectionBefore56.docx (28.5 KB)

@benestom Do you use the same input document you have attached earlier? When I use the following code for testing on your document, the output looks different than the document you have attached:

Document doc = new Document(@"C:\Temp\in.docx");

Document tmp = (Document)doc.Clone(false);
tmp.AppendChild(tmp.ImportNode(doc.Sections[57], true));


Please attach your original document here for testing.

in.docx (1.3 MB)

Document docTest = new Document(filePath + "in.docx");

Document tmp = (Document)docTest.Clone(false);
tmp.AppendChild(tmp.ImportNode(docTest.Sections[56], true));

tmp.Save(filePath + "out.docx");

In doc “in” is section 56 = 1page
in doc “out” and there are 2 page

@benestom This is not a bug, this is expected behavior. If remove all content form the document except the 56th section, you will see exactly the same result:
in_modified.docx (1.0 MB)

I modified document manually in XML so nothing has been changed in the document styles, or other options. The is simply too little space between end of the table and the paragraph followed the table. This is not seen in the original document because the next section goes next.

Also, here is the document modified in MS Word: modified_in_ms_word.docx (944.8 KB)
I have removed all content after the 56th section. As you can see an empty page is there.

That’s right, thank you very much for finding out….

1 Like