NumPages Error back in Word 2007

[Peter Karlström]

Hi

This question concerns a NUMPAGES bug, when the value is not updated when
the document is printed.
I've read a lot of articles regarding this error for the previous versions
of Word, and as I understand, fixes have been made to these versions.
However, I have not found one for Word 2007.

The COMAddin I have created for Office 2007 runs on client computers.
But when the user wants to create a PDF-file from the document, the PDF-file
is rendered on a server. The server have no COMAddin to force update.

The result is that in the header of page 1 it says Page 1 of 1. On the
following pages it says Page 2 of 4, Page 3 of 4 and so on.
This does not update as i should when printed.

Is there a configuration solution to this or is there a fix out there that I
have not found?

Thanks in advance

 

[Ji Zhou \(Wicresoft\)]

Hello Peter,

Seasons Greeting!

As to the NUMPAGES issue you post, I have searched in our internal data
base. I do find a similiar issue reported before like the one you talked.
The following is some background,

Numpage Field code in textbox in headers/footers does not update when saved
to PDF.Field codes in a text box in the header or footer do not save to PDF
correctly. Instead of showing as 1 of 5, 2 of 5 , 3 of 5, etc, the result
shows as 1 of 1, 2 of 2 etc. But any subsequent save as PDF in the session
after the XPS, results in a correct listing of the fields. Printing to
postscript or pcl printer also does not properly update the field code.

Therefore, let's go through the following steps to see if it will fix it.

1.Save your document to XPS file for the first time.(we will reproduce the
issue).

2.Left the original document opened and save it to PDF format. This time we
should see the NUMPAGES field update correctly.


If this is exactly the same issue as you encountered. Please wait for a few
days for the release of Office 2007 SP2. The issue will be fixed in the SP2
which is supposed to be released in the early 2009.

By the way, wish you a happy Christmas in advance!


Best regards,
Ji Zhou
MSDN Newsgroup Online Support

 

[Peter Karlström]

Hi Ji Zhou

Thank you for your reply and welcome back to a new year.

The issue is not PDF-related at all. To recreate the error, follow the steps
below:

1. Create a new Word 2007 document
2. Insert a page header with the values Page "pages" of "numpages" fields,
like Page 1 of 3.
3. Add 3 pagebreaks
4. Save the document in Office 2003-format (.doc)

When you open the document, the first page says Page 1 of 3. The other pages
says page 2 of 4, 3 of 4 and so on.
If you open Printpreview, first page says Pags 1 of 2 until you click the
document.
then it corrects itself to Page 1 of 4.

It is this behaviour that causes us problems when we try to create PDF-files.

Thanks in advance for any help

Best Regards
--
Peter Karlström
Midrange AB
Sweden

Hello Peter,

Seasons Greeting!

As to the NUMPAGES issue you post, I have searched in our internal data
base. I do find a similiar issue reported before like the one you talked.
The following is some background,

Numpage Field code in textbox in headers/footers does not update when saved
to PDF.Field codes in a text box in the header or footer do not save to PDF
correctly. Instead of showing as 1 of 5, 2 of 5 , 3 of 5, etc, the result
shows as 1 of 1, 2 of 2 etc. But any subsequent save as PDF in the session
after the XPS, results in a correct listing of the fields. Printing to
postscript or pcl printer also does not properly update the field code.

Therefore, let's go through the following steps to see if it will fix it.

1.Save your document to XPS file for the first time.(we will reproduce the
issue).

2.Left the original document opened and save it to PDF format. This time we
should see the NUMPAGES field update correctly.


If this is exactly the same issue as you encountered. Please wait for a few
days for the release of Office 2007 SP2. The issue will be fixed in the SP2
which is supposed to be released in the early 2009.

By the way, wish you a happy Christmas in advance!


Best regards,
Ji Zhou
MSDN Newsgroup Online Support

 

[Colbert Zhou [MSFT]]

Hi Peter,

Thanks for your clarification. I can see your issue now!

But if I print the document out as a pdf or other type, the NUMPAGES will
appear correctly. I notice that the incorrect value only shows when the
document is new opened. If we do any manipulation, Word corrects the value
in header. So usually, this will not affect most of the common Word users.
Therefor, would you mind letting me know how this issue affect your
busniess? So that I can try to help to find if there is any workaround.
Currently, my guess is that you may be doing automation job in the Open
event handle. And in the Open event handle, you just retrieve the NUMPAGES
and dynamically creat PDF by your algorithm, rather than by the Word UI,
right? In that case, yes, we will be affected by this issue.

So my workaround is starting a Timer in the Open event handle, and wait for
0.5 second or so, to let the Word correct the NUMPAGES. After that, in the
timer's Tick event, we can refresh the Screen and perform our tasks. See my
codes below.

Timer t = new Timer();

private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
this.Application.DocumentOpen += new
Microsoft.Office.Interop.Word.ApplicationEvents4_DocumentOpenEventHandler(Ap
plication_DocumentOpen);
}

void
Application_DocumentOpen(Microsoft.Office.Interop.Word.Document Doc)
{
t.Enabled = true;
t.Tick += new EventHandler(t_Tick);
t.Interval = 500;
}

void t_Tick(object sender, EventArgs e)
{
t.Enabled = false;
this.Application.ScreenRefresh();
//Do you work below
}

Please let me know if this resolves your issue! Thanks again for using MSDN
Newsgroup Service and have a nice day!


Best regards,
Colbert Zhou
MSDN Newsgroup Online Support

================================================================
I change my First name from Ji(Chinese Name) to Colbert(English Name)

 

[Peter Karlström]

Hi Colbert

Thank you for your reply.

I'm sorry to say that the problem lies in that we have little or no control
over the PDF-making process.
In the customers web-application (EMC Documentum-based), a user chooses to
create a PDF file from an existing Word DOC-file within the web user
interface.
The process runs in the server environment and the PDF is created using a
product called AdLib Express PDF Print Driver.

I have tried to make a temporary fix by creating a COM Addin for the server
with the following:
* In the DocumentOpen event:
On Error Resume Next
Doc.PrintPreview
Doc.ClosePrintPreview
Doc.ActiveWindow.View.ShowHiddenText = True

* In the DocumentBeforePrint event:
On Error Resume Next
Doc.ActiveWindow.View.ShowHiddenText = True

This solves the problem for some documents, but unfortunately not for all.
And as far as I know, using a COM Addin in a server environment is not a
recommended approach.

Have you any other suggestions on how to solve this?

Thanks in advance

--
Peter Karlström
Midrange AB
Sweden

 

[Colbert Zhou [MSFT]]

Hello Peter,

Thank you for your clarification.

Actually, the not recommended and supported thing is automating Office from
Server side, rather than using a COM Addin in a Server environment. If we
really need to do that, there are some considerations you can find in this
KB article http://support.microsoft.com/kb/257757.

And from your description, it should be the AdLib Express PDF Print Driver
that is doing Office automation from server side, our workaround Office
Addin is hosted in the Office application that remote started and automated
by AdLib Express PDF. So, please feel free to use your workaround Addin.

As to the issue itself, I think it is related to the Word product, rather
than the Office development. So the right place for it should not be the
com.addin newsgroup, but Word product newsgroup here,
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=micros
oft.public.word.numbering&cat=en_US_952c9b15-883f-4e1f-830f-b72aa840d6d2&lan
g=en&cr=US. But if this really affects and compacts the business, I highly
encourage you to open a case with the CSS to work it out. If its priority
is not that high, I think the Addin workaround is an OK solution at current
time. What is your opinion?


Best regards,
Colbert Zhou (colbertz @online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

 

[Peter Karlström]

Hi Colbert

Thank you for your reply.

We have started two seperate actions in order to get this to work.
We will see if AdLib Express can be updated to take care of the problem.
In fact, Adobe PDF Printer takes care of it, and no page-errors exist when
PDF documents are created with this tool.
We have also made some modifications to our COM Addin fix, to see if this
could help.

How ever, this is an obvious Microsoft Word 2007 bug, for which one could
expect that a bug fix have been made a long time ago.
I have small hope that this perticular error have been fixed in SP2.

Either way, thank you for your answers and recommendations.

Best Regards