真のWYSIWYG編集とは？

WYSIWYG（What You See Is What You Get：見たままを得る）という用語は広く使われていますが、その多くは緩い意味で使われており、しばしば誤解されています。

この記事では、アーキテクチャの観点から真のWYSIWYG編集が実際に何を意味するのか、なぜ多くのエディタがそれを実現できないのか、そして開発者が自社製品にドキュメントエディタを組み込む際に何を求めるべきかを解説していきます。

WYSIWYGは、誰もが使うものの、実際にその意味を尊重している人はほとんどいない用語の1つです。今日、ほぼすべてのリッチテキストツール、ブラウザベースのエディタ、コンテンツフィールドがWYSIWYGエディタとして販売されていますが、ドキュメントがエクスポートされた瞬間にレイアウトがずれると、その約束は崩壊します。この期待と現実のギャップは偶然ではありません。アーキテクチャ上の問題なのです。

現代のソフトウェアでは、WYSIWYGはUI機能として扱われることが多いですが、実際には、真のWYSIWYGはドキュメントエンジンとレンダリングの問題です。それは、ドキュメントが内部でどのようにモデル化されるか、レイアウトがどのように計算されるか、そして編集、プレビュー、エクスポート全体で同じロジックが一貫して適用されるかに依存します。

この区別は、ドキュメントエディタがアプリケーションに組み込まれる際に極めて重要になります。開発者、システムアーキテクト、CTOにとって、真のWYSIWYGは表面的な詳細ではありません。予測可能な出力、安定したテンプレート、ユーザーの信頼のための前提条件なのです。

WYSIWYGとは？定義と主な利点

真のWYSIWYGが稀である理由を理解するには、元々のWYSIWYGの意味に立ち戻ることが役立ちます。What You See Is What You Getは、編集を便利に感じさせることを目的としたものではありませんでした。その本来の約束は厳格でした。編集中に表示されるドキュメントは、印刷またはエクスポートされた際に生成されるドキュメントと同一でなければならないということです。

時間の経過とともに、この定義は薄められてきました。現在WYSIWYGテキストエディタとラベル付けされている多くのツールは、編集中の大まかなフォーマットのみを保証しています。これらは、エクスポート中の後処理に依存してレイアウトを「修正」し、多くの場合、まったく異なるレンダリングエンジンを使用します。技術的な観点から見ると、これはすでに契約を破っています。

真のWYSIWYGは、視覚的な類似性ではなく、レイアウトの忠実性に関するものです。これは、改行、改ページ、余白、オブジェクトの配置が、ユーザーがドキュメントを編集している間に確定していることを意味します。編集中に段落が2ページ目に表示される場合、エクスポート後も2ページ目にある必要があります。

これは、DOCX、XLSX、PPTXなどのオフィス形式で特に重要です。これらの形式はHTMLドキュメントではなく、ページネーション、フォントメトリクス、スペーシング、オブジェクトアンカリングに関する厳格なルールを持つレイアウト駆動の仕様です。これらをWebコンテンツとして第一に、ドキュメントとして第二に扱うエディタは、必然的にWYSIWYGの精度を損ないます。

Webエディタにおけるwysiwygの課題とデメリット

真のWYSIWYGがこれほど価値があるなら、なぜほとんどのWebエディタはそれを提供できないのでしょうか？答えは、レイアウトの決定論よりも利便性と速度を優先する一連の一般的な技術的妥協にあります。

最も広く見られる妥協は、HTMLおよびDOMベースのレンダリングです。ブラウザはレスポンシブなWebページのレンダリングには優れていますが、印刷に正確なドキュメントレイアウトには根本的に適していません。HTMLには、固定ページネーション、ページヘッダーとフッター、脚注、またはテキストに固定された浮動オブジェクトのネイティブな概念がありません。その結果、ドキュメントレイアウトは編集中に近似され、エクスポート時に後で再計算されます。

実際には、これは予測可能な一連のアーキテクチャ上の近道につながります：

• ドキュメントレイアウトのHTML/DOMベースの近似。オフィスドキュメントがページネーションされたドキュメントではなくWebコンテンツとしてレンダリングされます。
• 編集とエクスポートで異なるレンダリングエンジン。ブラウザが画面上の編集を処理し、別のエンジンがDOCXまたはPDF生成中にレイアウトを再計算します。
• エクスポート時のみ計算されるページネーション。ユーザーがドキュメントを編集している間、改ページは存在しません。
• プラットフォーム間でのフォントメトリクスの不整合。フォントレンダリングのわずかな違いが蓄積し、ページ間でレイアウトがずれます。
• ブラウザ依存のレンダリング動作。レイアウトがブラウザやブラウザバージョンによって異なります。

もう1つの一般的な問題は、ページネーション自体です。多くのエディタは、編集中に改ページをまったく計算しません。ページは、エクスポート時まで概念的にのみ存在するため、ヘッダー、フッター、法的条項などのページ依存コンテンツが信頼できません。

フォント処理は、さらに複雑さを加えます。フォントメトリクスは、オペレーティングシステム、ブラウザ、レンダリングエンジン間で異なります。最小限の違いでも、行とページ全体で蓄積し、コンテンツを前後に押します。フォントとメトリクス計算の一貫した制御がなければ、レイアウトの忠実性は保証できません。

最後に、ブラウザ依存のレンダリング動作は決定論を損ないます。異なるブラウザはテキストを異なる方法でレンダリングし、マイナーなブラウザの更新でさえレイアウト動作を変更する可能性があります。ドキュメントの外観がクライアント環境に依存する場合、WYSIWYGは保証されたものではなく条件付きになります。

真のWYSIWYG編集の技術的基準

真のWYSIWYGは主観的ではありません。実際のドキュメントエディタと視覚的な近似を区別する明確で譲れない技術的基準があります。

まず、編集とエクスポートの両方に使用される単一のドキュメントモデルが必要です。このモデルは、簡略化または中間バージョンではなく、ドキュメント形式の実際の構造を表す必要があります。コンテンツが編集用にHTMLに変換され、後で再構築される場合、情報が失われ、レイアウトのずれは避けられません。

次に、すべてのモードで同じレンダリングロジックを適用する必要があります。編集ビュー、プレビューモード、エクスポートされた出力は、同じレイアウトエンジンに依存する必要があります。レンダリング動作の乖離は、不整合を引き起こします。

第三に、エディタはすべてのレイアウトクリティカルな要素を正確に処理する必要があります：

• フォントとフォントメトリクス
• ページネーションと改ページ
• 余白、スペーシング、配置
• 表、画像、図形、浮動オブジェクト
• ヘッダー、フッター、脚注、ページ番号

これらは高度な機能ではありません。ドキュメントの忠実性の基盤となるものです。

最後に、真のWYSIWYGにはプラットフォーム非依存のレンダリングが必要です。ドキュメントは、ブラウザやオペレーティングシステムに関係なく同一に見える必要があります。クライアント環境に基づいてレイアウトが変わる場合、そのエディタはWYSIWYGの定義を満たしていません。

組み込みエディタアーキテクチャにおけるWYSIWYGの役割

WYSIWYGの重要性は、組み込みユースケースでさらに明確になります。開発者がWYSIWYGエディタとは何か、その機能が実際に何のために必要なのかと尋ねる時、その答えは予測可能性と信頼にあります。

ドキュメントエディタがSaaSプラットフォームに組み込まれる場合（APIまたはReact WYSIWYGエディタ統合を通じて）、ドキュメント出力の責任はプラットフォームオーナーに移ります。ユーザーは、ドキュメントが設計どおりに正確に見えることを期待しており、不整合は製品に直接反映されます。

自動化されたドキュメント生成とテンプレートベースのワークフローは、この問題を増幅します。テンプレートは固定レイアウトの前提に依存しています。予期しない改ページが1つあるだけで、ブランディングが崩れ、署名がずれ、法的フォーマットが無効になる可能性があります。真のWYSIWYGがなければ、テンプレートは脆弱で保守に費用がかかります。

法務、金融、ビジネスのコンテキストでは、レイアウトの精度はオプションではありません。契約書、請求書、レポートは、フォーマットを正確に保持する必要があります。エクスポートされたドキュメントが編集中にユーザーが見たものと異なる場合、システムへの信頼は即座に損なわれます。

運用の観点から見ると、WYSIWYGの欠如はサポート負荷を増加させます。レイアウト関連の問題は、チケット、手動修正、ユーザーのフラストレーションを生み出します。APIコンシューマにとって、予測可能なエクスポートの忠実性は想定されるものであり、交渉されるものではありません。この期待が裏切られると、組み込みエディタは資産ではなく負債になります。

ONLYOFFICE Docs DeveloperにおけるWYSIWYG編集アプローチ

ONLYOFFICE Docs Developerは、WYSIWYGがUI拡張ではなく、アーキテクチャ上の選択であるという前提の下に構築されています。

その中核にあるのは、DOCX、XLSX、PPTX構造を直接表現する統一されたドキュメントモデルです。HTMLプロキシはなく、編集とエクスポートの間に損失の多い変換レイヤーもありません。ユーザーが編集するのは、ドキュメントそのものです。

同じレイアウトとレンダリングエンジンが、編集、プレビュー、エクスポート全体で一貫して使用されます。これにより、ページネーション、スペーシング、オブジェクトの配置が一度計算され、ドキュメントのライフサイクル全体で安定したままになります。

エディタは、レンダリングにJavaScriptとHTML5 Canvasを使用し、サーバー側にNode.jsを使用することで、すべてのブラウザで100%の表示、印刷、ページネーションの忠実性を保証します。

ONLYOFFICEは、Office Open XML形式でネイティブに動作し、仕様によって定義されたレイアウトルールを正確に制御できます。このネイティブアプローチにより、形式変換から生じる不整合が排除されます。

組み込みシナリオでは、このアーキテクチャは、ブラウザやオペレーティングシステムに関係なく一貫したレンダリングを提供します。SaaSプラットフォーム、ドキュメントワークフローシステム、カスタムアプリケーションのいずれに統合されても、レイアウトの動作は予測可能なままです。

API中心ソリューションとして設計されたONLYOFFICE Docs Developerは、エクスポートの忠実性を維持しながらスケーラブルなデプロイメントをサポートし、ドキュメントの精度が重要な高負荷環境に適しています。

まとめ

真のWYSIWYGには、単一のドキュメントモデル、単一のレンダリングエンジン、レイアウトに対する決定論的なアプローチが必要です。それ以外は、インターフェースがどれほど洗練されていても、近似にすぎません。

ドキュメントエディタを組み込む開発者にとって、この区別は重要です。真のWYSIWYGがなければ、エクスポートは信頼できず、テンプレートは壊れ、ユーザーの信頼は損なわれます。それがあれば、ドキュメントワークフローは予測可能で、スケーラブルで、信頼できるものになります。

製品にとってドキュメントが重要であるなら、真のWYSIWYGはオプションではありません。

ONLYOFFICE Docs Developerを入手して、真のWYSIWYGドキュメント編集を実現

単一のドキュメントモデルと統一されたレンダリングエンジンで、編集からエクスポートまでレイアウトに正確なレンダリングを保証します。

ダウンロード