Posted: Tue Oct 23, 2007 3:24 pm Post subject: Page numbers in MS Word conversions
Hi all:
I am desperately trying to switch away from MS Office to NeoOffice, which I like. However, I have noticed that page numbering in converted Word files have the number with a box next to it. If I delete all the boxes in a document, Word hangs. I don't really want to inflict either page number boxes or worse on colleagues/students/whoever who gets files from me. Any thoughts?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Oct 23, 2007 10:37 pm Post subject:
Number with a box? Do you have an example? In OOo/Neo page nubmers do appear in grey backgrounds to indicate they're variables and, in headers and footers, in grey outlined text frames indicating separate text areas on a page. These should disappear on printout.
If it is not the standard areas, you may want to check the formatting of the page numbers. It may be either using a font that is incompatible or may contain glyphs that aren't recognized (e.g. I sometimes have problems with the swirly section symbol glyph)
Posted: Tue Oct 30, 2007 7:36 am Post subject: Example...
Yes, I'm seeing the same issue. Hit the links below to see a screen shot of what is going on.
What it looks like in Word 2004 on the Mac (notice box to the right of page number "i" in lower right corner):
What it looks like in NeoOffice (everything is fine):
Note: This issue occurs with the following sequence of events. A .doc file is created in Word that looks fine with page numbers at the bottom and formatted correctly. Next, a NeoOffice user opens the file (not touching the page numbers or their formatting in the footer), makes changes to the text in the body of the document, and then saves and closes the document. Finally, a Word user opens the modified file and finds boxes after the page number at the bottom of each page (see screenshot links above).
I suspect that this is a bug in NeoOffice's underlying OpenOffice.org code that does the export to Word. However, I cannot confirm my theory without a sample document so can you create a bug in Bugzilla and attach a sample document?
Then, we can open and save the file in OpenOffice.org and attach our saved Word file. If the same problem occurs, it is a bug in the OpenOffice.org export which we probably cannot fix. However, if it does not occur with OpenOffice.org, then it is our bug and we will work on finding and fixing the cause.
Thanks Patrick. I set up an account with bugzilla and I'll try to log in and submit this.
I'm finding lots of bugs when beginning a document in Microsoft Word, moving it to NeoOffice, and then bringing it back to MS Word. I'm assuming these bugs are all probably from the OpenOffice code, but its still frustrating. I'm trying to switch our office over from MS Office to OpenOffice, but the compatibility issues they're seeing is scaring them away.
I'm finding lots of bugs when beginning a document in Microsoft Word, moving it to NeoOffice, and then bringing it back to MS Word. I'm assuming these bugs are all probably from the OpenOffice code, but its still frustrating. I'm trying to switch our office over from MS Office to OpenOffice, but the compatibility issues they're seeing is scaring them away.
You should be aware no application can be expected to import and save MS Office formats perfectly. Even opening and saving an MS Office document created on Windows in MS Office on Mac has issues. In other words, I think you need to realize that NeoOffice and OpenOffice.org are not necessarily "drop in replacements" for MS Office. In fact, I do not believe that such an application exists.
Unfortunately, this is what you get with a proprietary document format: only the creator of the format can read it reliably. So, if you are really set on getting rid of MS Office in your organization, you will have to bear some pain in editing your existing documents to avoid the round-trip saving issues that you run into.
Posted: Wed Dec 12, 2007 9:33 am Post subject: Page numbering and table of contents getting whacked
Patrick,
Thanks for the note. Yeah, I understand some of the complexity that goes in to getting these apps to work as well as they do with the same document (yes, I too have seen issues between PC and Mac versions of Word).
In the event that someone who is good with the code is able to shed light on this, I'm going to post the documents on Bugzilla shortly. Maybe someone on NeoOffice or OpenOffice will be able to figure it out?
From a relatively long experience with supporting actively only NeoOffice and OpenOffice in our offices over M$ Office, I think I should advise you that you need to think and talk in terms of a one-way migration to Open/NeoOffice.
Passing documents back and forward between the two applications is far from ideal and needs to be actively discouraged. It is very inefficient and, as you've probably already discovered, it leads to employees repeating the same re-formatting steps with each and every conversion in each direction.
When we made the decision to move away from M$ Office, we accepted that there would always be some exceptions but basically once a Word document was moved into NeoOffice format (then .sxw, now OpenDocument), it must remain in that format as the original. Any copies made from that are not considered to be equivalent or originals but - rather in the same way as we think about PDFs - they are considered as derivative versions.
We still have a few copies of M$ Excel in use since not all formulas converted 100% and we have to balance the time (and cost) which would be needed to redevelop those instances against the fact that they are internal documents used by only a few staff involved in particular processes.
Just sharing some reflections, _________________ Ray Saunders
World Scout Bureau
I noticed that Schwie filed three bugs that had clear samples of the data corruption that was occurring. I now do not doubt that there was a real bug occurring and Schwie's case and the corruption was apparent in both Word 2004 and TextEdit.
What is interesting is that using the latest test patch (Patch 3 Test 5), I did not get any corruption in the files when I followed Schwie's very detailed steps. It is possible that I have inadvertently fixed this data corruption bug as a result of one or more of my other recent bug fixes.
I don't think this is the most advisable workaround for the file swapping issue, but I am wondering if there are users in your organization that insist on sticking with MS Office the Windows users can be encouraged to use the ODF converter plug-in from Sun and save and share copies of documents in in ODF for a more seamless integration with NeoOffice and OpenOffice users.
But it is easy for me to toss around facile advice. I am a single individual and when I send out stuff I usually don't want it altered--this makes the NeoOffice and OpenOffice built-in PDF creation a huge plus.
FYI. I found the cause of the problem and it is the well known Microsoft Office "list separator" bug.
The specific steps to workaround this bug as well as links to more details about this Microsoft Office bug are available at the end of bug 2808.
In short, the problem is that Word stores an index as a list and in Microsoft Office list items are stored using a list separator character. The bug arises because Office expects a different character as the list separator depending on your machine. For some machines, ";" is the list separator and for other machines "," is the list separator.
Since there is no way to anticipate which list separator readers of your document have configured, NeoOffice's underlying OpenOffice.org code must use one and hope that that character is more commonly used than the other.
In this particular case, OOo saves with the ";" character but Word is configured to use ",". Hence the problem.
Unfortunately, changing OOo to use "," is not a solution as that will merely make exported .doc files unreadable for the majority of people that have Word configured to use the ";" character.
I think that I have found a fix for this issue. I have found the OpenOffice.org code that does the importing of Word documents and there is a conveniently document variable called CommaSeparator that I can set if the imported document appears to use a comma as the list separator. Then, when exporting, I can use the same variable to determine if commas should be written to the .doc file instead of semicolons.
This approach will not work when you create a new .doc document in NeoOffice, but it will preserve the list separator character for .doc files originally created by Word.
For those who want to test out my fix, try the test patch listed at the end of bug 2808.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
