こんにちは、pixivFACTORY のサーバサイド開発を担当しています haya です。

今回は、3 月下旬にリリースされました pixivFACTORY の「テキスト入力機能」と、それを実現するために使用している技術と課題解決の事例をいくつか紹介します。

pixivFACTORY とは？

本題の前に、まずは pixivFACTORY について解説させていただきます。

pixivFACTORY（ピクシブファクトリー）とは、pixiv と連携した、ものづくりがもっと楽しくなるグッズ制作サービスです。入稿に関する知識がなくても、画像をアップロードするだけで、簡単に高品質なグッズをつくることができます。

というのが pixivFACTORY（https://factory.pixiv.net/）の description なのですが、この度ついに、「画像をアップロードしなくても簡単に高品質なグッズをつくることができる」ようになってしまいました。
テキスト入力機能を使えば、名言・格言、推しの名前などの文字をあしらったグッズが、サイト上だけでデザインできます。
もちろんスマホ・タブレット対応です。

すでにたくさんのユーザーにご利用いただいており、おもしろネタから本気のロゴマークまで、10,000 点以上のグッズデザインにテキスト入力機能が利用されています。

2019 年 5 月時点で、FONTWORKS と Monotype 提供の人気書体から 100 スタイル以上のフォントがご利用いただけます。

ものづくりがもっと楽しくなりましたね！

ご利用方法

使い方は簡単です。
デザインしたいアイテムを選択し、使用したい画像をアップロードします。
もちろん画像をアップロードせずに文字だけでデザインを作成することもできます。

文字や画像を自由に配置・サイズ調整。
文字ついては 100 スタイル以上のフォントが選択可能なほか、角度や色、行間・揃えといった細かい設定も可能です。

プレビューで仕上りを確認。
納得のデザインに仕上がりましたらぜひシェアしてくださいね。

（出典: フリー百科事典『Wikipedia（ウィキペディア）』）

気に入ったらすぐに購入できます。最高だ！自分は天才だ！と思ったら BOOTH に出品して世界中に販売しましょう。

どうやっているの？

さて、サービスの紹介もほどほどにして本題に移りましょう。

紹介しましたデザインエディタとプレビュー機能は、まさに pixivFACTORY のアイデンティティとも言える重要な機能です。
サービス開始当初から継続して改良が行われているのですが、今回、テキスト入力機能を実装するにあたっては、かつてないほど大幅な改修が行われました。

また pixivFACTORY の改修に加えて、一部機能の実現のために、２つのマイクロサービスを新規に開発しました。
具体的には、デザインエディタで使用するウェブフォントの配信、デザインデータを画像に変換する部分は、それぞれ pixivFACTORY とは切り分けられた新規マイクロサービスによって実現されています。

主な技術課題

大規模な改修であった都合、必然的に要件は多く、悩みどころは多かったのですが、以下の4 項目については、特に大きな課題でした。

テキスト入りデザインデータの記録方法
デザインエディタ UX / UI
デザインエディタ上でのテキストの表示方法
デザインデータの画像変換

このうち、デザインエディタの各種機能の実現に関しては、先に公開されている fsubal の記事（SVG + React でつくるレイヤーの自由変形, pixiv tech salon, 2019, 3, 5, https://speakerdeck.com/fsubal/layer-transformation-with-react-plus-svg）が詳しいですから、ここでは残りの３項目について解説するとします。

テキスト入りデザインデータの記録方法

pixivFACTORY は、1 枚の画像を使ってデザインを作成することを前提に設計されていたため、画像以外のデザインを、しかも複数組み合わせたデザインを扱うようにするには、デザインデータの記録方法を抜本的に見直す必要がありました。

まず、一つのデザインが一つの画像ID・位置・サイズを持つような構造をやめて、一つのデザインが、複数のデザイン子要素を持つようなデータ構造にする必要があります。
デザイン子要素は、位置やサイズの他に、画像IDまたはテキスト子要素と、重ね順を持つことになります。

こういった構造を表現するのに独自に構造、パラメータ定義を行うこともできますが、今回のケースでは SVG のスキーマに対応するような構造とパラメータを定義することにしました。
定義済みのスキーマを踏襲したテーブルを作成することで、定義を新たに考える手間が大幅に減りました。

他にもメリットがあり、データから SVG ファイルを容易に構築でき、SVG ファイルは当然そのままブラウザ上で表示することが可能です。
さらに、レンダリングサイズと無関係に ViewBox が設定できる特徴を利用すれば、内部座標をデザインデータの記録に使用する単位で表現しつつ、レンダリングサイズ（ピクセル単位）は自由に設定できます。

上記デザインデータ記録方法の変更後、デザインエディタ画面のリニューアルも行われ、これ以降はデータベース上とデザインエディタどちらにおいても、位置・サイズの単位は原稿実寸単位で扱われています。

デザインエディタ上でのテキストの表示方法

ユーザーの端末上に任意のフォントでテキストを表示する方法はいくつか考えられましたが、単純にウェブフォントを配信して、それを使って端末上で描画してもらう方法を採用しました。

サーバ上でレンダリングした文字の画像データまたはアウトライン化した文字の SVG データを配信するなども考えられましたが、SVG のスキーマを踏襲したデザインデータ構造を前提とするなら、テキスト内容と font-family 属性で表現した方が都合がよいからです。

通常、ウェブフォントはあらかじめそのページで使われている文字列のみを含むようにサブセット化されたものが配信されます。
和文フォントの場合、その膨大な数の漢字によって、サブセット化していないウェブフォントのファイルサイズは数MB～数十MBになるためです。

しかし pixivFACTORY では、ユーザー入力の任意文字種に対応する必要があるため、あらかじめサブセットを作成しておくことができません。
そこで、必要な文字に対してのサブセット化処理をその都度行って、動的に生成したウェブフォントを配信しています。
ただし、英数ひらがなカタカナなどの頻出文字だけは、事前にサブセット化して静的配信しています。

このために、ウェブフォントを配信するためだけのマイクロサービスを新規に開発しました。

ちなみに、Google Fonts （https://fonts.google.com/）のように、事前に細かくサブセット化したウェブフォントと、それを unicode-range 毎に割り当てる CSS を配信して、実際に使用された文字によって、細切れのウェブフォントが選択的にダウンロードされるようにする方法もあるのですが、今回は単純さを優先しました。

フォントの適用ロジックも少し工夫してあります。
pixivFACTORY では一つのテキストに対して3つのウェブフォントを指定した font-family 属性を適用しています。
font-family には複数のフォントが指定可能で、1番目のフォントに存在しない文字は2番目、2番目のフォントにも存在しない文字は3番目のフォントが適用されます。

1 番目はユーザー入力の文字に対応するためのフォント
2 番目はユーザー入力にかかわらず、書体のみによって決まる、頻出文字用のフォント
3 番目は特殊なフォントで、指定した書体に含まれない文字が入力された場合に、非対応であることを明示するためのフォント（Adobe NotDef）です。このフォントが反映された文字はすべて☒（『豆腐』）で表示されます。

これがないと、選択したフォントに存在しない文字はユーザーの端末にインストールされているフォントで表示されますが、同じフォントが pixivFACTORY のサーバ上も使用できるとは限りません。結果、画面表示とプレビュー・原稿が異るという問題が起こります。

一例として、フォントに秀英初号明朝が選択されている場合は
1 ~ 3 番目に、秀英初号明朝（動的追加サブセット）、秀英初号明朝（静的サブセット）、Adobe NotDef（静的フォールバック）が指定されたフォントが適用されます。

順を追って説明します。

ユーザーが入力した直後、フォントを反映する前の状態では、すべての文字がユーザーの端末に存在するフォントで表示されます。

秀英初号明朝（静的サブセット）と Adobe NotDef（静的フォールバック）は静的配信されているので、すぐに表示に反映されます。
秀英初号明朝（静的サブセット）に含まれる頻出文字だけが、秀英初号明朝で表示され、それ以外は Adobe NotDef によって『豆腐』で表示されます。

秀英初号明朝（動的追加サブセット）が取得されると、漢字などの文字にもフォントが反映されるようになりますが、絵文字などの非対応文字に関しては、引き続き『豆腐』で表示します。

頻出文字用フォントを静的配信することにより、頻出文字のみですが、反映を早めることができます。頻出文字だけのテキストというのも結構ありがちなので、すばやいフォント反映の恩恵を受けるケースは多いことでしょう。

デザインデータの画像変換

前述のとおり、デザインデータは SVG ライクなテーブル群に記録されるようになっています。
デザインデータから SVG を構築して画像に変換、その後様々な装飾効果を施したプレビュー画像がユーザーに提供されます。

SVG から画像への変換は過去にも多くの事例が存在し、難しくはなかったのですが、一つ追加で考慮すべき問題がありました。
有料フォントの利用料に関することです。

有料フォントの場合、利用するサーバ台数などに応じて必要ライセンス数、つまりフォント利用料が変わります。
pixivFACTORY は、負荷分散と冗長化のため、複数台のサーバで運用されていますが、負荷の上昇は必ずしもフォントの利用状況によりません。pixivFACTORY の負荷上昇に合わせてフォントを買い増しするのは無駄な費用増加となります。

この問題を回避するため、サーバを別途用意し、pixivFACTORY とは独立した画像変換マイクロサービスを用意しました。フォントはそのサーバのみに配置されます。

このような構成を採ることによって、フォントの利用状況だけにしたがって、負荷分散・冗長化すればよく、適切なライセンス数で無駄なく運用できます。
ちなみに、物理的に画像変換マイクロサービスと同じサーバに、フォント配信マイクロサービスも同居させることで、さらに費用を節約しています。

やってみた感想

かなり大規模な改修、新規実装を伴った「テキスト入力機能」ですが、実は何かノウハウがあったわけでもなく、当初は本当に何もわかっていない状態でした。
さすがに不安がなかったとは言えないのですが……。
頼もしいチームメンバーに恵まれていたため、根拠のある「なんとかなるだろう」という気持ちでスタートし、結局なんとかなりました。

一日中ひたすら情報検索しては情報共有、有望そうな技術を試してみるといのを繰り返した末、ようやく仕様が決まり始めてくる。
道筋が見えてくるときは、わくわくするものですね。本当に。

そして実際に動いてみると、思った以上にすごい。びっくりです。