Comment 7 for bug 481605
Revision history for this message
| Louis Simard (louis-simard-deactivatedaccount) wrote | #7 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
I have a bit more input for this bug.
If the opacity of two overlapping *translucent* figures is the same, the intersection of the two figures will be drawn with more opacity. Scour can't really do anything with that.
The set of circumstances where it would be perfectly safe to combine multiple figures into one is very narrow, and as such I doubt the savings in file size will be that much for most, if not all, files. I think the conditions would look like these:
1. Figures should not have any intervening figures defined in-between in the same container (such as <rect red> <rect green> <rect red>). If there are intervening figures, then the intervening figure must not intersect with the to-be-combined figures.
2. Figures must have either no transformation, or the same simple transformation (translate, skewX, skewY, scale), or two simple transformations that can be expressed in terms of each other (for instance, translate(25) and translate(50), which can both become translate(25) after adding 25 to the second figure's coordinates). This is to ensure that the coordinate system is the same for both.
3. Figures must intersect, or be adjacent.
4. Figures must have no stroke and either no fill or the same solid-color fill. Combining figures with gradients and patterns is troublesome with regards to the bounding box of the gradient or pattern.
5. Figures must have an opacity of 1, or be adjacent (not intersecting) and have any opacity.
6. Figures must not have different CSS classes.
7. Figures must not have IDs referenced in the CSS stylesheet defined with <style>.
8. Intersection calculations must take into account even-odd and non-zero fill/clip rules. Parts of a polygon could end up being "outside" itself if there's an intersection within its own coordinates, so the second figure might end up inside an "outside" region of the first polygon. This needs to be handled correctly.
It looks like the test file in comment 3 would benefit a fair bit, even with that impressive set of conditions. However, neither codedread nor I know where to start for this feature request.