On Sun, Nov 15, 2015 at 05:57:00PM +0100, Georg Baum wrote: > Enrico Forestieri wrote: > > > It is not intended to work that way. If the svgz image is there, it is > > not expected that Qt is not able to show it. The double entry are there > > only to assure that if there is no svgz then the png can be used instead. > > In this way, you are able to override the default icons by placing your > > own in the ~/.lyx/images directory, even if they are pngs. > > OK, if it is assumed that qt can show svg images, then it does not make > sense to ship or own .pngs. If we want to stick with this, we should remove > the .pngs now and require qtsvg at configure time.
Sure, all pngs which have a svg counterpart can be removed as they will never be used. BTW, isn't QtSvg already required at configure time? > For me personally the svgs work fine both with qt 4.8 and 5.3, so I would > not have a problem with that. I only thought there might by exotic systems > where it does not work, and therefore I thought it might be a good idea to > ship both png and svg for one release, instead of switching from only png > directly to only svg. I also use "exotic" systems that are not officially supported by Qt (which doesn't even compile cleanly without patching the sources) and never had a problem with svgs. The only problem that I can foresee is that Qt is built without zlib support (and this has to be done also deliberately excluding the zlib version that Qt would include in the absence of a system version), in which case compressed svgs cannot be read, or that Qt is statically built, in which case the qsvg plugin must be explicitly included when compiling. Note that this is not the QtSvg library, but the plugin in the plugins/imageformats directory. -- Enrico
