kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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