While in my previous post I explained how to mass convert images using the convert command line tool, I've found another solution using inkscape.
inkscape yourfile.svg --export-png=yourfile.png -w256 -h256
While in my previous post I explained how to mass convert images using the convert command line tool, I've found another solution using inkscape.
inkscape yourfile.svg --export-png=yourfile.png -w256 -h256
One of the tasks I come across often is converting images from one format into another. For instance, I need to convert SVG to PNG.
This can be achieved easily by using the "convert" commandline tool (ImageMagick) and a standard for loop in linux (note that I wrote the *.svg statement in the for command on purpose and that I use "$f" on purpose):
for f in *.svg ; do convert "$f" "$f.png" done
However, this produces ugly file names like "file1.svg.png", which could be desireable in some scenarios, but not in my case when I deploy it for a website. You can bypass this by using ${f%svg}png:
for f in *.svg ; do convert "$f" "${f%svg}png" done
Essentially this tool can handle a lot of use cases, for instance you can specify the picture density and which color should be used as transparent:
for f in *.svg ; do convert "$f" -density 300 -transparent white "${f%svg}png" done
If you only want your pictures to have a certain size, you can resize them, e.g. using -resize 64x64:
for f in *.svg ; do convert "$f" -resize 64x64 -density 300 -transparent white "${f%svg}png" done
However, you need to be careful when doing this. For instance, when the source image is smaller than the destination image, you might run into problems, and need to use the command like this:
for f in *.svg ; do convert -resize 64x64 -density 300 "$f" -resize 64x64 -density 300 -transparent white "${f%svg}png" done
I recently came across some very odd behaviour in MySQL with German Umlauts (ö ä ü ß) and Unique Constraints. The problem is even documented as Bug #57860 on mysql.com. In short, MySQL (or rather utf8_unicode_ci) would suggest that foobär
is the same as foobar
. So the statement
INSERT INTO test (test) VALUES ('foobar'),('foobär');
where test is a column with a unique index/constraint would fail.
This behaviour might be desired in some languages, but particularly for the german language this behaviour is not optimal. I'm sure if you find this blog post, you came across the same problem so I do not need to come up with another example.
The solution is simple, though you should think twice before you use it:
Instead of utf8_unicode_ci, you could use utf8_general_ci or even the newer and more appropriate utf8_german2_ci (available starting with MySQL 5.6).