Issue 98206 - exporting to raster graphics (PNG/JPEG) gives 0 byte file
Summary: exporting to raster graphics (PNG/JPEG) gives 0 byte file
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: DEV300m38
Hardware: Unknown All
: P2 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords: oooqa, regression
: 98310 (view as issue list)
Depends on:
Blocks: 95768
  Show dependency tree
 
Reported: 2009-01-18 19:36 UTC by aziem
Modified: 2009-02-20 13:53 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description aziem 2009-01-18 19:36:33 UTC 
1. Create a circle in OOo Draw
2. Click - File - Export
3. Choose PNG or JPEG

Result:
File size is 0 bytes

System:
Linux
DEV300m_39 (pre 3.1.0)

Comment:
Exporting to HTML or PDF seems fine.
Comment 1 Regina Henschel 2009-01-18 20:29:03 UTC 
Confirm for OOoDEV300m39 on WinXP. It has been OK in m37 here.
Comment 2 wolframgarten 2009-01-19 07:47:28 UTC 
Reproducible. Reassigned.
Comment 3 wolframgarten 2009-01-21 11:00:15 UTC 
*** Issue 98310 has been marked as a duplicate of this issue. ***
Comment 4 sven.jacobi 2009-01-26 19:34:24 UTC 
sj->mav: SfxMedium::Commit() is called twice, the first time it is called from
svx/source/xoutdev/_xoutbmp.cxx.

In the first time the Transfer_Impl in SfxMedium::Commit() is copying and then
killing the temporary stream. So the second commit call from
SfxObjectShell::SaveTo_Impl makes the Transfer_Impl() working with a killed
temporary stream having a size 0.

If I am skipping the secondary call, everything works as expected.
As you are having the most experience with sfx, I am glad hand over this issue
to you.
Comment 5 clippka 2009-01-30 08:56:08 UTC 
.
Comment 6 mikhail.voytenko 2009-02-06 10:58:48 UTC 
It is not the second commit to the same medium. It is a commit of the different
medium.

The problem here is that the filter writes directly to the document instead of
writing to the SfxMedium provided in ConvertTo() call. As result the framework
implementation commits at the end the medium that was never written.

It worked before because the medium did not try to open the output stream, and
thus has nothing to commit. Now it has to open the stream, to handle the file
locking centrally.

I believed till now that we have a kind of rule, nobody writes directly to the
target document file except framework. If it is still true then this is a
problem of the export filter, the filter should get stream from the provided
medium and export there.
Comment 7 mikhail.voytenko 2009-02-06 13:11:32 UTC 
I have changed the sfx2 behavior for 3.1, since it is not only one filter. At
least two filters in sd ( grf and cgm ) have the problem. Some other filters
might have the problem as well.

It looks to be too risky for me to change all the filters for 3.1 now. So I have
submitted a successor issue for this.
Comment 8 mikhail.voytenko 2009-02-06 13:20:04 UTC 
issue 98972 is the successor issue
Comment 9 mikhail.voytenko 2009-02-12 10:29:38 UTC 
mav->wg: Please verify the issue.
Comment 10 wolframgarten 2009-02-13 10:03:24 UTC 
Checked manually and autotests on linux/windows have been run- ok. Verified.
Comment 11 wolframgarten 2009-02-20 13:53:46 UTC 
Tested in OOO310_m2. Closed.