PDFの1p目のみウォータマーク(透かし)が入った画像にして縦横サイズも小さくする、シャープ処理も行う

■この記事の注意点
仕様：フローチャート｢mermaid｣を用いている、｢mermaid｣の書き方習得の側面あり
到達点：Automator自動化処理=目指す道半ば状態、無念

※後日改良したもので上書きするか別記事として投稿するかもしれない

最終目標、動機など

■最終目標

欲しいのはコレだ：
『PDFの保存で、1p目分のみ透かしが入った縦横サイズも小さくなった画像が生成される』
『もちろんシャープ処理も』

と、いうのはより一般化した言い方であって、具体的かつ個人的に何を自動化したいかというと、

欲しいのはコウだ：
『楽譜PDFの表紙用サムネ画像を自作してるんでそれを自動化したい』

これです。一般的なAutomatorの処理事例＆解説記事じゃなく、誰得な自分にだけ必要な自動化したい案件。

■動機
Automator.appを使って、PDFの1p目のみにウォータマーク(透かし)を入れる自動変換処理が欲しくなった。
※ウォータマークは以下｢透かし｣と書きます。実態は画像です、透過=透明な部分のある画像

複数の条件分岐があるような少しつっこんだ処理を望むなら『自作するしかないか…(面倒なのはきっと最初だけ)』、ということで自動化処理(フロー)を作ることにした。

■前提と想定読者
Automatorが何なのか、どんな機能があるのか、どこから起動するのか等は省きます。趣旨から外れるので。そういうのはもうわかっている/そこまで手取り足取り不要という方向け。

■環境とスキル

MacBook Pro
Sonoma 14.4.1
透過の画像は既にある(複数)
当方のスキル：JavaScriptなら分かるから出てくるコード構文、AppleScriptやシェルスクリプトも多分慣れたらボンヤリ分かる(ハズ)。分からないでも既知の記事からコピペで多分なんとかなる(ハズ)。

自動変換処理の結果〜希望と現実〜

最初に結果の提示。1アクションで各条件に沿った結果が欲しいわけです。この自動化による手順手間の省略具合は後述。

フローチャート(mermaid)：
✅ 希望(理想)：

✅ 実際(現実)：

用いるもの

Automator.app ❕Macに最初からあるやつ
XnConvert.app ❗️シャープ処理をこれで一括
透かしに用いる画像類(複数) ❗️今までも使ってたので既にある

最後のシャープ処理だけ別の方法(別appのXnConvert)を使って一括処理。なぜなら Automatorではシャープ処理が出来ないから。『Σ( ꒪π꒪)◜ …むしろ必須やろがい！』

一括画像処理でリサイズで、シャープが出来ないってどーゆーこと？！と暴れたくなる。

現時点での至らない点

✅ Automatorの使い方(習熟度)が初歩的
Automatorの左側ライブラリ(リスト項目としてズラズラいっぱい)のとこからD&Dやダブルクリックで右側スペースにフローを作っていく “初歩的な” 使い方しかできない＆それに応じた自動処理結果。...まだ希望する完全自動化処理になってない。

例1) レアケースだがPDF結合すべき場合があり、その結合後のファイル名が現状ランダムなアルファベット名。手作業での手直しが発生。

こういったのは、元ファイル名を取得したり (CODE的に$@ であることまでは把握済み)、設定したりその後のscriptを少し編集したりして、望む書式のファイル名もそうだけど、いろいろと望む結果を得られるハズというのは見当がついてる

　
✅ Automatorの処理が段階的に３つに分かれている
自動化用フォルダを1+3つで計4つあらかじめ作っておいてそれらを使う仕様、せめて処理の段階を２つに減らせないか。

フォルダ構成：

📁__from_pdf__        // PDFを保存するフォルダ(親フォルダ)
├ 📁__2_automator処理  // 処理用フォルダ１
├ 📁__3_automator処理  // 処理用フォルダ２
├ 📁__透かし入り        // 透かし入り画像が入るフォルダ
└ 📁一時避難     //動作テストetcでpdfを一時的移動用
🗒️ここにpdfファイル
🗒️ここにpdfファイル
🗒️ここにpdfファイル
：
：

フォルダアクションでやるのが最も手間が少なくなると踏んでフォルダアクションで作る。

フォルダアクションが設定されたフォルダであると分かるように、フォルダ命名規則が明示的。主に自分がフォルダの性質を忘れてしまわないために。__〇〇とprefix的にアンダーラン２つ。

Automatorに慣れてないのと・動作テストを都度するからなのと・なんだかんだでフローが多いのとで、処理が３段階、いわゆるchainになっている…

構想解説〜やることの書き出し〜

要点の書き出し：リスト形式

PDFの1p目のみ
→全ページ分は不要、1p目≒表紙として
透かし
→ 透過のある画像を重ねるということ
PDFから画像に
→ PNG/JPG/webP等なんらかの画像
リサイズ、縦横サイズ(単位: px)小さく
→ PDFのままだとアホでかいので画像として適当なサイズまで小さくする
リサイズしてボヤけた分シャープ処理
→鮮明化。シャープ(シャープンとも言うのか？)

このリストをフローチャートで視覚的にするとこう (以下、この記事では適宜フローチャートを用います)

⭐️要点フローチャート

最終目標の要件

ここで、最終目標の欠くことのできない条件 を確認しとく

シャープ処理必須 Σ( ꒪﹃ ꒪) ボヤけた状態許すまじ
PDFのファイル名によって透かしに使う画像を分けるファイル名(の一部)によって楽器種がチガウ → 使う透かし画像がチガウ。Σ必須案件

今まで(手作業) ←と→ これから(全自動)

今までは Gutiar ProにはPDF保存とは別にPNG保存があるのでそれを使い、プレビュー.appを使い、レイヤーの使える画像編集ソフトを使い、レンダリングしてた。

✅今まで(手作業)の作業を書き出すとこう：
① PNG保存＠Gutiar Pro
② PNGの1p目のみをリサイズ＠プレビュー.appなど
③リサイズしたPNGの1p目のシャープ＠プレビュー.appなど
④楽器種ごとの予め用意した透かし画像を重ねて＠画像編集ソフト
⑤曲名なども透かしの一種として文字化
⑥ レンダリング(画像の書き出し)
⑦ 楽譜販売サイトごとの推奨サイズにリサイズ、＆推奨の画像形式に
　x
楽譜種ごと(バンドスコア、各パート譜ごと)の透かし入り1p目

　
これが。
　

✅これから(全自動)作業を書き出すとこう：

① PDF保存＠Gutiar Pro
　x
楽譜種ごと(バンドスコア、パート譜の楽器種)の透かし入り1p目

　
...。
お分かりいただけるだろうか…？

この圧倒的手順の消失。ごっそりとすることが無くなる、全自動化で。Automatorで設定したらこれが実現するという…！Automator、『…恐ろしい子…！！』

白目にもなりますワ。

具体例
Guitar Proで作成した楽譜をバンドスコアとしてPDF保存、同じくパート譜としてA.Gt、E.Gt、Bass、DrごとにPDF保存。
とにかく｢PDF保存｣したら、透かしのありの1p目の画像が生成される。楽ちん。

もっというと E.GtとE.Gts は別です。これは実際の条件分岐の細かさの代表例で、楽譜種としてはほかにString(弦楽器)セクションやパート譜のVoだったりVo&Choだったりもあり、そういう時はそれぞれ別のそれ用の透かし画像を1p目に適用する必要がある。

楽器種ごと、を取り入れると先ほどの｢要点フローチャート｣では不足。以下が条件分岐を盛り込んだ｢要点フローチャート・改｣。

⭐️要点フローチャート・改：

“条件分岐” ではなく実際には “フィルター” です

※ホントに全ての~~条件分岐~~ フィルターをリストアップしてフローチャート図に落とし込むとフローチャートが“小さくなりすぎる”ので~~条件分岐~~フィルターを代表的な分のみにした簡易版です

…ワーオ、いきなり細かく(小さく)なった。
｢透かしを入れる｣も楽器種ごとの画像だからフローチャートとしてはこんなか？…まずはそこ(=フローチャートの理にかなった典型)をよく把握しきれてないのもアカンな…。

Automator 流れの確認〜理想と現実〜

この例では｢フォルダアクション｣として作成する流れで書く。

はじめに言っておくと理想と現実がだいぶ違う。以下は大まかな流れの説明。
⚠︎しかし仕上がり結果≒着地点はおおむね当初の目標通りなので、とりあえずこれで良しとしてる。

理想：
❶ PDFの1p目のみ抽出 → ❷ PDF:透かし入れ → ❸ 画像化 → ❹ リサイズ(縮小) (→別appにて⑤ シャープ処理)

現実：
❶ PDF:奇数pと偶数p → ❷ PDF:透かし入れ → ❸ 画像化 → ❺ リサイズ(縮小)(→別appにて⑥ シャープ処理)

｢理想｣は処理として無駄が少ない、｢現実｣は処理として無駄が多い。
｢理想｣は考えた時の組み立て通り、｢現実｣は実際Automatorでやってみて実現できるフロー。この流れでしか結果の出るやり方にならんかった。

シャープ処理について
⑤のシャープ処理は、記事冒頭でも書いた通り、別途 XnConvert で一括処理する。

考察〜理想と現実〜

特に①と②で本来PDFの1p目のみでいいトコロを、PDF数p分にわたって処理してるのが｢現実｣の流れ。

ちなみに①のPDF:奇数pと偶数p、の結果は奇数pのみが次の処理に渡る模様(なんでか知らんが)。これにより ②の時点で一応、処理量を半減することは出来てるが…。

※以上、これは大まかな流れ。個別に適用させる過程=バンドスコアかパート譜のA.Gtか、etcのところは略して書き出してる

現時点での評

自動化処理をフォルダアクションにより作ってみたが、

①処理に無駄が多い
②多い無駄=時間がかかる
：
③最終稿としてのPDFができたときに、フォルダアクションのあるフォルダにPDFを移動させ自動化処理を行う

…と、いうのが無難かつ現時点での最善策、という結論。シャープに関しては、記事冒頭でも書いた通り、別途 XnConvert で一括処理する。これはもうしょうがない。Automatorでは出来ないんだから。

✅ 上書きのたび連番suffixが増える問題 =回避策不明=
気軽にPDF保存≒上書き編集するたびにというのは良い手ではないというのがひとつ分かったこと、処理に時間かかるから。

あと、Automatorで自動生成される経過のファイル名はいつも同じでいいので、どっかのオプションで｢上書きする｣にチェック入れてるってーのに、

PDF上書き保存したら=自動変換処理する度に経過ファイル名に連番付いて、かつその連番が増えていく仕様なのよネ…。いやいやイヤイヤ、そこは上書きしてくださいヨ、というとこなのに。希望と異なる所業に回避策は解らぬまま。

✅ 処理段階が多い問題 (条件分岐、フィルター)
仕様上、JavaScriptでいう条件分岐のifで複数の道筋に分ける、ていうのが出来ないのカナ？
この、 “条件分岐” ではなく “フィルター(絞り込み)” 、このせいで処理段階(chain)が１段余計にかかってるのだけども…？

✅ ショートカット.appでは違うのか？=詳細未確認=
Automator.appじゃなく ショートカット.appだとまた仕様とか制限とか違うんだろうか、そういや試してなかった。最後になったけど。