[Bug]: Word转PDF文字会位移，以及转换完文件的时候，有时卡住一会才正常。 #511
Description
What happened?
Word转PDF文字会位移，以及转换完文件的时候，有时卡住一会才正常。
What did you expect?
No response
Steps to reproduce
转换就这样
Files involved
No response
Filee version
2.0
Operating system
win10
Engines page status
Log
05:20:38.776 INFO Program: Filee 2.0.0 starting: K:\安装软件\Filee\Filee.exe (installed), integrity High (elevated), Explorer High, Microsoft Windows 10.0.19041 X64, 0 argument(s)
05:20:39.020 INFO Program: Graphics adapters: [0] nvidia geforce gtx 1080 (used), [1] microsoft basic render driver
05:20:40.049 INFO App: Filee 2.0.0 started
05:20:40.054 INFO App: Rendering: AngleEgl with WinUIComposition (FILEE_RENDERING not set)
05:20:40.061 INFO TriggerService: Global input hook started
05:24:42.608 INFO App: A later launch handed over 2 argument(s)
05:24:42.609 INFO App: Handling a later launch: convert 1 file(s)
05:24:43.316 INFO App: RadialWindow: transparency Transparent (asked Transparent), composition surface, system backdrop unknown, transparency effects on
05:24:54.806 INFO RadialController: Converting 1 file(s) with preset to-pdf
05:24:59.863 INFO App: ToastWindow: transparency Transparent (asked Transparent), composition surface, system backdrop unknown, transparency effects on
05:25:30.421 INFO MemoryTrimmer: Trimmed memory: private 252 MB → 248 MB (managed heap 19 MB) in 78 ms
05:29:32.630 INFO App: TrayPopupRoot: transparency Transparent (asked Transparent), composition surface, system backdrop unknown, transparency effects on
05:29:57.771 INFO TriggerService: Global input hook stopped
05:31:11.217 INFO Program: Filee 2.0.0 starting: K:\安装软件\Filee\Filee.exe (installed), integrity High (elevated), Explorer High, Microsoft Windows 10.0.19041 X64, 0 argument(s)
05:31:11.344 INFO Program: Graphics adapters: [0] nvidia geforce gtx 1080 (used), [1] microsoft basic render driver
05:31:12.110 INFO App: Filee 2.0.0 started
05:31:12.114 INFO App: Rendering: AngleEgl with WinUIComposition (FILEE_RENDERING not set)
05:31:12.118 INFO TriggerService: Global input hook started
05:32:05.666 INFO TriggerService: Global input hook stopped
Activity
cre8ive-marketing commentedon Oct 24, 2026
谢谢反馈！为了找到文字位移的原因，需要文档本身：
另外，日志显示 Filee 是以管理员身份运行的（
integrity High (elevated)）。建议用普通权限运行 Filee，否则拖动手势和右键菜单可能不正常。#240、#280 也是 Word 转 PDF 排版不一致的问题，供参考。
Thanks for the report! To find why the text shifts we need the document itself:
.docx(a copy with dummy text is fine, as long as it still shifts).Also, the log shows Filee running as administrator (
integrity High (elevated)). Please run it with normal rights; elevated, the drag gesture and the context menu can misbehave.#240 and #280 are similar Word → PDF layout reports, linked for reference.
iverjun commentedon Oct 24, 2026
1.送达地址确认书.docx
2.没有使用LibreOffice，几乎所有字段落文字都位移。
3.转换后出现大概5，6秒，很卡那种，我都是默认启动，没有设置为管理员启动，右键也没有勾选管理员
4.转换后操作界面也很卡，然后点击关闭时更卡，留意鼠标光标都卡不见了
cre8ive-marketing commentedon Oct 24, 2026
谢谢补充，文件和说明都收到了！
@KnifeLemon，文件已经附上了。排版部分是 Filee 自带的 Word → PDF 方式。卡顿部分如果你希望由我来查，请把这个 issue 分配给我。
Thanks, the file and the details are in!
.docxshould reproduce it.@KnifeLemon, the file is attached. The layout part is the built-in Word → PDF route. If you'd like me to look into the lag, please assign it to me.
KnifeLemon commentedon Oct 26, 2026
@cre8ive-marketing yes please, it's yours: the lag and the frozen cursor after converting (with #528). The text shifting in Word → PDF stays a separate part of this issue.
cre8ive-marketing commentedon Oct 26, 2026
@KnifeLemon thanks, I'll take the lag and the frozen cursor (with #528). Here's the plan before any code.
What I think happens. Filee's global input hook is a Windows low-level mouse and keyboard hook. While it's installed, Windows waits for Filee to answer every mouse move before the cursor moves. So anything that keeps the hook's thread from running for a moment freezes the cursor for the whole desktop, not just Filee. Three things in the code can do that around a conversion:
TriggerService, "Filee global input") is at normal priority too, so it waits its turn. Only FFmpeg is started atBelowNormaltoday (FfmpegRunner.cs:123).MemoryTrimmerempties the whole process's working set (SetProcessWorkingSetSize(-1, -1)) 30 s later. The next mouse moves then page the hook's code and data back in from disk, one fault at a time.The plan, in this order:
ThreadPriority.Highest. It only reads the event and queues it, so this costs nothing.BelowNormalinProcessRunner, as FFmpeg already is, so a long conversion leaves room for the desktop.SetProcessWorkingSetSizewhile the global input hook is running, or trim only the managed heap.Each step is small, and they go into one PR. The text shifting in Word → PDF stays a separate part, as you said. Shall I go ahead?
谢谢！转换后的卡顿和鼠标指针卡住由我来查（与 #528 一起）。计划如上：先用你附的文件测量鼠标事件在 Filee 里等待的时间，再提高输入检测线程的优先级，让转换引擎以较低优先级运行，并修改转换后的内存整理和退出时的顺序。文字位移是另一个问题，单独处理。
KnifeLemon commentedon Oct 26, 2026
@cre8ive-marketing the plan looks good, go ahead. Measuring first is the right start; please post the numbers here before the changes, as you said. Nothing on our side has to land first. I've assigned #528 to you as well, since step 5 is that fix.
One overlap to keep in mind: #583 also changes
ProcessRunner(its drain timeout after a killed process), and that part may come back as its own small PR. Whichever lands second rebases; the priority change and the drain timeout don't touch the same lines.cre8ive-marketing commentedon Oct 26, 2026
@KnifeLemon here are the numbers from step 1, before any change goes in.
How I measured: a local build of Filee with throwaway timing code (not part of the PR) records, for every mouse move, how long Windows held it before Filee's hook got it: the event's own time vs. the moment the hook ran. A script moved the mouse about 50 times a second. The same workload ran twice: once as today (hook thread at normal priority, engines at normal priority) and once with the changes (hook thread Highest, engines BelowNormal). The workload was 3 long DOCX → PDF (rhwp), 3 images of 6000×6000 → JPG, a 1080p video → MP4, and then the memory trim 30 s later. Filee's data was in its own folder (
FILEE_DATA_DIR).The clock these times come from only ticks every ~16 ms, so everything up to 16 ms is "no wait".
What that means: on this PC (12 cores, Windows 11) I can't reproduce the frozen cursor, with or without the changes. That's not proof it's fixed for @iverjun: the report is Windows 10 with Filee running elevated, from a K: drive. A slower PC, fewer cores or a hard disk (for the trim) can still freeze where this one doesn't. So:
ObjectDisposedExceptionon the hook thread, and with our own queue it doesn't. The engine change is confirmed too: rhwp now runs at BelowNormal (priority 6 instead of 8).FILEE_TRACE_GESTURES=1trace: each mouse move that reaches Filee more than 50 ms late is logged with its delay. Then the reporter's log would show when the cursor waits (during the job, right after it, at the trim) and by how much.If that's OK, I'll open the PR now.
我在自己的电脑上测量了鼠标事件在 Filee 中等待的时间：转换期间、转换完成后、内存整理时都没有超过 16 毫秒（时钟精度），所以在这台电脑上无法重现卡顿。修复（输入线程优先级、引擎低优先级、退出时的崩溃）照常加入。新版本可以用
FILEE_TRACE_GESTURES=1记录鼠标延迟超过 50 毫秒的情况，到时可以帮忙在你的电脑上测一下。KnifeLemon commentedon Oct 26, 2026
@cre8ive-marketing thanks for measuring first, that's exactly what I wanted to see. Yes, please open the PR with steps 2, 3 and 5 plus the 50 ms trace line. Leaving step 4 (the trim) out is right while there's no evidence it holds the cursor.
@iverjun 等新版本发布后，如果还会卡顿，可以按上面说的打开
FILEE_TRACE_GESTURES=1记录一次，把日志贴在这里，我们就能看到鼠标在哪一步被卡住。cre8ive-marketing commentedon Oct 27, 2026
PR #638 is open with steps 2, 3 and 5 plus the 50 ms trace line. Step 4 (the trim) is left out, as agreed.
Keep the cursor moving while Filee converts or quits (#511, #528)
Trace mouse moves that reach Filee late (#511)
Merge pull request #638 from cre8ive-marketing/fix/511-hook-lag