The problem is still on 1.1 RC5 as this report was not handled since 
June. This is a serious bug in my opinion because when you write a big 
document with many images it is better to insert images by link until 
the document is near finished. This way, your numerous versions 
contain only text. Only when you are near completion, break all the 
links to include your images.
PNG does not compress as JPG, especially if the writer has carefully 
compressed its images. I tested with an empty Writer doc linked to a 
115Ko Jpg file : initial Writer doc size 6ko. After breaking the link, 
document size is 1.16Mo.

can confirm this with OOo 1.1.0(en) on Win98.

Reassigned to Hasan.

HI->SJ: MIB told me you have an issue where the png graphics will not
compress by saving documents. 
Please comment the rules about the handling of the graphics by saving
the documents.

Hi,

I don't know if my thoughts will help, but I thought I would make a 
suggestion.

When I reported the problem I thought embedding an image left the 
image in its native format in the zipped file. I just did quite a 
bit of testing and realise this is not the case.

In this testing I also found that embedding an image and braking a 
linked image resulted in different formats being stored in the 
zipped file.

IMHO I think at a minimum this should be consistent.

Embedding
BMP goes to PNG
JPG stays as JPG
WMF stays as WMF
GIF stays as GIF

I can understand why BMP goes to PNG for better compression. However 
one of the things I thought was excellent about OpenOffice.org is 
the picture was stored in the zip file in its native format. That 
means the original picture could always be recovered. I have since 
learned this is not true for embedding BMP files which I feel is a 
pity.

For linked images where the link is broken I found the following

BMP, JPG, GIF went to PNG
WMF went to SVM

IMHO this is inconsistent and both methods should result in the same 
outcome.

Whilst I personally would prefer the images stored in the zip file 
to be native format, that is only my preference. I mostly use jpg 
and png files. For those using bmp or other file types that compress 
well, then compression would be desirable.

Thanks again for looking into this issue. Hopefully some of my 
thoughts may be of use.

Kelvin

SJ->OS: I send you this Issue as you are the master of our User Interface
project and you probably know where the graphic links are broken. In general if
storing a xml document the native graphic is retrieved from the Graphic object
which is providing a SetLink and GetLink method. (vcl/graph.hxx)

If breaking the graphic links into empedded graphic objects the SetLink method
seems not to be called.
So it comes that every jpg is lost. Not setting the graphic link also leads to
problems when storing eps graphics, then only the preview graphic will be stored
instead of the original eps file.
Please call me if you have any further questions.

Sven

In OOo 1.1 the break is initiated in so3\source\dialog\linkgdlg2.cxx in
IMPL_LINK( SvBaseLinksDialog, BreakLinkClickHdl, PushButton *, pPushButton )

There the virtual method SvBaseLink::Closed() is called.

SJ->THB: It seems that this Issue can best be fixed in your graphic manager.

Yes, think so, too. Will have a look, this should indeed better work.

retargeted due to lack of resources

.

I take over this issue

retargeting

retarget

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

as per the duplicate issue I raised above, files become totally unusable when
many JPG links are broken and the file size explodes to over 200MB. This is a
result of the JPG -> PNG conversion. Competitor products store in native
format...and so since the file can be handled natively in the UI as a link, I'm
not so sure it's really a ui problem, rather a storage problem? When the link is
broken, the native jpg or whatever file should then live in the XML file... but
I haven't read the code and I really don't consider myself competent enough to
do so and actually understand what is going on...
...please consider a newer milestone. If I can be of any assistance in doing any
footwork for this issue, please let me know.

Bug confirmed 4 Nov 2008.

I just found that when I save an image into a file there is two ways to do this,
although both appear to do essentially the same task, yet I get two very
different results. To test this I am simply starting with 2 new odt files,
embedding the image (a jpeg file of ~30kb size), and saving.

1) Insert->Picture->From File... and un-check 'Link', save file and file size is
41kb.

2) Insert->Picture->From File... and leave 'Link' checked, then use: Edit->Link
to break the link, then save file and file size is 352kb.

Same image file, obviously the first method yields the correct result.

Issue from 2003 is still existing and annoying in OOo 3.1 June 2009! (I tested
with Ubuntu 9.04 and with the Windows Version)

Can someone in charge please change the category of this issue,  since it is not
only a minor "ui" problem, but a real performance problem! Please mark this
issue to be existing for OOo 3.x (because #15508 marks this issue OOo 1.1)

It is extremely annoying: A typical larger presentation (about 30-slides) or
text with about 50 drag&dropped 200kB (screen optimized!) jpegs would normally
have about 10MB.
With the OOo issue the file size would grow to >100MB for a presentation, which
extremely slows down the performance (especially load+save).

Sure I know the workaround adding pics with "Insert->Picture->From File...", but
it is impractical. A typical windows/desktop user is used to drag&drop images
form the filemanager or image preview program! (Me too, although I'm a linux/kde
user)

I forgot to send a link: Maybe the issue was already "forgotten", because in the
OOo forum they were discussing about this problem again:
http://www.oooforum.org/forum/viewtopic.phtml?t=67720

Hi rainman01,

thanks for your comment - I also consider it quite annoying.
However, the issue is still alive, so I think no action needs to be taken by the
developers.
The version field only means that this is the version this problem _first_
occurred. The version number is not updated if new versions come out, because it
is interesting to know, since which versions the issue exists.

The issue is targeted to "OOo 3.x", that's at least better than "OOo later".  :-)
The only thing you can do is to vote for the issue, so that it gets higher
priority. A vote sum of 24 is already quite good, so there may be a good chance
that this will be solved rather soon - maybe in OOo 3.2?

Best regards, phil

Somehow I think that problem with converting to PNG would not be an issue IF
size of output file is the same as input file (With Quality retained)

Eather OOo needs to import the same pictures document were linked to
or OOo should take care that pictures inside have same size AND quality as
starting one.

I suggest rising priority on this issue, due to real-worl problems that arise from 
making documents way to big with -> PNG conversion currently implemented.

Eather PNG conversion should be done in a proper way or disabled.

May also be of interest (TIF not converted to PNG, but probably should be...):
Issue 10776 - Inefficient saving of graphics file

I have created extension Images Embedder which breaks image links and embeds the image 
files without any conversion.
http://extensions.services.openoffice.org/project/ImagesEmbedder

It is a rather simple code in Basic using the API. I separated the cases for Writer, 
Calc, and Draw/Impress.

This issue could be resolved with a similar solution, I wish it will be done in a 
next release of OpenOffice.org.

BTW, apparently this is fixed in LibreOffice 3.3.0 Beta 2.

Up!
Too bad this issue has been fixed in LibO.
The bmarcelly's OXT could be embedded in AOO 4.1.x.

Just checked with current AOO version, in Draw/Impress, Calc and writer. Draw/Impress and Calc keep the original jpeg when loading a linked jpeg and breaking the link, then saving, thus all works as intended, no error here.

Writer indeed saves a png with a bigger size, this seems to be an error. This may indicate an error with breaking links with the writer graphic object.

Tried with a linked jpeg created in Draw, copied to Writer, break link, save -> stays the original jpeg. This hardens the suggestion that writer's graphic object/frame does not behave well when breaking links...

Getting some stuff with debug...

Writer is using the deep-buried GraphicObject/Graphic stuff. At write time when I compare (a) writer graphic inserted as link, then unlinked and (2) writer graphic inserted without link, I have when looking at the following code:

const GraphicObject aGrfObject(AsciiObjectID);
Graphic aGraphic((Graphic&)aGrfObject.GetGraphic());
const GfxLink aGfxLink(aGraphic.GetLink());

in (a) an empty GfxLink of type GFX_LINK_TYPE_NONE, no swap, no buffer.
in (b) one of type GFX_LINK_TYPE_NATIVE_JPG with a link to a local temp file containing the original

I would expect that breaking the link via the dialog would create the same result, this seems to be the problem...

Found the basic mechanism, but the SwapIn stuff (using several reschedules and calls over 40 stack levels) is too dangerous to touch (need to rework that in the not too far future). Luckily there are other ways to fix the two cases where breaking a link does not work:
(1) new writer, insert jpeg linked graphic, break link, save -> png in ODF
(2) new writer, insert jpeg link, save, reload, break link, save -> png in ODF
For both I added code to let the original data survive AFAP; the original data and data type is deep in the Graphic impl (ImpGraphic) in a sub-class called GfxLink (which has nothing to do with linked graphics but e.g. handles the temp swap file and type).
Grepping, changing importance (37 votes), preparing commit...

Adapting product and component, too

"alg" committed SVN revision 1566765 into trunk:
i15508 keep trhe original file and format AFAP when breaking links to graphic...

Okay, done.

taking over for verification

Using recent Windows build bot installation set (rev. 1571677) I got the following:
- linked TIFF, JPEG, GIF and SVG images are stored in their original format in the ODF text document after breaking the links.
- linked BMP image are stored as PNG after breaking the link.

@Armin: I am not sure, if it make sense to keep the conversion from BMP to PNG on link breaking.

It's not really a conversion, but the internal format is a BitmapEx, thus when no more info for the original import is there, it can only be saved in the most lossless format. When trying to keep the original files in the hardly to overiew code involved surely BMP gets handled differently since it's the original format used by AOO in the past; it also depends where it came from, when it got copy/pasted from another graphic app it probably never arrived with the original data, but as bitmap data via clipboard. Thus, I need to know how exactly you have inserted the BMP to AOO.

Checked the mechanism for BMP, indeed it does not work. Also found the reason: There is no define for BMP in enum GfxLinkType in vcl at all, so it is not set and saved at graphic import filter.
Something like GFX_LINK_TYPE_NATIVE_BMP in association to e.g. GFX_LINK_TYPE_NATIVE_GIF would be needed. I forced per debugger in GraphicFilter::ImportGraphic line 1766 to mark a bitmap as GFX_LINK_TYPE_NATIVE_GIF and indeed in the ODT the original BMP is saved in 'Pictures' as 10000000000004890000037292B065D6.gif. Of course this needs to be a *.bmp, but it shows the problem; the missing define and usage of a 'GFX_LINK_TYPE_NATIVE_BMP'...

BTW: That little experiment works even at load time since AOO does a filter detection, even when the data is named '10000000000004890000037292B065D6.gif' it gets loaded as BMP. Still, it's a hack. After a load - modify - save cycle it will revert to a PNG again.
The problem is that keeping BMP as original data was never intended (why ever) as can be seen by the missing GFX_LINK_TYPE_NATIVE_BMP type. It would have to be added and diverse places using these defines would have to be adapted, not sure how risky that would be...

I have checked GFX_LINK_TYPE_* usage and it seems not too dangerous and it will potentially improve other exports as well in the sense that these may use original *.bmp files, too. Trying the change...

Works as expected, I did many checks.

- for the main case (BMP graphic in AOO app, link and break or no link, save) the original is written to the ODF as expected -> enhancement

- Writer export graphic - checked, works the orig BMP is written, current version writes PNG -> enhancement

- Reload Writer when swapped - checked, works, orig BMP is reloaded instead of PNG  -> slight enhancement (potentially smaller, thus faster)

- Escher GraphicExport: Tried to use BlibType DIB, does not work, back to previous version which embeds a PNG. May work with direct DIB data, has potential to explore that -> no change

- RTF export: tried BLIPType OOO_STRING_SVTOOLS_RTF_WBITMAP, does not work, back to previous version which embeds a PNG. May work with direct DIB data, has potential to explore that -> no change

- OOX DrawingML::WriteImage not used yet, but may profit. Added example code, has potential for enhancement

- Gallery insert graphic: Can keep orig BMP, but already does. Found no calls in debugger to GalleryTheme::InsertGraphic, but is potentially better -> enhancement

- GraphicDescriptor::_getPropertyValues: support of BMP possible -> enhancement

- SvXMLGraphicHelper::ImplInsertGraphicURL: support of BMP possible -> enhancement

- XOutBitmap::WriteGraphic: support of BMP possible -> enhancement

All in all some enhancements and worth a try. The question is if this should go to the beta...

Asking for release blocker to get it to 4.1.0 beta. Need to correct/extend stuff which is already in the beta.

Preparing commit to trunk, committing.

"alg" committed SVN revision 1572569 into trunk:
i15508 Added support for BMP file type

grant showstopper flag

Applying to AOO410, building, checking...

Checked all combinations with BMP and linked and non-linked content save-load cycles, works as expected. Preparing commit...

"alg" committed SVN revision 1572717 into branches/AOO410:
i15508 Added support for BMP file type

Okay, done.

Verified on branch AOO410 (Rev. 1583666) and trunk (Rev.1583671).