Hi,
AFAIK, we cannot really change the behavior of transparency because it is defined by SVG standard.
I am not a specialist, but my reading of the SVG 1.1 standard is that all input colors are specified in sRGB. The sRGB standard itself, under section "Alpha Channel Masking and Computer Graphics Compatibility", suggests that "effects such as alpha masking be performed either prior to encoding or by decoding to a color resolution greater than 24 bits and then converting into linear intensity space."
Section 14.2 of SVG 1.1 defines the widely known pre-multiplied alpha formulas for alpha blending. That section does not explicitly require the involved colors to be in the non-linear space. Although it is a bit of a stretch, if we were to follow the sRGB standard recommendation, we would convert to linear intensities when the element colors are determined, and convert back to sRGB before the pixel values are written to the frame-buffer or to an image file.
In any case, it does not matter what the standard says. What matters is what people have come to expect from it. I am therefore not suggesting for anything to be changed abruptly. I am just pointing out the issue, and suggesting that it be addressed in the future. I don't know which software is the "de facto" standard for SVG rendering, but I wouldn't be surprised if it is Inkscape. It is therefore suited to lead the effort.
As for antialiasing, we can change it, but it would be very difficult to code because currently, pixel buffers for all objects are combined for the display, and this code cannot know whether a pixel's less-than-one alpha comes from an antialiasing edge or from the object's native transparency. Or even from both.
I know nothing about the internals of Inkscape, so I will take your word for it. It would seem to me, though, that the pre-filtering coverage alpha (geometric: due to proximity with an edge, or a thin stroke) must be obtained independently from the color alpha (explicit: comes from the color server, and could even be pre-multiplied). Given two colors to be blended and a coverage alpha for the one on top, you can derive a blending formula that combines them so that the anti-aliasing part is done in linear space, but the transparency part is done in the non-linear space. This solves the anti-aliasing issues, preserving the current (in my opinion broken) behavior for transparency. This is in fact the compromise I have adopted.
Please see attached files. The "non-linear" version was produced by Inkscape. The "linear" version was produced by the method I described above. Compare them with the "point" version, which uses point sampling, and I hope it is clear which method is more accurate.
Naturally, it would be much cleaner to convert colors to linear space at load time, perform all operations in that space, and convert back to sRGB right before saving each pixel. Perhaps SVG 1.2 could address this issue? I do not know what is the best forum to suggest this.
Kind regards, Diego
