This is the LO-4’s bug only. Do it:
 1. Follow steps 1-7 (Description).
 2. Open the file «410.odg/conten.xml» using a text editor.
 3. Change points of images. Write:
<draw:frame draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="8cm" svg:height="10.35cm" svg:x="11.5cm" svg:y="2.15cm">
  <draw:image xlink:href="Pictures/100002010000026E00000324983C42CB.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" /> 
- <draw:image xlink:href="Pictures/200000010000545600006D24A7271475.svg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">
  <text:p /> 
  </draw:image>
  </draw:frame>
as:
<draw:frame draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="8cm" svg:height="10.35cm" svg:x="11.5cm" svg:y="2.15cm">
  <draw:image xlink:href="Pictures/200000010000545600006D24A7271475.svg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" /> 
- <draw:image xlink:href=" Pictures/100002010000026E00000324983C42CB.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">
  <text:p /> 
  </draw:image>
  </draw:frame>.
 4. Save this file.
 5. Back up the contents of the folder "410" in the ZIP archive.
 6. Rename the archive «410.zip» in «410edit.odg»
 8. Open the file "410edit.odg", using LibreDraw-3.6.5.
 9. Save the file as "410edit-365.odg".
 10. Unzip the file “410edit-365.odg” and make sure that inside there is only a SVG image.
 11. Read the file "410edit-365.odg/content.xml". This bug is absent:
<draw:frame draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="8cm" svg:height="10.35cm" svg:x="11.5cm" svg:y="2.15cm">
  <draw:image xlink:href="Pictures/200000010000545600006D24A7271475.svg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" /> 
  <text:p /> 
  </draw:image>
  </draw:frame>
The file “410edit-365.odg” is identical to the original file “365.odg”.

Created attachment 76727 [details]
LO-4(dev_4.1.0.0) loses quality

Look at the picture (an attachment). You will compare the quality of work LibreOffice_3.6.5.2 ArchLinux_build-1 (above) and LibreOfficeDev_4.1.0.0_Win_x86 (below). It can be seen that LibreOfficeDev_4.1.0.0_Win_x86 displays and print bitmap (PNG image) losing quality.

Created attachment 76733 [details]
ApacheOO-3.4.1 loses quality

 It is possible that this bug came from the ASF:
"LibreOffoce 4.0 ReleaseNotes:
 Draw:
 - Multi-image support in ODF allowing a bitmap + SVG representation eg. (Armin Le-Grand - Apache)".
 
 ApacheOpenOffice-3.4.1 works on the same algorithm (picture in attachment):
content.xml (apacheOO-3.4.1):
- <draw:page draw:name="page1" draw:style-name="dp1" draw:master-page-name="Обычный">
- <draw:frame draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="18.999cm" svg:height="4.094cm" svg:x="1.129cm" svg:y="12.825cm">
  <draw:image xlink:href="Pictures/10000201000005F3000001480C4D13B2.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" /> 
- <draw:image xlink:href="Pictures/101D738500022ADA0000779DACC7D2B8.svg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">
  <text:p /> 
  </draw:image>
  </draw:frame>
  </draw:page>
  </office:drawing>

Created attachment 76737 [details]
ODG files for example

I imagine the multi-image support is a feature giving a fallback image for renderers that can't render SVG (I guess). It shouldn't really affect LibreOffice at all.

So - I'm trying to unwind the user-visible bug from comment #2 - I would hope that we would load/render the SVG fallback properly, however it is clear that the new SVG code produces rather lower quality output than the older one - though it is retained as vectors :-)

Can you be more specific on the problems - I see some pretty serious drop-offs in SVG rendering here as the main bug: I see only six of the large document icons rendered eg.

Created attachment 76757 [details]
This image shows the file in Inkscape.

Created attachment 76758 [details]
simple file with 2 SVG

Convert SVG image in a PNG bitmap takes a lot of time because DPI is changing and PNG smoothes. Compare the time required for programs (LO-3.6.5 vs. LO-4.x.x) to open this simple file.
Save the file in LibreOffice-4.x.x and look at its size.

This's not quality loss, this's corruption.

(In reply to comment #5)
> Can you be more specific on the problems - I see some pretty serious
> drop-offs in SVG rendering here as the main bug: I see only six of the large
> document icons rendered eg.

Michael,

LO 4.0 rasterize SVG to PNG and stores both original SVG and corresponding PNG at the same position on the page.
LO 3.6 doesn't read it the same way and "cleans-up" an ODF file by removing original SVG.
So if you resave original SVG-containing ODF with 4.0 and then resave result from 3.6, you will end up with a file with PNG (only) instead of SVG.

If I properly understand how ODF works, probably PNG could be stored by 4.0 as 'ObjectReplacement'. I believe in such a case it would not conflict with existing SVG.
What I'm not sure though is how LO 3.6 will react on it. Eg. will it take 4.0 rendered PNG or render SVG on its own? In the latter case the whole idea of storing PNG would be destroyed.

(In reply to comment #5)
> I see some pretty serious drop-offs in SVG rendering here as the main bug

That probably worth a separate bug, to compare SVG rendering in LO 4.0 and 3.6 and track regressions (if any).
I think the good (by time consuming) approach would be to run both over W3C test set.

Created attachment 76801 [details]
filter's work (AOO-3.4.1 vs. LO-4.0.3)

Michael,

Apache OpenOffice-3.4.1 uses a bilinear filter to output each additional PNG image. This is a quick filter of low quality. Therefore:
- Apache Draw opens the file with the time that is acceptable to the user;
- no messages in The Apache Bugzilla.

LibreOffice-4.x.x uses the Lanczos filter to output each additional image:
“Release Notes 3.6 >  Core: … Added Lanczos algorithm for resizing of images and use it instead of interpolate algorithm. This change has increased the quality of images when reducing image resolution in PDF export. fdo#46378 (Tomaž Vajngerl)”
This filter determines the transparency of the color at each point of each additional PNG image. Therefore, the filter works slowly, but with high quality.
I found the bug because of this.

You can compare works of filters if you look the picture in the attachment. In the image: at the top - Apache bilinear filter; at the bottom – the Lanczos filter (LibreOffice_4.x.x).

I think that we have needs for return to LibreOffice-3.6.5.

Hm, much more serious. Read:
bug 61899 (filters and storage)
bug 62284 (filters and storage)
bug 59259 (Impress)
bug 61230 (Writer; ODT file contains the backup PNG image)

FWIW, this is perfectly valid ODF, changing title accordingly. C.f. the zeroOrMore image/ole/applet etc. inside draw:frame in the odf1.2 RNG schema. It is of course unfortunate that 3.6.x picks the less-ideal graphic.

Created attachment 76814 [details]
ODT and ODP files by LO-3.6.5 and LO-4.1.0

(In reply to comment #13)
> FWIW, this is perfectly valid ODF, changing title accordingly. C.f. the
> zeroOrMore image/ole/applet etc. inside draw:frame in the odf1.2 RNG schema.
> It is of course unfortunate that 3.6.x picks the less-ideal graphic.
--
You try to work with files (an attachment) in LibreOffice-3.6.5, then - in LibreOffice-4.x.x.
LO-4 makes stop using SVG files in the ODT, ODP and ODG documents.
Is not that enough to go back to the old algorithm?
--
P.S. I understand that reducing the severity of the error is the most correct and shortest route to success.

(In reply to comment #13)
> It is of course unfortunate that 3.6.x picks the less-ideal graphic.
--
I think that:
A. If the patch provides good work to other Office programs, but hinders the work of LibreOffice, this patch should be canceled.
B. The user of such a program can start using LibreOffice or perform these steps.
 1. Extract the SVG file from the ODF container:
 2. Export SVG file into a PNG image using Inkscape.
 3. Replace in the ODF file native SVG drawing at this PNG image.

Created attachment 77524 [details]
Karbon-2.6.2 opened a file created by LibreDraw-4.x.x

No comment...

I got bitten by this when I used my laptop to display a presentation created on my desktop (which has been updated to a newer version). The rather complex lineart with text that I used was rendered unreadable.

Michael, the user visible bugs are:

1) I insert lineart because it is _required_ for my use. As a user of libreoffice I do not care about implementations that cannot display it. If you want to fix such cases, convert the svg to ODF drawings, or make it possible to disable such compatibility features.
2) Filesize is unnecessarily increased by saving PNG in addition. Again, such compatibility options belong in the separate "compatible" ODF format, or should be activated by user-intervention.
3) this 'feature' as currently implemented breaks compatibility with older versions of libreoffice and external tools (see previous comment). In the case of LO-3.x, only the png will be shown and subsequently saved, and thus causes a severe compatibility problem (the vector art is lost for ever and replaced by a badly rendered png). 

Again, the point of vector art is to prevent having bitmaps in the file. I do not like LO trying to second-guess my goals by doing such conversions behind my back. 

Its like saving bad quality JPGs for every embedded PNG. Such things are nicely available by right clicking the image where you can modify the compression setting. Same could be done for SVG, but do not do it automatically!

btw, from the spec:

"Each child element of a frame is a different representation of the same content. The order of content elements reflects the document author's preference for rendering, with the first child element being preferred. That means that consumers should render the first child element that they support. A frame may contain multiple content elements, but shall contain at least one content element."

In most cases, it is obvious that the document author, (i.e. me) prefers the content that he actually inserted. It may well be that older versions of OO.org will fail with this (that seems to have been Armin's reasoning for putting png first), but that only stresses the need for configuration of this feature and is not an excuse for breaking the spec.

Created attachment 89099 [details]
PNG by LibO-4.2.0 alpha1

LidreOfficeDev-4.2.0.0 began to understand the mask. But, nevertheless, problems arise when creating PNG (see attachment):
1. Object "Globe (Web template)" is lost.
2. Size (in pixels) is less than the size of the original SVG file.
  
The time required to display the image on the screen has not changed. This is indirect evidence that the filter each time re-converts the SVG file to PNG image and PNG, embedded in the file when you first save, do not use.

(In reply to comment #19)
> The time required to display the image on the screen has not changed. This
> is indirect evidence that the filter each time re-converts the SVG file to
> PNG image and PNG, embedded in the file when you first save, do not use.

Proof:
 1. File 410.odg extracted from the archive (attachment 76737 [details]).
 2. File 410.odg\Pictures\10000201000005F3000001484CF701B4.png extracted and then opened for viewing with using the external program such as IrfanView.
 3. Start LibO Draw 4.1.x and open the file 410.odt.
 4. Compare the pictures.

(In reply to comment #20)
> 3. Start LibO Draw 4.1.x and open the file «410.odt».

Sorry, start LibO Draw 4.2.0.0_alpha1 and open the file «410.odt».

I raised the status to "critical" because:
1. LibO-4.x.x creates an additional PNG file which API does not use.
2. Broken continuity versions (3.6.x vs 4.x.x).
3. Earlier versions of the program (3.6.7) do its work much better.

Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=306a39ec0d2cde09d7e75e726ce47622939733d7

Resolves: fdo#62461 put preferred image first



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Ordered with favourite first, followed by fallback. Seems to work ok, testing appreciated. Proposed for 4-1 as https://gerrit.libreoffice.org/6680

thanks. Will test early next week!

(In reply to comment #25)
> thanks. Will test early next week!

Surely you changed the status to unconfirmed by mistake : without explanation, just after a patch has been pushed.
Changed back to fixed.

Best regards. JBF

A bug shouldn't be listed at two MABs, removing it from the second (4.2) one.

Tested by recompiling fedora (fc20 branch) libreoffice with a patch based on the one in comment 23. Confirmed that older versions of libreoffice (3.6.7) now correctly read the svg file. However, saving in that version will drop the png copy from the file (cannot be helped, and is better than dropping the svg).

I assume that Armin put the png first to facilitate backwards compatability with OO.org versions that did not include svg support. Apparently these versions did not follow the spec well enough to check for alternative fallback images. However, i did not go through the trouble to test this. 

We should, however, ask ourself the question what is the purpose of this fallback image if there is no use-case for it (i.e. the software that does not support svg, also does not know how to read fallback images).

In my opinion, interoperability between LO 3.6.x and 4.x is more important than with ancient OO.org versions, so I think the new way is a more sane default. The user-visible bug for me personally is thus fixed.

Whether the original reporter is happy with the resolution I do not know as problems may remain:
- interoperability with 3rd party programs not dealing well with multiple images
- not asking for user confirmation and defaulting to including bitmap copies for vectorart images, thereby increasing file-size (perhaps without reason as explained above).


JBF: sorry, I quickly replied and it seems bugzilla defaults to putting unconfirmed in the bug status window when I add comments, I did not notice and thus inadvertently changed the status.

Seems the patch will be rejected for 4.1:
https://gerrit.libreoffice.org/6680

Also, it is not clear to me whether Michael understood that this breaks compatibility with LO in a minor way in order to maintain compatibility with much older OO versions in a bigger way.(I could be convinced by a good argumentation, but the point seems not to have been addressed).

Since this is a 4.1mab, I guess it does now make sense to reopen.

I propose an alternative fix for 4.1 by making the order depended on a setting.

Most obvious would be to save it in the wrong way for the 1.2 Compat ODF format.
(and this would avoid adding extra options).

Comments?

Changed importance to reflect the new policy - Sophie

Since the only 4.1.X version to be released is 4.1.6 and I suppose this one will contain only critical bug fixes (like crashes for example), I propose to close this tracker.
Just to be sure everything is still ok on 4.2 branch, I made the following quick test with 4.2 sources updated some days ago:
- create a brand new file on Writer
- insert SVG
- save in odt
- rename odt->zip
- unzip
- check svg is before png 
it's ok.

Any thought?

lets keep this closed, reopening bugs is really problematic. If there is still a bone of contention in some area I think its now better to open a new bug about that