Could we merge the PNG files into a tilemap like is commonly done for mobile/web applications?
On Thu, Aug 31, 2017 at 3:04 PM, jp charras <[email protected]> wrote: > Le 31/08/2017 à 20:27, Wayne Stambaugh a écrit : > > Is it possible to create image libraries with different size images > > using the method you described below? If so, this could give us a path > > forward for high dpi monitor support. This problem is only going to get > > worse as time goes on so it would be nice to have a solution. > > > > As for using rsvg for the svg to png conversion, I don't have a strong > > opinion but then I don't maintain the image files so my opinion carries > > less weight on this issue. If our image maintainers are set on Inkscape > > then I support their decision. I'm guessing you could make using rsvg > > optional with some clever CMake hacking. > > Only for myself, I can say Inkscape is the svg editor, but no need to use > it to convert svg to png. > As long an other tool is freely and easily available on all platforms, I > am fine with it. > > Currently we use svg (source) -> png -> png filtered -> .cpp file image of > png > The cpp is used because it is a text file easy to compile and include in > binaries. > > if the svg to png conversion is easy, no need to distribute the > intermediate .cpp files. > if of course there is a way to support 2 or 3 set of icons with different > sizes, this is really good. > > However I am not especially thrilled by using a lot of png files (500 > currently, and if 3 sizes > (small, normal, high) are available, 1500 files). > My concern is due to the fact loading 500 files each time kicad is started > could generate a very > noticeable loading time. > I know some applications with a very long loading time (especially > Inscape) and this is really a > serious problem. > So I am not sure using 500 .png files instead of only one (a .so or a > .dll) file is a very good idea. > This is especially true on Windows. > > > > > rsvg is packaged for msys2 so on windows there are should be no issues > > using it. > > > > On 8/31/2017 12:46 PM, Simon Wells wrote: > >> converting the png to cpp files can be done the same how it is now > >> (using cmake), although it would really only be used on linux i would > >> also look at making it so that they all went into a single cpp file > >> rather than the numerous files it currently is. > >> > >> On windows the files would end up as part of the "resource file" which > >> (not being up to date on windows) is either built into the app in the > >> resource part of the binary or there is a file but it still only looks > >> for it in once place > >> > >> On OSX it looks in the resources folder of the application bundle > >> > >> so there aren't the issues of it possibly being in many place which > >> exist with .so files at least and i think the same with dll files, but > >> on linux seeing as wxwidgets doesn't seem to like any of the icon > >> options they would just be built in as they currently are as xpm. If > >> you don't have the icon files on macOS (which is the only one that > >> stores them as physical files i believe) then it would be your fault > >> as you obviously must have deleted them from the bundle as they would > >> be part of the build process. Every other osx application has the > >> icons as resources in the resource folder or in one of the > >> language-dependent subfolders > >> > >> http://docs.wxwidgets.org/trunk/group__group__funcmacro__gdi.html# > ga30fc362d22b3045f58aed54fc808f203 > >> as can be seen here the wxBITMAP_PNG macro automatically sorts out the > >> different places they can be found on each platform. > >> > >> rsvg is one option for doing the svg->png conversion (its also fast on > >> OSX) not sure about other platforms but it is available for > >> linux/windows/macOS so theres no platform issues, however this could > >> equally be replaced with imagemagick instead which can use inkscape as > >> the backend if you have it installed but can also use rsvg as well (or > >> other options as well including an internal one) but this would not > >> give the same png/ascii file on all platforms obviously. > >> > >> there is also the option of commiting the png files in place of the > >> icon cpp files that are currently committed and then on linux its just > >> a case of creating the cpp files from the png which shouldn't take too > >> long as its effectively just catting files. this would avoid the issue > >> of needing the same png created from the same svg on all platforms, if > >> we did want to use imagemagick > >> > >> > >> > >> > >> On 31 August 2017 at 07:21, jp charras <[email protected]> wrote: > >>> Le 30/08/2017 à 20:54, Simon Wells a écrit : > >>>> my goal is more to move to using the wxBITMAP_PNG macro which would > >>>> use real files on osx and some weird resource hybrid on windows and > >>>> xpms on the other platforms that don't have a decent option. hence i > >>>> need to convert all the files into png > >>>> > >>> > >>> Perhaps you should explain *exactly* what you want to do. > >>> > >>> Before using svg files as sources, icons were stored in .xpm files, > often created from a .png icon. > >>> Only ascii files can be included in .cpp or .h sources. > >>> > >>> This was really a pain to maintain icons, and I do do want back to > .png files as sources. > >>> (note of course this is the .png files converted to an equivalent > binary tab coded in .cpp file that > >>> are included in kicad sources, so Kicad uses currently .png icons > internally, so I do not really > >>> understand the meaning of "using the wxBITMAP_PNG macro") > >>> > >>> Moreover I am not convinced using real files to store .png icons is a > good idea. > >>> (what happens if these files are for some reason not found? > >>> We have already issues with .so or .dll or script files not found on > all platforms) > >>> > >>> So my requirements are: > >>> > >>> - source icons must be .svg files. > >>> - avoid exotic tools to convert .svg files to ascii files. It must be > easily available (and run > >>> without crash) on 3 platforms. > >>> - png files can be only intermediate files created by the build > process (like any object file) > >>> - ideally, the same .svg file should give the same ascii file on all > platforms. > >>> > >>> > >>> > >>> -- > >>> Jean-Pierre CHARRAS > > > > -- > Jean-Pierre CHARRAS > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
