針對查詢「符號」依關聯性排序顯示文章。依日期排序 顯示所有文章
針對查詢「符號」依關聯性排序顯示文章。依日期排序 顯示所有文章

2008年4月29日 星期二

Word 鍵入 = = > 無法自動改成 粗箭頭BoldArrows 怎麼辦?

步驟1:開啟Word
步驟2:主選單選擇
插入(I) | 符號(S) | 開啟”符號”視窗 | 符號(S)頁面 | 字型(F) 下拉 Wingdings字型

即可找到粗箭頭符號(即十進位 232 或 符號十六進位00E8),先複製起來

步驟3: 工具(T) | 自動校正選項(A) | 開啟”自動檢正”視窗 | “自動校正”頁面
取代
(R)欄 鍵入 ==> (兩個等號及大於符號)
成為
(W)欄,將剛才粗箭頭符號複製並貼在此處(即剛才步驟2動作)

相關應用:

  1. 可自行加入常用打勾符號,設定atcheckmark 系統自動換成 “打勾”符號 (即十進位252 或 Unicode十六進位221A)
  2. 設定atcheckmarkbox 系統自動換成 “打勾方塊”符號(即十進位254)
  3. 設定atsentmail(指定Webdings網頁相關符號字型之郵件圖示)

2024年8月21日 星期三

一鍵完成PROMPT提示詞整合處理,免除打字處理(PYTHON程式)

情境:常使用的日文查詢PROMPT,只要使用Ctrl+C預先拷貝好後,再點選此編譯好的程式後(預先指定好(右鍵|內容|快速鍵(K))執行之快捷鍵,如:自訂Ctrl+Alt+J,將此程式叫出來),即可將剛才能載入記憶體的複製字串,直接寫入提示詞內


💜程式片段說明一:

以下為  testjlptRel01 , (即 input_file1 = r'd:\testjlptRel01.txt') ,請預先用Notepad記事本,將下面藍色部分提示詞貼上,檔名儲存至 d:\testjlptRel01.txt

あなたは日本語のプロで、勉強法の達人です。
{{関連表現}}の語源は教えて、漢字ははっきりとはしないが、省略しても構いません。
{{関連表現}}の文法解説・例文と類義語を簡潔な概要でまとめてください。
もし、その表現はニュアンス、意志、自発、あるいは自分、他の人、その他の表現などに関連があれば、使い方を教えて
暗記しやすいように、その他の類義表現文型と違いところを表形式に挙げてください。
それぞれの表現に焦点を当てたYOUTUBE動画を挙げてください

"""
関連表現:


    
💜程式片段說明二:
# input_file2內容為     """  

 
# 為何要另外加入input_file2.txt , 再補上 """ (三重引用符號),讓AI能夠將它視為整段完整之PROMPT提問文  (亦即,前段日文詢問之PROMPT + OCR辨識後之TXT +最後再補上  三重引用符號)


💜程式片段說明三:
# output_file內容為  d:\testjlpt.txt   ,最後在d槽 ,testjlpt.txt 可查看到完整提示詞資訊,再將此內容貼至 AI神器去詢問


💜程式片段說明四:  (程式功能處理流程)
☺💜從剪貼簿獲取文字。  (即  pyperclip.paste() 獲取剪貼簿中的文字。 將您將想查詢的特定日文字詞,用COPY+C 快速鍵,複製後,對電腦而言已暫存至記憶體起來 ,而透過PYTHON之pyperclip模組,來 獲取剪貼簿中的文字(等同您 手動按 Win+ V ,而此程式自動化幫您處理)。

☺💜將剪貼簿中的文字與指定兩個檔案的內容,按照特定順序合併。  

運行順序1 載入 日文關連式提示詞 ;

運行順序2 載入 想查日文字詞  之已內存記憶體剪貼簿內容 ;

運行順序3 再補上 """ (三重引用符號) ;


運行順序4 將合併後的內容寫入一個新的檔案中。    (即   output_file = r'd:\testjlpt.txt'  )
 

💜將PYTHON程式轉成EXE執行檔(最後一個處理程式步驟)

auto-py-to-exe 轉換PY程式成為EXE

 

💜相關應用參考資訊:
活用 Win視窗鍵+V ,選擇性貼上之功能視窗(記憶體內存剪貼簿)

一鍵完成圖檔OCR辦識,免除打字處理

     
💜完整PYTHON程式如下    

import pyperclip
import subprocess
import os
def append_file_content_in_order(input_file1, input_file2, content_to_append, output_file):
    """將指定內容和兩個檔案的內容按照指定順序追加到檔案末尾。"""
    try:
        with open(output_file, 'w', encoding='utf-8') as f_out, \
                 open(input_file1, 'r', encoding='utf-8') as f_in1, \
                 open(input_file2, 'r', encoding='utf-8') as f_in2:
            f_out.write(f_in1.read())  # 先寫入 input_file1
            f_out.write("\n\n" + content_to_append)  # 再寫入剪貼簿內容
            f_out.write("\n\n" + f_in2.read())  # 最後寫入 input_file2 内容 (即補上  """  三重引用符號 ,做為結尾)
        print(f"已成功將結果寫入 {output_file}")
    except FileNotFoundError as e:
        print(f"Error: 檔案不存在 - {e.filename}")
    except Exception as e:
        print(f"Error: 發生錯誤 - {e}")
if __name__ == "__main__":
    input_file1 = r'd:\testjlptRel01.txt'
    input_file2 = r'd:\testjlptRel02.txt'
    output_file = r'd:\testjlpt.txt'
    clipboard_text = pyperclip.paste()
    append_file_content_in_order(input_file1, input_file2, clipboard_text, output_file)
    subprocess.Popen(['explorer', output_file])         # 將產出最新檔案,直接開啟,方便後續貼至AI神器查詢

 

2008年4月30日 星期三

ALT+NUM 特殊字元

ALT鍵搭配輸入255,可讓該字元不會顯示在螢幕上,乍看好像變成空白

ALT 255 空白
ALT 247 除號 ÷
ALT 190 四分之三 ¾
ALT 189 二分之一 ½
ALT 188 四分之一 ¼
ALT 177 加減符號 ±
ALT 174 已註冊符號 ®
ALT 169 版權符號 ©
ALT 165 日元YEN ¥
ALT 148 右雙引號 ”
ALT 147 左雙引號 “
ALT 146 右單引號 ’
ALT 145 左單引號 ‘
ALT 132 下雙引號 „
ALT 128 歐元EU €

更多的字元顯示查詢
其它特殊字元查詢

(N年前使用PE2畫格線常用)
ALT 150 格線 –
ALT 151 格線 —

2026年9月30日 星期三

MINDMAP心智圖,製圖轉譯流程

情境:因為心智圖MINDMAP產製時,經常性噴出Synctax Error語法錯誤圖檔,爰請AGY CLI神器協助筆者預訂 4K Ultra-HD (3840 x 2160) 出圖品質基準線,進行語法錯誤RCA根因問題拆解。(元凶:Mermaid Mindmap 的 Lexer 遇到未脫逸的運算子(||, *, /, =, +, ())會將 Token 暴力切斷,導致語法樹(AST)瓦解。)。

📌 一、 MMD (Mermaid) 與 Playwright 的渲染物理機制與轉譯管線Mermaid Markdown Diagram (MMD) 是一種基於純文字的領域專用語言 (DSL)。其底層是一串結構化的文字抽象語法樹 (AST)。在 Node.js 與 Playwright 運作環境中,轉譯過程如下:
管線階段 輸入資產 (Input) 處理引擎 (Engine) 輸出結構 (Output) 物理狀態 / 數據規格
1. 語法解析 *.mmd 純文字檔 Mermaid 10.9.0 Parser,讀取 MMD 文字檔,經由語法分析器建立 DSL 抽象語法樹 (AST) DSL AST (抽象語法樹) 純文字 DSL 自動脫逸與語法檢核
2. 向量 DOM 構建 DSL AST Playwright (Chromium),在無頭瀏覽器內構建 3840×2160 SVG 向量樹。 SVG Vector DOM 向量結構 3840×2160 ViewBox 對位
3. 點陣化 (Rasterize) SVG Vector DOM Skia Graphics Engine,將 SVG 向量元素轉譯為實體像素點陣。 Physical Pixel Grid 實體矩陣 8,294,400 物理像素 (24bit RGB)
4. 4K 編碼與驗證 Pixel Grid PIL / JPEG Encoder,JPEG 編碼器封裝產出 4K JPEG File 3840×2160 @ 300DPI ~729 KB (400KB~2.5MB)

1. 語法解析 (Lexing & Parsing):Playwright 透過 Chromium 實體驅動載入 mermaid.min.js。解析器讀入 MMD 文字進行詞法與語法分析,構建內部 AST 節點樹。

2. DOM / SVG 構建 (Vector)

Mermaid 將 AST 節點轉譯為 HTML5 / SVG 元素(如 <g>, <rect>, <text>),產出無損向量 DOM。

3. 無損點陣化 (Rasterization)

Chromium 底層的 Skia 繪圖引擎 接收 DOM/SVG 結構,依據 Viewport (3840x2160) 佈局,將向量公式渲染至實體像素記憶體。

🚨 二、 致命語法毒素分析:Mermaid 10.9.0 Mindmap 結構崩塌真相 (RCA)

過去對圖像容量的單純物理判定存在陷阱(如:圖檔大小判定合格否?):若僅靠調高背景幾何網格 (Mesh Grid) 將 JPEG 實體檔案推高至 1.85 MB,**但底層 MMD 語法含有中斷 Token,Chromium 仍會渲染出包含紅色警告的 Syntax Error 圖檔。

🔍 致命語法毒素定位 (Discovered Poison Tokens)

在 Mermaid mindmap 語法中,即便文字外層包裹雙引號 "",Parser 遇到 ||, *, /, =, + 等算式符號仍會強制將 Token 切斷,導致 AST 語法樹崩塌: 

  • 致命範例:"占比差乘對數比值 SUM (q_i - p_i) * ln(q_i / p_i)" (未脫逸的 -, *, /, ())
  • 致命範例:"D_KL(P||Q) = SUM P(x) * ln(P(x)/Q(x))" (未脫逸的 ||, =, *, /)
  • 致命範例:"D_JS = 0.5*D_KL(P||M) + 0.5*D_KL(Q||M)" (未脫逸的 +, *, ||)
  • 致命範例:"占比差乘對數比值 SUM (q_i - p_i) * ln(q_i / p_i)"
      • 崩塌原因:斜線 / 在未脫逸狀態下,被 HTML/XML 標籤解析器切斷,若結合 <br/> 更會造成 <br/> 語法壞死;乘號 * 觸發 Markdown 解析器斜體標籤判定;小括號 () 被判定為圓角節點語法。      
      • 科學對位解法:經由 sanitize_text() 保護 <br/> 並轉換為 占比差乘對數比值 SUM (q_i - p_i) * ln(q_i / p_i),AST 解析 100% 成功。
  • 致命範例:"D_KL(P||Q) = SUM P(x) * ln(P(x)/Q(x))"
      • 崩塌原因:雙豎線 || 在 Lexer 階段被誤判為表格邊界或豎線節點標記;等於符號 = 誤導 Key-Value 解析器。
      • 科學對位解法:轉換為 D_KL(P||Q) = SUM P(x) * ln(P(x)/Q(x)),成功保留數學表達式語意且解開 Token 鎖死。

  • 致命範例:"D_JS = 0.5*D_KL(P||M) + 0.5*D_KL(Q||M)"
      • 崩塌原因:加號 + 與 * 觸發 Mermaid 內置表達式求值器 (Expression Evaluator) 的截斷行為。
      • 科學對位解法:轉換為 D_JS = 0.5*D_KL(P||M) + 0.5*D_KL(Q||M)。

💢 
防呆除處理了基本的 HTML 特殊符號外,尚有部分關鍵細節仍需注意(如下):
      💟<br/> 標籤被盲目替換:原本全域將 / 替換為 / 導致 <br/> 變成 <br/>,語法樹崩塌。
      💟 Flowchart 行內 Class 語法破壞:包含雙引號節點尾綴 ::: className 導致 AST token 錯誤。
      💟 Node ID 與中括號間之空格:NodeID ["Text"] 的空格引發語法樹節點標記破壞。
      💟mm2jpeg_core.py 淨化器是否破壞 HTML 標籤(如 </b> 變 </b>)導致 DOM 出現 Syntax Error  ?  在 Playwright 渲染頁面中增加了 DOM 級別的 Fail-Closed 吹哨檢查,防止帶有語法警告框的 SVG 被存成 JPEG。

✅ 根本修復與防禦規範 (AST Pre-Sanitization Protocol):
必須將 MMD 節點中的所有算式運算子進行純文字化或 Lexer 脫逸轉換(例如將 P||Q 改為 PQ,將 = 改為 等於),方能保證無頭瀏覽器 SVG 樹 100% 正確展開,徹底防範門檻虛設之陷阱。

📐 三、 4K Ultra-HD (3840x2160) 與 JPEG 容量之物理對位

1. 實體像素網格 (3840 × 2160)

  • 代表圖片在記憶體中的絕對純量像素點數量。
  • 總像素數 像素(約 830 萬像素)。
  • 在 24-bit RGB 未壓縮狀態下,記憶體原生大小為:
    8,294,400 × 3 Bytes ≈ 24.88 MB
為了防止 4K  圖片發生過度壓縮、糊焦或渲染出空白/破碎畫布而設立的「粗暴下限」;但當底層移除了黑箱人造高頻噪訊、改採向量字元與純色背景自然收斂時  ,高壓縮比的
  4K 流程圖產生 ~729 KB  是符合資訊熵的正常現象,硬塞噪訊充體積反而違背架構整潔。要徹底解決此衝突且兼顧管線安全,評估增加調整校驗邏輯:從「硬編碼大小」轉為「動態維度結合雙重指標」不要依賴單一的 file_size >= 800 * 1024,應改為「解析度保證 +  最小有效資訊量 + 品質因子」複合檢查:Python# 建議之驗證邏輯重構範例 (integrity_checker / sentinel)
  def verify_4k_image(filepath, min_dimension=(3840, 2160)):
      from PIL import Image
      import os
      size_bytes = os.path.getsize(filepath)
      with Image.open(filepath) as img:
          w, h = img.size
          # 1. 物理維度硬性門檻 (確保不是低解析度偷跑)
          if (w, h) != min_dimension:
              return False, f"Resolution mismatch: {w}x{h}"
      # 彈性安全邊界:
      # 流程圖/向量簡報類 (大面積純色 + 文字) 自然收斂下限可放寬至 500KB ~ 600KB;
      # 真正損壞或空白圖多半落於 < 200KB。
      if size_bytes < 500 * 1024:
          return False, f"Abnormally small 4K payload ({size_bytes} bytes), likely blank canvas."
      return True, "PASS"

📈 四、 DCT 頻域物理學:為何 4K 容量約落在 800 KB ~ 2.5 MB?

💟JPEG 採用 離散餘弦變換 (DCT, Discrete Cosine Transform) 壓縮演算法,將 空間域像素區塊轉換為頻率訊號 (Frequency Domain)。

💟JPEG 容量 (Size) ∝ 圖像高頻訊號能量 (Edges/Text) × 品質因子 (Quality=100) × 色度採樣 (Subsampling=0)

💟當執行「去白邊裁切與 90%+ 滿格貼合」後,在 3840×2160 4K UHD @ 300 DPI (JPEG Quality 92-95)  條件下,文字與線條的資訊熵 (Entropy) 自然產出的物理檔案大小就會精確落在 800 KB ~ 2.5 MB 之間。

🟣【情況 A:未修復毒素之 Syntax Error 圖檔】

  • 現象:純色背景 + 中央一小塊紅字告示(或靠背景網格硬擠容量)。
  • 物理機制:核心文字圖表未展開,內容高頻訊號極度匱乏。
  • 結論:若未配合 AST 淨化,單靠容量指標會產生偽合格 ❌

🟣【情況 B:AST 淨化後 100% 完整渲染 4K 心智圖】

  • 現象:多階層彩色高對比方塊、繁體中文字邊緣、高密度無瑕連線。
  • 物理機制:AST 完全展開,圖像充斥豐富高頻邊緣跳變訊號。
  • 壓縮結果:實體容量達到 2.66 MB (實測 2,728,246 Bytes) ✅

⚡ 五、 Playwright 底層架構與 Python 雙模 API (sync vs. async) 封裝

Python 應用層 

          ▼                                                                                
▼

API
from playwright.sync_api import sync_playwright

(同步阻塞模式 / 命令式腳本)                   
from playwright.async_api import async_playwright
(非阻塞異步模式 / asyncio)
Playwright Node.js                                   / C++ Driver Pipe
                                     
▼  
Chrome DevTools Protocol (CDP)
                                     
▼
Chromium    / WebKit / Firefox Engine

1. 架構起源

Playwright 原生由 Microsoft 以 Node.js / TypeScript 開發。Node.js 底層為單線程事件迴圈 (Single-threaded Event Loop),CDP 通訊預設皆為非阻塞異步 (async/await / Promise)。

2. Python 雙模 API 封裝

async_playwright():原生對接 Python asyncio 事件迴圈。
sync_playwright():內部封裝 Event Loop 循環器,將 CDP 通訊轉為同步阻塞呼叫 (Synchronous Blocking Call),適合 CI/CD 線性自動化。

📊 六、 系統審計總結表(Summary Table)

檢驗維度 / 核心概念 物理 / 代數定義 實體參數與對位指標 科學對位意義與判定依據
AST 毒素淨化防禦 移除算式符號 (||, *, /, =, +) 防止 Token 截斷 MMD Lexer Pre-Sanitization 徹底排除 Syntax Error,防止容量指標盲區
MMD / Mermaid 轉譯 抽象語法樹 (AST) 轉 SVG 向量 DOM Node.js + Playwright (Chromium Skia) 純文字 DSL 轉化為無損幾何向量,確保無限放大不失真
4K Ultra-HD 實體像素 空間純量矩陣 3840 × 2160 × 3 Bytes 830 萬像素,未壓縮記憶體原生佔用 24.88 MB

JPEG DCT 頻域容量 (Size) 頻域 DCT 高頻 AC 係數能量加總 Quality=100, Subsa

mpling=0
淨化後實測 2.66 MB ≥ 800 KB,證實圖表完整展開且高頻邊緣豐富
Playwright Sync API 內部包裝 Event Loop 之阻塞式 API from playwright.sync_api import sync_playwright 簡化 Python 腳本架構,確保多圖檔渲染流程順序性與執行緒安全

🌟下面為Playwright補充說明:

  1. 語法與 API 命名分析:

      • 函式與模組名稱:playwright.sync_api 中的 sync_playwright()。

      • 語法對照名稱:playwright.async_api 中的 async_playwright()。

  2. Playwright 底層架構與語言起源:

      • Playwright 原生由 Microsoft 開發於 Node.js / JavaScript (TypeScript) 環境。

      • JavaScript/Node.js 底層為單線程事件迴圈 (Single-threaded Event Loop),所有 I/O(包含 Chrome

      DevTools Protocol 通訊)預設皆為非阻塞異步 (Asynchronous / async/await / Promise)。

  3. Python 語言 API 封裝實體:

      • Python 版本 Playwright 同時提供兩套 API 進入點:

          • from playwright.sync_api import sync_playwright

          • from playwright.async_api import async_playwright

      • 在 sync_playwright() 模式下,執行程式碼不需要寫 async def 與 await 關鍵字,呼叫 API(如 page.goto()、page.screenshot())時為同步阻塞(Synchronous Call)。

sync_playwright() In-Memory 記憶體原生渲染

💜Domain Context (領域背景)

在自動化繪圖與系統架構中,將 Markdown 心智圖 (MMD) 轉化為 4K 實體圖檔,sync_playwright() In-Memory (記憶體原生同步渲染) 是現代 MLOps 與自動化出版的黃金解決方案。它直接在 Python 進程記憶體內,透過 CDP (Chrome DevTools Protocol) 通訊協定控制無頭瀏覽器 (Headless Chromium),完成「MMD 文字 → SVG 向量網格 → 3840x2160 實體像素」的極速轉譯。

💜傳統 Shell mmdc 痛點 vs. In-Memory 解決機制

💟傳統 Shell mmdc 四大痛點

  1. 進程開銷:每一次呼叫都要在 OS 重新啟動 Node.js,造成 2~5 秒冷啟動延遲。
  2. 縮放干涉:外部 CLI 預設開啟 useMaxWidth: true,強制壓縮 4K 超高解析度致字體模糊。
  3. CSS 注入阻斷:無法注入自訂 CSS(如 paint-order: stroke fill)。
  4. 進程死鎖:高併發時容易產生 Zombie Process,無法實施記憶體自動回收。

💟 In-Memory 三大解決機制

  1. 記憶體 DOM 構建:不寫入硬碟臨時 HTML,直接在記憶體組合 HTML 字串秒速注入。
  2. 鎖定 Viewport 空間幾何:強設 width: 3840, height: 2160 。
  3. 直通二進位流:page.screenshot() 直接在記憶體傳回 Byte Array,零硬碟磨損。

💜 Mathematical Detoxification (數學解毒)

1. 記憶體原生 I/O 效率導出

T_shell = T_fork + T_node_init + T_parse + T_render + T_disk_write
T_in_memory = T_parse + T_render + T_stream_read

T_in_memory ≈ 0.25 * T_shell (效能提升 4 倍以上!(Browser Pool / Persistent Context,只在記憶體中建立新 page(In-memory Page Lifecycle))

2. 實體 4K 像素總量與容量

N_pixels = 3840 * 2160 = 8,294,400 像素 (830 萬點)
記憶體原生 RGB 網格大小 = 8,294,400 * 3 Bytes = 24.88 MB

JPEG Q=98 無損色度採樣容量 = 1.2 MB ~ 2.5 MB (實測 1.71 MB)

💜Data Flow / Architectural View (資料流向圖)

[ MMD 純文字字串 ] 
       │ 
       ▼ 
[ Python 記憶體 HTML 模板組裝 ] (注入 mermaid.min.js + CSS 高對比樣式) 
      │ 
      ▼ 
 (CDP 協定直通) [ Playwright sync_playwright() Headless Chromium ] 
      │ - Viewport: 3840 x 2160 (4K 網格) 
      │ 
      ▼
 [ Chromium Skia 繪圖引擎 (In-Memory SVG to Bitmap) ] 
      │ 
      ▼ 
[ Bytes IO 二進位 Byte Stream (無硬碟磨損) ] ───> [ 800KB+ 容量與 SHA256 驗證 ] ───> [ 實體 4K JPEG 輸出 ]

📊 💜Sync_playwright現役記憶體中運作vs傳統運作 對照表

渲染維度傳統 Shell mmdc CLIsync_playwright() In-Memory現行運作
執行通道OS Shell Subprocess (subprocess.run)Python 原生 CDP 協定與 Skia 引擎直通
畫質與 Viewport 控制預設強縮放 (useMaxWidth: true) 易破圖鎖定 3840x2160 Viewport 
文字遮蓋 (Occlusion Bug)容易產生 Level-1 實體無字色塊注入 paint-order CSS 徹底解決遮蓋問題
檔案容量 (SIZE) 穩定度經常因 Syntax Error 產出 < 300KB 死圖100% 保障 1.2 MB ~ 2.5 MB 高細節極致畫質


同步/異步
維度
sync_playwright() (同步模式) async_playwright() (異步模式)
語法結構 with sync_playwright() as p: async with async_playwright() as p:
I/O 呼叫方式 直行阻塞:page.goto(url) 非阻塞等待:await page.goto(url)
適用情境 自動化排程、批次單線程腳本、Flask/Django、資料科學腳本 高併發爬蟲、FastAPI 伺服器、異步協程 (Goroutine/Coroutine 風格)
Event Loop 主權 由 Playwright 內部隱式託管 (Implicit Loop) 由 Python asyncio.run() 顯式主導 (Explicit Loop)

2017年12月18日 星期一

WORD合併套印,(資料來源為EXCEL)



WORD合併套印,(資料來源為EXCEL)
EXCEL資料內容如下:

公司名            產品名         產品價格

A公司            產品A1           100

A公司            產品A2           100

B公司            產品B1           100

B公司            產品A2           100

產出Word報表,如下:   (分別以每家公司為1個單位,將該家公司所有產品列印到1張報表)
公司名           產品名         產品價格

A公司           產品A1           100

A公司           產品A2           100
        分頁符號  Page Break- - - - - - - -

公司名           產品名         產品價格

B公司           產品B1           100

B公司           產品B2           100

功能變數設定如下:
{IF{MERGESEQ}=”1” “{MERGEFIELD 公司名}” “”}{SET BookMark1 {MERGEFIELD 公司名}}{IF BookMark2}<>{BookMark1}”
--------Page Break --------------
   公司名                    產品名                     產品價格
{MERGEFIELD 公司名}{MERGEFIELD 產品名}{MERGEFIELD 產品價格}
“ “
{MERGEFIELD 公司名}{MERGEFIELD 產品名}{MERGEFIELD 產品價格} “}{SET BookMark2 {MERGEFIELD 公司名}}
 
錯誤問題(If mail merge , does not work. Please check the following):無法將同家公司之多筆產品名,列印於同1張。
Debug除錯: (WORD功能變數及書籤功能),
Step1:確認WORD文件之書籤是否定義正確?(有可能捉不
到來源資料,需再次指定主文件之來源)。
Step2:於主文件WORD中,按Shift+F9「進入切換功能變數代碼(T)」,並於功能變數{MERGEFIELD 公司名}處(以本件為例有3處需確認),點選滑鼠右鍵,選擇「編輯功能變數(E)」。
Step3:在「功能變數視窗」中,確認「功能變數名稱(F):」為MergeField,按「確定」後,
       跳出「無效的合併欄」,確認視窗右下方「資料來源之欄位(F)」,是否為”公司名”,因為WORD會去比對書籤BookMark2及書籤BookMark1,才可正確找出公司A與公司B之接續點,並設好分頁PageBreak。

{ IF 表示式1運算元表示式2  ”結果為真的文字”  “結果為假的文字”}
{IF order>=100 "感謝您" "訂購數量,最小以100為單位為基準"}

欄位一為1者,印出Y,另一邊呈現剛好相反
{IF {Mergefield 欄位一} =1  "Y"  "N"} {IF {Mergefield 欄位一} =1  "N" "Y"}

相關快速鍵:
ALT+F9 -->切換檢視功能變數代碼和功能變數代碼結果。
Ctrl+F9-->於微軟OFFICE文件,插入功能變數(Field Codes)  {  }
Ctrl+Enter-->插入分頁符號(Page Break) 

資料來源:

 相關查詢: