I have a PDF that is generated with PDFlib that has fillable fields. They work as expected on Chrome, FF, Edge, IE, but not on Safari.
We have no Macs at work, so I'm looking at this using SauceLabs with OSX El Capitan, Safari 9.3 on 1376x1032 resolution.
When I fill out the fillable field on a form such as https://www.pdflib.com/pdflib-cookbook/pdf-on-the-web-server/starter-webform/php-starter-webform/ in-browser (again, Safari only), when you click outside the fillable field, the text moves up a couple of pixels. Click to edit again and it regains its original position. Click outside and it moves up again.
Is this an unavoidable Safari bug or is there anything I can do to prevent this from happening (currently reading the PDFlib documentation, and I have seen nothing that remotely mentions this)?
They work as expected on Chrome, FF, Edge, IE, but not on Safari.
please get in mind, all browsers have in the moment only limited PDF viewing support. (they are getting better and better with each versions, but they are not yet perfect)
Please use for viewing PDF files the PDF reference product Adobe Acrobat (Reader). Also other PDF viewers like the Apple Preview are not feature complete and might not display everything correct.
When it display correctly in Adobe Acrobat Reader, you know the PDF is fine and it's a bug in the viewer you use.
Related
Is there any way to modify texts in PDF on Chrome using the Chrome inspect tool? I was stuck because in the Chrome inspect element, differently than any other websites and even PowerPoint presentations opened in Chrome, I'm able to modify texts, while with PDFs I cannot. Does anyone know how to do it?
Edit: Yes I know that the changes made through Chrome DevTools are temporary, but usually I'm able to make those changes, even if they're temporary. But with PDFs I can't.
There are differences in the way some browsers handle PDF data.
Chromium based browsers are more traditional in that the PDF plug-in is based on a Foxit/Skia collaboration, So you need to understand in that case, the downloaded PDF you are viewing is in the binary application/pdf (file already outside of the html wrapper).
Just as you cannot edit the PDF text in Acrobat Reader, the most you can do is incrementally add comments/annotation or field data to the end of the file, before save as a secondary download. The server cannot see your changes unless you submit as an upload.
With Firefox and Google docs there is often a different approach where the PDF is "Repr"oduced as an "Ex"ample (A ReprEx of the PDF) so it is built of a hybrid image and text overlay to emulate that part of the real PDF source. When you previously or later save the underlying downloaded PDF (for viewing) it would not necessarily include any browser based HTML editing, in the saving.
There are other techniques for other cases, but to answer the basic OP question most simply, the answer is NO you cannot change a PDF body, only add notes, etc via extensions. Microsoft variant of Chrome I.E. Edge has some inbuilt annotation ability thus does not need a second extension.
Found this question because I was googling a similar situation--I was wanting to manipulate type sizes and margins on a PDF in inspector via Chrome. I found that FireFox DevTools will allow you to view those styles and even alter the content in the PDF while in browser. I am late to the game but hope this provides answers for someone else in the future.
I am developing a web page to show PDF (in .NET platform). The PDF is inside a iframe. One of the requirement is NOT allow client to print the PDF. I have already made the PDF to be password protected (with pdfsharp). I further hide the toolbar by setting toolbar=0. In Chrome & IE, this works fine. But for Firefox, the story is totally different.
In Firefox, the toolbar will be shown even append #toolbar=0 in the src link. Further, the password protected pdf can be printed by simply clicking the icon in the toolbar.
Can anyone suggest some ways to disable pdf printing in firefox.
Note: I need to show the PDF in the webpage. So, download the PDF is not a option.
You will not be able to control the toolbar or the ability to print (not all PDF viewers respect the permissions set by the password) if you rely on the native browser or OS level PDF viewer by using an iFrame. Different browsers will interpret those settings differently. Even different applications within the same browser will yield different results (Chrome vs Dropbox in Chrome)
You'll need to display the PDF using something like PDF.js or another such library if you want any kind of consistency in appearance and behavior.
I am generating a PDF using PhantomJS, and it opens fine with Macs built in Preview, Google Docs, and a few other tools that I tested it on. However, when I open it using Adobe Acrobat Reader DC version 15.010.20056, I receive one of the most unhelpful messages of all time.
After this, my PDF is only partially generated. This happens both on PCs and Macs. I have no idea how to debug this or even start to figure out the cause.
In case anyone was wondering, PhantomJS doesn't properly render Tiling Patterns, setting up offsets X and Y offsets to be 0, which is actually not proper PDF specifications. This is one of the many reasons that PhantomJS renders things differently depending on how you open the generated PDF.
Couldn't decide if this is a question better for Stack Overflow or Superuser, haven't got any bites on Superuser yet...
I have Adobe Acrobat 9.0 Pro, and with that, the Convert Web Page to PDF button that displays in IE. We use this at work to review web pages and comment/markup for changes, etc.
When I use it on a web page that is responsive (such as http://microsoft.com) the resulting PDF shows the page laid out as if the browser window was sized down, but then it stretches all the elements to fit the width of the PDF.
Does anyone know if this is because of the rendering engine the Convert button uses? The resulting PDF looks a bit similar to how the page would look in Quirks mode in IE9 (using F12 developer tools and choosing Quirks mode from the Document Mode drop down.) Thanks for any help!
Anyone know why the PDF controls normally available when displaying a PDF in Safari would be missing when displayed in an iframe? Neither the "hover" controls or the extnded contextual menu is available. Safari reognized it as a PDF because the contextual menu includes the word PDF in the Open commands, ie. "Open PDF in new Window"
Opening a PDF into an empty browser works fine. The built in controls in Chrome and Firefox are there as well and work fine.
I am serving the PDFs using a very simple web page with an iframe inside a div.
I could be wrong but thought that they were there when I first started this project but I just noticed today that they are missing. Without them, PDF drawings cannot be zoomed in and out rendering them useless as PDFs.