改編協調伺服器之開發

本設計將強調三個主情境感知資訊(Context Aware Information)來幫改 編協調伺服器(Adaptation Server)裡的主要轉譯協調模組提供必備的資訊:

z 內容版型資訊(Content layout information)

這裡會研究探討Layout 的影響因素如下：

1. 字形大小 2. 文字數目 3. 文具段落 4. 圖片大小 5. 影片大小

6. 以及各個多媒體物件位置座標 7. 裝置螢幕大小

為了使用者瀏覽方便，我們必須將Layout 作協調，我們底下以樣板式多媒 體英文試題為例：

圖 8：多媒體英文試題在 PC 及 PDA 上的畫面

圖8 的左邊是一個在 PC 環境瀏覽的樣板式多媒體英文試題，如果透過 PDA 原封不動的下載此內容，呈現結果將如右邊所示。可以看到陰影部分是使用者目 前沒辦法看到的部分，陰影部分必須藉由PDA 上的 Scrollbar 來拖曳才能使內 容呈現在PDA 螢幕上。但是如果我們將版型經過協調後，呈現的模式可以如下 圖9 所示，我們可以看到原本一個頁面的內容被我們分成三個頁面來顯示，而 每個頁面是由這份多媒體文件裡的相關多媒體物件來組成，也就是根據內容語意 (Content Semantics)來劃分。如本例來說是分成三個段落-“Stimulus” 、

“Question” 、“Answer”。而各個頁面是以超鏈結(hyper-link)來作切換。

圖 9：多媒體英文試題協調後在 PDA 上的畫面

z 裝置能力資訊(Device capability information)

依據裝置支援程度，多媒體物件必須轉換，轉換內容包括下列幾種：

1. 圖片大小縮放、格式轉換 2. 聲音格式轉換

3. 影片大小縮放、格式轉換 4. 腳本劇情描述格式轉換

z 空間和時間資訊(Spatial and Temporal information)

這裡會考慮到時間跟空間的衡量，而延伸出來不同轉換方式-靜態(static) 和動態(dynamic)轉換。我們可以先分析一個例子的數據如下表 3：

表 3:各種多媒體轉換所花費時間

從上表可以看出花最多的時間在於聲音及影片的轉換，因此我們可以將轉換時間

比較長的多媒體物件(Sound 、Video)以靜態方式事先轉換完成，而其他多媒 體物件(Image 、Text、 Layout)則以動態方式轉換完成。這樣一來可以降低 傳統用動態轉換過程時間，並可減少一般傳統用靜態方式的空間成本。這是本研 究將提出的靜態加動態的混和轉換存取方式。

改編協調伺服器(Adaptation Server)主系統詳細架構可以如下圖 10 所示，主 要由三個子模組所構成：

圖 10: Adaptation server 詳細內部架構圖

z 描述檔剖析器(Script parser):

此模組解譯來自未改編協調的內容伺服器(Server for Content without adaptation)資料庫裡的多媒體內容描述檔，描述檔由本實驗 室開發的一套多媒體編輯工具產生。解譯完的資訊我們會把他存在一個 資料結構裡，以提供轉換引擎(Conversion engine)作分析。

z 協調引擎(Negotiation engine):

此模組主要的目的是接受來自描述檔剖析器(Script parser)的劇情描 述資訊，並接受由應用端(Application Layer)傳來的各項參數，進行 分析協調的動作。過程會先經由分析(Analysis)、暫時轉譯(Temporal translation)、推薦選擇(Recommended choice)，然後將協調後的 資訊寫回劇情描述資料結構裡。過程中會依照參數的指定將多媒體物件

(Audio、Video、Image)轉換成相對的格式或改變大小。

z 目標模組(Target module):

最後我們要將已經協調完的劇情資訊寫回相對應的多媒體內容呈現描 述檔格式，這裡的腳本描述格式以XML Based 的為主。

而為了滿足應用端程式的需求，改編協調伺服器(Adaptation Server)可以額外 做包裝的工作。以多媒體英文試題試卷來說，還必須提供將試卷壓縮後，並上傳 至已改編協調的內容伺服器(Server for adapted content)的功能，當然這裡 必須搭配應用端的互動協定。