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).
1) 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.
3) 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