Lacking of Blackberry here, could you please attach three documents here:
- a source odt
- a doc exported from the source odt which will work on Blackberry
- a doc exported from the source odt which will NOT work on Blackberry
so that we can see where the difference may be.
Thanks for supporting us!

Created attachment 63564 [details]
simple 301 odt file

Created attachment 63565 [details]
simple odt file saved as 301 doc format views properly on Blackberry

Created attachment 63566 [details]
simple odt file created in 31 (different internally than the same text in 301)

Created attachment 63567 [details]
odt file in 31 saved as doc. This does not view properly in Blackberry

MRU->HBRINKM: there is a difference in export to WW8 format from 3.01 to 3.1.
The doc written by 3.0.1 is 8 kB and the doc written by 3.1 is 9 kB in size
(both having the same simple content). 
Problem now, that the new format cannot be opened by Blackberry doc viewer.
Maybe this is due to implementation from issue 97267 ("WW8: export custom fields")?

Are there settings in Writer 3.1 or options during installation that would
prevent "export custom fields"? (issue 97267) and perhaps provide a workaround
for the time being?

 

The target milestone for this is OOo 3.2. The 3.2 qa issue list includes
enhancements and features, but no defects. Will the fix for this be in 3.2? or
maybe 3.1.1? 

I tested the BB viewer with the new 3.1.1 release and the 3.2 dev build. Still
no solution. How would I find out whether this issue is being addressed in 3.2?

Branch off date for 3.2 is 21 September 2009 => Will not make it through QA and release engineering in 
time.

Moved target.

Based on the thread, it seems my problem may be tied up with WW8 (97267). I
don't know and can't test if that is the case.

I don't know if these issues are mutually exclusive or how much anyone has been
able to look at this. 

Is there any possibility that some setting, option or additional "save as"
format can be implemented in 3.2 that would be able to export .doc as 3.0.1 did? 

3.2 looks to be coming from the 3.0 codeline. I was hoping its similarity to
3.0.1 would help matters.

Are we certain it will be addressed in 3.3?

How can I see if this is being dealt with in the 3.3 development cycle?

I can't promise the issue will be handled for 3.3. There is always something urgent in the line (customers) 
that ruins the planning. But, you can raise importance of an issue by voting for it. Maybe you can help with 
programming skills or poke someone you know who might help. 

The system will not let me assign more than 2 votes. Originally the target 
milestone was 3.2, but missed the code freeze. Now it is 3.3. I don't see any 
dependencies and can't tell how to track whether it is being worked on or not.

The current dev builds for 3.3 crash when trying to export .doc so it looks as 
though something is being done regarding export formats, but there is no 
description of what. The issues listed with the dev release notes don't include 
this issue (103545) and I can't tell which issues to follow as the dev process 
goes forward. Iss 97267 isn't referenced either so I don't know what workspace 
is supposed to address "exporting custom fields" that may or may not have 
caused my problem.

I have leaned on the Blackberry folks hoping for a change in their viewer, but 
they have officially decided it is an openoffice problem. And the file specs 
appear to be a moving target.

I have moved my entire group (500) to openoffice and some of our sr admins are 
significant emergency responders who rely on Blackberries to view department 
documents in the field and after hours.

Right now they cannot view program attachments sent by their subordinate staff 
and I get asked daily when this will be resolved.  

I can have a bunch of people join  so they can vote on this issue, but that's 
like stuffing the ballot box. 

Do you know if 97267 and 103545 are related? Do you know what is being done 
regarding export formatting? 

I'm in the dark here.  
  

I do not know what could cause this problem either. Can you do the following:

- Reopen oo-31-d.doc in Word
- Save as oo-31-d-word.doc from word.
- Test if oo-31-d-word.doc can be read by the Blackberry reader.
- If so, attach oo-31-d-word.doc to this issue.

By comparing oo-31-d.doc and oo-31-d-word.doc we should be able to see what word does different.

Created attachment 65926 [details]
file re-saved by word97

As suggested, Reopened oo-31-d.doc in Word

Saved as oo-31-d-word.doc from word.

ent both to my blackberry. 
oo-31-d.doc would not open

oo-31-d-word.doc did view properly on the blackberry

In following 3.x dev, I download and try out the the snapshot builds to get an 
idea if the issue is being addressed. I have noted that in 3.1.1 and prior 
versions when options set .doc as the default format for text documents, the 
save is straight forward. In 3.x m64, save as .doc, whether done in the dialog 
box or set as default in options, initiated an expoer process indicated by a 
status bar being written across the bottom of the app window (in a manner 
similar to export to pdf. 

The file isn't properly written . OO crashes and the file fragments are picked 
up by a salvage process, reloading OOo and trying to rebuilde the file as odt.

 

In following 3.x dev, I download and try out the the snapshot builds to get an 
idea if the issue is being addressed. I have noted that in 3.1.1 and prior 
versions when options set .doc as the default format for text documents, the 
save is straight forward. In 3.x m64, save as .doc, whether done in the dialog 
box or set as default in options, initiated an expoer process indicated by a 
status bar being written across the bottom of the app window (in a manner 
similar to export to pdf. 

The file isn't properly written . OO crashes and the file fragments are picked 
up by a salvage process, reloading OOo and trying to rebuilde the file as odt.

 

We are using the Novell-Edition of OO together with Blackberry and have the same
problem. We opened a request at Novell. Here is the result: 

-----------------------------------------------------------------------------
I wanted to give you another update with respect to this issue.  

The only difference comes from the fact that OOo is handling a some features of
the .doc file format introduced by Word 2002 (fcAtrdExtra,lcbAtrdExtra,
fcAtrdExtra and lcbHplxsdr fields in the FIB structure).

The content of these fields are set to 0 in the case of this document because
they are not used, but the size of the FIB is then much longer(fcMin indicating
the start of the text data is corretly set). This is not an OpenOffice.org bug,
but rather a Blackberry builtin viewer. We, Novell, will report the issue to the
RIM Engineers so a fix for the viewer can be provided.
-----------------------------------------------------------------------------

*** Issue 114904 has been marked as a duplicate of this issue. ***

*** Issue 114975 has been marked as a duplicate of this issue. ***

*** Issue 116868 has been marked as a duplicate of this issue. ***

set target 3.x since not relevant for 3.4 release.

Reset assigne to the default "issues@openoffice.apache.org".