修正
Windows 拖放匯入失效（issue #6，感謝 @katiboy 回報）
在 Windows 上把檔案拖進視窗沒有任何反應，只能改用「瀏覽選擇」。原因是 pywebview 的 Windows 後端（EdgeChromium）只有在網頁端主動送出 FilesDropped 訊息時才會記錄拖入的路徑，而 macOS 後端是原生自動填入的；程式先前直接向後端索取路徑卻從未送出該訊息，因此永遠拿到空清單。自 v1.3.0 推出 Windows 版起的每一版都受影響。
發布方式改善
macOS 版已使用 Developer ID 簽章並通過 Apple 公證
v1.7.0 及更早的 dmg 只有 adhoc 簽章，Gatekeeper 會直接擋下，使用者必須右鍵開啟或到「系統設定 → 隱私權與安全性」手動放行。本版下載後直接雙擊即可開啟，不需要任何繞道步驟。三份說明文件中過時的 workaround 指示也一併移除。
已知限制
- Windows 版的拖放修復尚未在實體 Windows 機器上驗證。 開發與測試環境為 macOS，此修復有自動化接線測試涵蓋（釘住訊息送出順序），但實機行為仍待確認。若你在 Windows 上使用，歡迎回報是否正常。
- 掃描版 PDF（整頁為圖片）無法提取文字。
- 表格提取對無框線（純排版對齊）的表格仍無法辨識。
Fixes
Drag-and-drop was broken on Windows (issue #6, reported by @katiboy)
Dropping files onto the window did nothing on Windows; you had to use the browse button instead. pywebview's Windows backend (EdgeChromium) only records dropped paths when the page posts a FilesDropped message, whereas the macOS backend fills them in natively. The app asked the backend for the paths without ever posting that message, so it always received an empty list. Every Windows build since v1.3.0 was affected.
Distribution
The macOS build is now signed with a Developer ID certificate and notarized by Apple
Every dmg up to v1.7.0 was ad-hoc signed, so Gatekeeper refused to open it and users had to right-click → Open or grant an exception in System Settings. This build opens directly after download, with no workaround. The now-obsolete workaround instructions have been removed from all three user-facing documents.
Known limitations
- The Windows drag-and-drop fix has not been verified on physical Windows hardware. Development and testing happen on macOS. The fix is covered by automated wiring tests (which pin the message ordering), but real-device behaviour is still unconfirmed. If you use Windows, reports are welcome.
- Scanned PDFs (whole pages as images) can't yield text.
- Borderless tables (columns aligned by layout only, no rules) are still not detected.