VimTeX in WSL1,when call the SumtraPDF to preview, it loads the wrong PDF Path

[Liampor]

Description

Using Windows 10 WSL1 + NeoVim + VimTeX. LaTeX project is located in D:\Project SumatraPDF is the default PDF viewer in Windows

Access the project in WSL1 via cd /mnt/d/Project then call nvim. After successfully compiling the sumatraPDF shows error while loading the PDF file: D:/mnt/d/Project/main.pdf

From my understanding, the path is wrong, there shouldn't be /mnt/d there

Steps to reproduce

1. LaTeX project is located in Windows 10 D:\Project
2. enter WSL1, enter the latex project root path via cd /mnt/d/Project, then enter neovim via nvim
3. compile the latex project -> succeed
4. try to preview it with SumatraPDF, which is installed in Windows 10
5. SumatraPDF cannot load the generated PDF, shows error loading file: D:/mnt/d/Project/main.pdf

Related Settings:

    vim.g['vimtex_view_general_viewer'] = 'SumatraPDF.exe'
    vim.cmd([[let g:vimtex_view_general_options
    \ = '-reuse-instance -forward-search @tex @line @pdf'
    \ . ' -inverse-search "' . exepath(v:progpath)
    \ . ' --servername ' . v:servername
    \ . ' --remote-send \"^<C-\^>^<C-n^>'
    \ . ':execute ''drop '' . fnameescape(''\%f'')^<CR^>'
    \ . ':\%l^<CR^>:normal\! zzzv^<CR^>'
    \ . ':call remote_foreground('''.v:servername.''')^<CR^>^<CR^>\""']])

Expected behavior

After the compiling，sumatraPDF should be automatically called and loading the generated PDF

Actual behavior

SumtraPDF cannot load the generated PDF error, shows the error, "loading file: D:/mnt/d/Project/main.pdf", the path is wrong, it shouldn't contain "/mnt/d"

Do you use a latexmkrc file?

No

VimtexInfo

System info:
  OS: Ubuntu 20.04.5 LTS
  Vim version: NVIM v0.9.0-dev
  Has clientserver: true
  Servername: /tmp/nvim.timo/afd90X/nvim.354.0

VimTeX project: main
  base: main.tex
  root: /mnt/d/Project/
  tex: /mnt/d/Project/main.tex
  main parser: texroot specifier
  document class: scrbook
  packages: adjcalc adjustbox alphalph amsbsy amsgen amsmath amsopn amstext array atbegshi atbegshi-ltx atveryend atveryend-ltx auxhook babel biblatex bigintcalc bitset blindtext blx-case-expl3 bookmark booktabs calc caption caption3 collectbox color colortbl csquotes datatool-base datatool-fp datetime2 defpattern enumitem environ epic etexcmds etoolbox everyshi expl3 fix-cm float fontenc fontspec fontspec-xetex footmisc fp fp-addons fp-basic fp-eqn fp-eval fp-exp fp-pas fp-random fp-snap fp-trigo fp-upn geometry gettitlestring glossaries glossaries-compatible-307 glossary-hypernav glossary-list glossary-long glossary-super glossary-tree graphics graphicx hycolor hyperref ifoddpage iftex ifthen ifvtex infwarerr intcalc keyval kvdefinekeys kvoptions kvsetkeys l3keys2e letltxmacro lipsum listings logreq longtable lstmisc ltablex ltcaption ltxcmds mathtools mfirstuc mhsetup multirow nameref nccmath overpic pageslts pbox pdfcol pdfescape pdftexcmds pgf pgfcomp-version-0-65 pgfcomp-version-1-18 pgfcore pgffor pgfkeys pgfmath pgfrcs pgfsys ragged2e refcount rerunfilecheck rotating scalerel scrbase scrkbase scrlayer scrlayer-scrpage scrlfile scrlfile-hook scrlogo shellesc siunitx stringenc substr supertabular tabularx tcolorbox textcase textcomp tikz tocbasic tocloft tracklang translations translator trig trimclip trimspaces typearea ulem undolabl unicode-math unicode-math-xetex uniquecounter url varwidth verbatim xcolor xfor xfrac xkeyval xltabular xparse xspace xtemplate
  source files:
    main.tex
    preamble.tex
  compiler: latexmk
    engine: -xelatex
    options:
      -verbose
      -file-line-error
      -synctex=1
      -interaction=nonstopmode
    callback: 1
    continuous: 0
    executable: latexmk
  viewer: General
    job: 
      pid: 5944
      cmd: SumatraPDF.exe -reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 '/mnt/d/Project/main.pdf' -inverse-search "/usr/bin/nvim --servername /tmp/nvim.timo/afd90X/nvim.354.0 --remote-send \"^<C-\^>^<C-n^>:execute 'drop ' . fnameescape('\%f')^<CR^>:\%l^<CR^>:normal\! zzzv^<CR^>:call remote_foreground('/tmp/nvim.timo/afd90X/nvim.354.0')^<CR^>^<CR^>\""
  qf method: LaTeX logfile

[TryerGit]

I have a similar setup as yours. I do not encounter this error. (I use VIM and not neovim though). Infact, I do not have any pdf viewer setting in my .vimrc at all. Have you tried setting Sumatra PDF as the default application to open pdf files in native Windows? I know that Acrobat PDF does not work well with VimTeX and the latter tends to be the default application to open pdf files in Windows.

[Liampor]

I have a similar setup as yours. I do not encounter this error. (I use VIM and not neovim though). Infact, I do not have any pdf viewer setting in my .vimrc at all. Have you tried setting Sumatra PDF as the default application to open pdf files in native Windows? I know that Acrobat PDF does not work well with VimTeX and the latter tends to be the default application to open pdf files in Windows.

thanks for your reply, sumatraPDF is always the default pdf viewer in Windows. But the problem is still there

[TryerGit]

Hmm... I am not a great trouble shooter in this regard. WSL1 is rather old. Is updating to WSL2 a possibility? https://learn.microsoft.com/en-us/windows/wsl/compare-versions

Can you open a pdf file from within WSL by the following command?

/mnt/d/Project$ cmd.exe /C start main.pdf

Does this open up main.pdf using SumatraPDF and other variants of this command from different directories and providing relative addressing? This command works at my end as I described and if it doesn't at your end that may be a guide to troubleshoot.

[Liampor]

Hmm... I am not a great trouble shooter in this regard. WSL1 is rather old. Is updating to WSL2 a possibility? https://learn.microsoft.com/en-us/windows/wsl/compare-versions

Can you open a pdf file from within WSL by the following command?

/mnt/d/Project$ cmd.exe /C start main.pdf

Does this open up main.pdf using SumatraPDF and other variants of this command from different directories and providing relative addressing? This command works at my end as I described and if it doesn't at your end that may be a guide to troubleshoot.

WSL1 is rather old. Is updating to WSL2 a possibility?
I would like to stay in WSL1 for better IO performance

/mnt/d/Project$ cmd.exe /C start main.pdf -- will return permission error. But when I cd to /mnt/d/Project and then run cmd /C start main.pdf this could open up main.pdf without any problem

Another thing is, if the project is created in WSL1 it self (stored in WSL1 space), it also works fine

[lervag]

Related Settings:

    vim.g['vimtex_view_general_viewer'] = 'SumatraPDF.exe'
    vim.cmd([[let g:vimtex_view_general_options
    \ = '-reuse-instance -forward-search @tex @line @pdf'
    \ . ' -inverse-search "' . exepath(v:progpath)
    \ . ' --servername ' . v:servername
    \ . ' --remote-send \"^<C-\^>^<C-n^>'
    \ . ':execute ''drop '' . fnameescape(''\%f'')^<CR^>'
    \ . ':\%l^<CR^>:normal\! zzzv^<CR^>'
    \ . ':call remote_foreground('''.v:servername.''')^<CR^>^<CR^>\""']])

I would suggest the following changes to your options (similar to what is suggested in the docs at :help vimtex-view-sumatrapdf):

vim.g.vimtex_view_general_viewer = 'SumatraPDF.exe'
vim.g.vimtex_view_general_options = '-reuse-instance -forward-search @tex @line @pdf'

To configure inverse search, you should instead configure from within SumatraPDF (again, as described in the docs).

SumtraPDF cannot load the generated PDF error, shows the error, "loading file: D:/mnt/d/Project/main.pdf"

Can you show a screenshot of the error message?

From my understanding, the path is wrong, there shouldn't be /mnt/d there

The path is not wrong. If you are in WSL, then the full absolute path is /mnt/d/Project/main.pdf. What happens if you do this:

1. Start WSL1. It should open a bash shell.

2. Run nvim /mnt/d/Project/main.tex. Does it open the main.tex file as expected?

3. Exit Neovim, then run SumatraPDF.exe /mnt/d/Project/main.pdf. Does it work?

[lervag]

I would like to stay in WSL1 for better IO performance

I don't think that's a very good reason, except for very specific purposes. LaTeX is not one of them, I believe. At least, I've not heard anyone complain about performance related issues using LaTeX and VimTeX in WSL2.

[Liampor]

Related Settings:

    vim.g['vimtex_view_general_viewer'] = 'SumatraPDF.exe'
    vim.cmd([[let g:vimtex_view_general_options
    \ = '-reuse-instance -forward-search @tex @line @pdf'
    \ . ' -inverse-search "' . exepath(v:progpath)
    \ . ' --servername ' . v:servername
    \ . ' --remote-send \"^<C-\^>^<C-n^>'
    \ . ':execute ''drop '' . fnameescape(''\%f'')^<CR^>'
    \ . ':\%l^<CR^>:normal\! zzzv^<CR^>'
    \ . ':call remote_foreground('''.v:servername.''')^<CR^>^<CR^>\""']])

I would suggest the following changes to your options (similar to what is suggested in the docs at :help vimtex-view-sumatrapdf):

vim.g.vimtex_view_general_viewer = 'SumatraPDF.exe'
vim.g.vimtex_view_general_options = '-reuse-instance -forward-search @tex @line @pdf'

To configure inverse search, you should instead configure from within SumatraPDF (again, as described in the docs).

SumtraPDF cannot load the generated PDF error, shows the error, "loading file: D:/mnt/d/Project/main.pdf"

Can you show a screenshot of the error message?

From my understanding, the path is wrong, there shouldn't be /mnt/d there

The path is not wrong. If you are in WSL, then the full absolute path is /mnt/d/Project/main.pdf. What happens if you do this:

1. Start WSL1. It should open a bash shell.
2. Run nvim /mnt/d/Project/main.tex. Does it open the main.tex file as expected?
3. Exit Neovim, then run SumatraPDF.exe /mnt/d/Project/main.pdf. Does it work?

vim.g.vimtex_view_general_viewer = 'SumatraPDF.exe'
vim.g.vimtex_view_general_options = '-reuse-instance -forward-search @tex @line @pdf'

Same issue, screenshot is here as you can see, a "mixed" path is here, "D:\ " stay together with "/mnt/d" I could only understand either "D:\project\main.pdf" or "/mnt/d/main.pdf", not a combined with them

Regarding your questions:

Run nvim /mnt/d/Project/main.tex. Does it open the main.tex file as expected? Yes

Exit Neovim, then run SumatraPDF.exe /mnt/d/Project/main.pdf. Does it work? No, report the same loading error with "mixed" path

[lervag]

Hmm. That's interesting and seems like a hard problem. The problem here is that you are using neovim inside a Bash shell in WSL, in which case VimTeX "believes" it is on Linux and behaves accordingly. This is usually fine, but in this specific case we are passing a file argument to SumatraPDF, which is a Windows applications, and thus the absolute path is not recognized because we are also crossing the WSL boundary.

I've not encountered this before, so before looking into any specific solution, I'm curious if this may be already resolved on WSL2 in the underlying interface between WSL and Windows. @TryerGit: Do you have WSL2 and SumatraPDF both available; if so, would you be willing to try and duplicate this issue? It should be quite easy:

0. Open a WSL2 shell (bash or zsh).
1. Create or copy some minimal pdf file and put it at some location, say /mnt/c/tmp/test.pdf.
2. Check what happens if you do SumatraPDF.exe /mnt/c/tmp/test.pdf from the WSL2 shell.

[Liampor]

Hmm. That's interesting and seems like a hard problem. The problem here is that you are using neovim inside a Bash shell in WSL, in which case VimTeX "believes" it is on Linux and behaves accordingly. This is usually fine, but in this specific case we are passing a file argument to SumatraPDF, which is a Windows applications, and thus the absolute path is not recognized because we are also crossing the WSL boundary.

I've not encountered this before, so before looking into any specific solution, I'm curious if this may be already resolved on WSL2 in the underlying interface between WSL and Windows. @TryerGit: Do you have WSL2 and SumatraPDF both available; if so, would you be willing to try and duplicate this issue? It should be quite easy:

0. Open a WSL2 shell (bash or zsh).
1. Create or copy some minimal pdf file and put it at some location, say /mnt/c/tmp/test.pdf.
2. Check what happens if you do SumatraPDF.exe /mnt/c/tmp/test.pdf from the WSL2 shell.

Is it possible do some tricks in vimtex. For examle I could open the pdf right in shell with sumatrapdf.exe $(wslpath -m /mnt/d/project/main.pdf)

the wslpath -m command first converts the path to windows style -> D:\project\main.pdf, then call the sumatrapdf to loading

then I could create a function in bash, actually in zsh

function sumatraOpen() {
  sumatrapdf.exe $(wslpath -m $1)
}

After that I could use sumatraOpen /mnt/d/project/main.pdf in shell

But If I tried to set vim.g['vimtex_view_general_viewer'] = 'sumatraOpen', it will return error:

VimTeX: Generic viewer is not executable!
        - Viewer: sumatraOpen
        - Executable: sumatraOpen
        - Please see :h g:vimtex_view_general_viewer

But I still believe there is some trick to overcome my problem

[TryerGit]

0. Open a WSL2 shell (bash or zsh).
1. Create or copy some minimal pdf file and put it at some location, say /mnt/c/tmp/test.pdf.
2. Check what happens if you do SumatraPDF.exe /mnt/c/tmp/test.pdf from the WSL2 shell.

I got some interesting results:

:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$

This is the folder where in Windows (via WSL) SumatraPDF.exe resides.

Typing :/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$SumatraPDF.exe

returns SumatraPDF.exe: command not found

Typing as if in Linux : Typing :/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$./SumatraPDF.exe

opens up SumatraPDF app with no file loaded.

:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe /mnt/e/GoogleDrive/CVs/CV.pdf gives me the exact same error as reported by @Liampor

I get: Error loading C:\mnt\e\...\CV.pdf in the SumatraPDF application window which opens but does not load the file. Of course the file cannot be loaded because for some reason, C:\ gets added to mnt\e\ which gives rise to a garbage nonexistent and unrecognizable folder path.

I further tried: :/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$cmd.exe /C /start /mnt/e/GoogleDrive/CVs/CV.pdf

This gives error: Invalid switch - "/mnt".

Then, I navigated to E:\GoogleDrive\CVs\ in Windows and opened up WSL here. This gives me:

:/mnt/e/GoogleDrive/CVs$

Now issuing :/mnt/e/GoogleDrive/CVs$cmd.exe /C start CV.pdf

opens up SumatraPDF and properly displays CV.pdf

Then, I wanted to test if this across folder problem persists in native windows. It did not. For e.g., I issued cmd.exe in Windows. This opens up a dos command prompt : C:\Users\TryerGit> Here, I tried to start the same pdf file across folders.

C:\Users\TryerGit>start e:\GoogleDrive\CVs\CV.pdf

This works just fine and the CV.pdf file opens up in SumatraPDF app.

So, it seems that the "problem" is not because of which version of is being used -- WSL1 or WSL2, nor does the problem seem to be in VimTeX. It seems that WSL opening of native Windows files cannot happen across folders or else it cannot work with absolute paths. It only works if the file resides in the current folder or possibly with relative addressing. I am not sure about @Liampor 's workflow. The above tests are news to me as well and somewhat unexpected -- I expected WSL to be able to handle opening files fine across folders -- but my workflow with SumatraPDF has been working fine thus far (knock on all wood) since I have \ll open up the pdf file via continuous compilation where the pdf gets created in the same folder as the .tex file somehow. I do not have any pdf reader settings in my vimrc.

---

ETA: What finally worked was the following:

:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ cmd.exe /C start "e:\GoogleDrive\CVs\CV.pdf"

This may hold the clue -- i.e., the path to be specified via WSL to a Windows file should following Windows naming convention.

The above opened up SumatraPDF and the pdf file just fine.

Below also works: :/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ cmd.exe /C start "e:/GoogleDrive/CVs/CV.pdf"

:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe "e:/GoogleDrive/CVs/CV.pdf" works, as does,

:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe e:/GoogleDrive/CVs/CV.pdf but the following does not work:

:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe e:\GoogleDrive\CVs\CV.pdf -- this gives error Error loading E:\GoogleDriveCVsCV.pdf because of backslash \ escape character? The following works:

:/mnt/c/Users/TryerGit/AppData/Local/SumatraPDF$ ./SumatraPDF.exe e:\GoogleDrive\\CVs\\CV.pdf

[lervag]

Is it possible do some tricks in vimtex. For examle I could open the pdf right in shell with sumatrapdf.exe $(wslpath -m /mnt/d/project/main.pdf)

the wslpath -m command first converts the path to windows style -> D:\project\main.pdf, then call the sumatrapdf to loading

then I could create a function in bash, actually in zsh …

Ah, yes, I believe this is the most elegant and simple solution. I.e., not to change anything in VimTeX, but instead to make a simple wrapper script. It should be a script, not a function. E.g., ensure you have e.g. ~/.local/bin in your $PATH in your .zshrc, then create a file like ~/.local/bin/sumatraOpen:

#!/usr/bin/env bash

sumatrapdf.exe $(wslpath -m $1)

Notice, though, it must be slightly more complicated. I can help, but I don't have the time right now. The point is, you need to only wrap the path, not the other arguments.

---

Also, thanks for the input, @TryerGit! I believe @Liampor already found a proper way to solve this with the wslpath utliity, and that the best way to proceed is to use a wrapper script on the user side.

[lervag]

@Liampor Notice that with the earlier proposed settings (except changing the viewer command), VimTeX will execute the following command:

SumatraPDF.exe -reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 '/mnt/d/Project/main.pdf'

So, the wrapper script must recognize the paths (both of them, probably), and wrap these with wslpath. It should not be too hard (e.g., you could start by assuming there are 5 arguments and wrap argument number 3 and 5).

[Liampor]

-reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 '/mnt/d/Project/main.pdf'

Sorry for the late response, as your suggestions, I have created a zsh-script called open-sumatra.sh in ~/.local/bin defined as

#!/bin/zsh
new_arg=()   # ceate arguments array
for arg ($@){
  if [[ "$arg" == /mnt/* ]] {
    # convert to windows style path
    winPath=$(wslpath -m $arg)
    new_arg+=$winPath
  } else {
    new_arg+=$arg
  }
}
$(sumatrapdf.exe $new_arg)

and in VimTeX set:

vim.g['vimtex_view_general_viewer'] = 'open-sumatra.sh'

the main concept is, once the string in arguments, which starts with"/mnt/" will be converted to windows style path and re-call the sumatraPDF.

So far it works with the loading pdf file, but not so robust I think, Because I’ve never written a script before... but a new error is unknow source: D:\xxxx\main.tex

Since the issue is not in VimTeX side, I will close for this.

Thank you all @lervag @TryerGit

[lervag]

Sorry for the late response, as your suggestions, I have created a zsh-script called open-sumatra.sh in ~/.local/bin defined as …

Yes, this looks quite good. It doesn't need to be perfect as long as it works.

So far it works with the loading pdf file, but not so robust I think, Because I’ve never written a script before... but a new error is unknow source: D:\xxxx\main.tex

That's strange. It is unclear where this error appears. Inside SumatraPDF? If so, then I believe the best way to debug is to test various forms of the command used in the command line. For instance, in a WSL terminal, try to run these commands:

SumatraPDF.exe -reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 'D:\Project\main.pdf'
SumatraPDF.exe -reuse-instance -forward-search 'D:\Project\main.tex' 1 'D:\Project\main.pdf'

Do you see the error in both of these?

[Liampor]

Hi @lervag

SumatraPDF.exe -reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 'D:\Project\main.pdf' Will return the same error message as my script：unknow source file : (D:\xxxx\main.tex)

change to SumatraPDF.exe -reuse-instance -forward-search '/mnt/d/Project/main.tex' 1 'D:\Project\main.pdf' then it will return unknow source file: (\\wsl$\Ubuntu\mnt\d\Project\main.tex)

Issue may be related: https://github.com/sumatrapdfreader/sumatrapdf/issues/377

[lervag]

The issue you link is related, but I'm not sure if it is exactly the same.

I believe the problem is related to the inherent conflict that you are using a Windows application as PDF reader with a document compiled with synctex in a Linux environment. The synctex file uses a syntax that includes the source file path, and SumatraPDF probably does not "understand" the unix type paths. Or something like that. You can check this by examining the .synctex.gz file. First unzip the file, then read it with any editor. If I'm right, the synctex file will have /mnt/d/... paths, whereas SumatraPDF uses D:\ paths. As a test, you could try to change the paths in the synctex file and gzip it again afterwards. I believe things should work then.

[Liampor]

Hi @lervag

I have opened the main.synctex file and search with main.tex

SyncTeX Version:1
Input:1:/mnt/d/project/  ./main.tex
...

and then replace it with

Input:1:D:\project\./main.tex

then give command line

SumatraPDF.exe -reuse-instance -forward-search 'D:\Project\main.tex' 1 'D:\Project\main.pdf`

It works !

Now the question would be, how to control the *.synctex to overcome my problem

[lervag]

First, I'm glad to hear you tested this and can verify it works. It means I understood things correctly (I wasn't quite sure).

I think it would be possible to overcome the problem by making the wrapper script more advanced. It would require some semi-advanced scripting, e.g. a flow like gunzip ... -> advanced sed (or similar) -> gzip. I don't have the time to actually suggest something concrete here, but if you do expand the script you suggested in this comment, then please feel free to share the updated version. It may be of interest to more people.

In fact, this story could potentially be a helpful addition to the faq section (e.g. "How can I use VimTeX with SumatraPDF in Vim/Neovim in Windows WSL?"), at least if you happen to find something that works well.

[Liampor]

Hi @lervag. After some searchs I finally get it to work now. I have found a command in forum:

find -maxdepth 1 -name "*.synctex.gz" -execdir \
  bash -c 'cat "{}" | gunzip | sed --expression="s@/mnt/\(.\)/@\1:/@g" | gzip > "{}.tmp" && mv "{}.tmp" "{}"' \;

Explanation:

1. find the *.synctex.gz file under current working path
2. unzip the file to read the *.synctex file
3. remove the /mnt/ to let the /mnt/d/ like path to windows style d:/ in *.synctex
4. re-zip to *.synctex.gz

My script is now like:

#!/bin/zsh
# This script is used to let the SumatraPDF open the pdf after path conversion

new_arg=()                 # ceate arguments array
declare -i idxMntOccur=0

for arg ($@) {
  if [[ "$arg" == /mnt* ]] {
    # convert to windows style path
    idxMntOccur=idxMntOccur+1
    winPath=$(wslpath -m $arg)
    new_arg+=$winPath

    if (($idxMntOccur == 1)) {
      # convert the path in .syntex to windows style
      # run only "/mnt/d" like path is detected
      find ${PWD} -maxdepth 1 -name "*.synctex.gz" -execdir \
        bash -c 'cat "{}" | gunzip | sed --expression="s@/mnt/\(.\)/@\1:/@g" | gzip > "{}.tmp" && mv "{}.tmp" "{}"' \;
    }
  } else {
    new_arg+=$arg
  }
}

$(sumatrapdf.exe $new_arg)

[lervag]

Hi @lervag. After some searchs I finally get it to work now. …

Very cool! I took the liberty of slightly cleaning up your post, and I will write a short faq entry with a link to it. If that is OK with you, that is?

In case you should adjust or improve this further, please feel free to update your comment and/or continue the thread.

[Liampor]

Hi @lervag. After some searchs I finally get it to work now. …

Very cool! I took the liberty of slightly cleaning up your post, and I will write a short faq entry with a link to it. If that is OK with you, that is?

In case you should adjust or improve this further, please feel free to update your comment and/or continue the thread.

Of course, just take it without any restrictions. What I have done is just under your suggestions.