OVH Cloud OVH Cloud

[Help] Impression PDF automatique

46 réponses
Avatar
yapersonne
Bonjour,
Passé récemment de Jaguar à Tiger je me suis aperçu que Spotlight
snobait les documents AppleWorks 5. Or j'ai une base de 1600 docs qui
était indexée pour recherche par contenu.
Heureusement Spotlight connaît AW6, mais malheureusemen Automator non.
Ne connaissant rien à AppleScript j'ai passé 1/2 journée à ramasser
bouts et morceaux et obtenir un script qui ouvre tous les docs AW5 d'un
dossier avec AW6, les enregistre et les referme, au rythme de 1 toutes
les 2 seconde.
Problème résolu donc
... **mais**...

je vais un de ces jours larguer mon fidèle G3 de 10 ans, acheter un bel
iMac tout neuf et le risque est élevé que AW6 soit aussi oublié par un
futur félin. La solution semble être de passer tous ces docs en PDF mais
je ne vois pas comment, dans mon script AW6, lancer automatiquement ce
type d"impression".
Ma question est donc la suivante :

un doc AW étant ouvert par un script, comment dans le script
- l'imprimer en pdf par le dialogue standard ou
- créer une imprimante fictive pdf (genre PrinToPDF d'antan) et lancer
automatiquement l'impression dessus.

Merci de vos idées
HC

6 réponses

1 2 3 4 5
Avatar
Patrick Stadelmann
In article <1jemx47.11m91msu72i9fN%,
(Henri) wrote:

Patrick Stadelmann wrote:

> Il y a application créée dans ~/Libray/Printers chaque fois que l'on
> ajoute une nouvelle imprimante.

OK, je n'avais pas fait le lien.
Ça marche effectivement aussi. Il suffit de réaliser que le fichier
ouvert par Finder using printer doit être fermé par AW.



En principe, le fichier ouvert par l'application "CUPS-PDF" est ouvert,
imprimé, et fermé automatiquement.

Le seul hic est la disparition des signes diacritiques qui oblige à un
important boulot ultérieur de rectification.



Pas si le script traite les fichiers un par un, en mémorisant le nom
avant l'impression et en renommant le fichier PDF produit.

Patrick
--
Patrick Stadelmann
Avatar
Patrick Stadelmann
In article
,
Patrick Stadelmann wrote:

Pas si le script traite les fichiers un par un, en mémorisant le nom
avant l'impression et en renommant le fichier PDF produit.



Par exemple (adapter les valeurs de EXT en cupsPath) :


-- longueur de l'extension des fichiers d'origine
set EXT to 3
-- dossier de sortie des PDF créés par CUPS-PDF
set cupsPath to "/var/spool/cups-pdf/admin/"

set outF to POSIX file cupsPath as alias
set srcFolder to (choose folder with prompt ¬
"Sélectionner le dossier source")
set destFolder to (choose folder with prompt ¬
"Sélectionner le dosseir de destination")

tell application "Finder"
set fileList to every file of srcFolder as alias list
end tell

set EXT to EXT + 1

repeat with f in fileList
set outFile to {}
tell application "Finder" to set fName to name of f
tell application "CUPS-PDF" to open f
tell application "Finder"
repeat while outFile = {}
delay 1
set outFile to (get files of outF)
end repeat
set newName to (characters 1 thru -EXT ¬
of fName & "pdf") as text
set name of (file 1 of outF) to newName
move file 1 of outF to destFolder
end tell
end repeat


Patrick
--
Patrick Stadelmann
Avatar
blanc
Henri wrote:

C'est d'ailleurs bizarre car hier le é était "_303_251" et aujourd'hui
c'est "e_314_201".



Tes nombres c'est de l'octal.
303 251 en hexa donnent : C3 A9 qui est le double-octet UTF-8
correspondant au caractère 'é'.

314 201 donnent CC 81 qui correspond en UTF-8 au caractère unicode
(U+301) "Combinaison accent aigu" qui permet de transformer n'importe
quel caractère (ou presque) en caractère avec accent aigu.

<http://www.fileformat.info/info/unicode/char/0301/index.htm>

ou en français :

<http://translate.google.com/translate?hl=fr&sl=en&u=http://www.fileform
at.info/info/unicode/char/0301/index.htm&ei=nMaKS-2gA9Wz4Qba-5ynDw&sa=X&
oi=translate&ct=result&resnum=1&ved AgQ7gEwAA&prev=/search%3Fq%3Dcc%2B
81%26hl%3Dfr%26client%3Dfirefox-a%26hs%3DYtU%26rls%3Dorg.mozilla:fr:offi
cial>

Autrement dit ce sont deux manières de coder un 'é' en UTF-8.

305 222 --> C5 92
et 305 223 --> C5 93
correspondent de même aux codes UTF-8 de ¼ et ½ respectivement.

Le fait de traduire les codes UTF-8 en nombres octal ou hexa est un
artifice utilisé, lorsqu'il n'est pas possible d'utiliser directement ce
code. Par exemple en HTML, l'URL suivante :
<http://fr.wiktionary.org/wiki/%C5%93>

conduit à une page du wictionary qui correspond au caractère '½'.

La question est donc de savoir en quel code sont tes emails. Je
parierais que c'est de l'UTF-8.

Amha, les programmeurs de Cups-pdf n'étant pas sûrs qu'ils puissent
utiliser de l'UTF-8 dans les noms de fichiers qu'ils créent (cela dépend
en effet de la plateforme) préfère faire une substitution. C'est dommage
pour Mac-OS-X, car sjnmt les noms de fichiers sont codés de façon
interne en UTF-8.
Peut-être est-ce configurable ?
A toi de faire une recherche dans ce sens.

Plus de détails sur UTF-8 et unicode :
<http://fr.wikipedia.org/wiki/UTF-8>
<http://fr.wikipedia.org/wiki/Unicode>

--
JiPaul.
/ /--/--// Jean-Paul Blanc
|/| L | quelquepart en (somewhere in)
/|| = ||| FRANCE
Avatar
blanc
Henri wrote:

La
table de codage de CUPS ne semble connaître que l'ASCII de base. reste à
savoir où elle et comment lui substituer celle utilisée par
l"impression" PDF du système.



Non, non. Elle semble reconnaitre l'UTF-8 et le traduire volontairement
en ASCII. Voir mon autre réponse.

--
JiPaul.
/ /--/--// Jean-Paul Blanc
|/| L | quelquepart en (somewhere in)
/|| = ||| FRANCE
Avatar
yapersonne
JiPaul wrote:

Tes nombres c'est de l'octal



Intéressante explication de ces nombres esotériques.

Amha, les programmeurs de Cups-pdf n'étant pas sûrs qu'ils puissent
utiliser de l'UTF-8....
...sjnmt les noms de fichiers sont codés de façon interne en UTF-8.



Si je vais traîner dans /private/var/spool je trouve 7 dossiers dont 3
ont un "-" rouge (cups, fax, mqueue). En forçant l'entrée dans cups au
Terminal et en examinant ce qui s'y trouve on voit que dans les trces de
fichiers imprimés
- il est fait allusion à UTF-8
- les noms de fichiers sont mémorisés accentués
- si j'imprime avec Virtual Printer un fichier "àéèëêîôöù½.rtf" sa trace
dans cups est c00184 et head c00184 donne le résultat ci après où le nom
est explicite.

Le bizarre est que
- CUPS-PDF aka Virtual Printer me crée sur le bureau un dossier de
sortie "cups-pdf" avec un "-" rouge (que je peux cependant ouvrir sans
restriction) où apparaissent les fichiers imprimés à noms codés.
J'ai l'impression que ce dossier n'est pas créé à la bonne place, qu'il
devrait être dans /private/var/spool et que de ce fait le processus
d'impression ne va pas au bout, jusqu'à l'attrbution du nom correct
pourtant mémorisé dans /private/var/spool/cups.

- Il existe dans /private/var/spool un dossier cups-pdf sans "-" rouge,
contenant un dossier SPOOL vide. Pas idée de son rôle. Serait-ce par là
que passent les "impressions" pdf obtenues par le dialogue standard ?
En tous cas il n'est pas utilisé par Virtual Printer et ce n'est pas
très logique.
HC


********************************************
[iMac:var/spool/cups] root# head c00184
Gattributes-charsetutf-8Httributes-natural-languagefrE

printer-uri,ipp://localhost:631/printers/Virtual_PrinterBjob-originating
-user-namehenrijob-name!àéèëêîôöù½.rtfIdocument-format
text/plainBAP_D_InputSlot!copies"collate!

job-priority2Bjob-originating-host-namelocalhost!job-id?# job-state
!job-media-sheets-completedEjob-printer-uri.http://iMacHC.local:0/printe
rs/Virtual_Printerjob-name!àéèëêîôöù½.rtf!

job-k-octets!time-at-creationK??C!time-at-processingK??C!time-at-complet
edK??FDjob-hold-untilno-holdB
*********************************************
Avatar
laurent.pertois
JiPaul wrote:

Amha, les programmeurs de Cups-pdf n'étant pas sûrs qu'ils puissent
utiliser de l'UTF-8 dans les noms de fichiers qu'ils créent (cela dépend
en effet de la plateforme) préfère faire une substitution.



En regardant dans les extras de la dernière version (2.5.0, le code
source est dispo sur le site ci-dessus, pas de version packagée par
CodePoetry) on trouve un script perl capable de transformer les noms en
lui indiquant le jeu de caractère en entrée et en sortie, pas encore eu
le temps d'essayer ni de regarder si c'était compatible avec la 2.4.6.1.

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
1 2 3 4 5