Forward-search doesn't work when there're Chinese characters in the path.

[gaoqiangks]

SumatraPDF version v3.6.1677964-bit Pre-release

Describe the bug

Forward-search doesn't work when there're Chinese characters in the path.

To Reproduce Steps to reproduce the behavior:

1. Open a latex project whose path contains Chinese characters with vscode.
2. Build and perform a forward-search
3. Move the latex project to a directory whose path doesn't contain Chinese characters.
4. Open with vscode, build and perform a forward-search.

Expected behavior

Forward-search should behave well regardless of Chinese characters in path.

File that reproduces the problem If this is related to a specific PDF etc. file, please attach the file.

Screenshots If applicable, add screenshots to help explain your problem.

https://github.com/user-attachments/assets/46578cd0-ac10-441a-b41b-25558731dffb

Additional context Add any other context about the problem here.

[GitHubRulesOK]

This is not an uncommon problem see questions like https://tex.stackexchange.com/questions/562463/how-can-latexmk-compile-file-that-contains-chinese-characters-in-path-in-windows and many aspects of control of path is basically LaTeX.syctex or Windows UTF both Outside of SumatraPDF control. (the problem above is PERL "Latexmk is a perl script, and when Windows is used with a default configuration, perl scripts don't support the full range of Unicode characters in filenames" Thus to trace a problem combination the actual hardcoded files are needed. What can work for one user may fail for another machine.

video is not a good way to show filename faults so 3 SAMPLE failing (1 page) files written at the same time from same folder are needed 1) file.tex 2) file.synctex 3) file.pdf plus the true characters as used in the folder system and even then It may well work in others test systems as each user environment can be wildly different.

[gaoqiangks]

@GitHubRulesOK The attatchment is my source file. I just put it in my home directory, and compile with xelatex-> biber-> xelatex*2. SumutraPDF 3.5.2 works well , but for the the lastest pre-release, forward-search doesn't work. 抽象代数讲义.zip

[GitHubRulesOK]

xelatex and doubled calls for bibliography / multi index always pushes the auxiliaries to their limits I dont have a working configuration for testing all such mixes but SumatraPDF would tend to work well out of the box with most in the past.

I was pleased to see all files in one zip but that means more points of conflict :-)

For test I used C:\Users\K\Downloads\抽象代数\default as folder and double click the title 抽象代数 in PRE-release (3.6.### 32bit portable) replies no sync info found at that point.

HOWEVER using the traditional 3.1.2 also says exactly the same so not just caused by pre-release so we look at the synchronisation file and see it says the path for syncing with is 1:c:/Users/gaoqiang/³éÏó´úÊý½²Òå/./algebra.tex which is not conventional LaTeX Unix or Windows file-naming thus the path is not valid for working with.

OK IF it were true folder name would it work with traditional 3.1.2 ? Lets mod a test file.

Does it work with pre-release ? Of course it will nothing changed there in SumatraPDF it is the sync file is not correct

SyncTeX Version:1
Input:1:c:/Users/gaoqiang/³éÏó´úÊý½²Òå/./algebra.tex
Input:2:c:/texlive/2024/texmf-dist/tex/latex/ctex/ctexbook.cls
Input:3:c:/texlive/2024/texmf-dist/tex/latex/ctex/config/ctexbackend.cfg
...
Input:201:c:/Users/gaoqiang/³éÏó´úÊý½²Òå/./algebra.aux
Input:202:c:/texlive/2024/texmf-dist/tex/latex/biblatex/lbx/english.lbx
Input:203:c:/Users/gaoqiang/³éÏó´úÊý½²Òå/./algebra.bbl

[gaoqiangks]

@GitHubRulesOK I re-uploaded a zip file. Unzip it and there's a folder named forward_sync, and you can create a folder C:\test_folder, and put forward_sync into it.

test_folder.zip

SumatraPDf 3.5.2 works well.

However, the lastest pre-release doesn't work.

The operating system is Windows 11, and the SumatraPDFs are downloaded from the official site (portable version). The file algebra.synctex is encoded with GB2312, which is the default for Chinese.

[GitHubRulesOK]

The second set is partly not working for me because it is not a simple SyncTeX set the PDF +TEX +SYNCTEX should ideally always be same time so as to ensure they are from same source compilation. tex = 12:26 pdf & syntex = 22:24 (your local time of compile ?)

3.5.2 does not work here even with correct folder name (default WINANSI filenames are NOT UTF compatible)

[gaoqiangks]

@GitHubRulesOK Yes, they are from the same source compilation. I change the system encoding from GB2312 to utf-8, now the lastest prelease works, but 3.5.2 does't work.