Does rendering a PDF file in a HTML window retain hyperlinks?

I never say the pdf does not retain links, only when you load a pdf in a Canvas, the links does not works anymore in the Canvas.

Now if those links can be called from a “Declare” ? Or something else… That I do not know.

[quote=401855:@Steve Kelepouris]Retaining all internal and external links means twhat? How can I access those tags/links via Xojo?

If it can’t be done easily, then I’ll say: “Thanks for all the fish”, otherwise, if someone can explain this in really simpleton terms, then . . .[/quote]

I’m sorry, Steve. I thought I had been clearer. What I meant is that I have always used pdf.js and I serve the PDFs through it. Since I use pdf.js (a javascript PDF viewer) it doesn’t matter how the PDFs are created.

What I meant is that perhaps it’s easier handling a PDF than trying to generate an interactive canvas. Alternatively the image could be served via a webview in HTML with an image map.

The original title asked if it’s possible to render a PDF file in an HTML window retaining hyperlinks. I explained I have done this using pdf.js but you could also generate one image and one html map that maps sections of the image into links.

I’m missing why you’d want to do it through Xojo (not that I think you shouldn’t, but it didn’t fit the original title of the post).

and HTMLViewer…

It’s hard to describe, but it does fit the original title of my post (not that it really matters). I’ll explain:

The “Help System” is “dynamic” and an integral part of my application. It can be accessed throughout. It overlays (in a physical sense) the application window underneath. The “Help System” window is modal and a fixed size, as is the main application window.

The best way to sum up what’s going on, and the point of this post is via a graphic.

Please read the information in figure 1. The rest are just pointers. This is based on the Graph Editing Tools, which is quite prolific throughout the help window.

What’s made things more difficult is that there are three ways to get there, ie. ALL ROADS LEAD TO the Graph Editing Tools explanation (figure 4.) - although obviously not finished.

figure 1.

  • the link at left takes you directly to the graph editing tools section

figure 2.

  • the little blue (i) icon takes you directly to the graph editing tools section

figure 3.

  • shows a typical example of a reference to the Graph Editing Tools. It does look blue italic (and will be underlined to represent a link), But at this point it does NOT take you directly to the graph editing tools section - but that is what I would like to happen.

As Greg suggested, there may be a way to access the locations of the link text (fig. 3.) but not easily. I think I’ll have to manually do it.

@Greg: Actually, I think colossal might beat gargantuan? - We might have to do a poll :slight_smile:

Steve:
What is the link behind each in figures 1 to 3? I mean, the actual link.

PS: I really admire your aesthetic eye. I have none, so I’m always envious when someone does :slight_smile:

Do you mean “how” the link gets there?

If so, the link, or Y position is the pixel number which you can see at bottom left in the screen shots. 18,786 pixels (at this point) is where we arrive at the Graph Editing Tools section/topic.

Don’t forget, the canvas picture “holds” an image of approx. 44,000 pixels high (and counting). Yes, Forty Four Thousand. Consider it as a very long scroll. I was surprised that I could do this - but it is good - Xojo let me do it, and it was good - and power to the people that made it so.

Sorry about the last bit, but it is a long long bitmap image of “galactic” proportions displayed within a canvas. It is not slow, and how you get there is driven by the VerticalScrollBar.Value.

[EDIT] For example:

The (pseudo link) in figure one has in the MouseDown Event:

VerticalScrollBar.Value = 17390

That moves the scroll and changes the “picture” position to the Graph Editing Tools location. Same goes for the (i) icon. They do the same thing.

I understand.

What I meant is why not trying to do it in a different way, using PDFs with internal anchors.

Take this random PDF: https://www.antennahouse.com/XSLsample/pdf/sample-link_1.pdf

If you download it you’ll see it has an internal link to #appendix-a. This works within Adobe Reader and all other readers, but doesn’t work when opened from a webview.

Now take a look at pdf.js: https://mozilla.github.io/pdf.js/

pdf.js is a PDF reader for JavaScript. It should be able to render in a webview your PDF.

Try opening the demo: https://mozilla.github.io/pdf.js/web/viewer.html

And in the demo try uploading the PDF you downloaded earlier.

Once uploaded you can see the PDF contents, but in reality it’s no longer a PDF but an HTML view.

This means that internal anchors become accesible. If you add #appendix-a to the URL you’re taken to the correct location.

It also means other PDF shortcuts also work. For example #Page=2 takes you to the top of page 2.

If you can embed pdf.js in an htmlview you can load the PDF in it and call the PDF links directly. You can add those links in InDesign.

This is what I was proposing, rather than having a huge canvas to deal with and having to reinvent what the PDF already does natively :slight_smile:

Hello.

I’ve made a quick and dirty sample project to show what I mean. Sorry it took a while. It’s the first time I’ve done it in Xojo HTMLViewers :smiley:

https://github.com/eduo/XojoPdfJs

This file will compile into a desktop application for Windows or Mac or LInux and should show a PDF viewer that can be navigated from Xojo. I’ve included a couple of buttons that show the basic manipulation I was talking about:

  • Open and close files
  • Navigate to specific sections inside a PDF (as defined when creating the PDF)
  • Navigate to specific pages inside a PDF

The viewer itself is the default pdf.js viewer. A simplified one can be easily created following their instructions.

Thanks Eduardo, that is a lot of work to do and I appreciate your time taken.

At this point I’m still writing the “help system” and because I’m using InDesign, I guess I can make a decision later about how to present it - nothing will be lost regardless of how I go finally about it.

Cheers.

[quote=402870:@Steve Kelepouris]Thanks Eduardo, that is a lot of work to do and I appreciate your time taken.

At this point I’m still writing the “help system” and because I’m using InDesign, I guess I can make a decision later about how to present it - nothing will be lost regardless of how I go finally about it.

Cheers.[/quote]

Right. In the end I wanted to do this for a while and I wanted an excuse to do it so this was a good as any :smiley:

I internally now use as combination of factors to decide how to present PDFs, but I alwasy try to do so, because it’s a format better suited for my needs in a lot of cases (and because in many apps I need to present existing PDFs and I can’t choose the format).

In the past I’ve used both PDF and HTML as a way to present documentation, but for graphics-heavy documentation it may be easier to do and maintain in InDesign than HTML.

If you can use HTML, the solution obviously easier since what you want is already built-in (remember also that HTML supports “click maps” internally. Where a link can point to any part of a larger image. It’s standard HTML functionality that solves many problems and it seems to have been forgotten. it may also help in our case if you want to go that route (you’re essentially replicating this functionality through Xojo using coordinates, I think).

InDesign, IIRC, can create HTML maps for regions automatically as well. A secondary advantage (as with any HTML solution) would be that a “web version” could be presented as well for the users’ own web browser (like Xojo offers both online and offline docs)

67MB ?

10 minutes to download using this slow connexion :frowning:

[quote=402876:@Emile Schwarz]67MB ?

10 minutes to download using this slow connexion :([/quote]

The zip file is 6.9 MB uncompressed. O_o I just downloaded it in four seconds.

MacBookAir:XojoPDFjs eduo$ du -sh * 4.0K App.xojo_code 4.0K Build Automation.xojo_code 4.0K FileTypes1.xojo_filetypeset 4.0K MainMenuBar.xojo_menu 4.0K README.md 32K Window1.xojo_window 4.0K XojoPdfJs.xojo_project 4.0K XojoPdfJs.xojo_resources 6.9M pdfjs
How are you downloading it?

Wrong click probably… I get: GitHubDesktop.zip.

So I tried once more and get the 3MB zip this time.

Works fine (except for some links, but probably my fault: this is one of my pdf generated from an html file).

Niiiice ! :wink:

Edit: THANKS Eduardo.

I think you may have clicked by error on the GitHub Desktop application (from Github, not me) that allows you to manage repositories in Github.

Direct link to the latest version should always be https://github.com/eduo/XojoPDFjs/archive/master.zip

Internal PDF links should work OK. Links to external pages may try to open in the same HTMLViewer because I included the PDF.JS package as-is. It should be possible to catch the event and redirect elsewhere (just as it should be possible to “call” the properties of the PDF to display in the window using the title property and titleChanged event.

Since it really uses PDF.JS behind the scenes, all possible bugs or limitations that package may have also exist here. Just to clarify.

PDF.JS can be updated by replacing the contents of web/pdfjs/web and web/pdfjs/build with their corresponding folders from PDF.JS (either built by hand or using pre-built packages from Getting Started )