Losing Hyperlinks when Saving As PDF

There are two "types" of PDF conversion: client-side and server-side.  They both use different techniques to create the PDF:

• The "client-side" conversion (right-click, Save as PDF) uses Word to print the document as a PDF.  The features and functionality available here primarily depend on Word.
• The "server-side" conversion (via a workflow or API call) uses a library to convert the document to PDF.  The features and functionality available here primarily depend on the library.

You say that this breaks both standard hyperlinks and also the table of contents.  I just tried this and, whilst the table of contents was broken, I couldn't make the hyperlinks break.  Can you confirm?

Thanks.  Both the Table of contents and hyperlinks break.  I'm having to take the documents out of M-Files and resave them "As PDF" on my local computer to preserve the Table of Contents links and hyperlinks.

The table of contents is the more important item for us.  Because we create a lot of documents in Word with table of contents, then we make the PDF available for everyone, and these documents have too many pages to be scrolling down to just to get to that section.

Maybe I'd create a single step "Convert to PDF" workflow temporarily just to accommodate this while I research a solution. 

I thought there may be a setting in M-Files that would need to be set.

I'm not aware of a setting, although this isn't something I've come across before.

I am now not in work for a few days. Have you asked this of support?

Have just run a test. When using server side conversion the links still work. When using client side conversion the table of contents links are broken but hyperlinks still works even though they don't look like links in the PDF.

Have just run a test. When using server side conversion the links still work. When using client side conversion the table of contents links are broken but hyperlinks still works even though they don't look like links in the PDF.

I can't find any existing tracker items created for this issue.  If you can send me a private message with your company details then I can look to create one for you.

However: the workaround would be to use the (working) server-side conversion for now (as you suggested).  Depending on what skillset you have in your company, just be aware that you can probably use the ConvertToPDF API method (M-Files API) from scripting, if that would be more appropriate than using a workflow; my suggestion would be to have a property that triggers this running ("Convert to PDF = true"), and an on-demand background process that converts the document to PDF and removes the trigger.

Regards,

Craig.

So Joonas Linkola - who is incredible at finding stuff like this - pointed out to me that there is actually a tracker item.  It doesn't specifically speak about table of contents, but it does seem to be the same underlying issue.  The tracker item ID is 128483.

Please do send me your company details and I can add you as someone who has requested this.

Regards,

Craig.

Thank you again for your response.  I have contacted M-Files support and I was given the ID 159483.  I was told that an improvement request will be sent to the dev team.  The dev team will review and put out a fix at a future release.  Meanwhile, I was told to just Save As the document to PDF on my local computer before putting to M-Files.

We have also a client requesting the same, please vote me up..

No need to save to local - that's way more steps! You can still use the "Convert to PDF (separate File) option if convenient - but using the editng application to "Save As... PDF" will bring you to the multi-file if used correctly. 

I've had users save to the local PC - it creates way more steps and way more tedious and open to error. 

Just my experience these past few years. 

Please add me too Craig, I gave up asking as I was told it was a general limitation of PDF xChange

I've added both of your organisations to the tracker items.