If you search for something that opens Preview.app (e.g. a PDF file) in Spotlight, the application not only opens the file but actually copies the Spotlight query into the application's search field (for deeper search). iPhoto and Mail.app also do this.
This is a really nice feature. Unfortunately, Apple does not document how it's implemented. Opening a document from Spotlight appears to simply send application:openFile to the application delegate. Is it possible to retrieve the user's Spotlight query somehow? Or is this a hardcoded feature of Spotlight?
If you're looking for the term used in the query, keyAESearchText will work (see listing 10-1). So yes, they document it, but not in the expected place. File an enhancement request at the bottom of the page.
Related
So that the link can be used in some external applications, and users in that application can click the link and navigate to that specific location (text or area) in the pdf.
Is this possible?
There are several different URL # (fragment) constructs that were introduced by Adobe for use with their web browser PDf viewer plug-in. The current accessible list is at https://pdfobject.com/pdf/pdf_open_parameters_acro8.pdf
Many newer competing PDF enabled browsers may use similar, but there is no guarantee one URL.pdf#Fits all. Most will respect #page=number&zoom view or fit but it is very variable, thus you need to check each feature across browsers.
Important to switch off any PDF remember my view settings
For your previous request using Bookmarks can be unreliable (as can the comments ID) unless you are using Acrobat and can check the bookmark function. By far the more reliable may be the use of zoom at a scroll location so here using MS Edge:-
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" file:///C:/Users/.../Desktop/CEI-PID-Sample-Rev4annotsC.pdf#zoom=300,200,200
I support SumatraPDF however its browser plug-in whilst still functional is way past EOL thus unsupported, it had a limited support for those fragments even though the CLI was recently extended for some Acrobat /Action commands.
However related to your desire the one single portable EXE can jump to well formed text blocks. Here I call "V 4508" in a fairly similar fashion
"C:\Program Files\SumatraPDF\SumatraPDF.exe" "C:\Users\WDAGUtilityAccount\Desktop\SandBox\apps\Graphics\CEI-PID-Sample-Rev4annotsC.pdf" -zoom 300 -search "V 4508"
And if I press A then the text will be highlighted for comments
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.
I would like to ask the following if possible. We have a client that wants a separate pdf document, embedded in a main pdf document and opens when you click it. Like the function in MS Word where you can attach another Word document inside a Word document (Word-ception, lol) and you can still open it.
I've tried it in Acrobat Pro with the Attachment and Link tools. Another option was to put the link document in an ftp server for accessibility. but our client really wants this functionality. Is this possible in Indesign?
Thank you!
Using Word as your example vehicle there are several ways to link 2 documents.
One is an appendix to the other, in PDF terms is a merge or binding but its one flowing document with separate sequential sections/chapters.
Another way is to link to an external file, in PDF terms a hyperlink to a relative second file, which can be locally folder relative or a web absolute reference. You have tried that.
In Word we can add objects internally with icons, in PDF that can be an annotation comment attachment to save externally and action accordingly. You also seem to discount that approach.
Finally PDF offers an Adobe Specific Structure where multiple PDFs attachments can be imbedded in an overall PDF wrapper. These are called Portfolios and not! to be confused with their portfolio service
They are unpopular since in a browser without Adobe Reader they should only offer the cover page.
Whilst in securer offline readers the files may well be shown as attachments that you need to save or independently open to view them.
Only some non Acrobat viewers may view them as a collection. And in the past that required runing insecure SWFlash, But I understand that has changed ?
Here is how the 3 internal PDF files seen above were shown in older Acrobat 9.
Possibly the best experience is using Foxit Reader
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.
I am creating a Mac App, using NSDocument, that stores a custom class of documents to iCloud.
I was able to get the program to store documents to iCloud quite easily by just Code Signing it, Sandboxing it, and adding iCloud entitlements; however, I'm still encountering a problem where when I trigger an iCloud conflict and the program drops down the sheet allowing the user to resolve the conflict the rows in the sheet do not show the small image of the document (like Preview and TextEdit do).
Additionally, when I click on the area where the image should be (it's blank) it opens up a Quick Look window that just displays an image of the Document Icon together with some other information as opposed to a snap shot of the actual file like Preview and TextEdit do.
I have not found any information in Apple's documentation that explains what I need to do to implement the same behaviour as Preview and TextEdit.
So far I've been surprised by how easily I've been able to get all of the functionability of not only the Auto Saves and the Versions browser, but also saving to the Cloud. NSDocument seems to do all of this for the developer (resolving iCloud Conflicts, etc.), as Apple's documents says it does, but again I'm not getting this other behaviour and I don't want to reinvent the wheel by writing code that is not needed.
I'm thinking that the answer might lie somewhere with implementing a Quick Look thumbnail (for the small image in the table in the sheet) and a Quick Look preview for the larger preview of the document when that in the sheet is clicked on, but this seems like a lot of work and I'm afraid of losing some of the other build-in functions of NSDocument if I start "trapping" NSDocument routines up the food chain so to speak.
Has anyone else encountered this problem and found the easiest solution?
Update: Dec. 25/12
I've finally figured out that the problem is I need a QuickLook generator to display both a QL Thumbnail (which shows up in the table in the conflicts sheet) and a QL Preview (which is displayed when a user clicks on the Thumbnail)
I ended up creating the QL generator project, and afterwards creating a workspace which I added my main project and the QL generator project to. After that I added a Copy Files Build Phase to the main project to copy the QL generator into the main Application bundle.