Zoho Showで日本語Webfontが使えるようになっていた

もう10年以上の間仕事関係でプレゼンをする際は,いわばWeb版パワーポイントのZoho Showを利用してきた。単独でリモートプレゼンテーション機能を持っているのが離れたところにいる生徒を教えるのに好都合だった。

当初は,リモートプレゼンする当方はWindows PCを使用し,プレゼンを視聴する側もWindows PCを使用していることが大半だった。ところが昨今これは大いに多様化し,Macならまだしも,iPadや中にはiPhoneで視聴する人まで現れた。たまたま今まではなかったが,聴衆側でAndroidスマホ・タブレットが利用されることはいつ起こってもおかしくない。

そこで問題になるのがフォント。Zoho Showは当初ローカル使用が前提だったパワーポイントのクローンを目指して作られており,普通にローカルのフォントが使用できた。日本語のフォントとしてはWindowsに標準搭載されているメイリオを指定してきた。Windows上でそうやってZoho Show上に作られたスライドを見るのには問題ないが,リモートプレゼンをして,視聴者がWindows以外のOSのデバイスを使っている場合,メイリオフォントがないために表示が崩れてしまう。単純に文章を書いているだけであれば改行位置がずれる程度の問題かもしれないが,自分は図を多用している。例えば説明のため特定単語を四角で囲っている場合,フォントが変わって文字の表示位置がずれると,四角の位置と単語の位置がずれてしまう。

こういった問題を解決するために生まれたのがwebfont。フォントデータをWeb上に置きそれをWebページから参照することで,プラットフォームでどのようなフォントが用意されているかに関わらず,そのWebページの表示を統一させることができる。Zoho Showも何年か前からwebfontに対応していたが,その中には日本語フォントがなかった。

そこで2年前から任意のwebfontが使えるようにするよう要望を出してきた。それとは別にWebサイトも更新する予定もあったので,それに使うwebfontも調べており,そのときにはMigu 1Cが自分の好みに合うと思った。

自分のZohoのコミュニティーサイトへの投稿に対してZohoスタッフから直接告知の返答がなかったため知らなかったのだが, “Custom Font in Zoho Show” によればこの機能は既に実現されていた。ただし,Google Drive相当のZoho Docsではなく,Zoho WorkDriveの有償プランに移行する必要がある。WorkDriveには無償のSoloプランもあるがそれではこの機能の恩恵に預かれない。

ただ, “Font Customization” という記事も見つけた。Google Docs相当のZoho Writerでフォントを利用する方法の話だが,日本語用フォントとしては以下が使えるようになっている。自分の選んだ任意のwebfontが使えるわけではない。

  • Cardo
  • Hannari
  • Kokoro
  • Mplus 1p
  • Nico Moji
  • Nikukyu
  • Noto Sans CJK JP
  • Rounded Mplus 1c
  • Sawarabi Gothic
  • Sawarabi Mincho

Noto Sans CJK KR/SC/TCもリストされるが上のリストからは外した。それぞれNoto SansファミリーのうちのCJK Unicodeフォントの韓国語式,簡体字式,繁体字式であるから。

さらに,ローカルフォントを使えるような仕組みも準備してある。ただし,ローカルフォントを利用すると当然それがないプラットフォーム上では表示が崩れるので,その際使用する代替webfontも合わせて指定することになっている。残念ながらwebfontそのものをアップロードできる仕組みではない。

この記事を見てからZoho Showを注意深く見てみると,実はこれらのフォントはZoho Showでも既に使用できるようになっていた。ただし実際に使用するには, “Add fonts to gallery” から手動で選択し,my fonts に追加する必要がある。Zoho Showでは「日本語に対応したフォント」というフォント検索ができなかったため気づかなかった。

同じZohoの製品ということでZoho Writerで使える日本語webfontと,Zoho Showのそれは同一だと思いこんでいたが,精査するとそれは正しくないことが分かる。Zoho Writerで使えるがZoho Showで使えない日本語フォントはCardo。逆のケースもあるかもしれないが,Zoho Showでは基本フォント名が表示されるだけなのでパッとはわからない。

これらフォントのサンプルを示すスライドを作成したPDFファイル)。一部フォントは異なるweightのものも含めている(用意されている全てのweightをカバーしているわけではない)。

結局使えそうなのは,Mplus 1p, Noto Sans CJK JP, Rounded Mplus 1cのみ。だが,どれも「これだ!」という感じはしない。こうしてみるといかにメイリオが秀逸なフォントかよくわかる。Normal weightならMplus 1pか。Weightをlightにすることも考えると,Rounded Mplus 1cも候補になる。丸文字はプロフェッショナルな文書やスライドには決して使うべきではないと思うので,丸文字感がはっきり感じ取れるnormal weightのRounded Mplus 1cは論外。ところがlight weightではそれが薄まりパッとは感じられなくなる。ただ,やはりlight weightにすると文字の視認性が落ちる。結論としてはありきたりなMplus 1p(normal weight)。

アルファベット用には別途フォント選定が必要になるのだろう。

実は画面共有でスライドを見せるのであればwebfontは重要ではない。ローカルのフォントが使えるからだ。Zoho Showはスライドデックを公開してWebページに埋め込むこともできることになっている(…ただ現在この機能は提供されていないのかもしれない)ので,そういう機能を利用することがあるのなら,やはり最初からwebfontを利用したほうがいいと思われる。

ところで,webfontを使うようにしたスライドはAndroidのZoho Showのモバイルアプリでも同じように表示されると期待して見てみたら,激しく表示が崩れていた

ZoomによるオンラインミーティングでZoho Showによるプレゼンテーション

今まで仕事ではSkypeによる音声通話を主に使用し(ビデオは発音のしかたを見せたいときなどのみ),プレゼンをする際はZoho Showを利用してきた。Zoho Showは簡単に言うとマイクロソフト社のパワーポイントのWebアプリ版クローン。Zoho Showの採用を決めたのは10年以上前だが,決め手は単独でリモートプレゼンテーション機能を持っており,かつその際聴衆側では勝手に先のスライドに進んだりできないようになっていることだった。

対抗製品であるGoogle Slidesでは,その,聴衆側で勝手に先のスライドを見るということができたので却下したように記憶しているのだが,当時のその辺の判断を記録したMyspaceのブログはその後消えてしまってて確かなところはわからない。ともかく聴衆にそのような自由を与えてしまうとプレゼン中こちらの話をちゃんと聞いてくれなくなるので,自分にとってはこれは大事なポイントだった。

少なくとも今のGoogle SlidesではリモートプレゼンテーションはGoogle Meetを併用することで実現されているようだ。結局のところ画面共有なので,Zoomをはじめ他の画面共有機能と組み合わせることも問題なくできるはず。今のGoogle SlidesにはZoho Showが提供するようなリモートプレゼンテーション機能を自分では持っていないようなので,以前もなかったのかもしれない。オンラインプレゼン時には,単純に共有したファイルを聴衆がそれぞれ勝手に見る,というシナリオを想定していたのかも。

Zoho Showは,完全とはいえなくても自分に必要な機能がほぼ全て揃っており,かつ無料で使えるのでありがたく使わせてもらってきた。Skype主体でレッスンを行い,必要があるときにはZoho Showでリモートプレゼンテーション機能を追加する,というスタイルも我々のニーズに合っていた。ただ,最近新しい生徒さんで「SkypeではなくZoomで」という方が現れたため,Zoom対応を遅ればせながら検討しなくてはならなくなった。

コロナ禍でZoomは大いにシェアを伸ばし,それまでLine以外インターネットメッセージングあるいはインターネット通話機能は使ってこなかったという一般的日本人も,オンライン会議の類にはZoomを使うのが当たり前の人がかなり増えたと思われる(Linuxクライアントも用意しているのはさすが)。Lineが携帯電話番号に強く紐付けられたサービスであるため,一般人はスマホにLineアプリをインストールして使っていても,PC/MacにLineアプリはインストールしていないデスクトップ版Lineアプリはちゃんと用意されているが,使用しているのは少数派だろう。一方,オンラインミーティングのためにはPC/Macやタブレットを使うのが普通であろうから,そこにはZoomアプリを既にインストールしている。我々のレッスンで必要とする機能はLine, Zoomの双方で提供されているが,レッスンに使うのであればLineよりもZoomの方が生徒側に余分の手間が発生しないという意味でより適していると言える。

以前からSkypeではなくLineの使用にシフトしていかなくては,と思っていたが,そうではなくZoomの使用にシフトする,あるいは完全にシフトしないにしても最低限対応できるようにするのが正解なようだ。Line対応するとすると,通話ではなく,むしろ通知のための自動メッセージング(例: 「ご予約のレッスン開始まであと1時間です」)機能の方が重要だろう。

ちなみに,Skype for Business Onlineは2021年中にサポートが打ち切られたし,Skype for Business 2015も2023年4月11日のサポート終了が予告されているマイクロソフトがSkype for Businessを引退させたがっているのは間違いない。ただし一般向けSkypeにそういった兆候は今のところ見られない。SkypeとZoomは機能的に被るところも多いが,オンラインミーティングのためのZoomに対して,インターネット電話サービスとして始まったSkypeには自分の電話番号を持てたり(「Skype番号」),一般電話番号に電話をかけるような機能( “Skype to Go” )もあり,Zoomで完全に置き換えられるわけではない。そのためコンシューマ向けにはSkypeは今後もすぐはなくなったりはしないと予想される。

さて,音声・ビデオ通話のためにZoomを使用することが必須という前提で,Zoho Showで用意したスライドをリモートプレゼンテーションするには以下の3通りの方法がある。

  1. Zoho Show自身の,でそれ単独で実行できるリモートプレゼンテーション機能を使う。
  2. Zoho Showのプレゼンタビュー機能を利用しする。このモードでは,ブラウザでプレゼンタ用の画面(タブ)と,聴衆に見せるスライドのみを表示する別ウィンドウの2つが用意される。ローカルにプレゼンする際には,後者のウィンドウはプロジェクタを利用して投影するなどの使われ方をすることが想定されている。しかし,ここではこのウィンドウをZoomの画面共有機能を用いてリモートに聴衆に見せる。
  3. Zoho Showのスライドショー機能を利用する。このやり方ではプレゼンタが見ているものをそのままZoomの画面共有機能を用いてリモートに聴衆に見せる(ちなみに,Zoho Showでは,スライドデックの中から事前に選んだ特定のスライドだけでスライドショーができるカスタム・スライドショー機能もある)。

最初 1., 2.を200枚ほどのスライドデックで試してみたところ,1. は聴衆側で「(プレゼン視聴のために発行されたURLを)開いても何も起こらない」,2. ではプレゼンタ側でブラウザが固まってしまい,結局そのときはプレゼンを諦めざるをえなかった。

Chromeブラウザのタスク・マネジャー機能を眺めていると,1., 2., 3.の全ての場合でプレゼンタが操作するタブ( “Presenter” から「Pタブ」と呼ぶことにする)に,200枚ほどのスライドデックの場合800MBほどメモリを消費する。1., 2. の場合はそれとは別のタブも使用されるが(聴衆用なので “Audience” から「Aタブ」と呼ぶことにする),それには300MB弱ほどメモリを消費するようだ。

1., 3. の場合はプレゼンタのPCではPタブのメモリ消費しか起こらない(1. ではAタブも使われるが,それは聴衆のPCで開かれるので,プレゼンタのPCには負担がない)。2. はプレゼンタのPC上でPタブ・Aタブとも開かれるので,もっとも負担が重くなる。

Zoho Showの挙動を見ていると,プレゼンテーション開始時にPタブ,Aタブともスライドデータを新規に全て読み込むようで,それがスライド枚数が多い場合に固まってしまう原因ではないかと疑っている。例外が 3. の場合で,どうもそれ以前に編集・閲覧のためにダウンロードしていたデータをそのまま使うためか,待ちが起こらない。

正確には1., 2.の場合最初の最初にはスライド3枚分だけデータを読み込んだところでスライドデータの読み込みを休止する。プレゼンタがプレゼンテーション参加のために必要になるURLをコピーするなどの作業ができるようにするためだろう。だが,そのままほっておいてもスライドデータの読み込みを再開したりはしない。だめもとで徐々にダウンロードするように変更するようZohoに依頼した

聴衆側からすると,2., 3.の場合は画面共有なのでラスターイメージが継続的に送られてくることになるが,1. はいわばベクターイメージなので,受信するデータ総量は格段に少ないはず。しかし,おそらく現在のZoho Showの実装では,上で述べたように最初にスライドデータを全て聴衆側PCのブラウザでダウンロードするようで,スライド枚数が多いとここで一時的に固まってしまう。つまりネットワークの下流の速度に影響を受けるのと,スライドデータをメモリ内に保持する作りになっているのだとするとメモリの少ないPCでは頻繁にフリーズが起こるだろう。聴衆がスペックの低いPCを使用している場合は,Zoomでの画像共有(と音声通話)に耐えさえできれば,2., 3. の方が1.よりも実用になるだろう。

以前からわかっていたことだが,Zoho Show自身のリモートプレゼンテーション機能を利用すると,プレゼンタが見せていると思っているものが聴衆が見ているものとずれる,ということが定期的に起こる。また,現状ローカルフォントのメイリオをよく使用しているが,聴衆側がWindows PCを使ってないとメイリオフォントがないため期待したような表示にならず,伝えようとするポイントが伝わらない,という問題が起こる(ただしこれはwebfontを利用すれば解消できる)。画面共有であればその心配はいらない。

以上まとめると,プレゼンタ側で負担がないのは1.と3.。聴衆側に負担がないのは2.と3.,ということになり,結論としては3. がもっとも安全な策だといえる。実際に試してみたときのプレゼンタ側に見える画面がこの記事冒頭の図。スライドショーなのでスライドは全画面表示される。Zoomのチャットメッセージもそれの上に表示されるようにすれば使えそう。

ただし,プレゼンタがその後のスライドを眺めながら臨機応変に使うスライドを選ぶということはできなくなる。特に,所定時間内に収めるため,あるいは聴衆の反応に応じて内容を調整するためそういうことができるのが望ましいのだが。ただ,デック内容を事前にプリントしておく,別モニターに表示しておく,などすれば,大きな問題にはならないだろう。

3. は明らかにリモートプレゼンテーション (1.)やプレゼンタビュー (2.)を利用する場合に比べて軽い。3. であれば古PCでもZoomを介したリモートプレゼンテーションができそうだ。ちなみに,Zoho Showのリモートプレゼンテーションやプレゼンタビューの実装コードは大半共通しているんではないかと思っている。

実はもう一つ有効な解決策があり,それはデック内のスライドの数を減らすこと。現在使用している10年選手のCore i3-2120 @ 3.30GHz/ RAM 8GBのPCではデック内のスライド数が50枚程度なら,1., 2., 3.どの方法でも問題ない。100枚になると,1., 2.だとちょこちょこ固まる。200枚になると1., 2.では実用にならない程度のフリーズが起こる。どのようなトークであっても,「必要があれば使う」という予備スライドの数がだんだん増えていくのでどうしても総スライド数は膨れ上がりがちだが,この方向でもできるだけ努力してみよう。

3.の場合Zoomによる画面共有の対象はフルスクリーンのタブだから問題にならないが,一般的には,共有している画面を,自分自身は見てないからとモニターからはみ出すように配置してしまうと,その画面を見ている参加者には切れて見える。考えてみれば当たり前だが,2. の方法でやる際には要注意。モニター内に収まってる限り他ウィンドウの下にくるのは問題なし。

なお,1. の場合,時間的余裕を持ってリモートプレゼンテーションを始めておいて,プレゼンタ・聴衆の双方の側でスライドデータをダウンロードしておけば問題は軽減できるはず。ただ,Zoomにだけ慣れている人は,画面共有ですぐスライドが見える,ということを期待するだろうから,このようなやり方は,余計な手間,というふうに解釈するだろう。

また,Zoho Showを使う以上どのような使い方であろうと意味があるのは,ブラウザの負担を軽くすること。そのためZoho Showでのプレゼン専用にChromeのプロファイルを新たに作成した。そのプロファイルでは拡張機能は一切使わない。プレゼン時には通常のプロファイルのウィンドウは全て閉じるようにすればいくらかはましであろう。

以前iPhoneのみでレッスンを受けておられた生徒さんに,いくらかでもオンラインスライドが見やすいようにと古iPad 2をお送りした。そのときはまだZoho Show自身のリモートプレゼンテーション機能を使うことが前提だったが,これを機にこちらがZoomの使用に慣れたらZoomの画面共有でスライドを見せるようにした方が彼女にも使いよいだろう。なぜかこのiPad 2にもZoomアプリはインストールできたことだし。