kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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 <jp.charras@xxxxxxxxxx> 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 <jp.charras@xxxxxxxxxx> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>