Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | WW8: change in .doc format in OOo 3.1 break Blackberry viewer | ||
---|---|---|---|
Product: | Writer | Reporter: | jbintz <jeb03> |
Component: | save-export | Assignee: | AOO issues mailing list <issues> |
Status: | CONFIRMED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues |
Version: | OOO310m11 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Attachments: |
Description
jbintz
2009-07-14 16:01:20 UTC
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". |