Provide possibility to specify custom scaling
viliam-durina opened this issue · 16 comments
Most svg icons I download from internet have canvas size of about 512 pixels. Even if I specify xxxhdpi (which has factor of 4), the icon is still 128dp large, while icons on buttons normally have 24dp or so.
I know I can resize the icon in Inkscape, but this is cumbersome. Could it be possible to specify the scale factor manually, such as using "factor_6.4" in place of the density specifier?
good idea, will think about it to find the best way to do it
maybe an additionnal closure parameter in groovy
task {
preScale x%
}WDYT ?
No, you need to specify it individually for each file, as you do currently with the "-mdpi" postfix. I suggested to use the postfix, such asp "-dpfactor_6.4". You probably currently calculate such value from the postfix anyway. The value 6.4 will mean, that the svg's size of, say, 100 will be 100/6.4 for mdpi. "-dpfactor_1" will be equivalent to "-mdpi", "-dpfactor_1.5" to "-hdpi" etc.
hum, why don't you use inkscape to rescale your svg ?
once its done, its done...
You can group your svg by canvas size (in a svg-512 folder) and create a task for it with the desired scaleFactor... You can have as many task as you want...
This is easier. I look up icons on internet and need to adjust the size of each individually. Also, our graphic designer supplied svg-s, but with various sizes. When he alters the icon later a bit, I have again to open inkscape and resize. He just does not care about the size. He draws anything in any scale, then puts it to photoshop to the final layout and resizes. And I have to rescale.
or instead of naming like this :
- svgName-mdpi.svg
we can do :
- svgName-24mdpi.svg
meaning the svg should be scale so that it is 24px in mdpi. (= force 24px for mdpi and scale regarding this for other densities)
WDYT ?
It's good also. This way you don't depend on further resize (or replacing with completely different icon with completely different size).
But it's 24px width or height? What about "svgName-w24dp.svg". This will mean, that width will be 24dp, which is 24px for mdpi. This is more readable.
For completeness, we should support both "wXXdp" and "hXXdp"...
good remark ;) go for this
Great!
If u want to try, its on the custom-scaling branch
I tried it, it works. Thank you, I hope it will help others as well.
I still don't like the wXXmdpi syntax. It's not self-describing. I noticed, that w100dp is already used, maybe that's why you did not use it. What do you think about wscale24dp suffix instead? It's lot more intuitive to read.
Secondly, if I rename the file to have different size, PNGs will not be overwritten, unless I specify the overrideMode='always' (the parameter should be named overwriteMode, btw). I don't know of other way of doing this than checking the size of each PNG or keeping a track from last run somewhere.
for the syntax, wXXXdp and hXXXdp is a reserve Android qualifier different from the density ones... I prefer to use let user the ability to choose the density for the specified pixels because of https://github.com/avianey/androidsvgdrawable-plugin/wiki/Pixel-perfect-drawable (could be wscale24mdpi)
for the overrideMode, it's usefull to avoid generating very cpu intensive svg (some watch face with lots of filters) and loading already existing PNG will be cpu consuming too... You should output generated PNG to generated/res (like in the sample project) and perform a clean when upgrading this library... (will add this in the doc btw)
For the syntax, you always write density-independent sizes as 24dp, not 24mdpi... Android developers are used to this. But, I don't mind, both are working.
I understand why ifModified mode is useful. But the feature may cause, that changes in source files are not picked up, if you just change the qualifiers.
Maybe you could generate a status to a separate status.txt file, specified in some parameter. There will be SVG pixel size and PNG pixel size. When generating in ifModified mode, if the SVG's and PNG's last modification dates are equal, you will calculate destination size and compare it with the size stored in the file. If they are not equal, you will overwrite. If the status.txt file does not exist, you will work in always mode. This will make the overrideMode parameter obsolete.
Together with another issue #39 , I just entered, you will not ever have to clean the project in order to get things correct.
androidsvgdrawable plugin version 2.0.0 just pushed in maven central
Thank you! I'm going to upgrade the version.
upcomming version will use gradle UP-TO-DATE mechanism and kind of deprecates overrideMode, plugin upgrade, file rename and content modification will be transparently handle by gradle!