Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Break link converts bmp, jpg, png and gif to png format|
|Component:||code||Assignee:||Armin Le Grand <Armin.Le.Grand>|
|Status:||CLOSED FIXED||QA Contact:|
|Priority:||P3||CC:||ace_dent, Armin.Le.Grand, guido.pinkernell, ingo.goeppert, issues, jsc, kamataki, lohmaier, marcelly.bernard, masaya.k, oooforum, rbenech, steve.yin.aoo, www.openoffice.org|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description kelvine 2003-06-11 14:32:14 UTC
Hi, I'm submitting this as a bug because it may be an oversight. It however could just as easily be by design and then this should be and enhancement request. When invoking the Break Link in Writer Select Edit -> Links -> Break Link The file stored always seems to be a PNG file. The result is that a 1.2MB jpg image is expanded to 2.5MB causing significant bloat. From tests I have done all images inserted as links into Writer with the format of bmp, jpg, png or gif are converted to png format. If this is an oversight then storing the image based on the original file format would appear appropriate. If this is by design, then perhaps changing the design so that image is stored in its original format would reduce file bloat. Hope this helps. Kelvin
Comment 1 bmarcelly 2003-10-09 19:21:17 UTC
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.
Comment 2 guido.pinkernell 2003-10-23 22:40:51 UTC
can confirm this with OOo 1.1.0(en) on Win98.
Comment 3 stefan.baltzer 2003-10-27 11:31:12 UTC
Reassigned to Hasan.
Comment 4 h.ilter 2003-11-03 10:44:23 UTC
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.
Comment 5 kelvine 2003-11-04 08:23:31 UTC
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
Comment 6 sven.jacobi 2004-01-29 15:03:15 UTC
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
Comment 7 Oliver Specht 2004-01-30 07:05:25 UTC
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.
Comment 8 sven.jacobi 2004-01-30 10:43:43 UTC
SJ->THB: It seems that this Issue can best be fixed in your graphic manager.
Comment 9 thb 2004-01-30 16:05:21 UTC
Yes, think so, too. Will have a look, this should indeed better work.
Comment 10 ooo 2004-06-21 10:03:44 UTC
retargeted due to lack of resources
Comment 11 lohmaier 2004-11-18 20:43:01 UTC
Comment 12 clippka 2006-04-04 16:23:31 UTC
I take over this issue
Comment 13 clippka 2006-05-29 15:15:33 UTC
Comment 14 clippka 2007-09-12 16:58:05 UTC
Comment 15 ace_dent 2007-11-02 10:21:58 UTC
*** Issue 83216 has been marked as a duplicate of this issue. ***
Comment 16 swingkyd 2007-11-02 15:36:38 UTC
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.
Comment 17 bobban 2008-11-04 13:14:39 UTC
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.
Comment 18 rainman01 2009-06-30 09:15:29 UTC
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)
Comment 19 rainman01 2009-06-30 09:18:44 UTC
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
Comment 20 phil_ 2009-06-30 11:07:16 UTC
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
Comment 21 minikola 2009-08-14 11:34:05 UTC
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.
Comment 22 ace_dent 2009-10-06 14:54:21 UTC
May also be of interest (TIF not converted to PNG, but probably should be...): Issue 10776 - Inefficient saving of graphics file
Comment 23 bmarcelly 2009-10-29 14:37:40 UTC
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.
Comment 24 kozmoz 2010-10-16 14:23:09 UTC
BTW, apparently this is fixed in LibreOffice 3.3.0 Beta 2.
Comment 25 oooforum (fr) 2014-02-10 13:38:43 UTC
Up! Too bad this issue has been fixed in LibO. The bmarcelly's OXT could be embedded in AOO 4.1.x.
Comment 26 Armin Le Grand 2014-02-10 15:34:04 UTC
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...
Comment 27 Armin Le Grand 2014-02-10 17:07:45 UTC
Getting some stuff with debug...
Comment 28 Armin Le Grand 2014-02-10 18:20:53 UTC
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...
Comment 29 Armin Le Grand 2014-02-10 22:22:05 UTC
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...
Comment 30 Armin Le Grand 2014-02-10 22:22:58 UTC
Adapting product and component, too
Comment 31 SVN Robot 2014-02-10 22:24:18 UTC
"alg" committed SVN revision 1566765 into trunk: i15508 keep trhe original file and format AFAP when breaking links to graphic...
Comment 32 Armin Le Grand 2014-02-10 22:26:23 UTC
Comment 33 Oliver-Rainer Wittmann 2014-02-26 10:02:42 UTC
taking over for verification
Comment 34 Oliver-Rainer Wittmann 2014-02-26 11:33:19 UTC
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.
Comment 35 Armin Le Grand 2014-02-26 15:44:40 UTC
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.
Comment 36 Armin Le Grand 2014-02-26 17:31:54 UTC
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'...
Comment 37 Armin Le Grand 2014-02-26 17:36:02 UTC
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...
Comment 38 Armin Le Grand 2014-02-26 21:36:09 UTC
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...
Comment 39 Armin Le Grand 2014-02-27 02:12:53 UTC
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...
Comment 40 Armin Le Grand 2014-02-27 13:13:04 UTC
Asking for release blocker to get it to 4.1.0 beta. Need to correct/extend stuff which is already in the beta.
Comment 41 Armin Le Grand 2014-02-27 13:45:04 UTC
Preparing commit to trunk, committing.
Comment 42 SVN Robot 2014-02-27 13:46:24 UTC
"alg" committed SVN revision 1572569 into trunk: i15508 Added support for BMP file type
Comment 43 jsc 2014-02-27 14:08:09 UTC
grant showstopper flag
Comment 44 Armin Le Grand 2014-02-27 17:45:33 UTC
Applying to AOO410, building, checking...
Comment 45 Armin Le Grand 2014-02-27 20:16:38 UTC
Checked all combinations with BMP and linked and non-linked content save-load cycles, works as expected. Preparing commit...
Comment 46 SVN Robot 2014-02-27 20:19:23 UTC
"alg" committed SVN revision 1572717 into branches/AOO410: i15508 Added support for BMP file type
Comment 47 Armin Le Grand 2014-02-27 21:06:07 UTC
Comment 48 Steve Yin 2014-04-03 06:52:11 UTC
Verified on branch AOO410 (Rev. 1583666) and trunk (Rev.1583671).