Windows 列印驅動程式停止提供 ── 業務應用程式的報表與標籤列印如何因應

flowchart TB
    accTitle: 驅動程式停止提供會改變什麼、不會改變什麼
    accDescr: 單靠列印驅動程式的停止提供本身，應用程式繪製 API 的入口與既有驅動程式不會改變，只有在新導入或重新偵測時選中別的驅動程式，驅動程式回傳的紙張清單、專屬功能與佇列名稱才會被替換，而包含虛擬印表機被刪除在內的、由啟用 Windows protected print mode 帶來的變化屬於另一套機制，在第 4 章說明
    eos["列印驅動程式的停止提供"]
    eos --> keep["不會改變的東西"]
    eos --> cond["新導入、重新偵測時選中別的驅動程式"]
    cond --> change["會被替換的東西"]
    keep --> api["繪製 API 的入口"]
    keep --> drv["既有驅動程式"]
    change --> caps["紙張、紙匣、專屬功能"]
    change --> qname["佇列名稱"]

flowchart TB
    accTitle: 現場中驅動程式被替換的兩條路徑
    accDescr: 在與 IPP 類別驅動程式相符的機器上，更換電腦、重新安裝作業系統、重新偵測印表機時排名規則會選中 IPP 類別驅動程式而使驅動程式被替換，啟用 Windows protected print mode 時使用第三方驅動程式的印表機會被刪除，能以 Windows Ready Print 重新註冊的機種驅動程式被替換，不能重新註冊的機種則列印目標消失
    site["現場的電腦"]
    site --> r1["更換電腦、重新安裝作業系統、重新偵測"]
    site --> r2["啟用 Windows protected print mode"]
    r1 --> rank["在與 IPP 類別驅動程式相符的機器上優先選它"]
    r2 --> del["刪除使用第三方驅動程式的印表機"]
    rank --> swap["驅動程式被替換"]
    del --> re{"能否以 Ready Print 重新註冊"}
    re -->|"可以"| swap
    re -->|"不行"| lost["列印目標消失"]

flowchart TB
    accTitle: 與 IPP 類別驅動程式相符和取得 Mopria 認證是不同的條件
    accDescr: 印表機只要支援 IPP，排名規則變更後就可能被選中 IPP 類別驅動程式而替換驅動程式，而是否取得 Mopria 認證是另一個條件，它決定能否在 Windows protected print mode 之下重新註冊，網路連線機種需要 IPP 已啟用且可到達，USB 連線機種需要處於 IPP over USB 模式
    printer["印表機"]
    printer --> q1{"是否支援 IPP"}
    q1 -->|"是"| rank["可能被替換"]
    q1 -->|"否"| keep["維持廠商驅動程式"]
    printer --> q2{"是否已取得 Mopria 認證"}
    q2 -->|"否"| ng["無法在 WPP 之下重新註冊"]
    q2 -->|"是"| q3{"是否為 USB 連線"}
    q3 -->|"否"| q5{"IPP 是否啟用且可到達"}
    q5 -->|"是"| ok["可以在 WPP 之下重新註冊"]
    q5 -->|"否"| ng
    q3 -->|"是"| q4{"是否為 IPP over USB 模式"}
    q4 -->|"是"| ok
    q4 -->|"否"| ng

flowchart TB
    accTitle: 2026 年 1 月 15 日之後仍可取得驅動程式簽章的條件
    accDescr: 廠商提交驅動程式預設會被封鎖，只有符合無法取得 Mopria 認證的印表機、以 Windows 10 以下為上限的套件、原生 ARM64 驅動程式這三個條件之一的才能把例外申請送入個別審查，而經過審查也只是有可能核准，並不保證一定會被簽章
    submit["廠商提交驅動程式"]
    submit --> block["預設被封鎖"]
    block --> c1["無法取得 Mopria 認證的機種"]
    block --> c2["上限為 Windows 10 以下"]
    block --> c3["原生 ARM64"]
    c1 --> apply["可以提出例外申請"]
    c2 --> apply
    c3 --> apply
    apply --> review["個別審查"]
    review --> maybe["有可能核准（沒有保證）"]

flowchart TB
    accTitle: 傳統的驅動程式路徑
    accDescr: 業務應用程式的 GDI 或 XPS 繪製指令由以 SYSTEM 權限執行的列印多工緩衝處理器排入多工緩衝，第三方的 v3 或 v4 驅動程式在沒有驅動程式隔離時就在列印多工緩衝處理器本體之中、在共用或隔離時則在與列印多工緩衝處理器不同的處理程序中，把它轉換成專屬的 PDL 送往印表機
    app["業務應用程式（GDI / XPS）"] --> spooler["列印多工緩衝處理器（SYSTEM 權限）"]
    spooler --> iso{"驅動程式隔離為"}
    iso -->|"無"| inproc["在列印多工緩衝處理器本體中執行第三方驅動程式"]
    iso -->|"共用 / 隔離"| host["在另一個處理程序中執行第三方驅動程式"]
    inproc --> pdl["轉換成專屬 PDL"]
    host --> pdl
    pdl --> printer["印表機"]

flowchart TB
    accTitle: Windows Ready Print 的路徑
    accDescr: 業務應用程式的繪製指令由列印多工緩衝處理器接收，內建的 Microsoft IPP Class Driver 在用戶端算繪成 PWG Raster 或 PDF 並以 IPP 送往已取得 Mopria 認證的印表機，或由內建的 Universal Print Class Driver 以 IPP over HTTPS 送往 Universal Print 服務，而 Windows protected print mode 只允許這條 Windows Ready Print 的路徑
    app["業務應用程式（GDI / XPS）"] --> spooler["列印多工緩衝處理器"]
    spooler --> ipp["Microsoft IPP Class Driver"]
    ipp --> render["算繪成 PWG Raster / PDF"]
    render --> printer["已取得 Mopria 認證的印表機（IPP）"]
    spooler --> up["Universal Print Class Driver"]
    up --> cloud["Universal Print 服務（IPP over HTTPS）"]
    wpp["Windows protected print mode"] -.->|"只允許 Ready Print 的路徑"| ipp
    wpp -.-> up

flowchart TB
    accTitle: 分別確認多功能事務機各功能的順序
    accDescr: 逐一選出要使用的功能，依序確認機器是否搭載、是否支援表中的通訊協定、USB 連線時是否處於 IPP over USB 模式，不要把列印功能的結果套用到傳真或掃描，其餘功能也要分別確認
    start["選出一個要使用的功能"]
    start --> feature{"機器是否搭載該功能？"}
    feature -->|"是"| protocol{"是否支援表中的通訊協定？"}
    feature -->|"否"| unmet["此功能的條件未滿足"]
    protocol -->|"是"| usb{"是否為 USB 連線？"}
    protocol -->|"否"| unmet
    usb -->|"是"| mode{"是否為 IPP over USB 模式？"}
    usb -->|"否"| checked["此功能的條件已確認"]
    mode -->|"是"| checked
    mode -->|"否"| unmet
    checked --> next["其餘功能分別確認"]
    unmet --> next

flowchart TB
    accTitle: 只要還載入第三方驅動程式，緩解措施就無法生效的原因
    accDescr: 以 SYSTEM 權限運轉的列印多工緩衝處理器會載入第三方程式碼，而舊驅動程式與 CFG、CET 等緩解措施不相容，因此需要所有參與者都支援的緩解措施無法套用到列印多工緩衝處理器上，漏洞也就更容易被利用
    sys["列印多工緩衝處理器以 SYSTEM 權限運轉"]
    load["依需求載入第三方程式碼"]
    old["舊驅動程式與緩解措施不相容"]
    sys --> risk["漏洞容易被利用"]
    load --> nomit["無法套用緩解措施（CFG / CET / ACG）"]
    old --> nomit
    nomit --> risk

flowchart TB
    accTitle: 第三方驅動程式在哪個處理程序中執行是如何決定的
    accDescr: 在 INF 中宣告 DriverIsolation=2 的驅動程式預設在與列印多工緩衝處理器不同的共用處理程序中執行，沒有宣告的驅動程式預設在列印多工緩衝處理器本體中執行，系統管理員可以透過列印管理主控台或群組原則覆寫成共用、列印多工緩衝處理器本體之中、驅動程式專用的獨立處理程序（隔離）三者之一
    inf{"在 INF 中宣告 DriverIsolation=2"}
    inf -->|"是"| shared["在另一個共用處理程序中執行（預設）"]
    inf -->|"否"| inproc["在列印多工緩衝處理器本體中執行（預設）"]
    admin["由系統管理員的設定或原則覆寫"] -.-> shared
    admin -.-> inproc
    admin -.-> isolated["在專用的獨立處理程序中執行（隔離）"]

flowchart TB
    accTitle: 啟用 Windows protected print mode 的三條途徑
    accDescr: 可以透過設定應用程式、群組原則、Intune 的 OMA-URI 之一啟用 Windows protected print mode，能由本人在設定應用程式中改回去的只有本人在設定應用程式中啟用的情況，透過群組原則或 Intune 的原則派送的情況必須由系統管理員端變更原則才能解除
    s["設定應用程式（本人啟用）"] --> wpp["Windows protected print mode 已啟用"]
    g["群組原則"] --> wpp
    i["Intune（OMA-URI）"] --> wpp
    s -.->|"本人可在設定應用程式中改回"| off["解除"]
    g -.->|"本人無法改回"| adm["解除需系統管理員端變更原則"]
    i -.->|"本人無法改回"| adm

flowchart TB
    accTitle: 啟用 Windows protected print mode 時印表機會發生什麼
    accDescr: 啟用後以第三方驅動程式導入的印表機、不受支援的虛擬印表機、XPS Document Writer 與傳真的虛擬印表機會被刪除，已取得 Mopria 認證且網路連線時 IPP 已啟用且可到達、USB 連線時處於 IPP over USB 模式的機種可以用 Windows Ready Print 重新註冊，不支援的機種在啟用期間無法使用
    on["啟用 WPP"]
    on --> third["刪除使用第三方驅動程式的印表機"]
    on --> soft["刪除不支援的虛擬印表機"]
    soft --> xps["XPS Document Writer 與傳真也被刪除"]
    third --> mopria{"是否已取得 Mopria 認證"}
    mopria -->|"是"| conn{"連線方式為"}
    conn -->|"網路"| ipp{"IPP 是否啟用且可到達"}
    conn -->|"USB"| usb{"是否為 IPP over USB 模式"}
    ipp -->|"是"| re["以 Windows Ready Print 重新註冊"]
    usb -->|"是"| re
    ipp -->|"否"| no["啟用期間無法使用"]
    usb -->|"否"| no
    mopria -->|"否"| no

flowchart TB
    accTitle: Windows protected print mode 之下列印多工緩衝處理器的變化
    accDescr: 由於不再載入第三方二進位檔，就能做到模組載入的限制、以使用者權限算繪 XPS、使用受限權杖的背景工作處理程序、禁止建立子處理程序以及啟用 CFG、CET、ACG
    nodrv["不載入第三方二進位檔"]
    nodrv --> r["載入的限制"]
    nodrv --> l["權限的縮減"]
    nodrv --> m["緩解措施的啟用"]
    r --> r2["只載入 Microsoft 簽署的二進位檔"]
    l --> l2["使用者權限的 XPS、受限權杖"]
    m --> m2["禁止子處理程序、CFG / CET / ACG"]

flowchart TB
    accTitle: 業務應用程式中要盤點的 4 個地方
    accDescr: 業務應用程式的列印程式碼中，儲存驅動程式專屬設定、相依於佇列名稱（包含 SDK 與函式庫內部的）、相依於 WPP 不支援的虛擬印表機、向 WPP 之下不會保留的佇列做 RAW 傳送這 4 個地方是改造對象，只做繪製的程式碼則是驗證對象
    app["業務應用程式的列印程式碼"]
    app --> deps["盤點 4 類相依"]
    app --> d0["只做繪製"]
    deps --> d1["儲存專屬設定"]
    deps --> d2["相依於佇列名稱"]
    deps --> d3["相依於虛擬印表機"]
    deps --> d4["RAW 傳送"]
    d2 -.-> d2n["包含 SDK 內部"]
    d3 -.-> d3n["WPP 不支援的那些"]
    d4 -.-> d4n["送往不會保留的佇列"]
    d1 --> fix["改造"]
    d2 --> fix
    d3 --> fix
    d4 --> fix
    d0 --> verify["驗證"]

flowchart TB
    accTitle: 盤點現場印表機清單的步驟
    accDescr: 用 PowerShell 取得佇列與驅動程式的清單，透過 DriverName 以及與 Manufacturer 和 pnputil 第三方套件清單的對照，分成 IPP 類別驅動程式的佇列、Universal Print 的佇列（WPP 相容）、其他內建驅動程式的佇列（XPS 與傳真會被刪除，Generic / Text Only 不能當成一定留下，Microsoft Print to PDF 沒有被列入刪除對象因此要個別判定）、廠商驅動程式的佇列（會被替換的候選），其中 IPP 類別驅動程式的佇列還要另外確認 Mopria 認證、網路連線時 IPP 是否啟用且可到達、USB 連線時是否處於 IPP over USB 模式，然後兩類佇列都要和應用程式的設定與列印程式碼所指向的佇列對照後判定
    list["用 Get-Printer / Get-PrinterDriver 取得清單"]
    list --> cls{"DriverName 與提供者為"}
    cls -->|"IPP Class"| ipp["IPP 類別驅動程式的佇列"]
    cls -->|"Universal Print Class"| up["Universal Print 的佇列"]
    cls -->|"其他內建"| inbox["用第 4 章的表逐一判定是否留下"]
    cls -->|"廠商製"| vendor["會被替換的候選"]
    ipp --> mop["確認 Mopria、IPP 可到達性、USB"]
    mop --> match["與應用程式的設定和程式碼對照"]
    up --> match
    inbox --> match
    vendor --> match
    match --> judge["用判斷表分類"]

flowchart TB
    accTitle: DEVMODE 的公開部分與非公開部分
    accDescr: DEVMODE 結構在公開成員之後可以帶上由 dmDriverExtra 指明的、驅動程式自訂的非公開資料，只有公開部分會被 Windows 驗證，非公開部分只有那個驅動程式才能解讀，因此整塊儲存後一旦驅動程式變了就會失去意義
    dm["DEVMODE 結構"]
    dm --> pub["公開部分（dmSize）"]
    dm --> priv["非公開部分（dmDriverExtra）"]
    pub --> chk["由 Windows 驗證"]
    priv --> only["只有那個驅動程式能解讀"]
    only --> lost["驅動程式一變就失去意義"]

flowchart TB
    accTitle: 儲存 DEVMODE 和儲存受控值的出問題方式不同
    accDescr: 把 DEVMODE 緩衝區整塊儲存的實作，以及把以 SetHdevmode 接收了非公開區域之後的 PrinterSettings 整體序列化的實作，都會連非公開部分一起帶著走，驅動程式一變就失去意義，而儲存公開屬性值的實作則因為 Custom 或廠商專屬的紙張、紙匣編號是對應廠商驅動程式清單的值，無法保證在 IPP 類別驅動程式之下意義相同，兩者都要換成只儲存意圖的設計
    a["整塊儲存 DEVMODE"]
    a --> a1["連非公開部分一起帶著走"]
    s["儲存 SetHdevmode 之後的整個物件"] --> a1
    a1 --> a2["驅動程式一變就失去意義"]
    b["儲存公開屬性的值"]
    b --> b1["帶著自訂紙張、紙匣的編號走"]
    b1 --> b2["無法保證在新驅動程式之下意義相同"]
    a2 --> c["兩者都改成只儲存意圖"]
    b2 --> c

flowchart TB
    accTitle: 儲存下來的紙張、紙匣值中會出問題的部分
    accDescr: RawKind 中對應 A4 等標準紙張（PaperKind）或 Upper、Lower 等標準進紙來源（PaperSourceKind）的值，即使驅動程式變了意義也能保持，而 Custom 或廠商專屬的值是對應廠商驅動程式清單的編號，無法保證 IPP 類別驅動程式會把它解讀成同一種紙張、同一個紙匣
    raw["儲存下來的 RawKind"]
    raw --> std["標準值（PaperKind 等）"]
    raw --> cus["Custom、廠商專屬的值"]
    std --> keep["驅動程式變了意義也保持"]
    cus --> lost["無法保證被解讀成同一種紙張、同一個紙匣"]

flowchart TB
    accTitle: 只儲存意圖並在列印前與能力核對的設計
    accDescr: 設定檔中只以公開關鍵字儲存紙張、方向、雙面、份數、紙匣的意圖，在列印之前用 GetPrintCapabilities 取得目前印表機的能力，交給 MergeAndValidatePrintTicket，如果 ConflictStatus 為 NoConflict 就直接列印，如果為 ConflictResolved 就把被替換的項目和要求對照後轉入記錄與通知
    cfg["設定檔：只有意圖（紙張、方向、雙面、份數）"]
    cfg --> caps["列印前呼叫 GetPrintCapabilities"]
    caps --> merge["MergeAndValidatePrintTicket"]
    merge --> st{"ConflictStatus 為"}
    st -->|"NoConflict"| print["列印"]
    st -->|"ConflictResolved"| tell["把與要求的差異寫進記錄並通知"]

flowchart TB
    accTitle: 佇列名稱相依藏身的三個位置
    accDescr: 對佇列名稱的相依藏在設定檔中的固定名稱、程式碼中寫死的固定名稱、以及廠商 SDK 或報表函式庫內部呼叫的佇列和驅動程式這三處，前兩者可以透過搜尋程式碼與設定找到，後者要用 SDK 的文件和 5.1 的清單確認
    dep["對佇列名稱的相依"]
    dep --> cfg["設定檔中的固定名稱"]
    dep --> code["程式碼中寫死的固定名稱"]
    dep --> sdk["SDK、函式庫內部的固定"]
    cfg --> grep["搜尋程式碼與設定找出來"]
    code --> grep
    sdk --> doc["用 SDK 的文件和 5.1 的清單確認"]

flowchart TB
    accTitle: 啟動時對印表機名稱的驗證
    accDescr: 啟動時確認設定檔中的印表機名稱是否存在於 InstalledPrinters 中，存在就列印，不存在就留下記錄並通知使用者讓其重新選擇，不要默默退回預設印表機
    start["啟動時：設定中的印表機名稱"]
    start --> exists{"是否在 InstalledPrinters 中"}
    exists -->|"在"| print["列印到該佇列"]
    exists -->|"不在"| log["留下記錄並通知使用者"]
    log --> pick["在設定畫面重新選擇"]
    exists -.->|"絕對不能這樣做"| silent["默默退回預設印表機"]

flowchart TB
    accTitle: RAW 傳送的路徑以及在 WPP 之下會消失的環節
    accDescr: 應用程式以 OpenPrinter、StartDocPrinter、WritePrinter 把印表機語言的資料送往列印多工緩衝處理器，在 WPP 之下不會保留的佇列（例如廠商驅動程式的佇列）充當通道，資料經連接埠到達印表機，因此一旦該佇列在 WPP 之下消失，通道也就沒有了
    app["應用程式：StartDocPrinter（RAW）、WritePrinter"]
    app --> spooler["列印多工緩衝處理器"]
    spooler --> queue["在 WPP 之下不會保留的佇列（通道）"]
    queue --> port["連接埠"]
    port --> printer["標籤、收據印表機"]
    wpp["啟用 WPP"] -.->|"佇列消失"| queue

flowchart TB
    accTitle: 判定輸出路徑是否相依於列印多工緩衝處理器的流程
    accDescr: 候選路徑若送往 Windows 的列印佇列，那麼 IPP 類別驅動程式的佇列中印表機已取得 Mopria 認證且網路連線時 IPP 已啟用且可到達、USB 連線時處於 IPP over USB 模式的，以及身為 Windows Ready Print 一部分的 Universal Print 的佇列，雖然相依於列印多工緩衝處理器但與 WPP 相容，未取得 Mopria 認證的機種、第三方驅動程式的佇列、以及 XPS Document Writer 與傳真這類第 4 章表中會被刪除的佇列則可能在 WPP 之下停下來，而像 Microsoft Print to PDF 這種沒有被列入刪除對象的內建佇列依 5.1 個別判定，若不送往佇列，SDK 若在內部呼叫佇列或驅動程式就回到同樣的判定，不呼叫的 SDK 與直接送往裝置的路徑則是不相依於列印多工緩衝處理器的退路
    route["候選的輸出路徑"]
    route --> q1{"是否送往 Windows 的列印佇列"}
    q1 -->|"是"| q4{"是否為 IPP 類別驅動程式的佇列"}
    q4 -->|"是"| q5{"是否已取得 Mopria 認證"}
    q5 -->|"是"| q9{"IPP 是否可到達（USB 為 over USB）"}
    q9 -->|"是"| depok["相依但與 WPP 相容"]
    q9 -->|"否"| dep["相依，且可能在 WPP 之下停下來"]
    q5 -->|"否"| dep
    q4 -->|"否"| q6{"是否為 Universal Print 的佇列"}
    q6 -->|"是"| depok
    q6 -->|"否"| q7{"第 4 章的表中是否會被刪除"}
    q7 -->|"是（第三方驅動程式、XPS、傳真）"| dep
    q7 -->|"否（Print to PDF 等）"| indiv["個別判定（5.1）"]
    q1 -->|"否"| q2{"是否經由廠商 SDK"}
    q2 -->|"是"| q3{"內部是否呼叫佇列、驅動程式"}
    chk["確認：SDK 文件與 5.1 的清單"] -.-> q3
    q3 -->|"是"| q4
    q3 -->|"否"| indep["不相依的退路"]
    q2 -->|"否"| indep

flowchart TB
    accTitle: 依是否使用 WPP 區分的列印驗證步驟
    accDescr: 在驗證機上重現全部佇列並保存變更前的輸出，使用 WPP 時啟用它並記錄被刪除的佇列，比較相容機種重新註冊之後的輸出，同時確認不相容機種的另一條路徑，不使用 WPP 時則在維持停用的狀態下對實體的 IPP 排名變更對象機重新偵測並比較輸出，其餘則在實際的佇列上確認列印
    prepare["重現全部佇列並記錄"]
    prepare --> baseline["保存變更前的列印結果"]
    baseline --> use{"是否使用 WPP"}
    use -->|"使用"| enable["啟用並記錄被刪除的佇列"]
    enable --> compatible["相容機種視需要重新註冊"]
    compatible --> compare["用與變更前相同的列印做比較"]
    enable --> alternate["不相容機種以另一條路徑確認"]
    use -->|"不使用"| physical{"是否為實體的 IPP 排名變更對象"}
    physical -->|"是"| redetect["維持停用狀態刪除並重新偵測"]
    redetect --> compare
    physical -->|"否"| existing["在實際的佇列上確認列印"]
    compare --> finish["記錄結果並復原驗證機"]
    alternate --> finish
    existing --> finish

flowchart TB
    accTitle: 要在驗證機上重現的佇列
    accDescr: 在 5.1 的盤點中查明的應用程式所用佇列裡，廠商驅動程式的實體印表機、第三方 PDF 等虛擬印表機、Generic / Text Only 等內建驅動程式的佇列都要以與現場相同的組態在驗證機上重現，說明能用步驟 3 的刪除清單判定的只有驗證機上存在的佇列
    inv["5.1 的盤點：應用程式使用的佇列"]
    inv --> phys["實體印表機（廠商製）"]
    inv --> virt["虛擬印表機（第三方 PDF 等）"]
    inv --> inbox["內建驅動程式（Generic / Text Only 等）"]
    phys --> vm["在驗證機上以相同組態重現"]
    virt --> vm
    inbox --> vm
    vm --> judge["用步驟 3 的刪除清單判定是否留下"]
    note["驗證機上沒有的佇列不會出現在刪除差異中"] -.-> judge

flowchart TB
    accTitle: 裝機程序的重新檢視
    accDescr: 以 Point and Print 派送第三方驅動程式的程序，因為 2021 年以後需要系統管理員認證而且在 WPP 之下派送本身就不會進行，所以要從程序中拿掉，改成把 WPP 的原則（群組原則或 OMA-URI）與印表機的重新註冊程序納入派送機制
    old["以 Point and Print 派送第三方驅動程式"]
    old --> why1["2021 年以後需要系統管理員認證"]
    old --> why2["WPP 之下派送本身不會進行"]
    why1 --> drop["從程序中拿掉"]
    why2 --> drop
    drop --> add["納入 WPP 的原則與重新註冊程序"]

flowchart TB
    accTitle: 判斷是要修改還是只需確認的決策樹
    accDescr: 先判定列印目標的佇列在 WPP 之下是否留下（Universal Print 的雲端佇列或支援 WPP 的虛擬印表機）或者實體印表機能否以 Windows Ready Print 重新註冊，如果不行就選擇準備另一條路徑或不使用 WPP，如果該機器支援 IPP 且可能因排名變更而被替換，就依驅動程式專屬設定的儲存、對佇列名稱或虛擬印表機的相依（包含 SDK 與函式庫內部）、RAW 傳送的順序確認，符合的就修改後進入下一步，最後使用 WPP 的環境進入第 7 章的 WPP 啟用驗證，不使用的環境中實體的 IPP 相容機進入維持 WPP 停用的重新偵測驗證，雲端與虛擬的佇列進入實際輸出確認，既不使用 WPP 也不受替換影響的則維持目前路徑繼續維運
    q0{"佇列在 WPP 之下留下或可重新註冊嗎"}
    q0 -->|"否"| alt{"該怎麼做"}
    alt -->|"準備另一條路徑"| qi{"支援 IPP 且可能被替換嗎"}
    alt -->|"不使用 WPP"| qi2{"支援 IPP 且可能被替換嗎"}
    qi -->|"是"| q1{"是否儲存了驅動程式專屬設定"}
    qi -->|"否"| verify["只做驗證（第 7 章）"]
    qi2 -->|"是"| q1
    qi2 -->|"否"| keep["維持目前路徑繼續維運"]
    q0 -->|"是"| q1
    q1 -->|"是"| fix1["修改（5.2）"]
    fix1 --> q2{"是否相依於佇列名稱、虛擬印表機"}
    sdk["也包含 SDK、函式庫內部的相依"] -.-> q2
    q1 -->|"否"| q2
    q2 -->|"是"| fix2["修改（5.3、5.4）"]
    fix2 --> q3{"是否把 RAW 傳送送往 WPP 之下不會留下的佇列"}
    q2 -->|"否"| q3
    q3 -->|"是"| fix3["準備通道（第 6 章）"]
    fix3 --> vq{"是否使用 WPP"}
    q3 -->|"否"| vq
    vq -->|"是"| verify
    vq -->|"否"| pq{"是否為實體的 IPP 相容機"}
    pq -->|"是"| redetect["不啟用 WPP 的重新偵測驗證（7.3）"]
    pq -->|"否"| outchk["在實際的佇列上確認輸出"]

flowchart TB
    accTitle: 業務應用程式端準備期限的設定方式
    accDescr: 現在就做清單取得與盤點，把路徑的更換與驗證放在自家啟用 WPP 之前或推送 24H2 以後功能更新之前這個自家端的期限內完成，2027 年 7 月 1 日的驅動程式停止更新是供給端的節點而不是準備的期限，要先把環境做成時程未定的 WPP 預設啟用無論何時到來都不受影響的狀態
    now["現在：取得清單與盤點"]
    now --> prep["路徑更換與驗證"]
    prep --> deadline["期限：自家啟用 WPP 之前 / 功能更新推送之前"]
    deadline --> fine["WPP 預設啟用（時程未定）到來時也不受影響"]
    ms["2027 年 7 月 1 日：驅動程式停止更新"] -.->|"是供給端的節點而不是期限"| prep