This bug may have resulted from the fix to bug 1054. It started around the same time. DESCRIPTION: There are rounding problems on dashed and dotted borders. One edge ends up a little inside the ends of the sides that meet it. That is, the borders look like this (exaggerating greatly, since the errors are 1px): -------| ----- | | | | | | | STEPS TO REPRODUCE: * load http://www.w3.org/Style/CSS/Test/current/sec5517.htm ACTUAL RESULTS: * rounding problems. screenshot to be attached EXPECTED RESULTS: * no rounding problems DOES NOT WORK CORRECTLY ON: * Linux, apprunner, 1999-11-22-08-M12 WORKS CORRECTLY ON: * older builds, *I think*

The screenshot shows problems on * the right edge of the second-to-last (eleventh) and last (twelfth) paragraphs * the bottom edge of the first and second-to-last (eleventh) paragraphs

See also bug 19963.

This is part of layout, or CSS rendering, I'd guess.

It looks as if the bug occurs just inside of tables, my regression test work just fine on all platforms.. I will have to create some tests that duplicate this problem.. the test case included with this bug has way to many things going on to be helpful. It would be nice to have an isolated example for a specific bug. Also, is this a Linux bug only, which makes it a GFX bug.. or does it happen on all platforms. Knowing if it does happen on older builds does help, the -- "I Think" part does not help.. I will research these questions.

In the test case I just attached, the DIVs along the top all have the same top, and are successively taller by 0.05pt (1 twip). The DIVs along the left all have the same left, and are successively wider by 0.05pt (1 twip). This shows that the problems are with rounding, and don't have anything to do with tables. It's just the test cases inside the table end up rounded at different points because they're offset by the table's border width and cell padding.

And I forgot to mention that I see the problem along the bottom edge for some of the ones along the top (for me, the first 8 and the 8 separated by four from the end) and along the right edge for the ones along the left (for me, the 8 separated by 8 from the end). Which ones you see it for probably depends on your logical resolution. (I realize I may not have included enough along the left.)

The problems in attachment 3440 [details] first appeared in Linux viewer between the builds of 1999-11-02-12-M11 and 1999-11-04-08-M11. There was a significant change in how dashed borders were drawn between those builds. This means I think the problems were introduced in version 3.80 of nsCSSRendering.cpp, which was overall an improvement to these borders, except it caused this bug.

Thank you for all the input.. this will help out a Ton is solving this one!!!

Fixed the translation matrix, I had to add an error amount to the calculated width and height of the transform. This is because x0,y0 are transformed first and rounded. The width and height were then calculated and rounded. This rounding would take off some fractional part that was needed to calculate the x1,y1. So I calculated an error and added this amount to the width and height before rounding. I also made a speadsheet to prove and understand these errors. I will look at all the routines in the nsTransform class for this kind of error.

Fixed transformation matrix. The height and width did not include the a rounding error that can be introduced. An error is now built into the Transform to prevent such errors.

Verified. Worksforme.