逐步安裝Node.JS並實作SVG Path（文字路徑）產生器
在之前的文章中，我們實現了在瀏覽器端依據我們在網頁中給定的中文字型，繪製出SVG向量路徑在網頁上，讓網頁上某些需要使用特別指定文字的標題，可以突破以往用圖片來表示的困境，開始往無失真的方向移動，無論你的螢幕解析度有多高，顯示出來的文字因為是基於SVG PATH繪圖，所以根本沒有所謂的低解析度模糊之問題。
但，在上述的應用場景下，於Client端實作這樣的功能根本無濟於事，因為高容量的「中文字型」下載到終端根本是一場鬧劇，若可以接受這樣的流量那說真的也不需要SVG的技術來繪製了，直接上WebFont豈不妙哉？
這時候在茫茫NPM大海中我發現了一個叫做text-to-svg的套件，一實驗下去發現這就是我期待中的功能，太妙了啊！
逐步安裝Node.JS
Step 1. 撰寫文章的時刻Node.JS的版本來到12.16.3，可以到下列連結下載Windows x64 LTS Windows Installer安裝檔案：Download the Node.js，點擊安裝程式。
Step 2. 同意授權。
Step 3. 指定安裝目錄，x64版本預設指定到Programs Files目錄。
Step 4. 理論上是全部裝（重點是一定要裝npm套件管理器），但我沒有裝線上文件捷徑。
Step 5. 是否安裝其他必要工具，這邊我是沒有勾選安裝。
Step 6. 按下Install開始安裝。
Step 7. 安裝完成。
Step 8. 安裝完成後其實環境變數Path裡面已經被自動加入node與npm執行檔路徑，因此隨便開個console來跑一下node，觀察完版本號碼後可以輸入「.exit」離開。
利用黑洞級別的npm套件管理器來安裝text-to-svg
Step 1. 利用指令建立GenerateSvgText目錄，並作為基本的App運行目錄後，開始在裡面安裝text-to-svg，請輸入指令：
npm install text-to-svg
Step 2. 經過npm黑洞級別的相依套件安裝後（其實就這個套件來說算還好），你會看到一堆WARN警告的訊息，不用理會這些訊息。若你不想看到這些警告訊息的話，可以先進行下方npm init步驟後再來執行這個步驟，會來的比較正規。
Step 3. 用DIR指令查看這些目錄，可以發現一個叫做「node_modules」的資料夾，這裡面就是所有的text-to-svg依存套件存放的位置。
開始創造text-to-svg運算環境
Step 1. 利用npm init建立專案環境，如此一來可以健全package.json：
Step 2. 下載幾個你自己喜歡的字型，文中為例子是採用Google的「Noto Sans Mono CJK TC Regular.otf」，並創造一個叫做fonts的子資料夾將字型放入其中。
Step 4. 接下來就是撰寫entry point（index.js）的程式碼：
const cText = process.argv.slice(2)[0];
const cFontPathAndName = __dirname + "/fonts/Noto Sans Mono CJK TC Regular.otf";
const oOptions = {
fontSize: 100,
anchor: "left top"
};
const oSVG = require("text-to-svg");
const oInstance = oSVG.loadSync(cFontPathAndName);
console.log(oInstance.getSVG(cText, oOptions));
P.S 這邊的程式碼你完全都要遵守node.js的規範與函式，這裡的範例只是隨便亂實作一下，事實上text-to-svg還有提供很多的參數可以帶入產生不同的效果，請自行上網查閱：Text-To-Svg API
Step 5. 撰寫完後馬上來試一下，可以看到已經有產生出向量文字路徑了。
Step 6. 直接輸出轉向到「svg.html」檔案。
Step 7. 在瀏覽器中檢視的效果，可以正確的產生出向量文字路徑。
成果展示
以下就是svg.html真實輸出的向量文字，可以直接看網頁的原始碼就可以知道效果。要知道下面這段SVG向量文字的產生已經拋棄掉Client瀏覽器端下載肥大的中文字型檔案的架構嘍！你可以試著把網頁畫面直接放到，依然可以看到無鋸齒失真的文字。
後記
在前一篇的文章中我就有提到希望把功能搬回.NET Server端環境上面，但這篇文章跟伺服器端的ASP.NET或C#有何關係？這是node.js啊？
當然有關係啊，別忘了我們是在Windows Console下利用Node.JS運行V8引擎起來跑這段程式碼，這意味著我們可以利用Console模式的輸出來達到結果的產生，接下來只是擷取與傳遞的過程了不是嗎？但特別要叮嚀各位朋友，V8引擎每次的生成與毀滅雖然速度快，但耗費的CPU與記憶體也是非常可觀的，建議真實的設計上要加入Cache機制，不要去進行重複的運算為佳。
npm我稱為黑洞級別算是客氣了，可參考這張在程式設計界之間流傳的圖就知道所言不假：
相關參考文章：