Scribus――プロの使用に耐えうるレベルのLinux用ページレイアウトソフト

 Linuxへの移植を希望するソフトウェアについて語るとき、まず取り上げられるのがAdobe InDesignやQuarkXpressなどのデスクトップパブリッシング(DTP: desktop publishing)用アプリケーションであるが、実のところLinuxユーザをターゲットにしたDTPアプリケーションというものは既に存在しているのである。それがScribusというオープンソース形態のページレイアウトプログラムであり、プラットフォームとしては、Linux、Windows、Mac OS Xをサポートしている。問題はその完成度だが、果たしてこのプログラムは実務の現場においてプロプライエタリ系DTP製品の代替ソフトとして使用できるレベルに達しているのであろうか?

 私の主たる仕事は、グラフィックスおよびテキストデータを編集してドキュメント上にレイアウトすることであり、こうした作業を90年代中盤から既に10年近く続けている。この種のページレイアウト用プログラムとして私が最初に出会ったのはQuarkXpressであったが、程なくしてAldus(後のAdobe)PageMakerに切り替え、その後も各種のバージョンを使用してきた。PageMakerの後継者であるAdobe InDesignを使い始めたのは数年前のことである。

 こうした経験から言えるのは、各種のテキスト、表、グラフィックス(ベクトル系およびラスタ系の両フォーマット)をスムースにインポートしてフォーマット指定するワークフローへの対応が、優れたページレイアウト用プログラムにとっての不可欠な要件であるということだ。

インストール

 Scribusのインストールについては、最新バージョンの入手法が分かりづらいため、多少の注意が必要だ。それと言うのもScribusのWebページでは最新の安定バージョンは1.3.3.9であると紹介されているのに、それよりも新しいバージョン1.3.4に関するニュースリリースが昨年5月の段階で既に出されているのである。同リリースにはバージョン1.3.4のダウンロードページへのリンクが張られており、私の場合もそこから入手したソースファイルをコンパイルすることでインストール用パッケージを作成している。またこのページからは、その他アーキテクチャ用のRPMファイルを入手することもできる。

 かく言う私であるがLinux.comに掲載されたバージョン1.3.4のリリース記事を目にしなければ、おそらくその存在に気づきはしなかったであろう。実のところバージョン1.3.4は開発リリースという位置付けにされているのだが、安定版と開発版リリースの相違点など、オープンソースの開発サイクルに詳しくない人間にとっては些細な違いでしかない。

外部ファイルのインポート

scribus_thumb.png
Scribus 1.3.4

 一般のワードプロセッサとは異なり、ページレイアウト用プログラムでは、そのドキュメント上に配置するコンテンツは他のプログラムにて作成しておくことを前提にしている。よって1つのドキュメントを構成する場合、そこに配置するテキストはワードプロセッサなどの文章作成プログラム、グラフィックスはIllustratorやInkscapeなどの図形描画プログラム、写真データはPhotoshopやGIMPなどのラスタ系イメージ編集プログラムにて別途用意しなければならない。そのためこうした各種のファイルフォーマットのインポートおよびページ上での細かな配置設定への対応は、優れたページレイアウト用プログラムに求められる重要な要件となる。

 Scribusの場合も一般的なファイルフォーマットについては正常にインポートできるのだが、私が最初に使い始めた当時、意外なことにMicrosoft Wordファイルを読み込めなかったため大いに落胆させられたことがあった。実務の現場においてはMS Wordが広範に使用されている以上、テキストデータをWordフォーマットで提出する人間が多数存在するからである。ところがヘルプファイルを読んでみると、ScribusのインポートプロセスではAntiwordというユーティリティを介してWordバイナリファイルをテキストに変換してから読み込むという仕様になっていたのだ。実際Scribusはその起動時にAntiwordの有無をチェックするようになっており、私の環境でもこのユーティリティをインストールしたところ、Scribusで問題なくWordファイルをインポートできるようになってくれた。

 グラフィックスについてはScribusの場合、EPS、TIFF、JPG、SVG、PNGなどのラスタ系およびベクトル系イメージフォーマットを正常に読み込めるだけでなく、(驚くべきことに)ネイティブのPhotoshop PSDファイルをそのまま扱うことができる。

 ただし表組み関連のデータについては、それほど対応度は高くない。例えば空白の表を挿入すると、Scribusはこうしたテキストボックスを勝手に表セルとしてグループ化してしまうのである。よって表の配置後にテキストを挿入するといった場合は、このようなグループ化をいちいち解除しなければならない。いずれにせよ、表のインポートはうまく行かない場合があるものと覚悟しておく必要があるだろう。この問題に対するソリューションの1つは、他のプログラム(OpenOffice.org Writerなど)で表を作成する場合に、完成したデータをPDFファイルで保存しておき、Scribusにはグラフィックスとしてインポートするという方法が考えられる。

ドキュメントのセットアップとフォーマット指定

 Scribusでも他のページレイアウト用プログラムと同様、テキストおよびグラフィックスの格納コンテナとして機能するフレームを必要な数だけページ上に配置する方式が採用されている。こうしたパブリケーションの大部分を占めるのがテキストである関係上、最大の作業時間を取られるのがテキスト関連のレイアウトおよびフォーマット設定である。実際、複数のテキストフレームを配置してテキスト移動用のフレーム間リンクを設定するのは非常に手間のかかる作業だが、Scribusにはこの作業プロセスを自動化する機能が設けられている。具体的にはドキュメントの設定時に、各ページ上におけるテキストフレームの自動描画オプションを有効化しておけばよく、このオプション適用下では作成されるテキストフレーム間リンクも自動的に設定される。

 なおこのテキストフレームの自動作成機能が最も役立つのは、複数ページにまたがる分量の単一テキストを配置する場合である。例えば以前に私は、1ページ分に満たない短い文章が大半を占める40個以上のテキストファイルを配置するという作業にて、テキストフレームの自動作成機能を試してみたことがある。この場合、テキストフレーム間のリンク群を個別に解除しないとファイル別のテキスト配置ができなかったため、結果的にScribusによるテキストフレームの自動配置で節約できた以上の時間を費やすことになってしまった。

 テキストのインポート後に行うのは、段落および文字単位のフォーマット設定である。Scribusではスタイルマネージャを介してスタイルの設定と適用をする方式になっているが、私の使った限りそのインタフェースは操作性に難があるよう感じられた。各種属性のうち、ジャスティフィケーション、スペーシング、インデントを規定する段落スタイルが、フォントのサイズとカラーを規定する文字スタイルを包含しているということが直感的に分かりづらいのである。より重大な問題として、特定スタイルに対する設定変更が、その適用済みテキストに正しく反映されない場合がある点も指摘しておかなければならないだろう。

 マスタページは一種のページテンプレートであり、ヘッダ、フッタ、ページ番号などページ間で共通する要素を配置しておくために使用する。これらの要素は通常のページ上で変更することはできない。Scribusでもこうしたマスタページ機能に対応しており、複数のマスタページを使い分けられるようになっている。

 残念ながらイメージおよびグラフィックスに対しては、フォーマット指定を一括で自動適用する方法は存在しないようである。例えば私の場合、配置する各イメージに対してワードラップ処理をさせることが多いため、これを新規に挿入するイメージ用のデフォルト設定としておきたいのだが、Scribusにおけるその種のデフォルト指定機能が見つけられないままでいる。またScribusでは、テキストおよびグラフィックスボックスといったオブジェクトの表示設定についても、カラー指定などのごく限られた機能しかサポートされていない。こうしたオブジェクト関連の表示機能としては、テキストおよびグラフィックスボックスのドロップシャドウ効果などが用意されていてもよさそうなものなのだが。

まとめ

 Scribusについては、本文中で解説したようにいくつかの欠点が残されているものの、そうした制限を承知した上で使うのであれば、実用に耐えるページレイアウト用プログラムとして推奨してもいいだろう。もっとも、テキストフレームを一括してコピー&ペーストする場合などに原因不明のクラッシュに遭遇したケースが何度かあり、こうしたトラブル発生の頻度がもっと低ければ総合評価をもう1ランク高くしておきたいところである。

 Scribusを商用ページレイアウト製品と比較した場合、複数の点において見劣りする事実は否めない。例えばそのインタフェース構成はPageMakerやInDesignほど洗練されておらず、直観的な操作を大きく妨げている。特に強く感じたのは、マスタページの設計、段落スタイルの作成、インポートテキストのフォーマット指定に関する機能の不備で、これらの完成度は同種プログラムより数ランク劣っていると言えるだろう。このような不満については、Adobe製品使用歴の長い者が評価しているが故の偏見と受け止められるかもしれないが、Scribusのwikiに掲載されている開発ロードマップでも、いくつかの機能には改善の余地があり、PageMakerなどの古参プログラムに比べて未成熟であるとの記述がなされている。

 その他にも、1つのパブリケーションを構成する複数のScribusファイルを単一のブックとして管理するユーティリティの不在は、重要な問題であると見なせるだろう。こうしたブック管理ユーティリティが特に役立つのは、ドキュメントを構成する各章を個別のファイルとして整理する場合であり、その際に求められるのがブックに登録するファイルの管理機能および、全ファイルで共通化させる、マスタページ、スタイル、ページレイアウトなどの自動適用機能である。

 色々と未成熟な部分が残されたScribusであるが、コストパフォーマンス的に抜きんでた存在であることに間違いはなく、特にLinuxユーザが利用可能な最高のページレイアウト用プログラムという点は高く評価すべきだろう。またScribusユーザは、Scribusの機能やインタフェース的な不足分を補うためのPythonスクリプトを独自に多数開発しており、これらはScribusのwikiページにて公開されている。いずれにせよScribusの開発チームは、実用的なDTPプログラムの構築に成功したと総括していいはずだ。このままScribusの開発作業が継続していけば、商用製品に匹敵するレベルの完成度に達することに間違いないだろう。

Drew Amesは、ペンシルバニア州ハリスバーグにてトランスポーテーションプランナとして活動している。

Linux.com 原文