--- a/yuu-jssst.tex	Mon Aug 08 19:31:56 2011 +0900
+++ b/yuu-jssst.tex	Mon Aug 08 19:35:51 2011 +0900
@@ -126,21 +126,21 @@
 
 
 \section{java.util.zip.deflaterのバグ}
-VNCで扱うRfb Protocolには、使えるエンコーディングのタイプとしてZRLEエンコードがある。
-ZRLEエンコードはZlib圧縮されたデータを内包する。
+VNCで扱うRfb Protocolには、使えるエンコーディングのタイプとしてZRLE(Zlib Run-Length Encoding)がある。
+ZRLEはZlib圧縮されたデータを内包する。
 deflaterはプリセット辞書をもち、Zlib圧縮されたデータはその辞書を用いて解凍が行われる。
 辞書はで更新されることもあるのでZlib圧縮されたデータを解凍する為には辞書のデータも受け取る必要がある。
 しかし、JavaにはこのZlibの辞書を相手へ書きだす(flush)する機能が無い。
 元々のZlibの規約にはこの辞書をflushする機能があったがJavaには実装されていなかった。
-これはJava。util。zop。deflaterのバグである。
+これはJava.util.zip.deflaterのバグである。
 
 
-\section{ZRLEEエンコード}
+\section{ZRLEE}
 そこで、Top ProxyがZRLE(Zlib)で受け取ったデータをunzipし、データをzipし直して最後にfinish()
 をいれることで初めからデータを読んでいなくても解凍を行えるようにした。
 このエンコードはZRLEEエンコードと定義した。
 一度ZRLEEエンコードに変換してしまえば、そのデータをそのまま流すだけで良い。
-よって変換はProxyが行う一回だけですむ。
+よって変換はTop Proxyが行う一回だけですむ。
 ただし、deflaterでは前回までの通信で得た辞書をクリアしないといけないため、Client側では毎回
 deflaterは新しいものを使うことになる。
 ZRLEEはクライアント側が対応していなければならないという問題がある。
@@ -151,7 +151,6 @@
 
 
 
-
 \begin{figure}[tb]
 \begin{center}
 \scalebox{0.5}{\includegraphics{fig/compare_encoding.eps}}