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.
Related
With the latest version of Firefox (107) it is now possible to edit and sign PDF documents within the browser preview window.
But how can I upload an updated version of such a PDF file back into my Web Application?
Is there any kind of JavaScript API I can use?
There is much overlap between PDF web editing browsers and Browser editing PDFs
the data is pulled down locally and the binary application edits the data however for a PDF, that then requires a local save as a new combined PDF. here we can see a visual reminder.
In Firefox or Chrome there are slight differences but the core need is to resave the PDF as a clients local file.
Chrome has inking
And Firefox uses a slightly different overlay but again the conjoined local data must be first saved as a new PDF.
either by print
or the top right Save (again) AS
Thus to achieve your goal you need to ask the annotator user to upload their masterpiece. However you cannot easily do that in the sandboxed page (with work frame) it needs to be after a user signal such as press button here to upload where-ever IF you were able or bothered to save as a new pdf.
I'm curious how to make an accessible button for screen readers which downloads PDF.
I know that there is an option using href and pass there an URL to the pdf file, and even a download attribute inside an anchor to open a download window.
But it's not a good way for a screen reader. The screen reader reads it as a link but actually, this is not a link because it triggers downloading a pdf file rather than redirect to another page. So this can be confusing for people with vision disorders who rely on their screen readers.
Is it a good accessibility way to create such a button? Or relying on <a href='path-to-pdf'>...</a> is completely enough and not confusing for people with disabilities ?
General answer and basics of file download
Both a link and a button are perfectly fine, it doesn't make much difference.
IN any case, it's very important to explicitly indicate that the link or button is going to download a file rather than open a page, to avoid surprise.
The simplest and most reliable is just to write it textually, i.e. "View the report (PDF)".
You may also put a PDF icon next to the link to indicate it, but make sure to use a real image, i.e. <img alt="PDF" /> and not CSS stuff, since the later may not be rendered to screen readers and/or don't give you the opportunity to set alt text (which is very important).
A good practice is also to indicate the file size if its size is big (more than a few megabytes), so that users having a slow or limited connection won't get stuck or burn their mobile data subscription needlessly.
It's also good to indicate the number of pages if it's more than just a few, so that people can have an idea on how big it is, and if they really can take the required time to read it.
Example: "View the report (PDF, 44 pages, 17 MB)"
Note that similarly, that's a good practice to indicate the duration of a podcast or video beforehand.
Additional considerations with PDF
First of all, you should make sure that your PDF is really accessible. Most aren't by default, sadly.
You should easily find resources on how to proceed to make a PDF accessible if you don't know.
Secondly, for an accessible PDF files to be effectively read accessibly, it has to be opened inside a real PDF reading program which supports tagged PDFs, like Adobe Reader.
The problem is that nowadays, most browsers have an integrated PDF viewer. These viewers usually don't support tagged PDFs, and so, even if you make an accessible PDF, it won't be accessible to the user if it is open inside that integrated browser viewer.
So you must make sure that your link or button triggers an effective download or opening in a true PDF reading program, rather than opening in an integrated viewer of the browser.
Several possibilities that may or may not work depending on OS/browser to bypass the integrated viewer. They have to be tested to make sure they work:
Send a header Content-Disposition: attachment; filename="something.pdf"
Send a Content-Type different than "application/pdf" or "text/pdf", e.g. "application/octet-stream" to fake out basic type detection
Make the link don't ends with .pdf
Use the download attribute of <a>
The most reliable are response headers. Most browsers don't rely only on file extension alone to decide what to do.
Either a link or a button is fine. The most important thing is that the user is informed about what the element does - i.e. it downloads/opens a PDF file. So, this should be reflected in the element's label, whether that is a visible text label or an icon that uses alt text or aria-label to explicitly describe the element's purpose.
I agree with Quentinc's suggestion to also inform the user upfront about the number of pages and size of the document - that's a nice touch that I don't see very often!
PDF accessibility is a whole other topic, but again as QuentinC points out, there's not much good in allowing a user to download or view a PDF that isn't accessible, so it's a good idea to ensure the PDF has been tested against JAWS/NVDA/VoiceOver/TalkBack to ensure it is readable.
Quick description - My company has a webpage that we use for responding to emails and assigning them to people (team inbox basically). The page converts all attachments (that it can) to .pdf files and each attachment/page gets converted as it's own separate .pdf so we can navigate the pages easier (I guess? At least there's a way to merge them into one file, but that opens in a new tab). These .pdf files are displayed in-line. Currently I have to use another browser for this page, due to Firefox not supporting in-line PDFs. Can anyone please advise if they have found a way to view in-line .pdfs within Firefox? Thanks in advance.
See these pics for reference -
In-line .PDFs displaying in Edge (Chromium)
Firefox not displaying
Firefox actually supports embedding PDFs in <iframe>. So this might be a problem with how this web app is written.
This example page shows it working in Firefox: https://www.w3docs.com/tools/code-editor/1077
I created a browser extension that lets you look up words in Wikipedia or Wiktionary without needing to open a new tab ( https://addons.mozilla.org/en-US/firefox/addon/in-page-lookup/ , almost done porting to Chrome). It is very useful when you are doing research and come across a word you don't know or want to know more about. The only thing is, a lot of research content is in PDF format. A long time ago (~2013ish) I had an older version of the app based on the old Firefox add-on framework and that did let iframes show up over pdf documents but this has not been the case for many years. I don't think the extension is even recognized in pdf documents, I get "Error: Could not establish connection. Receiving end does not exist" and there is no extension content script on the pdf page. So, my question is, is it possible to put an iframe over a pdf document? Do I need to work on the background side, and if so, how? Thanks.
We are using Blackberries to display PDF reports. Here are background details on the problem:
The PDF reports are created using JasperReports.
Report format can be changed.
Different report formats are available (as per the feature set of JasperReports).
The PDF reports are on a website, too, so retaining a single source is ideal.
The page setup is in Landscape.
Here are the issues we have encountered:
Users cannot see a full line of text on the Blackberry.
The size of the PDF and UI makes reading difficult, at best.
The menu option to convert the PDF to text loses too much formatting to be useful.
The text is blurry (and too small).
Here are solutions we have thought about:
Create a second report (not ideal) in text or HTML format.
Simplify the original report format (not really an option, given the amount of data).
What other options are there for making a report available on the Blackberry, given the constraints of JaserReports, such that the report:
Is legible?
Is formatted for readability?
Displays quickly?
Essentially, we'd like to make sure there are no simple solutions we have overlooked for displaying legible PDFs on Blackberries.
We convert TIFFs to PDF for one of our applications, and have had mixed results with BlackBerry PDF viewers. These were our results.
Working
The following PDF readers worked for our purposes:
RepliGo Reader v1.1.1.1 - $19.95
Works fine.
DataViz Documents To Go Premium Edition v1.003.001 - $49.99
Works and includes a word wrap option to get the current zoom level to fit the available screen width, by moving text onto subsequent lines. Might fit your needs.
Non-Working
The following PDF readers did not work for our purposes:
BeamReader v1.0.8 - $17.99
BeamSuite v3.0.2 - $49.99
These couldn't open our PDF files ("Unsupported document format"). In addition they did not register as a PDF content handler, required for our application.
MasterDoc - $19.95
eOffice - $29.95
These also did not register as a PDF content handler. We had a range of problems with these, including installation issues, and not being able to open any PDFs at all.
Try BeamReader http://www.slgmobile.com/beamreader.html
I hear it's the best at reading PDFs for BlackBerry
How about outputting the file to an RTF or an image file (JPG/GIF), and then viewing them in your web browser?
If that doesn't work well on the native browser, I would focus on viewing the file via some other web browser - for example, Opera Mini. I know for images it's easier to navigate "big" images in Opera Mini than the native browser.
If your blackberries are on a BES server, couldn't you display the reports as HTML on your corporate intranet? - Then you could email a link to the blackberry and simply browse the report.
You can convert pdf to image via xpdf and than show image. xpdf is a BEST renderer of pdf.