On Mon, Nov 16, 2015 at 06:01:57PM +0100, Enrico Forestieri wrote: > 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.
There was an issue on Windows that came from not including a .dll. Now that the issue has been fixed, we should decide if we would like to consider removing the .pngs. If we would like to remove the .pngs for 2.2.0 I think we should definitely do this for beta1. Conversely, if we remove the .pngs for beta, I think it would still be OK to add them back for the final release if we discover problems, as JMarc proposed [1]. Thoughts? [1] https://www.mail-archive.com/search?l=mid&q=5648B9FA.3070705%40lyx.org
signature.asc
Description: PGP signature
