On 06/27/2012 12:31 AM, Achim Flammenkamp wrote:
On Wed, Jun 27, 2012 at 12:03:35AM +0300, Ilmari
Karonen wrote:
* The "Allahu Akbar" strips are each supposed to contain 11 copies of
I
'm still waiting that somebody changes these correct words on the quickly
added comments and png-sizes on URL
http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg from the false "Alkmar
Allah" -- I'm not religious, but there
exists fanatics. :-/
Well, that won't be me, since I can't read Arabic, much less write it.
the phrase,
but they actually contain 12 of them, with two of the copies
drawn on top of each other. This can cause one of the 11 phrases to
But I thought drawing one color exactly at the same position as before will
result in no change.
That's only true in theory, if the image was rendered at an infinite
resolution.
However, in reality, the resolution at which the image is rendered is
always finite, and the renderer must employ some form of anti-aliasing
to account for details smaller than one pixel in the rendered image, or
for lines that don't fall exactly on pixel boundaries.
Consider, for example, a black rectangle drawn on a white background,
positioned so that one of its sides falls exactly in the middle of a row
of pixels. When the rectangle is rendered, the renderer will,
correctly, make that row of pixels 50% gray, that being the color
halfway between black and white.
However, if another copy of the same rectangle is later drawn at the
same position, the renderer will again set the color of those pixels to
halfway between black and their previous color -- but since the previous
color of the pixels was already 50% gray, they'll now become 75% gray.
One way to minimize this issue is to first render the image at a much
higher resolution than the intended target and then to scale it down.
However, not only is this inefficient, but it cannot entirely eliminate
the problem: if the high-resolution intermediate image is anti-aliased,
the same effect will appear, just on a smaller scale; whereas if it is
not, interference patterns and other aliasing artifacts may appear, and
will not always be hidden by the downscaling.
appear bolder
than the others at some sizes (such as the 120 x 69 px
size used in gallery thumbnails). The way to fix that is simply to
remove the extra copies.
I did this only to make the drawing simpler and maybe faster.
While using cloned objects can make the SVG file smaller, it won't
actually speed up rendering -- the renderer must still draw each of
those clones separately after applying any transformations to them.
would be
better to merge them into a single path, and to make sure that
no path segments occur in places where a visible line is not supposed to
appear. (That is, if you set a stroke for the path, the stroked line
should appear only along the boundary of the red/green and white areas.)
Good idea. But this means you must explicitly state all 22 "Alkmar Allah"
elements. This can't be the sense/usage of SVG-coding. :-(
I want to have a logical strcutred SVG code reflecting the geometric constrcution, not a
meaningless heap of coordinates of 3 pathes for 3 colors ! :-((
Alas, SVG does not define any way of constructing a single path out of
cloned segments, so this is not possible in general.
In this particular case, one possible solution could be to keep the text
elements as separate objects, but to make them overlap the central white
area enough that no gaps can possibly appear between them. In fact, for
this image, you could even make the rectangles in the text that touch
the central area extend all the way across it to the other side.
* The emblem
in the center is built by drawing one half of it and then
cloning and mirroring it. At some sizes, this can cause a faint white
line to appear where the two halves join together. It would be better
to draw the entire emblem as a single path.
I know this issue. :-( And the current version has exactly corrected this problem
by add atiny logical overlap. But I think mirroring complex pathes is easier
for threndere than two times draw/interparte the compl4x path coordinates, doesn't
it?
While I haven't looked at the internals of the rsvg renderer (or any
other SVG renderers, for that matter), I doubt that two cloned paths are
any easier to render than a single path with twice as many nodes. While
in some special cases there might be optimizations that could be made,
few of those optimizations are generally applicable, given that, in
general, the two clones might be very differently transformed and might
be drawn on very different backgrounds.
--
Ilmari Karonen