C#编写文本编辑器

将文本行集合Lines清空

设置所有参与分行的元素集合

从前到后的遍历所有的参与分行的元素集合中的所有子元素

若子元素对象为制表符或水平线对象则重新计算它的宽度

若子元素为一个容器对象则调用它的RefreshLine方法

向当前行的元素列表中添加元素，并累计元素的宽度和，若宽度和大于容器显示宽度（我们称为情况1）或者当前元素单独占据一行则取消向当前行添加元素并结束当前行 若当前元素是强制换行的则结束当前行

在结束当前行前，若当前元素不能出现在行尾或者下一个元素不能出现在行首则取消向当前行添加当前元素（这也算情况1）。按照书写惯例，某些字符例

如!),.:;?]}¨·ˇˉ―‖ ”…∶、。〃 〆〈《「『〕〗！＂＇），．：；？］｀｜｝～ 是不能显示在行首，而另外一些字符例如([{· “々〇〉》」〔〖（．［｛ ￥是不能显示在行尾,此外在某些特定的应用中可能还有其他类型的元素也出现这种情况，这些情况需要考虑。为此在基础元素对象类型TextElement中定义了方法 CanBeLineHead 来判断元素对象是否可以出现在行首，定义了方法CanBeLineEnd来判断元素对象是否可以出现在行尾，这样字符元素对象和其他元素对象可以重载这两个方法来进行所需的判断。在进行这样的判断要特别的小心，若容器显示宽度比较小则有可能由于这种判断而导致死循环，因此还需要额外的进行反死循环的判断（当年为了发现这个错误而呕出了几十两血）。

在结束当前行时需要计算文档元素在当前行中的相对位置，若当前行是由于情况1而导致结束的则需要修正元素间距，由于文档行所有元素的宽度和不一定等于容器的显示宽度，因此若没有进行修正则文档的右边缘参差不齐，影响美观，因此需要计算元素宽度和和容器的显示宽度之差，将该宽度差比较均匀的插入到各个文档元素之间，这样文档的右边缘则比较整齐。为了保存这个修正值，在TextElement中新增一个WidthFix属性来保存该值。其实大家可以观察到IE显示文档内容时没有进行右边缘的修正而Word则进行了类似的修正 若当前行是由于最后一个元素强制分行而结束的则无需进行由于情况1而导致的右边缘修正，但计算文档元素位置时需要进行文档对齐方式的修正。首先找到影响当前文本行的段落对象，获得它的对齐方式设置(左对齐，右对齐，居中对齐)，根据对齐方式来计算元素见的空白，然后设置元素的WidthFix属性

此外还需要修正元素在文档行中的顶端坐标，由于同一行的文档元素高度不一定一致，此时需要遍历所有的元素，以最高的元素的高度为文档行的高度，以此计算元素在文档行中的顶端位置，以保证各个元素的低边缘在同一水平线上

结束完毕的行对象添加到容器的Lines文档行集合中，然后创建创建一个文档行对象作为当前行，如此循环直到处理了容器对象所有的内容

产生了所有的文档行对象后根据容器对象的在视图区域中的坐标和文档行的行间距设置来计算文档行在视图区域中的坐标，这样文档行中所有的元素的在视图区域中的坐标就是文档行的坐标和元素在文档行中的相对坐标的和

在修改文档行中元素的位置时，需要获得元素旧的在视图区域中的最小外切矩形数据，然后和重新计算过的最小外切矩形进行比较，若两者不一样则表示元素在视图区域中显示的位置发生改变，将这两个矩形添加到文本编辑器重绘矩形集合中，当文档重新分行完毕后，文本编辑器就将所有的重绘矩形进行加法操作，获得的矩形就是需要重新绘制的区域。如此这样是为了优化显示操作，减少页面闪烁；因为用户修改了文档内容后到而导致的分行只是影响显示区域中一部分，而其他部分虽然重新计算了位置但新旧位置没有差别，因此不需要重新绘制

其实关于分行操作应当还有更优化的方法，但本人能力有限，只能提出这种方法。试验