HTMLを手軽に作る方法を再検討します。手軽といえば、まずWordでHTMLを作ることが思いつきます。

このところ、CAS記法[1]の便利さになれてHTMLを作る他のオプションを忘れかけていました。

しかし、まだ巷ではHTMLを簡単に作る方法で苦労しているようです。そういう方には、CAS記法を使ったら如何ですか? と言いたいところです。しかし、いきなり結論を出しても、ということで、まずは久しぶりに現状を調べてみましょう。最近は、どんなのがあるんだろうねぇ。

こういうときはググるというわけで、「Office HTML 変換」で検索! 最近のGoogle検索はパーソナライズされていますので、すべての人が同じ結果になるかどうかは分かりませんが、私の画面でトップに来たのはこちらです。

「ワード文書を Web ページに変換する」
Last Update:12/22/2016 21:58:35

となっていますので新しいですね。どれどれ。

どうやらマンション管理組合関係のWord文書をHTMLに変換する話のようです。Word2007/2010の「名前を付けて保存」でHTML形式に保存しているようです。ああ、これはもう10年以上前に試した記憶があるなあ、と思って読んでみました。

この「ワード文書を Web ページに変換する」というWebページを作成された方は、Wordで紙に印刷するようにレイアウトした紙のページをWebページでも再現しようと考えておられるようです。そして、変換前のWordのレイアウトをWeb化したときのレイアウトを比較して「レイアウトが崩れること、その原因」についてのまとめがあります。

これはまさにWordで文書を作成している人の典型のパターンです。

まず、Wordの文書は紙に印刷することを想定しています。そして一定のサイズをもつ紙の印刷面にうまく適合するように、そして分かりやすいように画像や文字の大きさを決めてレイアウトするわけです。

しかし、Webページはコンピュータの画面で表示するものです。で画面はWebページを読むコンピュータの種類、最近ではスマホで見る方が多いと思います。スマホの画面でみるかタブレットの画面で見るかなど、使う人の時間やあるいは通勤途上、会社、自宅などの場所によって千差万別になります

ですので、そもそもWebを作るときには印刷レイアウトをそのままWebで再現したい、という発想はあまり良くないんですね。

ではどうしたら良いでしょうか?

まずは、Webページ=様々な画面で見たときに問題がない、というようなWord文書の作り方をする必要があります。このWebページで紹介しているようなチラシ的なレイアウトをした文書はWebに持って行くのはあまり適切ではないでしょう。

WordでHTMLを作るといったときは、まずWord文書の作り方を次のように変える必要があると思います。

・見出しと本文を明確に使い分ける。
・そして見出しの階層は文字の大きさではなくスタイルで表す。
・本文は段落を意識して書く。
・段落の種類(例えば、引用、箇条書きなど)はレイアウトで区別するのではなく、スタイルで区別する。

こうなると、結局、Wordで簡単にHTMLを作る=まずガイドラインの作成から? そのガイドラインはいままでのWord文書の作り方の発想転換を迫るものになって、結局は受け入れられるまでに時間がかかる? やれやれ。

[1] CAS記法リファレンス
[2] 前回:ワンソースマルチユースの課題:HTMLソースのオーサリング問題を改めて考えてみようと。

ワンソースマルチユースの課題:HTMLソースのオーサリング問題を改めて考えてみようと。

2017年になってから久しぶりにWebページを自分で編集・更新をし始めています。XHTML形式のWebページをoXygenというXMLエディタ[1]で編集しているのですが、このところ毎日Webページ制作の生産性の低さに辟易しています。

少し遡っての個人的な経験ですが、私は2000年頃からドキュメントの多くをXML(XHTML)で作成するようになり、Webページなども簡単なHTMLタグの組み合わせで作成していました。それらのWebページはXHTMLタグでマークアップして簡単なCSSでレイアウトを施したものです。今から見ますと原始的なものですが、この頃のマークアップ編集はAntenna House XMLエディタという自社開発のXMLエディタを使っていました。この間、Antenna House XMLエディタは、開発があまり進まず、時代の流れに遅れてしまい、結局、販売も断念してしまいました。

その間、HTMLのタグを直接編集するのはどうも生産性が低いのでなんとかうまい解決策がないものかと考えていました。そうした経験からWiki記法のような簡易マークアップを使ってHTMLを書くことで、HTML制作の生産性を高めることができるだろう、と考えました。それが、2010年にCAS-UBの開発を開始した一つの理由です。CAS-UBはWiki記法を拡張したCAS記法をつかってHTML文書を記述します[2]。これは檜山正幸さんという天才的なアーキテクトに設計していただいたものです。自分で言うのもなんですが、いつも良く出来ていると感じます。CAS記法をなかなか普及させられないのは、偏に私のマーケティング力が足りないからだと反省します。

もう一つの理由は、出版の世界は一品生産のため、DITAマニュアルの制作システムのように大きな投資が必要なシステムを作るのは難しいので、PDFとEPUBを作る仕組をWebサービスとして提供するのが向いているのではないかと考えたことです。CAS-UBは出版物を作る仕組としてうまく機能するようになっています。まだまだ改善が必要ですが。

そうしたことで、2011年頃から、業務上の文書はOffice、簡単なWebページはブログ、出版物にするときはCAS-UB、といった使い分をしていました。そんなことで、個人的には問題も感じなくなり、もうワンソースマルチユースには課題はないだろうなどと考え始めていたのです。そして、ワンソースマルチユースの大きな課題であるソースドキュメント編集の問題について、やや忘れかけていました。

で、久しぶりにWebページ(HTML)をXMLエディタ(oXygen)で編集し始めて、HTML直接編集の生産性がさらに低下しているのに辟易しています。ずっと、HTMLの生産性が低い理由は、コンテンツ(原稿)とタグ(マークアップ)の二つを同時に考えるためと思っていました。しかし、今回、久しぶりにWebページを編集してみて、レイアウトのための余計なクラス属性や余計な階層構造が、さらに生産性を下げる原因になっている、と痛感しています。

ちなみに、今『CSS設計の教科書』(谷 拓樹著、インプレス発行、2016年2月第1版第4刷)を読んでいます。この本を見ますとCSSのセレクタには要素ではなく、クラス属性を指定する方を推奨しています。要素のセマンティクスにはあまり依存しないで、div要素に多数のクラスを設定し、CSSではクラスのセレクタを使って部品化し組み合わせる方法などがあります(pp.45-52 OOCSS)。こうなってきますと、今度はコンテンツの編集の際に、レイアウトのためのクラスの設定を適切に行わなければならなくなります。結局、HTMLの編集において、テキストや画像コンテンツ、セマンティクスとしてのHTMLタグ、さらにCSSレイアウトのためのクラス属性の設定、という三つを同時に考慮しなければなりません。これはちょっと? です。

見栄えの良いWebページを作るために、CSSが複雑になりメンテナンスしにくいのでクラス属性を組み合わせ、今度は内容を書くのが大変になる! って本末転倒しているように感じます。どうしたら良いんでしょうかね。

また、最近、2回ほど学術情報XML推進協議会のセミナーに参加して、皆さんの意見も伺い、久しぶりにコンテンツ制作の問題がまだ課題なんだな、と痛感している次第です。ということで、HTMLのオーサリングについて、改めて整理し直そうと考えているところです。

[1] oXygen
[2] CAS記法リファレンス
[3] 次回 HTMLを手軽に作る方法を再検討します。手軽といえば、まずWordでHTMLを作ることが思いつきます。

Submission Request to W3C from Vivliostyleについての若干の感想

Current Status of Japanese Typography Using Web Technologies(Submission Request to W3C from Vivliostyle)日本語訳

という文書が1月27日付けで発表されているので、ざっと見てみた。以下に若干の感想を記す。

まず、この文書の中で一番重要なポイントは「Implementations that support pagination, such as EPUB readers or PDF formatters, do need to support such features.」(日本語訳「EPUBリーダーやPDFフォーマッタなどのページネーションをサポートする実装は、そのような機能をサポートする必要があります。」)という点だろう。

もともとJLReqは、紙に印刷する書籍の組版に関して整理したものである。従って、JLReqを議論の前提にする以上、縦横の大きさをもつページの概念が必須である。ページの概念を無視すれはかなりの部分が意味を失ってしまう。

一方において、ブラウザは画面に高速に表示することを目的としている。そしてページサイズの概念はブラウザには必要ない。このため、CSSの勧告仕様または勧告候補だけでは、まだページの大きさを指定できない。CSS Paged Media Module Level 3という仕様にページの大きさを規定する方法があるが、これはまだWorking Draftの段階であり[1]、正式な仕様として参照できる状態ではない。

CSS Paged Media Moduleの歴史は古い。一番最初は1999年にHPのRobert Stevahn氏がWorking Draftを出している。その後、2004年に勧告候補まで行ったが、次の2006年版ではまたWorking Draftに戻ってしまった。CSSを紙への印刷に使おうとするとページの大きさの指定は必須であるのに、正式な仕様ではそれができない状態がもう長いこと続いているわけだ。

現在、リフローのEPUB3を表示するリーダーは、ページ捲りを実装しているものが多い。しかし、これらは各リーダーの独自実装である。ページ捲りの一つとして、例えば、章の見出しを画面の上下・左右中央に配置したいときは縦と横のサイズを指定して、その中央に置くのが素直なはずだ。しかし、CSSではそういう指定はできない。このため、日本語のEPUB3ではトリッキーな指定をせざるを得なくなってしまっている。

このように、紙に限らず、画面表示を前提とするEPUBリーダーやブラウザでページめくりをきちんと実装しようとすればCSS Paged Media Module Level3を実装することが必要になる。

そこまでの理屈は良いとして、CSS Paged Media Moduleがブラウザの世界で受け入れられるかどうかが問題である。なぜならば、CSSの仕様開発作業はブラウザベンダーの主導で進んでいて、ブラウザベンダー以外はほとんど影響力を持っていないからである。さらに言うならば、CSS2.0で勧告になった項目でさえも、ブラウザが実装していないことを理由にCSS 2.1で削除されてしまったものもある。その一例がここで問題にしているページの大きさである。CSS2には@pageというルールがあり、CSS2.0ではそこに’size’プロパティでページの大きさを指定できた。しかし、CSS 2.1では’size’プロパティは削除されてしまった。’size’はCSS Paged Media Moduleに移行した。こうした経緯を知っていれば、CSS Paged Media ModuleをCSS3の勧告にもっていくのが困難なことは予想に難くない。

CSSがサポートしないためにできないことがいろいろあるのは確かである。そしてこれに正面から取り組もうとすると、現状のCSSワーキンググループと長く熾烈な論争になるのは確実である。このサブミッションがどう受け止められるか、興味深いところである。

[1] CSS Paged Media Module Level 3 W3C Working Draft 14 March 2013

ページっていったい、どういう意味なんだろう? ――Webページ

個人的にはずっと長いことページという言葉を紙と連想して使ってきました。もう一方で、ここ20年くらいはWebページという言葉もかなり頻繁に使っています。そうしますと、この二つのページはかなりかけ離れたもののように感じるのですが、ページっていったいどういう意味でしょうか? 

Webの発明者Tim Berners Leeの本[1]によりますと、WorldWideWebプログラムを初めてCERNの限定されたNeXTユーザーにリリースしたのが、1991年3月なのだそうです。そうしますと、Webページという言葉は1991年より前にはなかったはずです。

Webページという言葉を初めて使ったのが誰かは分かりませんが。とりあえず、上記の本でpageに関する文章を拾ってみました。

これらを見ますと、まず、HTMLのソースコードはWebページではないようです。HTMLはページとして整形する方法を記述しているもので、Webページとはブラウザなどでワープロのように可視化した状態を指すようです。

…Hyper Text Markup Language (HTML) I had written, which describes how to format pages containing hyper text links.(p.29)

The browser would decode URIs, and let me read, write, or edit Web pages in HTML. (p.29)

… users could bookmark any place and return to it, and could make links into any place from another document. This would give a feeling of persistence, of an ongoing existence, to each page.(p.37)

I never intended HTML source code (the stuff with the angle bracket) to be seen by users. A browser/editor would let a user simply view or edit the language of a page of hypertext, as if he were using a word processor. (p.42)

[1] 『Weaving the WEB』(Tim Berners Lee, Harper, 1999-2000)

★本ブログの内容をもう少し整理して、次のWebページとしましたので、ぜひご一読ください。
本のかたちを考える ― その2 ページって何? 「ページ」と本のかたちとの関係

★ページに関連するブログ記事の一覧
[1] ページってどういう意味? 紙のページ、Webページ (memo)
[2] ページってどういう意味? 続編 Kindleの紙の本の長さと、KENPについて
[3] Kindle Unlimited問題とKENPの関係について(続き)
[4] Amazonでは本のページの数え方が三つある。Kindle Unlimitedは第三のKENPで著者への支払いが行われ、KENP相場が基準になる。
[5] ページって何? 「ページ」と本のかたちとの関係、「ページ」と「頁」の関係、ブラウザと電子書籍の未来

ページってどういう意味? 紙のページ、Webページ (memo)

かねがね疑問に思っていることがあります。それはタイトルに挙げました「ページ」という言葉です。

個人的には、ページという言葉を、従来、ずっと紙の1ページとして考えてきました。つまり、ある大きさでカットされた紙があり、その上に確保された白紙の領域に、文字または絵が書かれたり、印刷またはプリントされたときその面がページとなります。実際に文字がなくても印刷されることが想定されていれば白紙のページです。

一方、文字が印刷されることが想定されていないとページとは言いません。たとえば、ティッシュペーパーは大体20cm四方でカットされていますが、ティッシュペーパーの1面をページと言う人はいないでしょう。

でも、紙に文字が印刷されていても、例えば紙幣の面、チケットや切符の面はページとは言わないように思います。

ページという言葉が断裁された紙と密接に結びついているかと言えば、全く逆の、Webページ、あるいはホームページという使い方もあります。

例えば、Mozillaの用語説明では、Webページとは「ブラウザで表示できる文書のこと」とされています。Webページのことを略してページとも言うそうです。特にHTMLで表記された文書がWebページであり、PDFのような文書はWebページとは言わないそうです[1]

でもなぜWebにページという言葉を使うんでしょうね。紙のページとWebのページとでは共通項がないような。そういえば、言葉が意味的にやや反対に使われる例として、以前にメモした、解像度[3]もそれに近いように思います。

Cambridge Dictionaryでは、Webページとは「a page of information on the internet about a particular subject, that forms (a part of) a website:」[2](特定の主題についての、インターネット上の情報の1ページであり、Webサイト(の一部)を構成する)とあります。

そうしますと、ページというのは情報と密接に関係しているようにもみえます。

言葉の意味は時代に応じて変化するものです。そうなってきますと、将来は、ページとは紙のページではなく、ブラウザで見るHTMLファイルのことになるのでしょうか? 

[1] What is the difference between webpage, website, web server, and search engine?
[2] web page
[3] 解像度とは(草稿)

続き:ページってどういう意味? 続編 Kindleの紙の本の長さと、KENPについて

10月24日(月)バージョンアップ内容についてご案内するセミナーを予定しています。お申し込みはこちらからどうぞ:
http://www.cas-ub.com/user/seminar.html

★本ブログの内容をもう少し整理して、次のWebページとしましたので、ぜひご一読ください。
本のかたちを考える ― その2 ページって何? 「ページ」と本のかたちとの関係

★ページに関連するブログ記事の一覧
[1] ページってどういう意味? 紙のページ、Webページ (memo)(本ブログ)
[2] ページってどういう意味? 続編 Kindleの紙の本の長さと、KENPについて
[3] Kindle Unlimited問題とKENPの関係について(続き)
[4] Amazonでは本のページの数え方が三つある。Kindle Unlimitedは第三のKENPで著者への支払いが行われ、KENP相場が基準になる。
[5] ページっていったい、どういう意味なんだろう? ――Webページ
[6] ページって何? 「ページ」と本のかたちとの関係、「ページ」と「頁」の関係、ブラウザと電子書籍の未来

「CAS-UBによるPDF生成のためのガイド」 Web版試作のお知らせ

弊社では、今年度の目標として、製品の利用ガイドや、機能リファレンスなど製品ドキュメントのWeb化を進めています。

このことは前回のブログで紹介いたしました:「瞬簡PDFシリーズのマニュアルのWeb公開と冊子の販売」

瞬簡PDFシリーズをはじめとして、弊社製品のマニュアルの多くは、CAS-UBを使って編集・制作されています。CAS-UBではワンソースでPDF、EPUB、HTMLヘルプを生成できます。さらに、次期バージョンの目標としてWeb形式の生成機能を充実することを掲げています。

CAS-UB自身のマニュアルも、CAS-UBを使って制作し、PDFとEPUB形式で公開してきました:CAS-UB サポート&ガイド

次期バージョンからはWeb形式でも公開する予定です。とりあえず、現行バージョンの「CAS-UBによるPDF生成のためのガイド」のWeb版を試作しました。

HTML形式(試作)(2016.7.12)

試作ですので、いろいろ不適切な部分があるかもしれませんが、お試しいたければと存じます。

【お詫び】CAS-UBの現在バージョンでもWeb生成ボタンあります。しかし、これまでは機能が限定的でした。紹介させていただきました製品マニュアルを始め、「CAS-UBによるPDF生成のためのガイド」の試作Web版は、開発途上のCAS-UBで制作したものです。本機能はまたユーザーの方には公開されていません。しばらくお待ちください。

■PDF関連情報
流通によるプリントオンデマンドでの出版が現実のものとなった今、その活用の課題を考える。(2017年1月時点)

出版における情報アークテクチャーの必要性

出版=情報を流通させるということと考えます。出版がすなわち「紙に印刷し、本や雑誌のかたちに製本による流通」を意味していた時代は終わりつつあります。

紙の本や雑誌がなくなるということを主張するつもりはないのですが、いま、情報を広く流通させようとすれば、Web技術(Webページや電子書籍)と印刷技術(PDFや紙の本)という二つの方法を、うまく使いこなす必要があります。これはほとんど説明の必要がない事実でしょう。

しかし、Web技術と印刷技術は全く異なります。この両者をうまく使いこなしている事例もありますが、まだ主流になっていません。雑誌や本の場合は、現在は、DTPで紙に印刷するためのページをつくり、そのデータを基にしてWeb版を作る、という方法が主流です。Web版はWeb制作ツールや簡単なものはブログなどで作ります。電子書籍も別の制作ツールを使うことが多いでしょう。

しかし、このような方法では、効率が悪いのは明らかです。Webと印刷の両方を簡単・効率的に使いこなせない限り、出版は生き残れないでしょう。

ではどうしたら良いでしょうか。

CAS-UBは、そのひとつの解決策を提案するために作りました。2010年から2016年までほぼ5年間かかりましたが、ひとつの成果として本をつくりました。これです。
20160123

015c5c287030d1e1f3a8b2193ca19091ced9ac2111

5年間の経験に基づいていえることは、異なる二つの技術を使いこなすためには、上流、つまり情報を作るところからきちんと考える必要がある、ということです。

情報やその作り方の仕組みを設計するところから始めなければなりません。
出版における情報の設計、すなわち情報アーキテクチヤーが必要なゆえんです。

アクセシビリティとは(草稿)

アクセシビリティとは
国際連合(国連)の障害者の権利に関する条約(障害者権利条約)では、アクセシビリティとは障害者にとっての施設やサービスの利用しやすさのことである。日本では年齢や身体障害の有無に関係なく、誰でも必要とする情報に簡単にたどり着け、利用できること、すなわち情報アクセシビリティと同義に使うことが多い。さらに、情報アクセシビリティの中でも特にウェブアクセシビリティが重視されている。

障害者権利条約
国連の障害者権利条約は2006年に成立したが、日本では国会での批准を経て効力が発揮したのは、2014年2月19日である。障害者権利条約の第9条はアクセシビリティ(英文)の見出しがあり、障害者が自立して生活し、及び生活のあらゆる側面に完全に参加することを可能にすることを目的として、①建物、道路、輸送機関その他の屋内及び屋外の施設(学校、住居、医療施設及び職場を含む。)、②情報、通信その他のサービス(電子サービス及び緊急事態に係るサービスを含む。)を簡単に利用できるようにすることとしている。

障害者基本法と障害者差別解消法
日本では、障害者権利条約批准のための国内法整備として、障害者基本法の改正(2011年)と障害を理由とする差別の解消の推進に関する法律(障害者差別解消法)が制定(2013年)された。日本の国内法とそれに基づく施策では、施設やサービスの利用しやすさ、あるいは障害者の社会参加の障壁の解消にバリアフリーという言葉を充てている。障害者基本計画には、情報アクセシビリティという項目がある。そこでは、「障害者が円滑に情報を取得・利用し,意思表示やコミュニケーションを行うことができるように,情報通信における情報アクセシビリティの向上,情報提供の充実,コミュニケーション支援の充実等,情報の利用におけるアクセシビリティの向上」を推進するとしている。このように、日本では情報アクセシビリティに力点をおいており、障害者権利条約と用語のずれがある。これは歴史的なものであろう。

情報アクセシビリティの向上
第三次障害者基本計画(2013年度~2017年度)で情報アクセシビリティの向上に向けて次の取り組みが行われている。
(1)情報通信における情報アクセシビリティの向上
○障害者に配慮した情報通信機器及びサービス等の企画,開発及び提供を促進する。
○日本工業規格等標準化を進めるとともに,国際規格提案を行う。また,各府省における情報通信機器等の調達は,情報アクセシビリティの観点に配慮して実施する。
○国立研究機関等において障害者の利用に配慮した情報通信機器・システムの研究開発を推進する。
○障害者に対するIT相談等を実施する障害者 ITサポートセンターの設置の促進等
(2)情報提供の充実等
○身体障害者の利便の増進に資する通信・放送身体障害者利用円滑化事業の推進に関する法律に基づく放送事業者への制作費助成,「視聴覚障害者向け放送普及行政の指針」に基づく取組等の実施・強化により,字幕放送(CM番組を含む),解説放送,手話放送等の普及。
○聴覚障害者に対して,字幕(手話)付き映像ライブラリー等の制作及び貸出し,手話通訳者や要約筆記者の派遣,相談等を行う聴覚障害者情報提供施設の整備を促進する。
○身体障害者の利便の増進に資する通信・放送身体障害者利用円滑化事業の推進に関する法律に基づく助成等により,民間事業者が行うサービスの提供や技術の研究開発を促進し,テレビや電話等の通信・放送サービスへのアクセスの改善を図る。
○電子出版は,視覚障害や学習障害等により紙の出版物の読書に困難を抱える障害者の出版物の利用の拡大に資すると期待されることから,アクセシビリティに配慮された電子出版の普及に向けた取組を進めるとともに,教育における活用を図る。
○日本銀行券が,障害者等全ての人にとってより使いやすいものとなるよう,五千円券の改良,携帯電話に搭載可能な券種識別アプリの開発・提供等を実施し,券種の識別性向上を図る。
○ 心身障害者用低料第三種郵便を検討する。
(3)意思疎通支援の充実
○手話通訳者,要約筆記者,盲ろう者向け通訳・介助員等の養成研修等により人材の育成・確保を図り、また派遣,設置等による支援を行う。
○情報やコミュニケーションに関する支援機器の開発促進と,障害者に対する給付,利用の支援等を行う。
○意思疎通に困難を抱える人を支援するための絵記号等の普及及び利用の促進を図る。
(4)行政情報のバリアフリー化
○利用しやすさに配慮した行政情報の電子的提供の充実に取り組むとともに,地方公共団体等の公的機関におけるウェブアクセシビリティの向上等に向けた取組を促進する。
○災害発生時に障害者に対して適切に情報を伝達できるよう,障害特性に配慮した情報伝達の体制の整備を促進する。
○政見放送への手話通訳・字幕の付与,点字又は音声による候補者情報の提供等,障害特性に応じた選挙等に関する情報の提供に努める。
○知的障害者等にも分かりやすい情報の提供に努める。

ウェブアクセシビリティ
ウェブコンテンツのアクセシビリティについては、Web技術の標準化を行なう団体であるW3C (World Wide Web Consortium) よりWeb Content Accessibility Guidelines (WCAG) 2.0が勧告されている。これに基づき、日本国内では「高齢者・障害者等配慮設計指針 −情報通信における機器・ソフトウェア・サービス − 第3部 ウェブコンテンツ」(JIS X 8341-3)が制定されている。WCAG 2.0/JIS X 8341-3は、HTML、CSS、PDFで作成する情報コンテンツを、アクセシブルにするために守るべき項目が提示されている。

[1] 著作権法とアクセシビリティ
[2] アクセシビリティという言葉がどのように使われているか
[3] PDFのアクセシビリティ。ワンソースマルチユースのもう一つの応用。
[4] EPUB3.0のアクセシビリティを高めるためのガイドライン

MathJax V3開発は、根本的な方針変更となる

MathJaxのホワイトペーパー“Towards MathJax v3.0”が発表されました。MathJaxはV3.0でかなり根本的な方針変換を行うようです[1]

MathJaxは、2010年8月4日にV1.0がリリースされ、5年間でWebにおける数式表示のデファクトスタンダードになりました。この間、コアを除くモジュールの開発は大幅に進みました。しかし、コア部分は、当初の主要ブラウザであったIE6以降をターゲットにして開発されたV1.0からまったく更新されていません。V1.0の開発時には、ブラウザのレイアウト機能が低かったので、それを補うために、様々な回避策を実装していました。しかし、最近のWeb標準とブラウザのレイアウト機能の進歩により、そうした対策は不要となりました。現時点では、プログラムの保守の負荷が大きくなってしまったため、新しいV3.0では、現在の古いブラウザを対象とするHTML+CSS出力を廃止し、新しいCommonHTML出力をデフォルトにします。また、APIも変わります。このような変更は、過去のバージョンとは非互換の改造となります。

実装し直しにあたり、大きな方針の変更が決まりました。

当初は、WebブラウザのMathMLネイティブサポートまでのつなぎ役として位置付けられていました。しかし、この5年でブラウザのMathMLサポート実現は当初の期待よりも遠ざかってしまい、今後も期待できないことがはっきりしてきました。

このため、数式をHTML+SVGとして出力する方向へと方針転換するようです。また、従来は、クライアントのブラウザの上でのみ動くものでした。しかし、今後は、ブラウザのみではなく、サーバー上でも動くようになるとのこと。

[1] MathJax whitepaper “Towards MathJax v3.0” releasedDecember 15, 2015
[2] Safari とFireFoxのMathMLレンダリングの改良は、クラウドファンディングを利用したボランティアの手で進んでいる
[3] WebKitの数式(MathML)でSafariはボランティアの努力を採用し、数式を表示できる。Chromeは同じものを不採用として批判を浴びる。
[4] EDUPUBで数式をどのように表わすのか? MathMLが飛翔するか、それともSVGなのか?