Iain, there is a plugin for CEF3 that we think might help out. We need to do some work in the product and we're going to do some R&D into that. We are not going to pick this up until after Sept, U10 is our focus right now. 

 Confirmed ,work fine with G303 Patch Tested  with a pdf  460 pages, 1703 ko Tested with pdf generated with  itext 2.1.7 version pdf 1.5 Tested with pdf generated with ghostscript 9.01 version pdf 1.3

To add some additional info to this, and perhaps give an internal view on some of our 'releasing software' life.. The pdf enhancement was 'code complete', but we have to go through some legal processes in regards to scanning our source code to check for 3rd party licenses. CEF3 is a particularly nasty one, it as a few things in there, specifically around CODECs, that needed legal advice so we had to check with the lawyers.  We did not get the all clear in time for G302.  Now we do have all we need to release, so unless something unforeseen happens, we should be good for G303. 

I just checked, and no it's not, it's set for G303. I've not spoken to anybody, but I'd assume we did not have enough time to complete the work in time for the EOD for G302. 

 Well, nothing new in the G302 Patch 

Adrian Gosbell said

Adrian Gosbell said Iain, there is a plugin for CEF3 that we think might help out. We need to do some work in the product and we're going to do some R&D into that. We are not going to pick this up until after Sept, U10 is our focus right now.   

As an update to this one.. there is pdf support in a newer version of the CEF3 library. Seems this caused some issues in Uniface which we are working through. We are aiming to have this included in the G302 patch on Uniface 9.7. TBA for Uniface 10.   

http://unifaceinfo.com/fixes/issuelist/31403.php  it's not a bug, but we treated it as one more for our administration purposes. 

Adrian Gosbell said Iain, there is a plugin for CEF3 that we think might help out. We need to do some work in the product and we're going to do some R&D into that. We are not going to pick this up until after Sept, U10 is our focus right now.   

As an update to this one.. there is pdf support in a newer version of the CEF3 library. Seems this caused some issues in Uniface which we are working through. We are aiming to have this included in the G302 patch on Uniface 9.7. TBA for Uniface 10. 

Apparently the .gov.uk site now only allows you to download forms if you have Adobe DC. So I can no longer put off migrating. I will have to work on the web browser solution as fast as possible. 

I've tested the solution proposed by sochaz with shell.explorer : I've created an OCX field and selected the 'Microsoft Web Browser'  $WEB_HANDLE$ = $ocxhandle(MyOcxField) $WEB_HANDLE$-> NAVIGATE("MyPdfFile",-,-,-,-) I've tested it with Adobe reader XI and DC and it works. This oblige you to store a local copy of the pdf file In our application we would loose some functionnalities with this solution as we have buttons which can directly control the Pdf document (GotoFirstPage, GotoNextPage, SetZoom, etc). But this would give us the possibility to display the pdf files without dependancy with the Pdf viewer installed, whilst waiting for a Uniface solution... Nicolas

And as a caveat, I have since discovered that if you have a uniface screen with the Adobe XI OCX on it, and display that screen, the HTML 5 widget is incapable of displaying the PDFs in that session any more. I presume this is an Adobe collision and not a problem in Uniface. 

That is exactly where we are. I was trying to migrate to Adobe DC (rather than Uniface 9.7) and better yet, to FoxIT reader for a customer who is of the opinion that Adobe is too slow.  The HTML5 widget with the embed function gave me two things.  1. Reader independence, rather than having to enforce one version of one reader across all customers....  2. I was able to pass the 'web-page' data rather than a file name, so I didn't have to store a local copy of the PDF to display it.  It was all good, until I found out that (due to upgrading their infrastructure, and a decision made by Google, not Uniface) the embed function would not work in 9.7.  So I now have to develop an alternate strategy to migrate to PDF reader independence/Adobe DC whilst still being able to migrate to 9.7. Technology eh? Who'd have it?  Iain

We use also Ocx containers to load Pdf files. We have a form with 2 Ocx fields defined with Adobe object side by side. This is used in our application to compare versions of documents. I've discovered the problem thanks to your topic and I've made some tests in our application - With Adobe DC and Uniface 9.6 - it doesn't work - With Adobe DC and Uniface 9.7 - it doesn't work - With Adobe XI and Uniface 9.6 - it works - With Adode XI and Uniface 9.7 - it works It is currently still possible to download the version XI of Adobe Reader. So from our side, we will continue to use this version and ask our customer to not migrate to Adobe Reader DC. But it will not stop us in our migration process to Uniface 9.7. Hope this helps Nicolas

You could use PDF.js, a "general-purpose, web standards-based platform for parsing and rendering PDFs" from the Mozilla project. One challenge with PDF.js is that you need to do a view things if you want to load a PDF from a different location than the PDF.js is running (cross domain request). And there are probably other, JavaScript based, solutions out there you could use. One remark: prior to Uniface 9.7.02 the HTML5 widget uses the NPAPI Plugin to load the Adobe Reader for displaying a PDF. But the Netscape Plug-in API (or NPAPI) is not supported anymore by the version of the Chromium Embedded Framework (CEF3) that is used by the HTML widget. CEF3 has a new plugin for displaying PDFs, but this is (currently) not used by Uniface - the HTML widget only utilizes the HTML rendering engine of CEF. Hope this helps. Best regards, Daniel Iseli Uniface Technical Support

Sorry, I meant I could not find the OCX for the DC Adobe to import the signature, otherwise we'd have been able to do what we did before, update the OCX wherever used and make the relevant version of Adobe a pre-requisite for installing the client. Not being able to map the OCX widget to Adobe DC is why I went to using the HTML 5 widget, and embed, so it became PDF reader 'independent'.  I have not yet implemented the solution via Shell.explorer, although I was quite pleased that I could use the embed command with data rather than storing temporary files on the client machine to show the PDF. I think (if I recall previous uses of the Shell.explorer OCX) there is no way to pass it the HTML directly, instead you must save a file and run it against that?  Considering the picture widget allows us to do this native, it's a royal shame there isn't a PDF widget.    Iain

We use something like this:

$ocxhandle(MYFIELD.DUMMY)->Navigate("file:///myfile.pdf", "", "", "", "")

This might work for you, Kind regards, Zdeněk Socha

Iain Sharp said Hmm, I can't get it to work with DC. I suppose I could use shell.explorer (the I.E. interface?)  

Hi Iain, "… as long as user can view PDF files in explorer, it can view it in our Uniface form." I think you have to tell IE to use the AR-plugin. Just as a test: if you use the IE and load a PDF: does it show the document?

Hmm, I can't get it to work with DC. I suppose I could use shell.explorer (the I.E. interface?)

Hello, we used Adobe Acrobat Reader via ocx to show PDF files in Uniface forms. It worked fine with version 8, then 9, then X, then DC. Unfortunately, Uniface needs a signature for this and Adobe changed the interface with every version. So, if we designed form for Reader X it did not worked with DC and vice versa. Nowadays we use OCX conntected to Shell.Explorer and it seems to work fine. Now, it is not dependent on Acrobat Reader version... as long as user can view PDF files in explorer, it can view it in our Uniface form. Kind regards, Zdeněk Socha

Unfortunately, the situation is that, having worked out a solution for Adobe removing com support, and Uniface not having .net dll support, (i.e. the use of embed in the html5 widget), this has apparently (and I understand not through Uniface's control) been removed as well.  Which means that "in the future" is going to leave me/us in a dirty great hole in the present.  Until I can develop another viewer solution, I cannot upgrade my versions of uniface, and cannot therefore stay current. 

I was very keen on getting this into the product a few years ago. At that time there were serious challenges because of the lack of unicode support in the pdf format, and there were some really complicated licensing agreements to work through. It made the project unrealistic. From a quick search, it looks like Adobe have now helped in this area with some libraries. Maybe it's something to look into in the future. 

Oh yes, very much like. A large proportion of the utility of our system is based on displaying past copies of documents printed. The printer model is not so important as we use an integration with crystal reports, but a native or stable PDF view capability is a must. 

gianni said Considering PDF format is today "de facto" THE standard format widely accepted to digitally sign / trasmit / store digital documents it would be VERY nice if Uniface could include some standard functionality to manage this format: a P_PDF printer table, a library to manipulate PDF files (merge, protect, ...), an easily customizable viewer to present them... Not being this the case for time being, am I asking too much if I ask ULab to take a definite and stable position about PDF support within Uniface?

Like !

Hi, in a project I am directly following at customer site we are building a Uniface subsystem/module dealing with PDF files. This module is in these days built and tested using Uniface 9.7.01. It is managing communications between a Uniface C/S application and a Document Server; all digital documents generated from the Document Server are in PDF format. The first prototype of an interactive form showing to end user a PDF file was  using HTML5 widget and we discovered it used the NPAPI Plugin to load the Adobe Reader. Reading this discussion let me to think we could get some trouble migrating our project to newer version(s) of Uniface, depending from implementation choices... :-) Considering PDF format is today "de facto" THE standard format widely accepted to digitally sign / trasmit / store digital documents it would be VERY nice if Uniface could include some standard functionality to manage this format: a P_PDF printer table, a library to manipulate PDF files (merge, protect, ...), an easily customizable viewer to present them... Not being this the case for time being, am I asking too much if I ask ULab to take a definite and stable position about PDF support within Uniface? Thanks! Gianni