Re: building graphicsmagick 1.3.38 on Windows

On Fri, 22 Apr 2022, LM wrote:
>>
> I started testing GraphicsMagick to see how well it handled SVG.  I tried
> converting the SVG file to PNG and checking if the drawing was
> recognizable.  I tested against the three sample programs that come with
> nanosvg.  GraphicsMagick handled two of the three nanosvg samples as well
> as nanosvg does.  The third sample was the tiger head that a lot of
> graphics programs use for demonstrating vector graphics.  It failed to
> convert and gave the warning "Negative or zero image size".  When I tried
> to convert the output from abcm2ps from svg to png, I also got error
> messages.  There's a reference to currentColor and GraphicsMagick gives the
> error "Non-conforming drawing primitive definition (fill)".  There's also a
> command in the SVG file ( <use x="22.00" y="93.00" xlink:href="#tclef"/> )
> and the error is "invalid primitive argument (Primitive "use" id "tclef"
> not defined)".  I modified currentColor to #000000 in the file and I
> removed the use line and I was able to get a graphic that was fairly close
> to the original SVG.  I'm wondering if it would be worthwhile to try to
> find work-arounds in the code for the commands that are erroring out in the
> conversion.  It would be really incredible to have something that could
> convert abcm2ps SVGs to a format that's more easily viewable on systems
> that may not have browsers with SVG capability or other complex SVG
> rendering programs installed.  Except for the error messages/issues,
> GraphicsMagick did a really great job in converting these files.  They look
> really good.

I have a "Tiger" SVG which renders very well.

The problem with the SVG standard is that it is complex and a moving 
target and continues to add new versions which lots of new features, 
assuming that implementations will be able to keep up.  Projects like 
major web browsers are able to keep up because they have many paid 
developers.

It may be that parsing issues are minor, or they may be major.

The SVG renderer works by having a front-end (coders/svg.c) which 
converts to a simplified textual internal format called MVG, which is 
rendered by code in magick/render.c (DrawImage()).  So first the front 
end parser needs to handle the syntax.  And then the rendering code 
needs to have the underlying capability to perform what was requested.

There may be areas where there are non-conformances such as SVG saying 
that order of object declaration does not matter but GM expects that 
objects are defined when they are first referenced/used.

The project needs capable volunteers to work on improving SVG.  It may 
be that the SVG produced by abcm2ps could be handled with just some 
minor fixes, if the problems can be identified.

The "Negative or zero image size" issue may be related to the many 
security-related fixes that I added to the code.  Sometimes being a 
little less picky (e.g. ignore something with a size of zero) will 
allow success.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt