枠に収まるテキスト
Publisherには、自分から意識してオンにする人がほとんどいない設定があります。「オーバーフロー時に文字を縮小する」という設定で、テンプレートが最初からオンにしています。見出しやキャプションが枠より長くなると、Publisherは文字サイズを一段ずつ下げ、言葉が収まるまで続けます。
その動きが目に見えることはありません。見えるのは、ただ収まっているテキストだけです。
これまで私たちのコンバーターはこれをしていませんでした。ファイルに保存されたサイズのまま組むので、枠に対して文字が多すぎると縁からはみ出すか、下で切れました。見出しがぎりぎりのチラシでは、それが「仕上がったページ」と「明らかに壊れたページ」の差になります。
Publisherと同じ収め方になりました
このリリースから、オーバーフロー時の文字縮小が既定でオンです。
公開前に、私たちの出力とPublisher自身の出力を比べました。もともと正しかった枠は正しいままです。私たちがいちばん気にしているのはそこです。動いていたページを壊す修正は、修正ではないからです。
うまくいかなかったほう
Publisherのこの設定は両方向に働きます。小さな枠に収まるように縮むこともあれば、大きな枠を埋めるように広がることもあります。広がる側も作りましたが、こちらは今もオフのままです。
私たち自身の見積もりでは効果があるはずでした。実際にページを描画してPublisherと比べたところ、効果はありませんでした。そこで見積もりを撤回し、その部分はオフのままにしました。公開したのは縮む側だけです。両方出してから気づいてもらうより、こうしてお伝えするほうがいいと考えています。
途中で犯した関連する間違いも、はっきり書いておきます。私たちはしばらく「広がる動作が足りない」と思って探していましたが、出力の本当の欠陥は逆で、Publisherが組むよりも文字が小さくなっていました。方向を間違えたまま走ったせいで、ほぼ1週間を失いました。
行分割、その後
行がそこで折り返す理由で仕組みを説明しました。その作業は止まっていないので、そこからの動きを短くまとめます。
ハイフネーション規則の波がさらに2回入りました。どちらも標準的なアルゴリズムからではなく、Publisher自身がどこにハイフンを置くかを観察して導いたものです。
ウェブアドレスには専用の規則ができました。これには驚きました。Publisherはメールアドレスのローカル部分、つまりアットマークより前の部分は分割するのに、本物のURLの構成要素は分割することを拒みます。正反対の挙動なので、信じるには実際の文書で両方を検証する必要がありました。
フランス語のテキストにも専用の調整を入れました。あちらの字間と分割の規則は英語のものとは違うためです。
見出しが枠からはみ出していたり、段落の折り返しがおかしかったりしたファイルは、もう一度変換してみてください。プレビューは無料なので、支払う前にご自分のファイルで結果を確認できます。変換は一度きりの49米ドルで無制限です。