v1.2.0: Problem with PreserveAspectRatio for some SVGs about androidsvg

[GoogleCodeExporter]

Hi. Thanks for the report.

The sample file you attached is an example of the sort of file that I refer to 
in the release notes.  That is, one that might previously have been scaled but 
won't be now.

The reason it is not being scaled is because it has no viewBox defined.  
Without a viewBox, there is nothing to tell the renderer how the content should 
be scaled to fit the canvas.  See 
http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute

In previous versions of the library, I was being a bit over-enthusiastic and 
auto-scaling documents that in theory shouldn't have been.  That code worked in 
some situations, but not others, and made some assumptions that meant that 
scaling wouldn't necessarily be correct anyway.

I decided to remove that code and instead provide some API methods that would 
allow users to have better control over how scaling happens.

In this particular situation (with this particular file) there are two 
solutions to your problem.

Solution 1: Add a viewBox to the file.
  Add the following attribute to your root <svg> element.

  viewBox="0 0 20 20"

  You will also need to remove the "width" and "height" attributes (or
  set them to "100%") if you want to scale this document to any size
  other than 20x20.

Solution 2: Use the API to make the equivalent changes.

  After loading your SVG add the following:

  // (setVewBox() values may need to be different for other files)
  svg.setDocumentViewBox(0f, 0f, 20f, 20f);
  svg.setDocumentWidth("100%");
  svg.setDocumentHeight("100%");


My apologies that this release broke your code, but I felt it was important 
that I brought AndroidSVG into line with other renderers.  Your file as it is 
would not scale with any other renderer either.

If you have any other problems, let me know.

Paul

Original comment by [email protected] on 18 Jul 2013 at 8:31

• Changed state: Invalid

[GoogleCodeExporter]

Thank you very much for the full response, you have solved my problem.

The problem was not the viewBox. I am using viewBox, but was testing different 
options to find if something works and for some reason uploaded a file without 
one.
The problem was the presence of width and height. Almost all of my files do not 
have width and height, just a few and they had the problem.

Something to note is the fact that the Apache Batik library allows for scaling 
when width and height are set in pixels. Apache Batik is perhaps the most 
popular SVG library for Java (not Android). I have also tested a few other 
non-Android SVG libraries and 5-10 Android libraries and I think most allow for 
scaling when width and height are set. Having said that the SVGs I use will not 
have width and height from now on, so I will not use it if you decide to change 
it.

I am making a game that supports both web and android version and something 
else I have noticed not supported by androidsvg is preserveAspectRatio inside 
the SVG. For example:
preserveAspectRatio="xMidYMid slice"

Having said that your library is incredible. It is so much better than anything 
else available on android, it is unbelievable. With the latest 1.2.0 update it 
renders everything I have perfectly (I had some alpha objects rendered solid 
color with the previous version).

Original comment by [email protected] on 18 Jul 2013 at 9:26

[GoogleCodeExporter]

Thanks for the nice feedback.

You wrote:
> I have noticed not supported by androidsvg is preserveAspectRatio inside the 
SVG. For
> example: preserveAspectRatio="xMidYMid slice"

This should be working. My tests are all working. Can you send me an example of 
one that fails?

Original comment by [email protected] on 18 Jul 2013 at 9:37

[GoogleCodeExporter]

I stand corrected. You are right, preserveAspectRatio does work. I was testing 
with files having width and height. Now that I test with correct files it 
works. Thank you very much.

On a side note if you are interested in the game I am working on (as it uses 
your library) send me a message.

Original comment by [email protected] on 18 Jul 2013 at 10:02