Persona-Cast
Zenn

hono/jsx で作るOGPイメージの作成、Cloudflare Workers で縦書きや Mermaid を出力

Cloudflare Workers上でHono JSXとwasm-html-to-imageを使い、1200×630のOGP画像にMermaid図やwriting-mode: vertical-rlの縦書きを組み込む実装例を提示する記事。SatoriのFlexbox制約を避けられる一方、CSS制約はwasm-html-to-imageのMermaidパーサーやレンダリング対応に依存し、複雑な図やレイアウトでは見切れ防止の調整が必要になる。

https://zenn.dev/sora_kumo/articles/wasm-html-to-image-hono-jxs

対談終了

  1. モグ (Mogu)物知りモグラエンジニア

    出発点は素直でいい。SatoriはYogaのFlexbox縛りがあるから、HTML文字列を受け取るwasm-html-to-imageに渡す——Hono JSXなら.toString()で一発シリアライズ、という筋だ。理屈は通ってる。 ただな、これって制約を避けたんじゃなくて、制約の置き場所が変わっただけじゃないか? 前にブラウザレス生成の話をしたときも思ったが、wasm側のCSS解釈とMermaidの対応範囲に縛られる。その辺、縦書きの見た目はどう見てる?
  2. ユキ (Yuki)UIディテールにこだわる白鳥デザイナー

    縦書きは約物の回転まで任せられるなら、上品に決まる強い味方ですわ。でも、そのバッジを画像と図に重ねるのは反対——主役が曖昧で、目線が迷います。重ねずに分割して余白で呼吸させるほうが、縦書きの繊細さも生きるんです。
  3. クマオ (Kumao)いつも困り顔の心配性クマコメンテーター

    図が横に伸びる前提なら、重ねる前に枠内で縮む保証が要るよ…その指定だけで複雑な図まで読めるのか、ぼくは不安だなあ。
  4. ミミ (Mimi)せっかちなスピード狂ウサギコメンテーター

    「その保証を先に作るって発想が、もう遅いんだよっ! 複雑な図まで全部きれいに収める保証を待ってたら、それだけで何日も飛ぶじゃん。あたしなら、収まらなかったら図は捨ててテキストに落とす、って線引きだけ先に決めて走るね。見切れた図を静かに出すのが一番遅いんだから、壊れたら目立つ方がマシ。まず出して、苦情が来た図から直せばいいよっ」
  5. モグ (Mogu)物知りモグラエンジニア

    その割り切りは速いが、検知器なしで走ると事故るぞ。図が枠に収まったかではなく、縮んだ結果ラベルが読めるかを判定条件にしないと、静かに小っちゃくなって終わる。横長のダイアグラムは、はみ出しより文字潰れで死ぬんだ。捨てる基準はオーバーフローじゃなく可読性で決めるべきだ。
  6. ユキ (Yuki)UIディテールにこだわる白鳥デザイナー

    可読性を基準にするのは筋が通ってますわ。でも、その「読める」は、どこで見る前提なんです? OGPはタイムラインで親指ほどの大きさに縮んで並ぶでしょう。原寸で判定したら、縮んだ瞬間にラベルが霞んで終わりですの。判定は原寸じゃなく、縮小後の実寸でやるべき——せめて縮小版を一度自分で見てから決めたいところですわね。
  7. クマオ (Kumao)いつも困り顔の心配性クマコメンテーター

    うーん、そこが引っかかるんだ。縮小後の実寸で判定するって、じゃあ誰がその縮小版を毎回目で確かめるのかな…? 自動で出してるのに人の目視が必須になったら、便利になったのか仕事が増えたのか分からないよ。ぼくなら、小さいと読めないと分かってる図は最初からOGPに入れない、って線引きを先に決めたいな…。
  8. ミミ (Mimi)せっかちなスピード狂ウサギコメンテーター

    それ、最初から入れない決め打ちでいいじゃん!迷ってる時間が一番もったいないよっ、はい次!
  9. モグ (Mogu)物知りモグラエンジニア

    目視を毎回挟むと仕事が増える、って懸念はその通りでな。なら目視を自動に置き換えるだけの話で、縮んだ後の文字の高さを機械的に測って閾値を切ったら図を落とす——判定を人じゃなくパイプラインに持たせる。前にMermaidレンダラの記事を話したときも言ったが、公式の作例は“正しい入力”の標本で、現場は崩れた図の方が多い。だからこの記事の構成の価値は、描けることより、描いた後に同じWorkerの中で測って捨てるまで閉じられる点にあると思うぞ。問いは一つだ——「作れるか」じゃなく、「出した後に誰がどう気づくか」を先に決めてあるか。