macOS
3.0.2
Joplin Cloud
Markdown Editor
I've found a weird little anomaly.
I'm trying to link to a particular page on a locally hosted pdf. When I use "[Link](file:///Users/routetofile/filename.pdf)", it links perfectly. But Joplin won't recognise "[Link](file:///Users/routetofile/filename.pdf#page=16" as a link. Any ideas why?
I do not understand the technicalities but this is discussed in this GitHub issue about URLs with parameters not working.
opened 01:24AM - 19 Feb 22 UTC
closed 04:08PM - 30 Mar 22 UTC
bug
stale
## Description
I am trying to open a pdf to a certain page via link to local … files.
Say I have a pdf at `/home/abc/file.pdf`
In markdown this works fine as it should.
```
[File](file://home/abc/file.pdf)
```
However, when I try to specify the page number
```
[File](file://home/abc/file.pdf#page=4)
```
Nothing happens. On seeing the `journalctl` logs I see this error.
```
Feb 19 01:13:08 appimagekit-joplin.desktop[7182]: gio: file:////home/abc/file.pdf%23page=4: Error when getting information for file “//home/abc/file.pdf#page=4”: No such file or directory
```
I have tried to URL encode the path, like so
```
[File](file://home/abc/file.pdf%23page%3D4)
```
but this still doesnt work.
Shouldn't it (i think electron handles this) just check for the existence of `file://home/abc/file.pdf` instead of `file://home/abc/file.pdf#page=4`
## Environment
Joplin version: 2.7.12
Platform: Linux
OS specifics: Ubuntu 18.04
## Steps to reproduce
1. Create a note with the following text
```
[File](file://home/abc/file.pdf#page=4)
```
2. Try to open the link.
3. The link doesnt work. Nothing happengs.
## Describe what you expected to happen
The pdf should open at the correct page number.
## Logfile
```
useMessageHandler.ts:16 Got ipc-message: file:////home/abc/file.pdf#page=3 null
Logger.ts:219 06:49:17: CommandService::execute: openItem file:////home/abc.pdf#page=3
```
No error messages.
## Diagnosis
I think these [lines](https://github.com/laurent22/joplin/blob/dev/packages/app-desktop/gui/MainScreen/commands/openItem.ts#L22-L32) might be the reason.
Is there a reason we are using `openPath` for files instead of `openExternal` whose argument is URL.
Huh. From that it seems that the issue ran out of steam. It's probably not a very common thing to do, and the team have to focus on what would benefit the majority of users I guess.