Anti-aliasing is a feature, not a bug. As long as your SVG is going to be displayed on a monitor that uses pixels, you have to code it with this in mind. There is no such thing as a "correct" thumbnail size. All thumbnails are going to have anti-aliasing unless they consist of nothing but flat squares that are all multiples of the same dimensions, i.e. virtually never.
I fixed the rendering issue with the Iranian flag by making the tekbirs slightly overlap the central field. Now it will look correct no matter what thumbnail resolution you request. The fix took a total of 10 minutes to figure out and implement, which is probably a lot less time than has been spent on writing emails to argue about it.
Ryan Kaldari
On 6/26/12 12:27 PM, Achim Flammenkamp wrote:
Hi
There are no politics involved, there is just misunderstanding of your point, which is something completely different. Calling things 'miss-design' will also not get you helped to get this solved - we are not your enemy.
The last I know! :-) But all looked like secret politics which defined these arbitrary sizes. :) I got the hint "don't "bingo" with these sizes!" from an SVG-editor. :-/
Yes. Essentially, you have to choose *a* size, and they might as well be these. The problem you are encountering is a more generic one - even though SVG images are scalable, you will always have rounding issues.
Yes. BUT: It could also be that there is only the prominently displayed png-image in the size of the given SVG-file and no other prefered/suggested png-sizes. ;) Moreover, these other sizes are secretly protected from editing by the user on the description page. This supported the subjective impression of "politics".
That, on itself, is not a large problem.
Small (relative) differences could have big consequences. ;)
So the problem is the SVG is rendered incorrectly when such an aspect ratio is chosen.
Yes, you could/might/may see it this way.
I don't see how HCN's would solve this. It makes much more sense to calculate the sizes that are close to the target value (which can be the same as currently), but with the exact aspect ratio. So instead of 320 x 183, one would get 322 x 184. However, it's still a workaround: we really should have an SVG renderer that 'does the right thing'.
The last sentence I agree by heart. :) And the important point is: "close" ! The now used sizes are TOO close. :-/ The should respect the ratio given by the original SVG perfectly (a suggestion).
- update the description page to list alternate sizes that do render
correctly (which I just did [3]). 2) upload a PNG version and link to that from the SVG version 3) fiddle with the SVG until the renderer used correctly interprets what you want - maybe someone with a lot of SVG-fu can do that for you.
- I did four hours! :-( And tryed other SVG-coding but it did not work.
I had to mis design the Tekbir by more than 15% then some artifacts for some sizes vanished. Using a none buggy png-renderer when scaling doing, would solve this issue. (This was my suggestion).
Best, Merlijn
Thanks & Regards Achim