按照Windows的標準處理一個純文字檔案有令人難以想象的複雜度，尤其是打開了自動換行的情況下：

識別編碼並轉化為Unicode按換行符將文字拆分成行，每行當作一個段落處理按照Unicode語義分析文字，將文字按照不同語言分拆成從左到右和從右到左的段。這一步是比較複雜的，某些語言在字串當中是abcdefg的順序，但顯示的時候必須從右到左顯示為gfedcba，但是如果再中間換了行，比如在d的後面換行，又要變成dcba \n gfe……而且，按照規範，從左到右的文字中可以嵌入從右到左的文字，從右到左的文字又能嵌入從左到右的文字，這個嵌入還是可以巢狀的，比如最外層是從左到右，裡面有一段文字是從右到左，這個從右到左的文字裡面又嵌入了從左到右的詞……將每個從左到右或者從右到左的段進一步進行語義分析，找出：字元邊界（部分連續的多個Unicode字元是不可拆分的，比如字元與上面的注音符號，選擇文字的時候只能選到字元邊界，不能選進字元裡）；可以換行的斷點；可以分詞的斷點（在編輯器中雙擊一個字元會選中詞，對英文就是按空格，對中文一般就是選中單字）；定寬的空格；不定寬的空格等等。這個過程對不同的語言有完全不同的處理方式，需要按照字元選擇相應語言的處理方法。嘗試將文字轉換為符號（Glyphs）。Unicode字元到符號的對映並不是一一對應的，對於某些語言來說，字元的上下文會影響字元的顯示，讓字元顯示為完全不同的樣子；符號的排布並不是簡單的從左到右按順序，某些字元需要在之前字元的基礎上調整位置（比如上下標，注音符號，還有泰語裡面那個會飛出去的字元）從右到左的文字也會有影響，在處理時會將符號逆序，統一處理成從左往右。 這一步對於自動換行的程式來說要更復雜一些，不過事實上所有的文字編輯器都自動換行，區別只是開啟自動換行的時候換行按照當前視口的寬度，而關閉的時候按照一個固定的最大寬度（你可以嘗試在記事本里面輸入非常多的字元，你會發現最終還是換行了的）。對於自動換行的程式來說，不能一次性轉換成符號然後判斷寬度，因為不同的輸入內容可能導致不同的符號輸出，而且混排從右到左和從左到右的情況下，換行會導致符號順序發生嚴重的變化，因此唯一可靠的方法是按照前一步找出的所有可以換行的斷點分別嘗試，直到得到的符號總寬度超過行寬為止。在前一個斷點將文字拆開換行。如果第一個可以換行的斷點就超出寬度了，還需要再嘗試從詞或者字的邊界換行。處理對齊。文字顯示有左對齊、右對齊、中間對齊、兩端對齊四種主流的方式，如果最外層文字從右到左顯示一般基礎是右對齊，否則是左對齊，內部嵌入的文字不影響對齊方式。前三種相對處理起來容易，兩端對齊就要用到前面計算出的定寬空格和不定寬空格的問題了：在某些語言中，某些空格必須是固定的寬度，不能變得更寬，而某些空格允許在兩端對齊的時候增加寬度，在兩端對齊的時候，必須只加寬那些可以變寬的空格，而不加寬那些不能變寬的空格。渲染文字。按照符號和字型，將字型裡的圖畫出來，變成影象。字型可能按不同字號有不同的繪製方法，還有抗鋸齒、ClearType等處理，不再細說。計算行高。相對簡單，一般按照字型、字號折算一下就行了。

即便如此，我們還是有必要指出：對於現代的文字編輯器，即使是Windows 10的記事本，也能瞬間開啟一個幾兆的文字檔案，這主要還是演算法最佳化的效果，以前舊版本總是會嘗試一次把所有的文字都渲染出來，自然就比較慢。而且以前的GDI介面也比較慢。