Menu

#535 Support for SVG images

3.0 Series
open
nobody
5
2019-03-17
2016-08-30
user01
No

Since 3.0 there is ManifestDPIAware option, but upscaled BMPs doesn't look good. SVG would be universal at any resolution and scale.

Discussion

  • Anders

    Anders - 2016-08-30

    Neither WIC nor GDI+ supports SVG so we would have to bundle the decoder.

    If you need a solution today you can ship multiple bitmap sizes and decide at run-time which one to extract or write a plugin that converts SVG to BMP at run-time...

     
  • user01

    user01 - 2016-09-01

    I can ship single BMP, as it fits to size. But standard wizard BMP made for 192 dpi will size nearly whole megabyte. Unless at least could it support PNGs?

     
  • idleberg

    idleberg - 2016-09-01

    The installer compression alone – especially LZMA – should shrink the size of any Bitmap considerably. On top of that you can always reduce the colors of an image, e.g. to 8-bit color instead of 24-bit.

    In a quick test, an empty installer with a 24-bit wizard image (1.1MB) came out at 225kb. Since the same image looked fine at 16-bit (770kb), I ended up with an installer at 74kb. The ratio might even be better for simpler images (mine was made of two overlapping gradients, since I aimed at large file size!)

     

    Last edit: idleberg 2016-09-01
  • Marshall

    Marshall - 2019-03-04

    It should be possible to use NanoSVG to write a small plugin.

     
  • Marshall

    Marshall - 2019-03-11

    Here's a plugin to convert SVG files to BMP: https://github.com/darealshinji/nsis-plugin-svg2bmp-test
    I just don't know how to use it in a good way inside an NSIS script.

     

    Last edit: Marshall 2019-03-11
    • Anders

      Anders - 2019-03-11

      That is just the source code, those files need to be compiled to a .DLL before you can use it. Visual Studio has a free version you can use or you can contact the author at the email listed at the top of plugin.c and ask if he/she has posted a compiled version anywhere. You could also suggest that he/she should upload the plug-in to our wiki.

       

      Last edit: Anders 2019-03-11
      • Jason

        Jason - 2019-03-12

        build.sh is a linux bash script, and it uses mingw-w64. I can have a go at making a VS version and adding a 64 bit version too.

         
        • Marshall

          Marshall - 2019-03-13

          I should have mentioned that I'm the guy who wrote the plugin. I've uploaded compiled DLLs to the release section: https://github.com/darealshinji/nsis-plugin-svg2bmp-test/releases
          The reason I'm using a shell script to build is that I only have VS 2017 installed. I don't have too much experience with VS and using MinGW seems to create smaller binaries while limiting the runtime dependencies to KERNEL32.dll, msvcrt.dll and USER32.dll.

           

          Last edit: Marshall 2019-03-13
          • Jason

            Jason - 2019-03-13

            Oh, ok. I had a play around and changed the file handling to Windows calls, that gets rid of unicode conversions which can be problematic.

            But, it might be possible to build a linux .exe version, because I don't see any windows calls in your code. Then we could use !execute or !system in the .nsi to generate the .bmp.

            There was an issue though, I found a couple of places where double is being converted to float, and a possible loss of data. So I just changed it to float and typecast the return value to float too:

            static float nsvg__atof(const char* s)
            {
            ...
            return (float)((double)(res * sign));
            }

            Also, I can't remember where it was, but there is a variable that is not declared at the top of the function, so I moved the variable declaration up.

            Oh, and nsis plugin directories are called x86-ansi, x86-unicode, and amd64-unicode. That would make it easier to copy/paste the whole folder.

            It's a cool plugin though, but it starts getting slow when you go above about 200 x 200. I tried a 700 x 700 image, that took about 4 seconds.

             
            • Marshall

              Marshall - 2019-03-14

              Can you make a pull request to Github or post your changes somewhere else? Using Windows specific calls is fine since NSIS is Windows specific. As for float, isn't it better to use double everywhere? Maybe rendering of larger images can be speed up if you lower the DPI, which is currently hard-coded to 96.0.

               
            • Marshall

              Marshall - 2019-03-16

              I've changed the code to not convert any unicode names. I've also edited nsvg__atof().
              https://github.com/darealshinji/nsis-plugin-svg2bmp-test

               
              • Jason

                Jason - 2019-03-16

                I've found that one piece of code (in nanosvgrast.h) where the variable was not declared first:

                static NSVGactiveEdge nsvg__addActive(NSVGrasterizer r, NSVGedge e, float startPoint)
                {
                NSVGactiveEdge
                z;
                float dxdy;
                ...
                dxdy = (e->x1 - e->x0) / (e->y1 - e->y0);

                And EXDLL_INIT(); must be moved below the variable declarations in plugin.c.

                Also, I get a couple of warnings (plugin.c) about scale_x and scale_y being converted from double to float in:
                nsvgRasterizeXY(rast, svg, 0, 0, scale_x, scale_y, img, w, h, w * comp);

                 
                • Marshall

                  Marshall - 2019-03-17

                  Is that variable declaration thing in nsvg__addActive() really an issue?
                  As for the float thing, the regular atof() function returns returns double too. I'd rather replace float with double wherever it's possible.
                  Update: I've fixed remaining "-Wfloat-conversion" warnings.

                   

                  Last edit: Marshall 2019-03-17
                  • Jason

                    Jason - 2019-03-17

                    I have strict C set on my compiler, that's the only reason. It's a C++ thing to allow variable declarations anywhere.

                     
                    • Anders

                      Anders - 2019-03-17

                      Variables anywhere is also allowed in C99 and later. In NSIS-land we prefer older compilers so that does not really apply to us.

                       

                      Last edit: Anders 2019-03-17

Log in to post a comment.