おすすめ | #iOS | #Android ファショ通

【Mac】PDF に無料プレビューアプリで自在に文字入力する方法 - 入力フォームに文字が収まらない

最終更新日時 : 2024-10-13 21:27

役所関連の配布された様式 PDF に文字入力した PDF を作成します。

ここでは、国税庁「居住者証明書交付請求書」を作成していきます。

👉 No.9210 居住者証明書の請求｜国税庁

国税庁のサイトで様式が2つ公開されています。

「印刷用」は、印刷して手書きで記入してね、

「入力用」は、そのままパソコンで入力できますよ、

ということなのでしょう。

🧑🏻‍💻 PDF入力フォームに文字が収まらない問題

配布されているPDFに設定された入力フォームでは、

フォントやサイズや入力位置が変更できないようで

きれいに収まってくれません。

🧑🏻‍💻 パスワードロックを外す

プレビューや Chrome の「印刷」機能からパスワードロックなしの PDF を作成します。

ダウンロードした PDF をプレビューで開いて、「ファイル」-「印刷」から、

または、Chrome でリンククリックでPDFを開いた状態から「印刷」-「保存」で一度PDFを書き出すか、
または「プレビューで開く」とそのまま編集可能な状態になります。

使う様式はどちらでもいけますが、

PDFにすでに作成されている入力フォームは必要ないので

「印刷用」のほうが混乱しなくて分かりやすいと思います。

覚えておくことは、プレビューでも、Chromeでも、

「印刷機能を使ってパスワードロックなしPDFを再作成する。」

ということです。

🧑🏻‍💻 PDF に文字を入力する

昔からある「マークアップパネルからテキストを追加」する方法。

一番万能で自在。

または、

最近のプレビュー新機能の「自動で作成される入力フォームからテキスト追加」する方法。

これも便利かもしれません。

🧑🏻‍💻 まとめ

元はといえばこんなメッセージがきましたので。

役所へのPDF様式を元にした書類作成は、

慣れてる人以外は毎回イライラしますよね。

毎回、紙に印刷して手書きで記入していたので、

今回少し調べてみました。

最後に、作成してる風景を動画を。

🧑🏻‍💻 参考

👉 【Android】Google Play Store Developer アカウントを「個人」から「組織」に変更した手順をきちんとまとめておく
 👉 PDFのメタ情報を確認する
 👉 リンゴ印のライフハック(103) Macの「PDFとして保存」を上手に使おう | マイナビニュース

SwiftUI・UIKit・AppKitでの画像処理の煩わしさを解消するためのヒント

最終更新日時 : 2024-10-10 22:29

図を作ってみました。

Appleの異なる画像処理フレームワーク（SwiftUI、UIKit、AppKit）間で画像データをやり取りする際のフロー図を示しています。

この図が示しているように、iOS や macOS で画像を扱う場合、複数の異なるフレームワーク（SwiftUI、UIKit、AppKit）間での画像データのやり取りが必要となることがよくあります。

しかし、それぞれのフレームワークは異なる画像型（UIKit では UIImage、AppKit では NSImage など）を使っているため、これらを統一して操作するのは煩雑です。

処理の煩わしさは以下の点にあります：

🧑🏻‍💻 異なる画像型の存在

UIKit、AppKit、Core Graphics などの各フレームワークはそれぞれ独自の画像データ型（UIImage、NSImage、CGImage など）を使います。

異なる画像型を相互に変換する必要があり、そのための変換処理が増えてしまいます。

🧑🏻‍💻 変換処理の多さ

SwiftUI の Image コンポーネントに画像を渡すには、UIKit の UIImage や AppKit の NSImage などの形式に適切に変換する必要があります。

例えば、UIImage を SwiftUI に渡すために Image(uiImage:) を使う必要があり、AppKit の NSImage なら Image(nsImage:) を使います。このように、変換手順が異なり、統一感に欠けます。

🧑🏻‍💻 データ型の制約と互換性

画像データをファイル形式（例えば、PNG や JPEG）に変換したり、ネットワークで送信する場合、Data 型を使う必要があります。

そのため、 UIImage.pngData() や NSBitmapImageRep.representation(using:properties:) のような変換処理を追加で行わなければなりません。

こうした一連の変換処理は単純な画像表示のために多くの余分なコードを必要とし、開発者にとって煩わしいと感じる要因です。

🧑🏻‍💻 フレームワーク間の相違点

UIKit は iOS 向け、AppKitは macOS 向けのフレームワークなので、同じアプリをクロスプラットフォームで開発する際に、これらのフレームワーク間の違いに対応しなければならず、異なる API や処理方法に習熟する必要があります。

総じて、このような画像の処理は、単純に画像を表示・変換・送信したいだけであっても多くの手順が必要となるため、効率的でないことが多いです。

これが処理の煩わしさにつながっています。

🧑🏻‍💻 SwiftUI

Image(uiImage:) または Image(nsImage:) を使って、それぞれ UIKit の UIImage または AppKit の NSImage を表示できます。

ImageRenderer(content:) を使って、 UIImage または NSImage を作成することが可能です。

🧑🏻‍💻 UIKit の UIImage

SwiftUI の Image や AppKit の NSImage との間で画像の相互変換が可能です。

UIImage は pngData() でPNGフォーマットのデータに変換できますし、 UIImage(data:) でデータから画像を生成できます。

🧑🏻‍💻 AppKit の NSImage

AppKit では NSImage.cgImage() で Core Graphics の CGImage を取得でき、NSBitmapImageRep クラスを使って画像表現の変換が行われます。

NSBitmapImageRep を通じて、NSImage は、PNGなどの形式でエクスポート可能です。

🧑🏻‍💻 Core GraphicsのCGImage

UIKit の UIImage や AppKitの NSImage と互換性があり、それらを通じて画像を描画・変換する基盤を提供します。

🧑🏻‍💻 Foundation の Data

UIImage や NSImage から変換したデータ（例：PNG）を保持するデータ型。

これにより、画像データをファイルとして保存したり、ネットワークを通じて送信したりできます。

🧑🏻‍💻 したかったこと

AsyncImage 内での画像データの比較です。

302 リダイレクト後の画像を確認しています。

🧑🏻‍💻 まとめ

SwiftUI、UIKit、AppKit での画像処理は、それぞれのフレームワークが異なる画像形式を扱っているため、煩雑に感じることが多いです。

しかし、正しい変換手法を使い、CGImage などを活用すれば互換性を確保できます。

さらに、最新の API を使いこなすことで、画像処理を効率的に行い、開発の手間を減らすことが可能です。

この記事で紹介したヒントを参考に、より快適な画像処理の開発を目指しましょう。

【SwiftUI】UIImage / NSImage の Image への抽象化

最終更新日時 : 2024-10-05 23:55

どちらが好きですか、以下2つのコード。

■ 1つ目


import SwiftUI

public extension Image {
    #if canImport(AppKit)
    init(image: NSImage) {
        self = Image(nsImage: image)
    }
    #endif

    #if canImport(UIKit)
    init(image: UIImage) {
        self = Image(uiImage: image)
    }
    #endif
}

特徴：
- 拡張機能 (extension) を使って、Imageに新しいinitイニシャライザを追加しています。
- プラットフォームごとに異なる型 (NSImageやUIImage) を直接引数に取ります。
- プラットフォーム依存の条件付きで、NSImage（macOS）またはUIImage（iOS）を使用してImageを初期化しています。

メリット：
- 各プラットフォームに対応したイニシャライザが個別に用意されており、Imageの初期化が直感的です。

デメリット：
- プラットフォームごとにinitメソッドが別々に定義されているため、共通の型を扱うのが難しい。

■ 2つ目


#if canImport(AppKit)
import AppKit
public typealias PlatformImage = NSImage
#elseif canImport(UIKit)
import UIKit
public typealias PlatformImage = UIImage
#endif

import SwiftUI

extension Image {
    init(platformImage: PlatformImage) {
        #if canImport(UIKit)
        self = Image(uiImage: platformImage)
        #elseif canImport(AppKit)
        self = Image(nsImage: platformImage)
        #endif
    }
}

特徴：
- PlatformImageという型エイリアスを使って、macOSのNSImageとiOSのUIImageを抽象化しています。
- platformImageという共通の引数型を持つイニシャライザを追加しています。これにより、プラットフォームごとにImageを初期化しますが、型エイリアスによって共通化されています。

メリット：
- 抽象化されているため、呼び出し側のコードがプラットフォームに依存しません。つまり、共通のコードでPlatformImage型を使えば、iOSでもmacOSでも同じコードで動作します。
- 可読性が高く、メンテナンスが容易です。プラットフォームごとにメソッドを分ける必要がなく、1つのメソッドで対応しています。

デメリット：
- プラットフォームごとに異なる処理を追加する際に、多少複雑になる可能性があります。

■ まとめ

AIによると、

結論：どちらが良いか？

2つ目のコードの方が一般的に推奨されます。理由は、コードの抽象化によって、呼び出し側がプラットフォームに依存しない形でImageを扱うことができるためです。メンテナンス性が高く、同じコードベースで複数のプラットフォームをサポートしやすくなります。

ただし、プラットフォームごとに異なる処理が必要なケースでは、1つ目のコードの方が直感的に分かりやすい場合もあるので、状況に応じて選択が変わることがあります。

ということです。

私的には、どっちも勉強になります、としか。