Vous trouverez ci-dessous un AppleScript qui déclare un gestionnaire permettant d'obtenir une liste de pages d'un document PDF, auquel vous fournissez le chemin d'accès au fichier. Lorsque le gestionnaire est appelé, si le chemin d'accès au fichier est valide, il doit retourner un AppleScript list qui contient l'étiquette de chaque page, ordonnée par l'index de la page. Cependant, gardez à l'esprit que les pages PDF sont indexées à partir de zéro, alors qu'AppleScript lists sont indexés à partir de un. Par conséquent, item n de la liste retournée vous donne l'étiquette de la page à l'index n - 1 .

use framework "Foundation"
use framework "PDFKit"
use scripting additions

property this : a reference to the current application
property PDFDocument : a reference to PDFDocument of this

on PDFPagesInDocument at filepath
        local filepath

        try -- test file exists
                set fileURL to filepath as text ¬
                        as {alias, POSIX file} ¬
                        as «class fsrf»
        on error
                return false
        end try

        script pages
                property list : {}
        end script

        tell PDFDocument to tell alloc()
                initWithURL_(fileURL)
                repeat with i from 0 to pageCount() - 1
                        tell pageAtIndex_(i) to set the end of the ¬
                                list of pages to its label() as text
                end repeat
        end tell

        return the list of pages
end PDFPagesInDocument

Après avoir collé le code ci-dessus en haut de votre propre script, vous pourriez alors l'utiliser comme ceci :

choose file of type "com.adobe.pdf" with prompt "Select PDF File"
set PDFpath to the result

PDFPagesInDocument at PDFpath

Cela permettrait à l'utilisateur de sélectionner lui-même un fichier PDF à chaque fois que le script s'exécute. Cependant, vous pouvez spécifier votre propre chemin de fichier codé en dur, comme je le fais ici :

PDFPagesInDocument at "/Users/CK/Library/Mobile Documents/iCloud~com~apple~iBooks/Documents/Sun Tzu - The Art of War trans Giles Pax Librorum 2009.pdf"
set pageList to the result

--> {"Cover", "i", "ii", "iii", "iv", "v", "vi", "vii", "viii", "1", "2", "3", ¬
    "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16", ¬
    "17", "18", "19", "20", "21", "22", "23", "24", "25", "26", "27", "28", ¬
    "29", "30", "31", "32", "33", "34", "35", "36", "37", "38", "39", "40", ¬
    "41", "42", "43", "44", "45", "46", "47", "48", "49", "50", "51", "52", ¬
    "53", "54", "55", "56"}

Comme vous pouvez le voir, cette copie PDF particulière du livre de Sun Tzu L'art de la guerre compte 65 pages, où la page qu'un lecteur considère traditionnellement comme la page 1, c'est-à-dire la première page sur laquelle il se rend pour commencer à lire le récit d'un livre, est la dixième page du fichier PDF.

Autres questions :

Existe-t-il un moyen d'accéder au numéro de page des métadonnées au lieu de l'index normal des pages ?

Solution ci-dessus.

J'aimerais également savoir pourquoi l'inspecteur d'accessibilité n'a pas indiqué d'informations sur le champ de texte ?

Le développeur de logiciels qui code une application peut choisir les informations qui seront exposées pour les crochets d'accessibilité. Apple a établi des directives que les développeurs doivent suivre et, heureusement, la plupart d'entre eux sont consciencieux et veillent à ce que leurs logiciels communiquent des informations sur les principaux éléments de l'interface utilisateur. Ces informations comprennent au minimum le nom de l'élément, sa description, sa classe d'objet, sa fonction (ou son rôle), sa position dans la hiérarchie et quelques autres éléments de base.

En plus d'être agréables pour ceux qui script l'interface utilisateur à mort, ils servent en fait un objectif plus important, en aidant les utilisateurs ayant des besoins spéciaux à être en mesure de s'interfacer avec des logiciels qu'ils ne pourraient pas utiliser autrement (par exemple, une personne aveugle ne peut pas voir la valeur affichée pour un index de page, mais le logiciel de voix off utiliserait des crochets d'accessibilité pour récupérer l'information et la lire à haute voix à l'utilisateur... à condition que l'information ait été exposée).

Il semble que Écrémer les développeurs sont simplement paresseux ou ne souhaitent pas que les aveugles utilisent leurs logiciels.

J'ai découvert que l'on peut accéder au champ de texte avec :

text field "Page" of group 2 of toolbar 1 of window " - 2013 - .pdf (page 1150 of 1696)" of application process "Skim" of application "System Events"

D'où la tentative suivante pour obtenir sa valeur :

tell application "Skim"
    activate
    set theDoc to front document
    get value of text field "Page" of group 2 of toolbar 1 of theDoc
end tell

Le script ci-dessus a donné lieu à cette erreur de syntaxe :

Expected end of line, etc. but found “"”

Les informations que vous avez glanées dans le premier extrait sont des objets de classe qui appartiennent tous à l'application System Events . Donc quand vous essayez ensuite d'obtenir l'application Skim pour référencer ces objets, il ne le peut pas : il n'a jamais entendu parler d'une text field . Elle reconnaît toutefois text comme le nom d'un objet de classe (la classe de toutes les chaînes AppleScript), et suppose ensuite provisoirement que field est un identifiant pour une variable qu'il devra rechercher et dont il devra lire la valeur. C'est là qu'il devrait normalement se plaindre que vous n'avez jamais déclaré de variable avec cet identifiant, mais le mot "Page" qui suit immédiatement est une plus grande préoccupation, car cela n'a aucun sens pour lui dans aucun contexte.

Le compilateur considère alors qu'il s'agit d'une erreur de syntaxe et signale le guillemet double comme le caractère définitivement illégal qui rend l'expression entière impossible à évaluer.

Cela dit, même si ce n'était pas une erreur de syntaxe, cela aurait conduit à une erreur d'exécution car votre référence s'arrête à toolbar 1 en ayant complètement omis l'objet parent de toolbar 1 qui est window " - 2013 - .pdf (page 1150 of 1696)" (que vous pourriez aussi appeler window 1 pour plus de commodité), et son l'objet parent, qui est process "Skim" et son l'objet parent, qui est application "System Events" .

Ce qu'il faut faire, c'est prendre l'extrait que l'on vous a donné et l'utiliser avec un petit ajustement : l'objet le plus haut, qui est celui qui se trouve à l'extrémité de l'écran, doit être le plus haut possible. fin de la référence - va toujours être une application qui, dans ce cas, est "Événements du système" . C'est l'objet qui possède tous les autres objets que la référence contient, et c'est donc la chose que vous devez être tell -.. :

tell application "System Events"
    value of text field "Page" of ¬
        group 2 of toolbar 1 of ¬
        window 1 of process "Skim"
end tell

Cependant, ne mettez pas - comme vous l'avez fait - votre tell application "System Events" bloc à l'intérieur de a tell application "Skim" bloc. Bien que vous ne le voyiez pas, AppleScript se plaint de cette situation, génère une erreur (discrètement), comprend ce que vous voulez dire et, heureusement, poursuit son travail. Mais cela ralentit les choses, ce qui est le meilleur des cas, mais dans d'autres situations, cela peut provoquer un chevauchement des classes d'objets ou un conflit de terminologie. Si vous avez de la chance, le script se terminera par une erreur d'exécution. Si vous êtes malchanceux, des choses seront écrasées et des données seront perdues.

Sauf s'il y a une raison spécifique de le faire, et que vous savez précisément ce que vous faites en le faisant, ne jamais mettre une application tell bloc (ou clause) à l'intérieur d'un autre. D'une manière générale, puisque la plupart des langages n'effectuent qu'une seule opération à la fois de toute façon (ce n'est pas vrai, mais faites comme si ça l'était, parce que c'est le cas pour AppleScript), vous ne ferez jamais en sorte qu'AppleScript parle à une seule application à un moment particulier de votre script, donc essayez de vous assurer que c'est le cas lorsque vous révisez ce que vous avez écrit.