Bad way of storing path of background PDF file inside .xopp files?

[liar666]

Hi,

There is a problem in the way "background" PDF file paths are stored in .xopp files. When reopening a .xopp file from another directory than the one in which the .xoop was created results in the "background" PDF not being found and Xournalpp asking for another path.

Steps to reproduce the problem:

• Get a PDF file, let's say test.pdf
  • wget -U "Mozilla/35.0"https://arxiv.org/pdf/2112.13896.pdf -O test.pdf
• Put it in some subdir/ sub directory of .
  • mkdir subdir && mv test.pdf subdir/
• Stay in .
• Open dir/test.pdf in xournalpp
  • xournalpp dir/test.pdf
• Create some annotations
• Save the result in test.xopp file
• Move to subdir
  • cd subdir/
• Try to open test.xopp in xournal again
  • xournal test.xopp

Actual Result xournalpp will complain that "background" PDF file cannot be found and prompt for a new location

Expected result xournalpp opens the files (xopp & pdf) correctly

Problem From my simple understanding (looking at the path xournalpp is trying to access), it seems that the path stored in the .xopp file is relative to the current directory from which xournalpp is opened, instead of relative to where the background PDF is with respect to the path of the newly created .xopp file.

[liar666]

NOTE: even reopening from the original directory does not work in Xournal++ 1.1.1 └──libgtk: 3.24.20

By unconmpressing the .xopp file, I can see that the path is subdir/test.pdf:

<background type="pdf" domain="absolute" filename="subdir/test.pdf" pageno="1"/>

So it seems 1- the path is indeed relative to xournalpp exe starting directory, not between pdf/xopp files 2- the way the path is used/reconstructed when storing is not the same as it is used/reconstructed when opening the .xopp file. I imagine the .xopp dirpath is appended to the xml "filename" attribute from the .xopp which would result in "subdir/subdir/test.pdf" which would explain why xournalpp does not find the file...

[FabianSchwartau]

Interestingly, Xournal++ 1.1.1 is using an absolute path here. This is also quite annoying, as I am dealing with files inside an SVN repo. Other people have the files in different locations and we always have to select the background pdf after pulling the latest version from someone else. I also think that the link should be relative to the xopp file, or ask the user if he prefers an absolute link.

[FabianSchwartau]

This seems to be related to https://github.com/xournalpp/xournalpp/issues/2638 and https://github.com/xournalpp/xournalpp/issues/3189

[mesonium]

This seems to be related to #2638 and #3189

and to https://github.com/xournalpp/xournalpp/issues/2736 and somehow to https://github.com/xournalpp/xournalpp/issues/3273

[andrewaclear]

Ya it seems to be using absolute path (unless there is a new update that has not been released yet). Please use relative path it would fix all these issues.

[vincent1703]

That is correct, I wanted to signal a bug but found this existing thread. Xournal ++ is using the absolute file path. If it was the relative file path, I would not have the issue. The issue is that I use Mega cloud to sync the folder in which I have PDF and xopp annotations of the pdf, and whenever I open it on my second computer the pdf file is not found because it shows the absolute file path instead of the relative one.

I can fix it easily because I know where the pdf file is, but whenever I change computer I have to do it all over again. Don't have time to work on it now but should be an easy fix for whoever would like to work on it if they have the chance.