kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/23/2011 01:05 AM, Dick Hollenbeck wrote:
> On 08/23/2011 01:02 AM, Dick Hollenbeck wrote:
>> http://docs.wxwidgets.org/stable/wx_wxbitmap.html
>>
>> says PNG format is not supported on Windows version of wxWidgets, but I would
>> not walk away without consulting the sources.
>>
>> More below.
>>
>>> PNG can be in the flow of information as an intermediate (man in the middle)
>>> technology.  But I would like to treat it as almost a *.o file in a build
>>> process.  Our real source file should be the *.svg file.  So I would like to see
>>> us find a cross platform tool, and I think you have found that already, which
>>> can be run from the command line to build the *.png files from the *.svg files.
>>>
>>> I propose that we agree never to post edit the PNG files, and that they must
>>> come from the *.SVG files.  I suggest we have a separate CMakeLists.txt file to
>>> build the *.PNG files from the *.SVG files automatically, but perhaps not make
>>> it a mandatory part of the build process, on the theory that some builders will
>>> not want to have the tool which converts from *.SVG to *.PNG installed.
>>>
>>> *.SVG -> *.PNG
>>>
>>>
>>> Therefore this means distributing both the *.PNG and the *.SVG files as part of
>>> the source tree.  That is, unless you want to burden every builder with the need
>>> to have this tool installed.
>>>
>>>
>>> Then we have to decide on how to load the PNG files into the programs, and there
>>> seem to be at least two ways to do this:
>>>
>>>
>>> A) read the *.PNG files into memory from disk at program start time.
>>>
>>> B) convert the *.PNG files into a BYTE array which is compiled into the
>>> respective program.  But the byte array is definitely a PNG format, meaning we
>>> get the advantage of the alpha channel support, which we do not currently have.
>>>
>>>
>>> If B) is the chosen path.  This entails yet another step that we need to add to
>>> the build path, meaning it needs to go into a CMakeLists.txt file and needs to
>>> be able to happen from a commandline tool.
>>>
>>> *.PNG -> *.cpp
>> http://www.libpng.org/pub/png/book/chapter09.html
>>
>> Although we are going with larger ICONs, I believe there may be no real memory
>> penalty since the PNG byte array is essentially be the PNG file in RAM, and it
>> is in a compressed format already. 
>>
>> So I think sticking with a BYTE array is the best path, because it will lead to
>> faster loading and we can continue to maintain the bitmap collection as a
>> library, and applications can continue to link against that.  I'm just proposing
>> that we put some of the build paths into a well documented CMakeLists.txt file,
>> one that does not necessarily run all the time as part of the normal compilation
>> process.
> And if you are really paying attention, you recognize that the "byte array
> containing" *.cpp files for the bitmaps would also need to be distributed as
> part of the source tree also.

A reasonable tool to convert the *.PNG files into *.CPP is a cmake script itself.

In doing so, it can also write code to generate a global wxBitmap from the
filename of the PNG file.

The cmake script can be chain loaded from a CMakeLists.txt file which builds the
bitmap library.

So I rescind my proposition that the *.cpp files must be distributed as part of
the source tree.  They can be generated by a *.cmake script.