Document Could Not Be Opened

[ntx]

Hello,

Since I updated my NWP 1.1 to 1.2, I have exactly the same problem. When I try to open any ".doc" file, NWP 1.2 displays first "converting file formats.." dialog, then "loading additional file filter..." and finally gives up with the error message as uploaded by mwiseman on Mar 23.

My console log says typically :
"Nisus Writer Pro[1411] * failed OOo conversion: Exception was thrown when loading the document."

or alternatively, font-related messages were recorded depending on case. e.g.

"2009-06-02 20:27:35.874 Nisus Writer Pro[1455] * font ""ArialMS 12.00 pt. P [] (0x15801710) fobj=0x154de260, spc=3.33"" is missing face: (
(ArialMT, Regular, 5, 16777228),
("Arial-ItalicMT", Italic, 5, 13),
("Arial-BoldMT", Bold, 9, 16777226),
("Arial-BoldItalicMT", "Bold Italic", 9, 11)
)

and/or

2009-06-02 20:27:35.944 Nisus Writer Pro[1455] * font ""TimesNewRoman 12.00 pt. P [] (0x1560ccf0) fobj=0x1584fc80, spc=3.00"" is missing face: (
(TimesNewRomanPSMT, Regular, 5, 16777228),
("TimesNewRomanPS-ItalicMT", Italic, 5, 13),
("TimesNewRomanPS-BoldMT", Bold, 9, 16777226),
("TimesNewRomanPS-BoldItalicMT", "Bold Italic", 9, 11)
)

etc.

I have temporarily given up 1.2 to go back to 1.1 which works fine and opens any .doc files without problem.

I use Tiger 10.4.11 on PowerMac G5 Dual 2.5.

Any workarounds to try ?

[dshan]

Have you tried validating the fonts in question with Font Book? From the messages it looks like there may be problems with at least Arial and Times New Roman. Are you using any sort of 3rd party font management software like mwiseman was?

The messages seem to indicate the failure is happening in the new-in-1.2 Open Office MS Word format conversion routines rather than NWP itself. If that's true then I would expect the same or similar problems would occur if you tried to open the same Word document using Open Office itself. If your fonts check out okay you could try downloading Open Office 2.4 for PPC (that's the version NWP 1.2 uses, OOo 3.x isn't available for PPC Macs unfortunately) from www.openoffice.org, and then try opening the Word document with OOo Writer. It might give you more information about what the underlying problem is.

[ntx]

Hi dshan, thanks for your quick advice !

I downloaded Open Office 3.01 for PowerPC and tried to open some .doc files with it. It failed also, but this time with a curious message saying "/Volumes/...(file path)../filename.doc does not exist." Suspecting OpenOffice could not understand the file path correctly, I tried to open .doc files sitting on various locations - to find that Open Office (and NWP 1.2 .doc filter) cannot handle a path name containing non-alphabet or accented characters (Japanese, in my case) !

So I could successfully open so far all the .doc files that previously could not be opened, by changing their name and/or location - but it's a pain, as many people send me .doc files with Japanese, Chinese or French name. Futher, it may be crucial to users who have adopted his/her user name or HDD name which requires non-alphabet character. I hope this issue will be fixed soon.

BTW, I don't use any 3rd party font management utility. I checked all the installed fonts using Font Book anyway and test passed. I am not 100% sure, but I think neither "Times New Roman MT" nor "Arial MS" (rather than standard Times New Roman/Arial) is installed on my system - am I wrong ?

[Kino]

Thousand Bravos for your discovering the crucial bug!

I am not 100% sure, but I think neither "Times New Roman MT" nor "Arial MS" (rather than standard Times New Roman/Arial) is installed on my system - am I wrong ?

ArialMT, TimesNewRomanPSMT and other names you saw in Console.app are PostScript names of the standard Arial and Times New Roman font families. So you have them. Font Book.app's "Preview:Show Font Inf" (command-i) lets you know this kind of information.

That said. I have to confess that I don't know what those log messages mean. Presumably OO is panicked because it cannot find those basic fonts — basic for MS world — due to disorder caused by non-ASCII character(s).

[CrisB]

I use 10.4.11 on an obsolete G4 twin 867 and I've been having the very same problem ever since I updated to NWP 1.2 many months ago, actually 2008/11/06 - last year!

Nisus know all about the problem, and they have told me that my problem files open fine for them. It's indeed connected with the new MS-Word decoder they're using which is, in their words, "massive, complex, and not produced by us."

So, back in February, I eventually suggested that :

Yes, I understand that the file translator is "massive, complex, and not produced by" Nisus. So how does that change the problem? Why do you suggest that extra information on why the OPEN failed would NOT be valuable to help solve the problem?

Months ago, I recall that you said the faulty files open fine on your machines, which suggests that it's something particular to NWP 1.2 in my hardware/software configuration. So it may be a file translator problem, or it could be something else. Collecting extra information at the source of the problem cannot do any harm at all, and actually helps most all of the time to solve complex problems... So please allow me to repeat my now slightly amended question.

- Why doesn't Nisus collect the information which could help them to fix this highly annoying error, which just wastes so much of my time? Nisus already know exactly what to do to find and help solve this problem - give your users a NWP version that has an option to send full debug info along with any .doc file that won't open.

I get several files a week which don't open. So if I'm not in a rush, I now send such files to Nisus to remind them that this problem continues to cause an enormous amount of frustration for many loyal customers.

If enough users complain about the serious lack of progress on this issue, then perhaps Nisus might be persuaded to allow us to help resolve this long outstanding problem! I'm not talking about a new NWP release or any new facilities - simply for Nisus issue a bug fix version (1.2.1?) which could collect enough information about an OPEN failure to enable them to resolve the problem.

Warm regards,
Cris
Tuesday, 2009/06/02

ps: My work-around is to open the file in Pages. Copy the text. Paste it into a New Nisus Document. This gives me the text, but without formatting. So then I try and work out which styles were used, and then reformat the Nisus document. A royal pain in the ass!

It doesn't seem to be much if anything to do with the fonts used. I can't open documents returned to me from unsophisticated users, who just use the fonts already there...

[dshan]

ps: My work-around is to open the file in Pages. Copy the text. Paste it into a New Nisus Document. This gives me the text, but without formatting. So then I try and work out which styles were used, and then reformat the Nisus document. A royal pain in the ass!

It doesn't seem to be much if anything to do with the fonts used. I can't open documents returned to me from unsophisticated users, who just use the fonts already there...

Why don't you open them in Pages and then save/export them as RTF files to open in Nisus? That way you won't lose the formatting.

Also, did you read what ntx has found and posted above? It sounds like a common cause of the Word conversion failures is the OOo translator not working with non-ASCII filenames/paths. Could that be the situation your case? If so the workaround is relatively simple - rename/move any Word documents containing non-ASCII characters in their filenames or filepaths before attempting to open them with NWP. This would also likely explain why Nisus have been unable to reproduce the problem when such files are forwarded to them, I'll bet they only use ASCII character filenames and paths.

[dshan]

Hi dshan, thanks for your quick advice !

I downloaded Open Office 3.01 for PowerPC and tried to open some .doc files with it. It failed also, but this time with a curious message saying "/Volumes/...(file path)../filename.doc does not exist." Suspecting OpenOffice could not understand the file path correctly, I tried to open .doc files sitting on various locations - to find that Open Office (and NWP 1.2 .doc filter) cannot handle a path name containing non-alphabet or accented characters (Japanese, in my case) !

So I could successfully open so far all the .doc files that previously could not be opened, by changing their name and/or location - but it's a pain, as many people send me .doc files with Japanese, Chinese or French name. Futher, it may be crucial to users who have adopted his/her user name or HDD name which requires non-alphabet character. I hope this issue will be fixed soon.

That's very interesting, it's the first time I've seen any explanation or workaround for the translation problems some people seem to be encountering. Unfortunately I cannot reproduce the problem on my MacBook Pro using NWP 1.2 and Mac OS X 10.5.7. I've tried Word documents with spaces, accented Latin characters, Greek characters and Katakana characters in their names and they all open and convert just fine with NWP 1.2.

There are possible explanations for the different behaviour we're seeing I can think of:
1. Maybe it's only a problem with the PPC Mac version of the OOo translator. Unfortunately I no longer have a PPC Mac so I can't test this.
2. Maybe it's only a problem under Mac OS X 10.4.x (perhaps only PPC machines running 10.4.x even). It's interesting that most/all of the people having this problem seem to be using PPC and 10.4.x. Unfortunately I no longer have any machine running 10.4 so I can't test this either.
2. Maybe it depends on what language you're using in Mac OS X and/or NWP (I use Australian English for both). What language do you use?

[CrisB]

Thanks dshan for your helpful replies.

Why don't you open them in Pages and then save/export them as RTF files to open in Nisus? That way you won't lose the formatting.

I've just found out that a .doc saved in Pages still doesn't OPEN. My latest copy of Pages (now 4.0.2) only gives me the two options: to SAVE a file as an Word doc, or as a iWork 08 document. An .rtf option is not available in SAVE AS. The resultant document when SAVEd AS a Word .doc still fails to open in NWP 1.2.

I hadn't noticed the rather clumsy EXPORT with an RFT option before, and my NWP 1.2 does open such EXPORTed .rtf documents. How much of the formatting it keeps nees investigating but, on a cursory look, the indentation is definitely different, and the .rtf version is incorrect, whereas when saved as .pages, the indentation seems fine ...

did you read what ntx has found and posted above? It sounds like a common cause of the Word conversion failures is the OOo translator not working with non-ASCII filenames/paths.

The file name seems to be a worthwhile suggestion, although I would imagine that I checked this out when the problem first appeared so long ago... So I have just renamed one of my original problem documents to invoicerenamed.doc and it still fails to open in NWP 1.2.

Unless there are two problems with exactly the same outward symptoms, then this OPEN failure of the invoicerenamed.doc, see attached file, suggests that its original unusual name (with the @ character) is NOT the cause of the failure. Although ntx's post does say that his failures have different symptoms. I guess I should confirm that I also have documents which opened fine in NWP 1.1, and now won't open in NWP 1.2. And all documents emailed to me go into the same folder, which implies that the path name may be irrelevant since some open and some don't.

As suggested to Nisus months ago, collection of more information about the reasons for the OPEN failure would help narrow down the cause of the problem. My long experience in software, including a stint as a software developer, suggests this would probably be the logical next step.

The continued reluctance (refusal?) of Nisus to take this simple step just wastes so much time dealing with such documents. It also wastes dshan's time and energy in such matters as responding to my post, suggesting that I should read the post by ntx before I reply, and pursuing the possible cause of file names with unusual characters.

I'd be very interested to know if this OPEN failure affects any users running Leopard, or with Intel machines. Is it only Tiger users on ppc machines who are suffering? What's your configuration dshan, and are you actually experiencing this failure yourself?

This would also likely explain why Nisus have been unable to reproduce the problem when such files are forwarded to them, I'll bet they only use ASCII character filenames and paths.

Lastly, I would doubt that Nisus would rename files sent to them before checking whether or not they fail to open...

Over six months later - the problem was first reported last year - Nisus still don't appear to realize that some users would really appreciate this problem being solved urgently. I suggest we all click to send such OPEN failures to Nisus, in the hope that this would motivate them to do something about this rather frustrating and time-wasting problem...

dshan, I look forward to your response.
Warm regards, Cris
Wednesday, 2009/06/03

ps. Thanks for the suggestion to zip the files, Hamid. Thursday, 2009/06/04

[Hamid]

[...]

ps. I've just tried to add this "Invoicerenamed.doc" file to this post, but the add failed with the admonition (in red):

The extension doc is not allowed.

Zip the doc file. The maximum zipped file size allowed is 100KB.

[ntx]

There are possible explanations for the different behaviour we're seeing I can think of:
1. Maybe it's only a problem with the PPC Mac version of the OOo translator. Unfortunately I no longer have a PPC Mac so I can't test this.
2. Maybe it's only a problem under Mac OS X 10.4.x (perhaps only PPC machines running 10.4.x even). It's interesting that most/all of the people having this problem seem to be using PPC and 10.4.x. Unfortunately I no longer have any machine running 10.4 so I can't test this either.
2. Maybe it depends on what language you're using in Mac OS X and/or NWP (I use Australian English for both). What language do you use?

From my tests so far, I can say that possibilities 1 and 2 are unlikely. I have just observed the same glich on my MacBook running 10.5.6 + NWP 1.2/OOO 3.1.

My language preference order is set to Japanese, English, French in system preference app. So when I launched NWP on my system, it is in standard "English" mode.

I' m not sure but there must be other factors, as, a .doc created by NWP can be opened without any problem - for instance.

xx

I could open CrisB's invoices, but with an accented character inserted in file name or name of the folder containing the file, it becomes unopenable.

[ntx]

ArialMT, TimesNewRomanPSMT and other names you saw in Console.app are PostScript names of the standard Arial and Times New Roman font families. So you have them. Font Book.app's "Preview:Show Font Inf" (command-i) lets you know this kind of information.

Well understood. Thanks kino

[dshan]

I can open both of Cris's invoices with no problems and putting one or more accented characters in their filenames makes no difference.

Cris can't open either invoice period, ntx can open them both as long as there's no accented characters in the document name, and I can open them with or without accented characters in their names.

ntx experiences conversion failures on both PPC using 10.4.11 and Intel using 10.5.6. Cris is using PPC 10.4.11 and I'm using Intel 10.5.7.

How curious this is. The little grey cells, they become fatigued trying to make sense of it.

[CrisB]

If you can open those posted invoices, ntx, that suggests you are experiencing a different file opening problem. NWP 1.2 fails to open both those invoice documents on my ppc/Tiger machine, which is why I posted them. Like you, my console log says:

"Nisus Writer Pro[193] * failed OOo conversion: Exception was thrown when loading the document."

Yet my NWP has no problem opening file names with the @ character, for example. I've just created such a file in NWP, saved it as "test on @ and ƒ in name.doc" and it opens fine in NWP. And I designate all my folders with the character ƒ, which is probably a funny character as far as ASCII is concerned...

My long-standing problem is that NWP 1.2 won't open many .doc files created on other machines, which probably means Windows, even when I have previously opened them with NWP 1.1. Whereas ntx has a problem opening files with unusual characters in the file name or path, and dshan is experiencing no opening problems at all. I'm now wondering how many people have the .doc opening problem and how many have the ntx file name/path problem?

So we seem to be confounding two similar but different problems. Perhaps it might be valuable to split the threads to discuss each one separately? What's your take on this point, Martin?

Warm regards,
Cris
Thursday, 2009/06/04

[Hamid]

I had no problem opening both documents. I also changed their file names to Arabic characters, and they opened just fine.
I am running OS X 10.5.7 on iMac Intel Core 2 Duo.

[ntx]

Yet my NWP has no problem opening file names with the @ character, for example. I've just created such a file in NWP, saved it as "test on @ and ƒ in name.doc" and it opens fine in NWP. And I designate all my folders with the character ƒ, which is probably a funny character as far as ASCII is concerned...

Can you try the same thing with a file created by other applications ? My NWP 1.2 can open ANY file created by NWP. Situations here are summarized :

NWP 1.2 can open .doc files as far as :
1. The file was created by NWP, or
2. File path dos not contain exotic characters (incl. ƒ, é, and chinese/japanese characters, but excl space or @)

and "loading additional filters..." dialog pops up only when the problem occurs.