Opening a PDF in a new tab

#1

How can I open a PDF stored in my wiki in a new tab?

I’m starting a wiki to track my work on a subcommittee of a local School Board I’ve recently joined. Each month, we will review 5 - 10 documents in PDF form. I’d like to include them in my wiki (which will be only for my own use.) Some of these PDFs are reasonably small: a few dozen KB. But a few are much larger: 1 - 4 MB.

These larger ones are not rendering inside TW; I’m not sure why. I was hoping to offer myself a simple workaround. From some other wikis, I’ve used a download link for binary documents, with the following code:

title: $:/_/macros/download-link
tags: $:/tags/Macro

\define download-link(title, text:"download", class:"")
<a 
    download=<<__title__>> 
    title=<<__title__>> 
    class={{{ [[binary]] [<__class__>] +[join[ ]] }}} 
    href={{{ [[data:]] [<__title__>get[type]] [[;base64,]] [<__title__>get[text]] +[join[]] }}}
><<__text__>></a>
\end

which I can use by

<div class="doc-downloads">Download as <<download-link "PDF tiddler title" "PDF">></div>

I brought that macro into the current wiki (and yes, at some time, I will need to switch to something newer than the macro, but I don’t think that’s at issue!), and while it works fine, I don’t really want to download the documents; if possible, I would like to simply open them in new tabs.

But adding target="_blank", with or without keeping the download property doesn’t word:

  • If I keep download, it simply offers to download the document
  • If I drop download, it opens a new tab, but with no content, and the URL: about:blank#blocked (I’m using Brave.)

Any suggestions?

#2

If I had to have the PDF’s in my TiddlyWiki instance and I had no choice but to setup an option to open PDF’s in another browser tab.

I would set things up this way:

<a href={{{ [[tiddler.pdf]get[text]addprefix[data:application/pdf;base64,]] }}} target="_blank">right-click this link and choose to open the PDF in a new tab or a new window</a>

Right-click required because left-click on the link does not work when that link is a data uri. I don’t know enough about this stuff to tell you why.

#3

Thank you. That does work in Firefox, but not in Chrome, and not in my usual browser, Brave. I get no context options to open in a new window/tab.

#4

I did not test it, but if your PDFs are included using _canonical_uri the tm-open-window or tm-open-external-window messages should work.

https://tiddlywiki.com/#WidgetMessage%3A%20tm-open-window:[[WidgetMessage%3A%20tm-open-window]]%20[[WidgetMessage%3A%20tm-open-external-window]]

#5

Right-click on a link does not open a context menu for you?

Works with my Chrome web browser. I’ve never used a web browser that does not have right-click on a link to open a context menu.

Aside: I thought you were asking to open a PDF (stored inside the TiddlyWiki) in a new tab. Did I misunderstand something there?

#6

I get a context menu, but it does not include “Open in new tab” (or any related link-opening options):

Brave:

image
image1817×700 76.7 KB

Chrome:

image
image1827×1006 115 KB

It works fine in Firefox:

image
image1823×742 75.6 KB

That’s the goal exactly.

Ideally, I want this in a single-file wiki. I edit it using Node, but would like to export it without external data. If I can’t get them to stop creating the stupidly large PDFs that may not be practical, but I will try. (They seem to be scanned images of printed documents; there’s no good reason for that, which I can see.) So I don’t think canonical_url will help. But I don’t have much experience with it, and may be misunderstanding.

#7

Here’s what I get with Chrome. The Chrome web browser on Chromebooks must have more features than Chrome on other computers.

  • I’m also used to Internet Explorer on Windows computers providing the same options as Chrome on my Chromebook.
  • The “Open with Firefox” menu item is an option to open the link in the Android version of Firefox

Screenshot 2024-01-07 2.38.27 PM - Display 1
Screenshot 2024-01-07 2.38.27 PM - Display 11085×785 54 KB

#8

Or the version I have on this small Surface Tablet/Laptop is particularly anemic.

Thank you for spending the time on this. Unless someone comes along with a new solution, I’m not going to go any further. It’s for my own use, and I have a tolerable work-around. Mostly I was surprised that the obvious thing didn’t work and was wondering why.

Again, thank you very much for your help!

1 Like
#9

Sorry I can’t help you much.

I keep files (PDF’s etc.) outside of TW instances, which makes links to open in new tabs trivial.

I cannot stand TW instances bulked up with PDF’s etc. because I repeatedly/constantly save TW instances during edit sessions, and bulk just slows things down too much for my liking.

#10

Not at all. Thank you very much for trying!

My wikis are of a migratory breed. I will host them in various places, email them to colleagues, and there may be half a dozen versions of them – in various states of completion – all around at the same time. This makes your workflow difficult for me. What could serve as a canonical URL in this scenario?

I almost always edit them in Node, and save to Git, generating standalone versions from this whenever necessary. Doing that, I’m only saving the changed bits at a given time, and it all takes place behind the scenes; saves are quick enough to be unnoticeable. So my concerns about bloat have only to do with the bulk of the standalone versions. Is this too large to email? Will my cheap hosting provider finally topple over if I add one more 15MB wiki?. Etc.

#11

I just had a thought, a work around is if you can read an embedded PDF in a tiddler, rather than open the pdf in another window/tab you can open the tiddler in a new window and read there.

  • See the view toolbar more dropdown
#12

Thank you for the suggestion. Unfortunately, Tiddlywiki does not want to render these PDFs either inline or in that alternate popup window. I don’t know why. I don’t know if there’s a size restriction, or if perhaps whatever it is that makes these ones so large is also something that TW can’t handle.

I will check to see if we can fix this at the PDF-generation end. I think that the person who creates these probably prints a MS Word document, uses a physical stamp to add “Enclosure # _________” to the top, hand-writes the enclosure number, then scans the resulting document into a PDF. I will suggest that instead she adds the enclosure number to a copy of the Word document, then simply prints it to a PDF driver (there’s probably one built into Word, but I don’t know for sure; I’m not much of a Word user.)

#13

I think understand why, the open in new window displays the text field rendered. It does not render the other view related content such as the PDF I may already have a solution if that really is the problem.

I just dropped a PDF on tiddlywiki.com and used open in new window successfully. it was type application/pdf

#14

Yes, I did say in the OP that most PDFs work fine. The two that don’t also happen to be much, much larger than the others. I was assuming that the size was the issue, but I could easily be wrong.

#15

Sorry, couldn’t resist…

PORTABLE document format.

:roll_eyes:

I’ve always said, HTML is (or easily can be) portable.

(I’ll get my coat).

#16

The ancestors of laptops, were called “Portable”, but we often renamed them “luggable”. Perhaps html with all its external images is a “Luggable Document Format” LDF. :nerd_face:

#17

AFAICT there’s a limit to the browser’s URL length, which you may hit with large data-encoded PDFs.
A quick search popped this article, which accuracy should be verified:

HTH,

Fred

#18

Sorry if I misunderstand, or you’ve already solved your issue.

I have a wiki that links to PDFs only - all my music charts. I’ve created a tiddler to reference each PDF, so they open in the wiki.

BUT I also use Brave and have no problem opening the PDFs, stand-alone in a new browser tab. I can right click and the context-menu allows.

I recall figuring out the file-path from a TW perspective was tricky, so I just tested now, using the same pathname style… without a need to “right click”. PDF files size = 4.7mb

file:///D:/Downloads/Catalogs/Tenso.pdf]]

#19

I’m pretty sure those limits don’t affect data-uris.

But I suppose we should check.

I haven’t solved it, although I have a reasonable enough work-around that I’m not overly bothered by not solving it. Now it’s mostly curiosity.

In my case, the PDFs are embedded, and most of them load fine. But a few of them (coincidentally or not, it’s the ones that are far larger than the others) don’t load in the wiki. I’m using a second link that offers a download for these rather than loading them inline, and it works fine. It’s simply not what I would prefer to do.

#20

Is loading them externally out of the question?
I thought you could access almost any file format in an external folder, regardless its saved locally, on google-drive, or dropbox?

Another thought, in the past I’ve come across PDFs that behave oddly, can’t be opened by one or other app, or won’t display in a web browser yet reveals itself in a file browser. I’d thought it was due to how the PDF was created, ie. metadata attached to prevent printing or selecting text, etc.