Hi It is explained in detail at the (yes, very lengthened section) who's URL I pointed you at first. But okay, I will repeat very thing relevant for you: 0) Where: on my personal/office monitor when displaying certain wikimedia pages. 1) I use different versions of Firefox 3 and 4 but the visual effect is in always the same (running on different Linux flavors) (and not only at me). 2) If you like, take as a good example the URL http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg 3) I triggered this here because I created the valid (last) version of this SVG-file and people now come to me and complain about it's appearance on wikimedia and wikipedia. Thus I dig done the problem and it seems to be out of my reach to correct this miss-design by wikimedia but identified it to got founded in some wikimedia politics or history which now noone seems to be responsable. :-/ Detailed explanation at example: If there is a SVG-file on wikimedia, some fixed logic generates png-images for the flag's description page generally. The first image, here 800 × 457, is displayed very prominently always at the beginning of the SVG-description file, others (320 × 183 pixels | 640 × 366 pixels | 1,024 × 585 pixels.) follows as links. All these sizes seems to be bounding-boxes from historic used (maybe even today) resolutions of (CRT-)monitors respecting aspect about ratio as near as they can If horicontal OR vertical is maximized to this resolution. Then some facts to the original SVG code is stated and than further fixed png-sized images follows as links (This image rendered as PNG in other sizes: 200px, 500px, 1000px, 2000px.). The last , in small font set explanation, I added for people to get an understanding of the reasons lying behind the scene. :-/ [Only for thios flag]. This flag should have a ratio of 7:4 which has the SVG original, but NOT the prominantly displayed first image (800 × 457 , 800 is not divisible by 7, nor 457 by 4)! Because in this flag, there are these two strips of "Alkmar Allah" Tekbirs, rendering artifacts can get easily visible if improper rendering occurs! First reason is: flag height in pixles is not divisible by 3, so the three green, white and red strip can't be of equal height (as demanded in the original SVG-code)! And because the Tekbirs should be exact aligned at the border of the green/white and red/white strip rounding errors may provocate a green or a red one-pixel-thick line to appear between the white strip and the Tekbir as you see in the 800x457 image! It seems the scaling and rendering is doing in the wrong order (my guess, I also tried different work-arounds but got no satis- factoring solution, because it is not a coding issue in SVG!). I guess: IF one would FIRSTLY render the original SVG to its orignal size into a fixed bitmap format and then scale this down to the wanted (png-)size, several visibale artifacts (like the just mentioned MUST be gone!). So, this is a rendering-design issue. Moreover to avoid further artifically introducted problems by chosen thoughtless fixed sizes (500px), I propose NOT to use multiples of 100 or 1000 nor historican monitor sizes as fixed image sizes (which are out of control for the user/uploader!!), but sizes which consists on many small primes, i.e. HCN (highly composite numbers). Thus my second pointer in my first email to explain the background. BTW: The same effect/statement is correct for SVG-templates like the one which uses national flags displaying in info-boxes in articles. But here maybe I can trigger guys responsible for these templates on XY-wikipedia (language specific). I hope I have explained it righlty and (nearly) relevant completely now. Thanks for your attention, Achim

So, the aspect ratio is right. Your problem is that you want it to be a perfect multiple of 7:4. (...) Those links as provided as convenience for downloading smaller versions. They were added per bug 2581. I think those were added as arbitrary sizes (with a large history usage, as noted). So nobody should be allowed to get a thumbnail with eg. exactly 120px width? (As used in the galleries, meaning you would end up with differently-sized thubmnails, which would look bad) So your problem is not the scaling itself but that it gets wrong (I don't see a red line above the letters or a green one below them, btw so seems to render fine). We are just asking rsvg to "render this svg in this size", not doing two different passes. Well, if the given instance renders badly you should take the issue upstream to rsvg authors (unless the problem is that wikimedia is using an outdated version). I'm pretty sure this will turn out to be a bad idea, but please propose the alternative sizes. Those templates usually request a fixed size, so not related to MediaWiki defaults. Thanks for your explanation.

On 06/26/2012 03:12 PM, Achim Flammenkamp wrote: Is there something sacred about the ratio that means anything less than perfection is unacceptable? There are some *real* issues with the rendering on Commons -- especially SVGs -- and it looks like the thumbnail on http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg from "20:14, 21 June 2012" (http://hexm.de/jg) shows the real issue here. The proper place for reporting this issue is probably the ImageMagick developers. They've been really quick about responding and fixing problems in the past. After the problem is fixed on the ImageMagick side, you need to get Wikimedia Operations to deploy the fixed code. I've reported this to the ImageMagick devs (http://hexm.de/jh). Let's see what their response is before we blame "Wikimedia Politics". Mark.

On 26/06/12 22:24, Mark A. Hershberger wrote: Tha shows a problem in the central image, I thought the Tekbir were the white "letters" on the color stripes? http://upload.wikimedia.org/wikipedia/commons/thumb/archive/c/ca/2012062120… does show a 1px green/red border (not the full one, mixed with white) between them and the white stripe. Are you sure it's rendered with imagemagick and not with rsvg? (we use imagemagick for thumbnailing raster images) I suspect we may be pulling the wrong developers. OTOH, both rsvg and imagemagic seem to show a "dragonfly" in the center, with inkscape showing instead the "trident", so it seems adequate to drive it to the attention of both groups. In fact, imagemagick isn't showing the 1px "border". rsvg-convert -w 800 -h 457 '20120621203246!Flag_of_Iran.svg' > output.png convert -resize 800x457 '20120621203246!Flag_of_Iran.svg' output.png

On 26 June 2012 21:12, Achim Flammenkamp <achim(a)uni-bielefeld.de> wrote: By pressing the 'edit' button - it's just part of the page text. I removed the entire section, as Ryan solved the issue. Best, Merlijn

On Wed, Jun 27, 2012 at 1:33 PM, Achim Flammenkamp <achim(a)uni-bielefeld.de> wrote: Actually, SVG previews _are_ rendered/displayed at the size the SVG file specifies, but only if that size doesn't exceed the viewer's image size limit (specified in their preferences; I think the default is 800x600px). Larger images are previewed at a smaller size that won't exceed the limit instead. -- schnee

this restriction and ALWAYS render them at the given SVG-size prominantely. (browser will show (the lower left) part, but you can move the mouse-pointer to see the whole image, or browser can scale it (the pixel image) down). I dislike the idea of displaying the rendered PNG at the given SVG-size even if it is above the user's screen size. I think most people would prefer to see the image in the biggest size they can without having to scroll. I know it always annoys me to have to scroll to see the rest of an image. Further, if we send a huge image and tell the browser to scale it down we are making inefficient use of our, presumably limited, bandwidth. Also in my experience ImageMagick generally does a better job downscaling images than most people's browsers. An user-preference would be nice though perhaps? Although I must say it isn't too much extra work to click one more itme to view the full size if you really need to. Thank you, Derric Atzrott Computer Specialist Alizee Pathology

It is not an SVG! It is a band-width problem, in this case. I needed about 10 minutes real-time to download this image at full-size to my computer, but can work anyway in parallel. Vector-grafics should have been FAR MORE compressibale then jpeg or other snapshots from random/real-word scenery! Thus, an irreal example. ;-) I just wonder: Why do we not simply transmit the SVG image, but render a png for an SVG-file to the browser? Historic reasons? BTW: I have such an image printed out as 72 x 80 cm poster in my private room. It is a crab-nebula photography overlaid from 3 or 4 spectral lengthes. :) Here is a better, realistic example: http://upload.wikimedia.org/wikipedia/commons/e/e8/Flag_of_Ecuador.svg Cheers, Achim

I c. So historic reasons. Do we keep a list of user-agents able of supporting png images? ;-) I have to thank, Achim

On Thu, Jun 28, 2012 at 4:13 AM, Derric Atzrott < datzrott(a)alizeepathology.com&gt; wrote: Pretty much. Back in the day (2003-2005 era) SVG support was very limited in common browsers -- only very recently did Internet Explorer 9 add it, and most Android devices still don't support it. We did some experimentation with using the <object> tag and fallbacks so that supporting browsers & browsers with plugins could get native SVG but it had negative effects, such as throwing up annoying prompts and not always showing the fallback content if there was no SVG support available. Since <object> fallback is wonky and Accept headers can't be used reliably, we'll likely end up using different tools. In these modern days, it's likely we'll end up with something like this: * load the PNG as a default * in JS, detect native SVG support and swap the SVG original in in place following similar logic as we'll probably end up using for raster images on high-resolution screens (such as the new MacBook Pro and iPad "Retina" screens, the upcoming Nexus 7 and Transformer Infinity tablets, the higher-resolution version of Microsoft's upcoming Surface tablet, etc). Sending the low-res rasterization first feels like a waste of bandwidth, but usually shouldn't be too extreme, and basically will "look and feel" like progressive loading. :) -- brion

Exactly this I do often: Displaying the 208+30 national flags all as SVG on one browser-page! :-) It takes about hmm ... about 62 seconds. I just made a first time time-measurement. My hardware uses an Athlon-Thunderbird 2 GHz with 4 GB RAM running FireFox 3.6.17. Chears Achim

I know this. But I wonder why an width/height length is given at all? The viewBox I would enforce and this is much better, IMHO. Therefore, if length/width is wanted, then this should give a different/further information, if useful. I don't like to warm up the debatt, but if the SVG-size is larger than a fixed arbitrary limit, maybe it is better not to render to the maximum in vertical or horizontal direction, but only to the maximum such that the precise aspect ration is still given? Of cource you get other problems (or impossible) if this is strange like 701:401 or even bigger primes. :-/ But you will get anyway self-introduced problems if not rendering at the given SVG-size, because only for the last the original SVG-coder is responsible and not you. :) BTW: This just springs to my mind: I discovered if defining a path with <path d="M 3,3 h 0" stroke-width="1" stroke-linecap="square"> you get a 1x0 square (no visible effect), not a 1x1 square as I would expect. But <path d="M 3,3 h 0.001" stroke-width="1" stroke-linecap="square"> shows a 1x1.001 rectangle (centered at 3,3.0005) as expected. Is this a known bug? Achim

you misunderstood. In the original SVG there are no thin lines. The thin line was introduced/inserted by buggy down-rendering to the wanted size. (There are coincident lines in the SVG). Also the double drawing would be mostly irrelvant, if first render to the original given SVG size. It seems many problems are only introduced artifically by this toughtless(?) rendering-philosophy of RSVG (or Imakemagic), IMHO. :-/ Surely Achim

https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=svg&list_id=1257… I think you may have missed link #3. Thank you, Derric Atzrott Computer Specialist Alizee Pathology

Guys, please don't forget to CC him in your messages, I don't think he subscribes to the mailinglist. It would be a bit of a waste if you write your arguments not to be heard for the person intended. On Tue, Jun 26, 2012 at 8:23 PM, Merlijn van Deen &lt;valhallasw(a)arctus.nl&gt; wrote:

Hi "Mark A. Hershberger" already discovered/guessed my still missing 2nd point: There seem to be an (unknown?) rendering bug. See URL http://commons.wikimedia.org/wiki/File:Flag_of_Iran.svg and the flag's/file's version of 20:14, 21. Jun. 2012 . The original sized image had no artifacts, only this thumb nail in the preview (and maybe others of these 4+4 fixed sized png-images on the description page, but I forgot which). I remeber that I deleted all leading digit 0 from coordinates in a SVG path-command inside for the center emblem. Maybe this was a reason for miss-rendering at certain sizes, but I strongly wonder that this only hurts certain final absolute sizes of a rendered image so drastically. Achim

On 06/26/2012 10:27 PM, Achim Flammenkamp wrote: I took a look at the SVG code, and I see several things that could be done to improve the rendering at arbitrary sizes: * The "Allahu Akbar" strips are each supposed to contain 11 copies of 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 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. * The faint green/red line appearing between the phrases and the central white part of the flag at some sizes occurs because the phrases and the white area are different paths, and are thus rendered separately. It 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.) * 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. All of these issues fall into the general category known as "coincident paths". Specifically, whenever a vector renderer is told to draw two lines that fall exactly on top of each other, it's very likely that there will be rendering errors under some circumstances. Careful design and implementation of the rendering code can minimize these issues, but it cannot eliminate them entirely. The only way to reliably solve the problem is to design your drawings so that they don't contain coincident paths. -- Ilmari Karonen

On 06/27/2012 12:31 AM, Achim Flammenkamp wrote: Well, that won't be me, since I can't read Arabic, much less write it. 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. 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. 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. 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

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: