Pixel 7aを買ったので自分が購入前に読みたかったレビューを自分で書いてみる

カメラ性能がどうとかスペック比較がどうとか、そういう一変通りな評価ブログ記事ははっきり役に立たないので、本当のスマホ端末の評価ブログ記事というものはこう書くのだという記事を自分で書いた。

スマホ端末レビュー記事で一番大事なのはちゃんと筆者の自分語りがされていること。なぜならスマホ10台持っていてスマートニュースとITmediaに寄稿して技術書典に出展しているガジェットナードの書いた記事（このスマホはレンズが５つあるし世界で唯一ホンジュラスでしか使われていないバンド帯域のSIMにも対応しているので最高！）はガジェットナード以外が読んでも参考にならないから。
このブログ記事の筆者は、「スマホの画面はデカければデカイほどいい」と信じており、8インチタブレット(huawei media pad M5 lite 8)がSoCスペック十分だった頃にはメインスマホとしてポケットに入れて持ち歩いていたことがある。
そして7aはRedmi note 10tからの買い替えで、「音楽再生しながらChromeでツイッタを見ているだけでもミュージックプレイヤーがKillされるのが辛い」という理由で買い替えに踏み切った。

＃＃総合

とにかく音楽再生しながらChromeでツイッタを見ていてもミュージックプレイヤーがKillされないのが最高。
タブを移ったりちょっとLINEを触ったあとにツイッタに戻ってもページリロードで見ていた箇所が消えないのは素晴らしい。
 

＃＃（購入前）Suica対応

Suicaが不安定な個体があるという未確認情報があるため、購入はギャンブル要素がある。
この情報源のブログ、やたらと冗長な文章でどうにも信頼性を怪しく感じる。閑話休題。
私が買った端末は問題なく改札Suicaタッチできたのでよかった
 

＃＃ロック

電源ボタンに指紋センサがないのは面倒
また画面の指紋センサはあまり効きがよくない
ガラスフィルム貼って使っているから感度が低いという話はあるが、ン万円もする端末をフィルム貼らずに使うはずがないのだから（要出典）最初からフィルム貼られる前提で指紋センサ作っておくべきというだけ
購入してまずフィルムを貼ったため、指紋登録自体をフィルム有りで行っている
PIN入力の際、以前の端末までは正解PINを入力すれば解除されていたのが、確定ボタンを押さなければいけないのが１アクション増えて面倒になった
（セキュリティが気になるユーザは１文字増やせば同じようなものなのだから、省略させてほしい）
 

＃＃ウィジェット

アプリ一覧のアプリを種別ごとにまとめられないのはどうなのか
（数ヶ月使ってみたら後述の検索でなんとか運用でカバーできるようになり、まあまあ慣れた）
インストール済みアプリを検索でひっかけられるのは良い。ただ全く引っかからないこともあり、もっとあいまい検索でもひかっけられるように（カタカナでラインと打ってもLINEがひっかかるとか）できているべきだと思うが（Googleって検索で大きくなった会社じゃなかったのか？　検索の技術力が低すぎる企業なのではないかと感じた）

＃＃キーボード記号入力

gmailのメールアドレス拡張(+xxxx@gmail.comをつけ放題の機能)のメールアドレスをよく使っていたのだが、ログインなどでメルアド入力する際に入力が地味に面倒。
インテリセンスが効かないのと、｀+｀の記号を入力するのがテンキーでもできないため。
わざわざキーボードを記号入力までモード移動しなければならないが、7aでは「使用歴あり記号一覧」みたいなのがあり、少ない候補からいつもの｀+｀が入力できるのは便利。ただこれ私はいいけれど各種記号使うユーザはすぐ溢れるのでは？
 

＃＃カメラ

画質はそもそも気にしていない。気になるほど悪くはないのでOK
前の端末より起動が早くなったのは嬉しい

が、以前の端末と違い、ロック画面からアクセスできなくなったのは不便

pixel 7aの問題と言うより、スマホ以外のカメラも含めて、やはりまだ、撮りたくなってからアプリを立ち上げてシャッターを切るまでの時間で、撮りたいものに撮影が間に合わないな、と感じている

 

＃＃アラーム

以前はホーム画面の時計をタップすれば設定に入れたが、今は一旦メニューを出してから時計を触る必要があり、かつ時計が小さくアクセスしづらくなった

＃＃ あとがき

購入して上記のレビューの原文を書いてからざっくり半年ほど経った。pixel 7aに慣れてしまっただけかもしれないが、いまのところ大きな不満はない
あえて言うなら、以前はPixelの広告がプッシュ通知されていたのだが、OFFにしたのか覚えていないが最近は出てこなくなったようで良い、というのが近況だろうか
 

個人的には、早く24インチディスプレイが気軽にモバイルできるようになってほしい 

スズランのフィギュア作りました

スズランのフィギュア、なかったので作りました

フルスクラッチ 1\7 スケールの光学式3Dプリントガレージキットです

 

 

「無いんだったら作ればいいのよ」という古い神様の格言に従った次第

2022/09から着手して2025/5リリースとなり、足掛け2.5年かかってます

まあ途中中断していたからなのですが、正月アカリを作ったり商業出版したりいろいろあった間に競合でもある素敵なガレキがいくつか出てきたものの、公式からスズランフィギュアが出ないままだったのは、良かったのか悪かったのか

Blenderの利用

スズランのモデルデータはBlenderにてポリゴン方式でモデリングしました

 

 

今回いわゆる「ローポリ」の先人たちの知見を応用させていただいた次第です

ポリゴン方式は、ざっくり説明すると三角形の面をくっつけ合わせるタイプの作り方です

2Dにベクタとラスタがあるように3Dにもポリゴンとボクセルがあり、Blenderは3Dモデリングソフトウェアとしてはボクセル風な作業もできますが基本はポリゴン系ベースです

ただ、いわゆる美少女フィギュアのモデリングで一般に多いのは、ZBrashでボクセルです。ようはCG粘土細工といった手触りになります

つまり、Blenderでモデリングをすると一般的なフィギュアモデリングのテクニックそのまま使えない部分が出てくるということです。ゲームキャラクターCGなどでこれまた知見の多いローポリを応用する必要があった理由でもあります

あとついでに、Blenderは元はCGアニメーション向けとして出発しているソフトウェアです。なので3Dプリント用モデル製作での使用は、向いてないというか不便なところは正直ちょっとあります

髪と顔

頭部は前髪と後頭部をパーツ分けする標準的な分割です。耳は後頭部と一体化

 

 

 

髪は房毎のポリゴンパーツとしました。参考モデルがそうだっただけなのですが、結果的に流れるような綺麗な髪を持つモデルの素敵なスズランとなり、作り直しせずに済みました

とはいえ次モデルでは、パーツ管理の都合で一体ポリゴンパーツに挑戦すると思います

顔モデルは元々CGアニメーション向けのポリゴン構造を参考にして流用しています

 

 

そこから手元にあるフィギュアや、デッサン用に持っているアニメドールの頭部を参考に、アイペイント向けに作り変えています

また、フィギュア向けを意識して、元イラストよりも僅かにシュッとした縦長で大人っぽい造形に寄せています

スカート周りの造形

薄いマテリアルはプリント時に歪みの原因となり、広がった裾が3Dプリンタの造形サイズ限界を叩き、多量のフリルは作業工数を爆発させ、左右非対称の皺がスケッチ技能を要求する...等々、スカートは単純ながら難しいターゲットです

 

 

モデルとして固定方法も困りもので、最終的に、スカートを胴体と下半身の間で挟んで固定するため、腰回りの全モデル含有を断念しています

最初はアンダースコートもそうだったのですが、スカート厚の問題もあり、かなり手間を掛けて、スカートにビルトインする形に変更しました

BlenderではSubdivisionSurfaceを用いることでかなりポリゴン数を削減しなめらかなスカートを作ることができます。この方式は操作ポイント数をかなり削減できるため編集が楽になるのですが、Blenderと印刷の都合によりViewレンダリングが重くなってしまうのを避けられません

アンダースコートのフリルは何かしら良い感じの幾何学的操作で半自動で作ったような気がするのですが、時間が経ちすぎて手順を忘れてしまいました

スズランの背中

スズランの背中側、意匠がどうなっているのかは正直よくわからず、あちこち調べまわりました

現状、調査の結果として公式の3DモデルがX周年記念動画で登場しており、後ろからのショットもあったのでこれを参考にしています

 

  

(CG,VRでない立体造形用モデリングなので色付けは適当です)

 

ただしこれも3Dモデル用にディフォルメなどされたものである可能性はあります

また、どうにも首元の布色など詰めていくと矛盾するようなところがあり、最終的には首裏の構造には創作も少し混じっております

公式資料集などには答えが載っているのかもしれませんが、タイミングにより入手はできなかったため、情報をお持ちの方は良ければお知らせください

とはいえ、最終的には後述の通り、マントをマウントする都合で本モデル固有な意匠も入れています

マントの固定

引き続きベルトも関係する話として、フィギュアのマントの固定

フィギュアのマントパーツは、どう固定するかという問題がつきまといます

スズランの意匠の場合、肩を覆うフリルと前面の止め紐で全周を覆っているのも問題です

今回のガレキでは、パーツ構成としては止め紐はパーツ分離して肩フリル付きのマントを一体出力

組み立ては首を外した状態でマントをかぶせて組み立て

基本的には接着剤で固定する、という想定としました

 

 

 

成形について、最初は止め紐含め一体で3Dプリント出力していたのですが、

上半身の方にマントの止め金がありそうな位置に対応するマウントポイントを造形することで対応しました

マウントポイントは創作で、背中の見えないところは完全に固有ですが、前面の止め金は本家デザインにも存在する蓋然性はかなり高いのではないかと思っています

ワンド（杖）

フィギュアモデリングはキャラクターが主体ですが、直線が多く作りやすい装備類、特に長物として目を引く杖のモデリングは、ある意味３Dモデリングで最も楽しい工程ではあります

 

 

 

今回悩んだのですが、弊シャとしては新しい試みとして、ワンドの軸に既製品3mmプラ棒を採用することとしました

パーツ管理まで考えると意外とこういう単純な形を3Dプリント出力するのは面倒ですし、あと弊シャは高価なレジンを使っているので置き換えられるパーツは節約したい、という都合もあります

 

モデル側の工夫として、杖自体ではありませんが、杖を持つ手のひら内側に杖を位置固定する凸モールドを入れてあります

中折装着にすることで杖の塗り剥げを防止し、杖を持つ高さも固定できます

３Dプリント工程

苦労が多い3Dモデリングですがフィギュア制作においては道半ばに過ぎません

モデル完成から、3Dプリントにたどり着くまでにはいくつか乗り越えるハードルがあります

＊多くの場合、モデルをそのまま一括3Dプリントはサイズ上厳しいため、印刷モデルはパーツ分割が必要です。パーツ分割方法によっては後の着色工程を支援することもできます

＊コストと取り扱いの都合、印刷モデルは中抜きするべきです。中抜き自体はスライサが自動でしてくれますが、中に溜まるレジンを抜くための抜き穴の位置はヒトが調整して開ける必要があります

＊多くのモデルは全てが土台にひっついた出力とはならないので、出力中に印刷物を支えるサポート材を付けることになります。これもスライサが自動で付けてくれますが、あまり賢くないので最後はヒトが調整します

＊これらを３Dプリント土台上で配置し、必要なら複数回に分けて、3Dプリントを実施します

パーツの分割

パーツを分割してしまうとポーズの大幅な変更は厳しいため、非可逆な工程となります

3Dプリンタの印刷可能サイズによってはモデルデータを未分割で出力が厳しい

大きなスカートなどをモデリングするときは、当初から分割可能になるようデザインを検討することになります

芯棒穴をあけておく

ガレージキットといえばパーツを繋げる針金を刺す穴も購入者が開けるもので、パーツ同士ズレないように穴をあけるテクニックがよく取り上げられています

 

 

流し込み複製では難しいですが、３Dプリント向けモデルでは穴を開けることも容易なので、最初から芯棒を刺す穴をあけておくことにしています

自分で仮組みをするときにも役立ちます

モデルの中抜き

高価な光造形レジンを使っている都合、モデル中抜きは大切で、中抜きの有無で材料費が３倍とか違うため試作にも影響が出ます

ちなみに、弊シャことdaisy bellではエキマテという安価帯価格から5倍くらいする高額レジンを使っています

アレルゲンフリーを謳っており、うっかりレジンアレルギーで光造形3Dが出来なくなるなどのリスクを低減できる、はずです（ちなみにエキマテ販売元に「硬化前から大丈夫なの？」と訊いたことがあるけれど成分表だけ渡されて大丈夫と明言はしてくれなかった）

閑話休題

初期、中抜きはBooleanモディファイヤで手作業していました

できるだけ材料消費を減らすよう薄くギリギリを攻めて、試作を出力すると薄すぎて破綻したり中貫が突き抜けて穴が空いていたりで、やり直しに時間と材料費が無駄にかかる本末転倒、みたいなことになっていました

ほかにも、Booleanモディファイヤで複雑になるとモデルデータが重くなるとか、モデルを編集したとき中抜きも編集して追従する必要があり面倒、などのデメリットがあります

結局、モデル作成でまごまごしているうちにスライス後工程ソフトウェアのCHITUBOXに中抜き（Hollow）機能が実装されたため、ほとんどのパーツで中抜きをCHITUBOXに移行してモデルからは削除しました

3Dプリント実施

スズランはスカートが大きく他パーツも点数が多いため、結局、弊シャ環境では4回に分けて3Dプリント出力が必要となりました

総括

満足いくものが出来ましたが、もっと工程は洗練できると思うので、次回はもっとうまくやります

 

daisy-bellのBOOTHにて頒布

https://daisy-bell.booth.pm/items/6800571

 

 

 

Blenderクイズ：SubdivisionSurfeceの結果がおかしい

（今回、持って回った英文翻訳風にざっくり雑にブログ記事を書きたい気持ちだったのでクイズの形式を取っているだけです。答えバレ防止反転表示などはしていないので、本当にクイズ当てしようとせず、軽い気持ちで読んでください。）

 

3Dモデリングソフトウェアは立体という我々が日常に何時も触れている身近な存在を扱うソフトウェアですが、あくまでコンピュータの中にあるObjectは計算で仮想しているものでしかなく、そのため時に思いがけない結果形状を示し、望みの外観を得るためには（私がそういった深い認知を持っているかは棚に上げますが）Blenderへの深い理解や長い経験が必要な場合があります。

 

今回はクイズです。Blender上でSubdivisionSurfece モディファイアを掛けた結果がおかしいのですが、まずどこがおかしいか気づきますでしょうか。そして、原因と解決法は？

 

詳しい状況として、肩掛けのフリルを作成しています。先程Split>Selectionでオブジェクトを分割してフリルを切断し、空いてしまった面を埋めたあと、EditModeでいくらか点を動かして形状の調整をしたところでした。

 こうすると見える対象Objectのフリルの端はObject形状の調整前というだけで、クイズの答えではありません。

正解はフリルのこの面です。

この面だけおかしなことに、SubdivisionSurfeceが効いていません。隣の面と比べれば一目瞭然です。

Blenderでのモデリング中、SubdivisionSurfeceがおかしな結果を示すことは枚挙に暇がありません。

大抵の場合、点の重なりを散々調べることになり、膨大な点を１つずつクリックしてみる作業に１時間を費やした後、面のNormalがおかしいことに気づきFlipで解決、といったコトになります。ですが今回、スクリーンショットをご覧いただければ、最初からFace Orientation のView設定が有効な状態で、一発で見て判るとおり、今回は面のNormalも原因ではないようです。

 

今回、原因を探るには、 別のView設定で見る必要があります。

 

X-Ray設定です。いわゆる透過。

今回のフリルは一見複雑に見えますが、わりと点数が少なく単純な構造です。BlenderとSubdivisionSurfeceの組み合わせのメリットといえます。

閑話休題。

どこがおかしいかわかりましたか？

では原因を発表しましょう。

 

 

今回、スクリーンショットが最初からEditModeのSelectModeがFace selectだったのは重要なヒントだったかもしれません。 

実際にはこの問題を解決した後、記事を書くために、Ctrl+Zだけで問題再現してSelectMode等は切り替えせずスクリーンショットを取ったというだけです。

 

====

これは自慢になってしまうかもしれませんが、私が異常に気づいたのは、フリルの谷の端の分割がおかしくなっているところでした。フリルの谷にも折れ目が発生していますね。

（ちなみにこの前後のスクリーンショットは問題の再現が不完全なので、実際の問題をきちんと再現したスクリーンショットと微妙に形状が違います）
  

====

 Blenderは、そしてモデル奥が深いですね。

残念ながら、今回のそれは実装に必要でなく邪魔するものでしたが。

TIGORA(ティゴラ)のトレッキング シューズ

 TIGORA(ティゴラ)の トレッキング シューズを買いました。

メインの靴がアシックスウォーキングで街歩き用なのですが、これまではこれで高尾山などの軽い山も登っていました。

今回、靴底があまりに摩耗したこともあってアシックスウォーキングを買い替えたのですが、ついでに消耗が激しそうな山歩き用は別の靴を用意して履いてみよう、という感じです。

私が調べたときはamazonで「ティゴラのトレッキングシューズ」とすると背が高いトレッキングシューズしか出てきませんでしたが、ある程度街歩きもできる普通サイズのトレッキングシューズも出ています。

裏側はこんな感じです。

 

靴底の中敷きにも厚みがあり、期待できそうです。

アシックスウォーキング（フィールドウォーカー）を買い替え（新旧比較写真など）

靴を買い替えました。

 

それまでは靴は適当に入った店で最安のスニーカを買っていたのですが、4年ほど前に「足に合う靴」を求めて一念発起し、アシックスウォーキングを買ったのが初めて真剣に靴選びをしました。

そのときはアシックス直営店で足のサイズを測り、中敷きも調整オプションを入れてもらっています。

その後、2年ほどで履き潰したアシックスウォーキングを同じ型番で買い直し、 それもまた2年ほどで履きつぶしたため、同じものを探して買い換えたものです。

現在はフィールドウォーカーという名前になっており、後で見ていくように細部のデザインも違うため、厳密には違う靴なのかもしれません。

（あまり関心がないためこういう認識になってます。）

 最初の選定時に見た目はあまり気にしていなかったのですが、革というかフェルト革風のデザインも靴としては珍しく、今では気に入っております。

 

 というわけで上から撮った写真。

中敷きは真っ赤です。とはいえ靴紐のように外からは見えないので悪目立ちのようなことはしません。

 

購入時ではなくちょっと履いたあとですが、足裏はこんな感じです

 

内側の写真。比較写真はないですが比べてみると、靴のべろが被覆でくっついているように変わっています。

 後ろ側もデザインが違います

後部を横から見ると、紐の衣装があったのが省略されています

側面としてはメッシュ風のラインが入る感じに変更されています。

 

 

並べてみると古い方の履きつぶしっぷりが解ると思います。

次は少なくとも踵にもうちょっと気を遣うようにしたいです。

横から見た感じ。外見の靴底の厚みなどは変わらないように見えます。

WebExtensionsのAPIの非同期対応が呼び出し箇所により異なる(Async,Primise)

 TL;DR

FireFoxでchrome.*()系APIを使うとき、content_scriptだけpromiseなAPIで、ほかはコールバックな模様

概要

そもそも、
- FireFoxはChrome拡張機能互換の一環として、chrome.storage.local.get()といったchrome.*()系APIを実装している
https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/API/storage/StorageArea/get
> この API は Chromium の chrome.storage API に基づいています。
- MDNのドキュメントではchrome.*()系APIはコールバックで非同期を返すものとなっている
(前述のURLにて。2024年現在も)
- Chromeブラウザのchrome.*()系APIは実際にコールバックのAPIで、Primise非対応だった
（おそらく当初、あるいはmanifest V2の頃は）
- 2023年時点のFireFoxでは、chrome.*()系APIはPrimise非対応だった
(当時の挙動からおそらくそう思われる)

- 一方、現在のChromeはchrome.storage.local.get()はPromiseを返すようになっている
(2024年現在。ドキュメントに記載されている通りならば)
https://developer.chrome.com/docs/extensions/reference/api/storage?hl=ja
> chrome.storage.local.get(["key"]).then((result) => {

- 2024年、FireFoxのchrome.*()系APIは、content_script内ではpromiseを返すようになった模様
(とりあえずchrome.storage.local.get()は。全てのAPIが対応しているかは不明。)

説明

気づいたのはdaisy AddCharaIconブラウザ拡張の開発中で、これはページ内のゲーム登場人物名の横に顔アイコンを付与するブラウザ拡張。
毎回アイコン画像をloadするのは負荷が高いため、ローカルでキャッシュするためにWebExtensionsのstorage APIを叩いていて気づいた。

https://github.com/MichinariNukazawa/add_chara_icon_webextensions

```: option_page/option_page.js

const getHashFromTitle = async (title) => {

return new Promise((resolve) => {

// TODO FireFoxではchrome.storage.local.*()で

//promise構文が通用しない様子

// (FireFox127.0.2, 2024/07, Ubuntu 24.04)

chrome.storage.local.get(null, (hash) => {

//console.log('src', hash);

const filterHashFromTitle = (title, hash) => {

let res = {};

for(let key in hash){

if(hash[key].title == title){

res[key] = hash[key];

}

}

return res;

}

const res = filterHashFromTitle(title, hash);

resolve(res);

});

});

};

```


面白いのはoption_pageでもPromise()構文自体は有効であることで、これはcallback版をPromiseでwrapして機能していることからわかる。
つまりFireFoxではchrome.storage.local.get() API側が2種類あるということで、content_scriptとそれ以外で同じAPIのインタフェースが異なる、ということを示しているのだと考えられる。

Linuxコマンドライン上でSVGベクタ画像をJPG等へラスタライズ変換する

 Linuxコマンドライン上でSVGベクタ画像をJPG等へラスタライズ変換することができるが、上手く変換されない場合がある。

 

以前作った魔法陣イラスト素材をイラスト素材ストックサイトへ登録しようと思い立ち、改めて素材用にラスタライズ変換をかけようとした。

 

ラスタライズ変換にはImageMagickの convert が使用でき、DPI的な設定  -density 600  でサイズ調整している。

` convert -density 600 $filename.svg $filename-ss.jpg `

 

元画像はこちら

 変換結果はこのようになってしまう。

30枚の画像をSVGからJPGへ変換した結果、6枚ほど結果が明らかにおかしい。
 

失敗しているものを拡大した抜粋。

真っ白で明らかに変換できていないものもあれば、circle要素などSVG画像から一部が抜け落ちてしまっているものもある。

 

また上のような真っ白な変換失敗や大きなパーツの欠損は明らかに見てわかるのでまだ良いが、小さなパーツの漏れ欠けがあるかもしれないし、そうなると今回のように多数の画像を扱っている中では見落としが起こると思う。

 

コマンドラインでバッチ処理したのだが、いくつかはエラーが通知されている。

```

MN@daisy-bell:MagickCircle/$ bash a.sh

convert-im6.q16: memory allocation failed `' @ error/draw.c/CheckPrimitiveExtent/2274.

convert-im6.q16: non-conforming drawing primitive definition `circle' @ error/draw.c/RenderMVGContent/4405.

convert-im6.q16: memory allocation failed `' @ error/draw.c/CheckPrimitiveExtent/2274.

convert-im6.q16: non-conforming drawing primitive definition `circle' @ error/draw.c/RenderMVGContent/4405.

convert-im6.q16: memory allocation failed `' @ error/draw.c/CheckPrimitiveExtent/2274.

convert-im6.q16: non-conforming drawing primitive definition `circle' @ error/draw.c/RenderMVGContent/4405.

convert-im6.q16: memory allocation failed `' @ error/draw.c/CheckPrimitiveExtent/2274.

convert-im6.q16: non-conforming drawing primitive definition `circle' @ error/draw.c/RenderMVGContent/4405.

convert-im6.q16: memory allocation failed `' @ error/draw.c/CheckPrimitiveExtent/2274.

convert-im6.q16: non-conforming drawing primitive definition `circle' @ error/draw.c/RenderMVGContent/4405.

```

ただ、 ` memory allocation failed` とはいうものの、メモリはかなりとっているのだが。

```  /etc/ImageMagick-6/policy.xml

<policy domain="resource" name="memory" value="8GiB"/>

<policy domain="resource" name="map" value="8GiB"/>

<policy domain="resource" name="width" value="128KP"/>

<policy domain="resource" name="height" value="128KP"/>

<policy domain="resource" name="area" value="2048MP"/>

<policy domain="resource" name="disk" value="16GiB"/>

```

 

小さなサイズで出力してみる。

```

convert -density 600 $filename.svg $filename-ss.jpg

convert -density 90 $filename.svg $filename-3ss.jpg

 ```

 

 

小さなサイズで出力すると、たしかに結果が改善する。

 エラー通知も1個減っていた。

 

とはいえ、ストックサイトへ登録するにあたっては大きいサイズでほしいのだが。

 

GIMPでもSVGをインポートしてラスタライズすることができる。

GUI操作で読み込むと任意のスケールで問題なく読み込めるのだが、CLI呼び出しでバッチ処理に使おうとすると、きちんと変換された結果が出ない。

 画像のような変換結果になる。変換されているごく一部のパーツを見るだけでも、明らかに画質が悪い。

またこの場合は背景を 白背景で書き出せば上手く行きそうに見えるが、試した範囲では、変換結果が真っ白になるだけで上手く行かなかった。

 

以下、うまく行かなかったGIMPでのSVGインポート変換を一応抜粋。

```

# GIMPのコマンドを使ってSVGを読み込む
gimp -i -b - <<EOF
(let* (
       (image (car (gimp-file-load RUN-NONINTERACTIVE "$input_file" "$input_file")))
       (drawable (car (gimp-image-get-active-layer image)))
       (new-width $size)
       (new-height $size)
       )
  (gimp-image-scale image new-width new-height)
  (file-jpeg-save RUN-NONINTERACTIVE image drawable "$output_file" "$output_file" 0.9 0 1 0 "" 0 1 0 1)
  (gimp-image-delete image)
  )
(gimp-quit 0)
EOF

```

またGIMP操作にはもう１つ、Pythonからgimpfuを経由して呼び出す方法もあり、こちらは上野LISPな古いGIMPスクリプトより高度な操作ができるのだが、現状GIMPがPython3に対応していないとかで、今回は断念した。