See http://community.sharpdevelop.net/forums/t/14176.aspx
Tab markers now report a size one pixel smaller than the tab glyph.
The problem was that if the tab glyph already advanced to (or over) the next multiple of the indentation size, the normal tab character advanced the rendering position a second time. This always happened if the IndentationSize was 1, but it could also happen in some other cases, for example when IndentationSize=4 and Text="aaa\t".
The issue is complicated by proportional fonts: there, a tab can be very small (maybe only a single pixel) if there is text in front of the tab that almost reaches the next tab position. In this case, we have only two choices: make the tab larger than it would be without the tab glyph, or have the tab glyph overlap with the next character after the tab. (a third choice would be not to draw or clip the tab glyph if there's not enough room, but that's difficult to do with the WPF text layout engine)
This fix makes the TabGlyphRun report a size one pixel smaller than the actual width of the glyph. This way the invisible tab character can fit in that one-pixel gap, which fixes the issue for monospaced fonts. But if there isn't enough room for the tab glyph (as can happen with proportional fonts), the tab will still be larger than it should be.
When the last line in the document was collapsed, the method HeightTree.GetNodeByVisualPosition(position after end of document)
was returning the last line in the document, when it should have returned the last non-collapsed line.
Also fixed a minor bug in FoldingMargin (missing end marker when folding starts above viewport and ends on last line of document).
This was caused by the optimization that moved the text from the AE TextLayer to separate DrawingVisual controls:
Hit testing was disabled for the TextLayer, but we forgot to disable hit-testing for the DrawingVisuals
Daniel Grunwald
Siegfried Pammer
Matt Ward