DTPab

印刷やデザイン、アドビ製アプリやスクリプトなど、雑多な技術ブログ

『ESDebugger for VS Code―ESTKから卒業しよう 第2版』を書きました!

技術書典14にて、新刊『ESDebugger for VS Code―ESTKから卒業しよう 第2版』を頒布しました!

techbookfest.org

BOOTHでも頒布しておりますので、どちらでもお好きな方からお求めください!

uske-s.booth.pm

せっかくなので執筆を振り返ろうと思います。

まず第一に執筆の時間が取れなかった…。
2022年6月にExtendScript Debugger for Visual Studio Code(以下ESDebugger)のv2がリリースされたものの、ろくに触れることができず。
気づけば繁忙期を迎え、2022年中の同人誌執筆は諦めました。

2023年に入り、今年の技術書典はいつ開催だろうと調べたところ5月だとわかり、それに合わせて頑張ろうと一念発起。
GWもあるからなんとかなるかな〜なんて思ってましたが甘かったですね。
技術書典開催前日に書き終わり、技術書典開催日に推敲していましたw

次に、同人誌とはいえ「技術書」というものを書くので、情報の正確性を期すことがやはり大変でした。
書く内容一つ一つを実際にテストし、ほかにもっといい方法がないか検証したり、時には人に相談したり。また、VS Codeは頻繁に更新されるので、機能やUIが大きく変わる可能性があり、ダラダラと書いていると過去のキャプチャと今のキャプチャで整合性が取れなくなるかもしれません。そういう意味でも執筆に長い時間をかけるべきではありませんでした。

そんな中でもどうして第2版を書き上げなければならないと思ったかといえば、VS Codeへの移行を解説する初版を書いた者の責務だと思ったからです。
とにかくv2に対応させた第2版をリリースしなければ、という義務感で書き上げました。 それもあって頒布自体が自分の中で大きな一区切りになり、ろくに宣伝できませんでしたね😅

v2になり、ScriptUIやCEPのデバッグがやりやすくなったと思います。
ScriptUIでいうと、スクリプトと同じターゲットエンジンを指定してattachモードでデバッガーを起動しておき、InDesignのスクリプトパネルから対象のスクリプトを実行すると、VS Code側に設定したブレークポイントなどでちゃんとスクリプトが一時停止し、変数ビューを参照することができます。
このあたりは同人誌側にあまり細かくかけなかったので、もくもく会などで聞いていただければ実演します!

ということで、v2の使い方がよく分かんないなぁとか、使ってるけどなんとなくしか使ってないなぁ、みたいな方に届いたら嬉しいです!

InDesign USフォーラムウォッチング 6月第4週

というわけで先週のUSフォーラムウォッチングです。

Page.pageItemsだとグループ化された内包オブジェクトにアクセスできないので、Page.allPageItemsを使うといいよ、という話。
ただ、Page.allPageItemsプロパティにはグループもその中の内包オブジェクトもどちらにもアクセスするので、処理がダブってしまう可能性も考慮しましょう。
このあたりは似たようなプロパティ名でもホストアプリケーションによっても挙動がまったく異なります。InDesignだからIllustartorでもこうだろう、とはならないので気をつけてくださいね(ついこの間やらかした)。

まだ解決されていなくて、すごく気になっているスレッドです。いろんな方法が示されているのですが、果たしてどういう解決に至るのか…。
ちなみに自分はこの現象に遭遇したことがないです。

例えばA・B・Cという3つのドキュメントを開いていたとして、アクティブなAで2ページ目を開いていたら、ほかの2つのドキュメントも2ページ目を表示させる、という感じ。
とても簡単なスクリプトで対応されています。

これは面白くとても仕上がりが楽しいスクリプトです。
最初と最後の行を好きな色で塗ったら、その間を(まるでIllustratorのブレンド機能のように)色を補完してくれます。
こういうのこそスクリプトらしい処理で楽しいですね。

InDesign USフォーラム紹介 6月第3週

ちょくちょく見に行くInDesign USフォーラムで見かけた有益情報を共有しようかなと思って記事にしてみました。好評なら定期的にやろうかな…。 キュレーション自体はかなり自分基準です😅

  • 長いドキュメントでfindGrep()メソッドを実行すると待機時間が長すぎるためユーザーに処理中であることを伝えたいが、1行のメソッドなのでScriptUIのprogressBarが使えない。どうしたらいい?*1

手法としてはpaletteを使って対応してはどうか、というアイディア。確かにそれはアリだな〜と思ったので試してみました。
paletteを指定したScriptUIのウィンドウはモーダレスダイアログ(ウィンドウを出したままアプリを操作できる)になるのですが、スクリプト自体はfindGrep()メソッドの処理中なのでInDesignを操作することはできない、という挙動になりました。
これは悪くないアイディアだな〜と思って数回試したんですが、ある時はメインウィンドウの裏側に隠れてしまったり、ある時はダイアログが表示されなかったり(別のアプリをアクティベートしてからInDesignに戻ると表示されたりする)、少なくとも自分の環境では安定して動作させることができませんでした。

  • 正規表現検索置換で、ある単語があるストーリーの末尾に文字を挿入したい*2

質問では「Baseball」という単語があったら、そのストーリーの最後にアスタリスク「*」を挿入したいという内容です。
正解として提示された正規表現は(?s)Baseball.*\K$でした。

(?s)でシングルラインモード*3にし、「Baseball」が見つかったら、末尾を示す$までマッチさせて直前の挿入点を\Kでマッチさせるというアイディア。
ちなみにストーリーの最後を示す\Zという正規表現もあるのですが、\Kの良さはその直後の文字のみをマッチさせるというところ。\Zを使って(?s)Baseball.*\Z$などとしても、結局Baseballからストーリーの最後の文字まではマッチしてしまうので*4うまくありません。ストーリーの最後に1文字挿入するために(?s)(Baseball.*)\Z$で検索して$1★で置換するとか無理やり処理することもできますが、検索置換で文字列が置き換わるためルビが消えるとかオーバーライドが解除されるとかいろんな弊害が考えられます。
\Kを使うことでそうしたリスクも回避できているので、おそらくこの正規表現が最適解なのでは、と思いました。

\K$については過去に仕様が変わっている*5ので、古いですが当時の記事も念のため紹介しておきます。

uske-s.hatenablog.com

uske-s.hatenablog.com

というわけで久しぶりのブログ記事でした。

*1:参照元:Solved: Re: InDesign script executing after dialog.show() - Adobe Support Community - 13847029

*2:参照元:Solved: Grep Question: Command to find word then go to end... - Adobe Support Community - 13859615

*3:改行文字も含んですべてのテキストが1行に繋がったように検索できる検索オプション

*4:肯定後読みに文字数が不定長になるような正規表現が使えない

*5:\KはCS6から使えるようになった

PDF書き出しダイアログのページ範囲をリセットしたい

概要

PDF書き出しダイアログのページ範囲

タイトルどおりの要望がフォーラムに出ていたので、スクリプトで解決できますよ、という話です。

どうやってやるの?

PDF書き出しダイアログの該当部分はアプリケーションレベルで記憶されます*1。ページ範囲「4」を指定してPDF出力すると、アプリケーションはこの「4」を記憶します。次に開いたドキュメントに同じページ範囲(ノンブル)が存在すると、それが再びセットされた状態のPDF書き出しダイアログが出現する仕様のようです。このとき、前回記憶したページ範囲(ノンブル)がドキュメントになければ設定がリセットされます。
PDF書き出しダイアログの設定の一部はスクリプトでいじれます。なのでその仕様を利用して、ドキュメントには存在しないページ範囲(ノンブル)を指定してダイアログの設定をリセットしようという理路です。

スクリプトで解決しよう

スクリプトで解決したいのですが、そのためにはスクリプトを実行するというアクションを起こさねばなりません。ドキュメントを開いたらこのスクリプトを実行しましょう、では面倒ですよね。ドキュメントを開いたら自動的にスクリプトを実行してほしいわけですが、InDesignではそれができます。

それにはスタートアップスクリプトという仕組みと、スクリプトにあるイベントリスナーという仕組みを併用します。

NOTES

スタートアップスクリプトとは、アプリケーションの起動時に、所定の場所に保管したスクリプトが一度だけ自動的に実行される仕組みです。

イベントリスナーはもともとJavaScriptが持つ仕組みで、それがExtendScriptとしてInDesign用に拡張されたものです。InDesignの特定のイベント(ファイルを開く、特定のメニュー操作を実行する等)に対して、そのイベントが実行されるタイミングに合わせて実行したいスクリプト処理を登録できます。あえて端的に言えば、イベントにスクリプト処理を登録するためのスクリプトの仕組み、でしょうか。

  1. ダイアログの設定をリセットするスクリプト処理を用意する
  2. 「ドキュメントを開いたとき」というイベントに対して 1 の処理を登録するためのスクリプトを用意する
  3. スタートアップスクリプトとして 2 のスクリプトをInDesign起動時にアプリケーションに自動実行させる

というのが今回の一連の流れになります。

コード

コード全文は下記の通りです。

InDesignPDF書き出しページ範囲をリセットするスクリプト

ざっくり解説すると…

  • 冒頭の//@targetengineはイベントリスナーを利用する際の、ExtendScriptのルールです*2
  • addEventListener()というメソッドがイベントリスナーを登録するためのメソッドです
    • 引数は順に、スクリプト処理を登録する対象イベント(String)、登録する内容(コールバック関数)、バブリングするかどうか(Boolean、省略可)です*3
  • コールバック関数の引数には、対象のイベントがEventオブジェクトとして渡されます(引数eを設定していますが、このサンプルではどこにも使っていません)*4
  • PdfExportPreference.pageRangeがPDF書き出しダイアログのページ範囲です
    • 普通、ドキュメントのノンブルに0は使わないと思うので、この値を"0"にすることで設定をリセットさせています

となります。

インストール

このコードを適当な名前で.jsxファイルとして保存し、下記の場所に入れてください(InDesign 2021(v16)の場合)。

  • Mac
    ~/Library/Preferences/Adobe InDesign/Version 16.0-J/ja_JP/Scripts/startup scripts
  • Windowsの場合
    ~\AppData\Roaming\Adobe\InDesign\Version 16.0-J\ja_JP\Scripts\startup scripts

この場所に「startup scripts」というフォルダがなければ作成してOKです。

スタートアップスクリプトとイベントリスナーの組み合わせは非常に強力です。うまく利用してInDesignをゴリゴリ活用しましょう!
こんなことできるかなとか、もっと詳しい話が聞きたいな、ということであればもくもく会でお待ちしています!

*1:筆者調べ

*2:指定するエンジン名(サンプルでは "PDFpageRangeReset")は任意です

*3:詳細はInDesignスクリプティングガイドを参照ください

*4:このケースであれば、開いたドキュメントの情報がこの引数eに渡されています

InDesign Tips - 桁区切りのカンマを挿入する正規表現

ご無沙汰の更新となってしまいました。

もともとInDesignのTipsをまとめて同人誌にしようと思っていたのですが、なかなかまとまって書くタイミングがないので不定期的にブログ記事にしていこうと思います。

今回はその一発目で、正規表現の話です。

桁区切りカンマの正規表現

正規表現

割りと悩ましい3桁区切りカンマの挿入について、過去にDTP Transitさんがツイートされてました。

検索:(\d{1,3})(?=(?:\d{3})+(?!\d))
置換:$1,

それとは別に、先日、某掲示板にてもう少しシンプルなものが紹介されていました。

検索:(\d+?)(?=(\d{3})+(?!\d))
置換:$1,

どちらも3桁区切りのカンマを挿入できます。
たまたまですが、自分はここで紹介されたものと同じものを使っていました*1

ほとんど違いがないので後者だけ((\d+?)(?=(\d{3})+(?!\d)))少し分解してみますと、

  • (\d+?):連続する数字(最短一致)、キャプチャされ置換時$1の対象
  • (\d{3})+(?!\d):左が後ろに続く場合、上記がマッチする(キャプチャされない)
    • この正規表現は「後続に数字が存在しない、『3つ連続する数字』の連続(最長一致)」
    • 否定先読みは、文字列が存在しない場合でも対象になる*2

と、正規表現自体はおよそこんな意味です。

挙動の説明

この正規表現((\d+?)(?=(\d{3})+(?!\d)) )について、少し挙動を分析してみましょう。見本として、InDesignにて下図の文字列を用意しました。

正規表現を確認すると、肯定先読みの前、(\d+?)この部分をまず見つけます。

+?は最短一致なので、最初の数字にマッチするわけですね()。
ここから、肯定先読み部分((?=(\d{3})+(?!\d)))にマッチするか調べます。

分かりやすいように数字3文字で区切っています

上図の通り、連続する3つの数字と数字以外、という組み合わせ条件にマッチします。
肯定先読み部分のチェックが終わると、元の検索位置(つまりの直後)まで戻って検索を再開します。

こんな具合で、うまく3桁の区切りにカンマを挿入できるわけです。

ちなみに

掲示板で(\d)(?=(\d{3})+(?!\d))が期待通りマッチしないと書かれていましたが、これはおそらくInDesignの不具合のような気がしてます。
CotEditorなどほかのエディタではマッチするからです。

参考文献

*1:過去の記事にも桁区切りカンマの正規表現を書きましたが、こっちはマッチしないケースがあるので使っていませんでした。ということで記事も直しています。
InDesignで数字3桁区切りをする正規表現(メモ書き) - DTPab

*2:例えば、前掲注の僕の過去の記事では [^0-9] としていましたが、これは文字列として存在しないとマッチしないので悪手でした

InDesign v18.0リリース:UXPスクリプトが導入されました🎉

先日リリースされたInDesign 2023(v18)にて、UXPスクリプトが使えるようになりました。
AdobeのTechブログにも記事がアップされています。

blog.developer.adobe.com

記事の中にもあるように、これからアップデートされていく予定です。

Also note that UXP panels or plugins are not yet supported and will be available in upcoming releases. InDesign 18.0 and InDesign Sever 18.0 have only added UXP Scripting capabilities.
UXPパネルやプラグインはまだサポートされておらず、今後のリリースで利用可能になることに注意してください。InDesign 18.0(及びInDesignサーバー)はUXPスクリプトのみが追加されただけです。(筆者訳)

記事の最後には今後の機能実装予定があるので、そちらも転載しておきます。

🔜 Near future (2023 First Half)
- Additional Scripting APIs
- Menus & Events
- Function Pointers
- Complete File and folder access
🔮 Future (2023 in general)
- 3p UXP Plugins
- Script versioning

というわけで、2023年がUXPスクリプトの幕開けになりそうですね。非常に楽しみです!

一応、公式ドキュメント(英語)も用意されています。
広く多くの方に触っていただき、フィードバックをぜひAdobeのフォーラムにぶつけましょう👊
オブジェクトモデルはこっちにあります。

また、以前記事にも掲載しました*1が、ExtendScriptからUXPスクリプトに早急に置き換わることはありません。現在のUXPスクリプトはまだまだ荒削りという印象ですので、これから触れようという方はUXPスクリプトのあら捜しをしようくらいの気持ちで利用するのがいいと思います*2

*1:参照:DTPerのスクリプトもくもく会#30を開催しました - DTPab

*2:UXPスクリプトには割と致命的な不具合があるようです。参照:Adobeフォーラム

DTPerのスクリプトもくもく会#30を開催しました

ひさしぶりのもくもく会開催報告です。
忙しかった仕事がやっとひと山いやふた山くらい越えたなというところですが、職場は慢性的な人不足で綱渡り状態です。
即戦力のDTPオペレーターさん(正社員)を引き続き募集中っぽいので、ご興味があればお声がけください!

それはさておき、第30回目のもくもく会を9/10に開催しました。今回は初心者枠に2名、一般枠に4名、合計6名の方が参加してくださいました!
もくもく会中、実はミュートできていなくて、娘を叱る声とか、娘が鼻を啜る音とかが入っていたみたいで大変申し訳なかったです^^;;

では、当日出た話題を振り返ってみます。

InDesign 2023(v18)プレリリースビルドにおけるUXPスクリプトについて

僕とお〜まちさんの当日のタスクがかぶり、ふたりしてUXPスクリプトについて調査とテストを行いました。僕からすると頼もしい限りで、自分で調べたり試したりしたところをお〜まちさんとも共有できて、非常に有意義かつ実りのある時間になりました。

UXPスクリプトとExtendScriptの今後の関係性

プレリリースビルドのアプリについてなので細かいことは書けませんが、お〜まちさんがブログでも書かれているとおり(以下引用)、

ExtendScriptでの財産がまるっきり無駄になるということはなさそうです。ただ修正は必ず発生します。一括置換で済まないのでちょっと面倒です。

とあるように、過去のExtendScriptで開発したスクリプト資産をUXPスクリプトとして移植する場合においては、僕も同じ感想を持ちました。
より具体的にいうと、スクリプトの中身(変数の参照先など)を把握し、適切な書き換えを行う必要があるということです。

では、過去のExtendScript資産は無用の長物になるのか、つまりExtendScriptが廃止されるのかについては、

最終的にはそうでしょう。ただそれはかなり先のことになると思います。InDesignではまだExtendScriptで可能なことでUXP Scriptingでは対応していない部分があります。

とお〜まちさんも書かれているように、僕も同意見です。

あとで調べてみたら、Adobeの中の人であるErin Finnegan氏もそうツイートしていました。

UXPスクリプトのメリットと今後の課題

そもそも、UXPスクリプトをわざわざ利用するメリットは何か? それはES6*1という比較的モダンなJavaScriptが利用できる点です。
ExtendScriptはES3という大昔の仕様でしたが、UXPスクリプトを利用すれば、配列を扱う関数が豊富になり、テンプレートリテラルが使えたり、アロー関数も使えたりします。
もくもく会の最中にツイートしましたが、UXPスクリプトはJavaScriptからAdobeが独自拡張させてきた部分を、本来のJavaScript(ECMAScript)に近づけよう/あるべき姿に戻そうという意識を感じました。特に、ExtendScriptにおけるグローバルメソッドがその煽りを喰らった格好です。

見方を変えると、UXPスクリプトのメリットを享受するためにはES6を使えるようにならないといけないわけです。先述の通り、ExtendScriptからそのままUXPスクリプトに乗り換える(変換する)というのは非常に面倒くさく、しかもExtendScriptでできたことがUXPスクリプトでは(現時点では)一部できないこともあります*2

ExtendScriptがすぐ利用できなくなるわけではないでしょうから時間をかけて地道にアップデートしていけばいいのですが、問題はUXPスクリプトで利用できなくなるあれやこれやが、UXPにおいてどう解決を図る必要があるのか、スクリプトでいいのかプラグインが必要になるのか、その見極めが必要になります。
まだプレリリース段階だからか、Adobeもしっかりしたドキュメントを用意できていないようで*3、現在公開されている「UXP」と書かれた資料の大半はPhotoshop用のUXPプラグインのものでした。
このあたりは引き続きキャッチアップしていく必要がありそうです。

段落スタイルの基準スタイルにアクセスしたら「ルートスタイルに対する無効な要求」と怒られが発生した

「[基本段落]」のParagraphStyle.basedOnプロパティを参照すると「ルートスタイルに対する無効な要求です」と怒られるようです。
アプリケーションの「ルート段落スタイル」(造語)にはアクセスできない、ということです。
概念としてはものかのさんの記事のここらへんが参照になるかと思います。

回避方法としては、そのようなエラーが発生する段落スタイルでは対象プロパティを参照しない、というほかありません。

Duet DisplayでInDesignコントローラーを作ってみる

デモをTwitterにあげてくださっていたのですが、尖っててめっちゃ面白かった!w

さいごに

というわけで、今回も非常に楽しくもくもく会を行うことができまいた。
参加してくださった皆さま、ほんとうにありがとうございました!

*1:ES2015、ともいいます

*2:僕の推測ですが、ExtendScriptでできて現在UXPスクリプトでできないことは(このまま秋にリリースされるであろうv18の製品版でもその仕様が変わらないようであれば)UXPプラグインでやってね、になるのではと考えています

*3:リポジトリのリンク先が404だったり…

退避したはずのOsakaが復活した?

自分用の覚書です。

InDesign 17.3から解消された、Macユーザーには馴染み深いページ情報の文字化けの話。

それ以前のInDesignでは、Osakaフォントを所定の場所から退避させることで(別のフォントにフォールバックさせて)文字化けを回避するというバッドノウハウみたいのがあります。

僕自身そうしていたのですが、いつからか濁点・半濁点が化けた状態のページ情報が入るようになってしまいました(Osakaがどこかに復活してた)。
所在を調べたところ、自分のMac(macOS Mojaveの場合)ではここにいました。
/System/Library/Assets/com_apple_MobileAsset_Font5

macOS Sierra以降、インターネット経由でインストールされるフォントがここに格納されているようです*1

というわけで、移動するよりFont Book.appからOsakaの利用をオフにしたほうが身のため。

Font Bookからコントロールしよ

【InDesign】セルの幅を3pt未満に設定するテクニック

以前、セルの高さを任意に設定するスクリプトを紹介しました。

uske-s.hatenablog.com

単純にheightwidthに変える程度で幅も変えられるようになるかなと思ったんですが、それは許してくれませんでした*1

今回はスクリプトではなく、セルの幅を3pt未満に設定するテクニックを紹介します。
InDesignの標準機能だけで実はできるんです。が、一筋縄ではないのでテクニックなのです。

InDesignから列の幅を指定できる最小値は3pt≒1.058mmです。

mm換算で1.058mmが設定できる最小値

例えば、この列の幅を0.5mmにしたいとしましょう。

手順

  1. 表のどこでもいいので行を挿入します
  2. 調整したい列を含めて2セル分結合します
  3. 結合したセルと同じ列の別の2つのセルの列幅を調整します
    • 「最終的に設定したいセルの列幅(A):結合した隣のセルの列幅」が「2:結合した隣のセルの列幅 * ( 2 / 列幅A )」になるように計算します
    • 今回は 0.5mm:30mm が最終的に設定したい列幅になるので、30 * ( 2 / 0.5 ) = 120 となり、細い方の列幅を2mm、隣の列幅を120mmに設定します
  4. 結合したセルの列幅を、もともと設定したかった2つのセルの列幅の合計にします(今回は 0.5 + 30 = 30.5mm)
  5. 挿入した空の行を削除します

これで完成です!

完成図

まとめ

  • 結合されたセルの列幅を調整すると、内包する列の列幅が均等に調整される
  • その性質を利用して、比を使って列幅を調整してから、結合したセルのサイズを変える

非常にかんたんなんですが、知っておくと役に立つテクニックでした。おわり。

*1:スクリプトがエラーを吐いて止まってしまう

【InDesign】検索置換で段落スタイルを適用する際の注意点

久しぶりの更新になりました。仕事の繁忙期と、この間の登壇準備でブログの更新などそっちのけでした…。

さて今回は久しぶりにスクリプトから離れて、InDesignの機能についての記事です。どうぞ最後までお付き合いください。

はじめに

大した内容ではないんですが、検索置換を利用して段落スタイルを適用する際に注意しているところを記事にしました。

段落スタイルを適用する方法(おさらい)

テキストに段落スタイルを適用するには、①段落スタイルを適用したいテキストを選択した状態で、②段落スタイルパネルから任意のスタイルをクリックするのが一般的かと思います。

検索置換による段落スタイルの適用

日常的によく使うテクニックとして、段落スタイルを検索置換で適用するというのがありますね。

置換条件に段落スタイルを指定して検索置換を実行する

この画像では#で始まる見出しに段落スタイルを適用しています。

パネルから適用する/検索置換から適用する、その結果の違いは?

端的に言うと検索置換による段落スタイルの適用ではオーバーライドが解除されます

検索置換による段落スタイルの適用はオーバーライドが解除される

事前に文字を赤くしてテキストをオーバーライドさせておきます。分かりやすいようにオーバースタイルハイライターを適用させました。この状態で検索置換を行うと、置換後にはオーバーライドが解除されています*1

同じデータでも、パネルからスタイルを適用した場合はオーバーライドが残ります。

パネルから段落スタイルを適用するとオーバーライドは残る

不具合ではなく、おそらくこういう仕様なのだと思います。
検索置換を日常的に利用している方にはよく知られた挙動かもしれません。

検索置換で段落スタイルを適用する際の注意点

  • オーバーライドが含まれる段落へのスタイル適用は、置換ではなく、検索→段落スタイルパネルからスタイルを適用するのがベター
  • 「すべてを置換」でまとめて置換したら、必ず全体の結果を確認すべし
  • スクリプトなどで連続して検索置換を行う場合、段落スタイルを適用するものを先に、オーバーライドによる文字設定を行うものは後にすることでうまくいく

検索置換(特に正規表現検索置換)はその条件がハマると非常に強力ですが、自分の認識外でどのような変化が起きたか捉えにくいという側面もあります。
検索置換だとこわいとかそういう話ではなく、特性を理解しうまく使い分けていければいいですね!

*1:置換文字列を空にしてスタイルを適用するだけ、という状態にしても結果は同じです