search

sumatrapdfreader / sumatrapdf

SumatraPDF reader
http://www.sumatrapdfreader.org
GNU General Public License v3.0
13.54k stars 1.72k forks source link

Fix synctex handling of gzipped files #3697

Open kjk opened 1 year ago

kjk commented 1 year ago

At some point synctex started failing to parse sync files. I narrowed it down to them being .gz files but no luck figuring out why it fails.

I verified I can load and ungzip using my code.

Unfortunately synctex only parses from files, not from memory and fixing that would not be easy.

So here's a hack: ungzip to temporary file and pass uncompressed file to synctex.

kjk commented 1 year ago

Relevant code is SyncTex::RebuildIndexIfNeeded

GitHubRulesOK commented 1 year ago

I seem to recall (not revisited as am on 32bit ok ?) it was only 1/4 of variants i.e. installed 64bit but not standalone ?

kjk commented 1 year ago

I don't think I've seen 100% pattern.

GitHubRulesOK commented 1 year ago

I note you said compressed not an issue for you on 64bit, but your "biased" to have such support ?? https://github.com/sumatrapdfreader/sumatrapdf/discussions/2640#discussioncomment-2859309

inexperienced synctex users may cloud the issue as the files for synctex must be known to be tested before say it does not sync. hence best to use a good referenced set, not users own.

unknown if file size of synctex is a factor, but those with big synctex.gz files suggested uncompressed.syctex was working !

commonly compressed copy of a working install fails on those with 64bit systems commonly those advised to use portable reported similar to this https://github.com/sumatrapdfreader/sumatrapdf/discussions/2741#discussioncomment-2982137

However one user that dug deeper into working non working was this one !! https://github.com/sumatrapdfreader/sumatrapdf/issues/2642#issuecomment-1159665980

GitHubRulesOK commented 1 year ago

as a result of my failed demo (thanks now it is not crashing) I note there are internal problems with the fact that 1) during compilation a synctex file is always stressed as should be built in the same folder as its tex (1st rule of LaTeX is dont use other folders for compiler runs only move files after project completion.)

2) hence the folders referenced by the wide range of samples come from different drives as absolute addresses (my own sample uses ./samename.tex to avoid such as odd "cant find relative.tex" messages (the file is clearly there) so there is one source of conflict.

3) Looking at unpacked OP MWE.tex with problems it was possibly using an auxiliary.aux folder (as per 1st rule of LaTeX, likely to cause problems)

GitHubRulesOK commented 1 year ago

possibly related to https://github.com/sumatrapdfreader/sumatrapdf/issues/3774