Porting Rust to your platform

Rust Language Advent Calendar 2014の12/15日分です。今回はRustの言語仕様とかの話しません。

現在Rust自体は以下のプラットフォームをサポートしています。

• Android/arm
• DragonFlyBSD/x86_64
• FreeBSD/x86_64
• iOS/arm
• Linux/arm
• Linux/mips
• Linux/x86
• Linux/x86-64
• OSX/x86
• OSX/x86-64
• Windows/x86
• Windows/x86-64

これ以外のプラットフォームのバイナリを吐くことはできないのだけど、Rustコンパイラは所詮LLVM使ってバイナリを吐いているので、LLVMでバイナリを生成できるプラットフォームなら(少しの変更で)対応することは可能です。AMDのR600とかでもホントに動かせるのかもしれない。

プラットフォーム用のクロスコンパイラを作成するためのMakefileの作成

<rust root>/mk/cfg 下に新規プラットフォーム用のMakefileを作成する。実際はコンパイラを指定するとかなので、UNIXなプラットフォームの場合はLinuxの定義を丸パクりするだけでいけます。not UNIXの場合は、gcc使う定義作りましょう。

CPUが異なる場合も、ほぼ一緒で構わない。

LLVM用のパラメータの設定

<rust root>/src/librustc_back/target/ にLLVMのターゲット用コードを追加 (コマンドラインオプションなど)。

ランタイム用のコードを追加

<rust root>/src/librustrt に各プラットフォーム用のコードを追加。具体的には stack.rs にコードを追加するのが最低限必要。not POSIXだとThread Local StorageとかThreadの定義とかを一から書く必要が。

Rust自体をLinuxのKernel Driverで使いたいなんて場合は、ここのランタイムコードをLinux Kernel用に別途作成しないと動かないんだよね。

自分のプラットフォームがLLVMで対応されていないんだけど。。。

LLVMのポーティングから始まります。


そんな感じ。LLVMのお蔭でいろんなプラットフォームへの対応が楽になったなぁと。

Status of 縦書き on Firefox

今週とある情報筋よりMozillaは縦書きのレイアウトに反対しているから実装しないと言っているという痛い噂が流れているという情報を耳にしたので、現状の話を書いておく。

元々の縦書き (CSS Writing Mode) のスペックにはいろいろ問題があって、例えば世の中のどの言語であっても存在しないレイアウトが規格として存在してた (これは後に削除) とか、縦中横の時の文字のレイアウト (90度回転するかどうかとか) が決まってなかったとか (これは後にunicode.orgでTR#50としてちゃんと定義される)。そんな感じでまだstableではないという判断をしてて、もう少しstableな仕様になった時に実装を始めようということで内々の人たちでは合意が取れてたって感じだった。すごく中途半端な仕様で実装を始めても、それはCSS Flexboxみたいに間違った利用をする人たちを増やすだけだからね！

ということだったんだけど、今年になってある程度stableになったという認識になっていて、最低限のところ (実際には writing-mode プロパティ) の実装は始めるということでPlatform Teamの今年の目標になってた。

この縦書きレイアウトの実装に関しては、Gecko 36の開発サイクルの中で開発が大きく進んで、Nightly Buildのみabout:configでlayout.css.vertical-text.enabledをtrueにすればwriting-modeプロパティで縦書きを指定可能になった。

もちろんcontenteditableを使えば、こんなHTMLで縦書き編集も可能。

<div contenteditable="true" style="writing-mode: vertical-lr;">
私の名前は中野です
</div>

仕様があっても仕様がstableじゃないと実装ってのは進まないものなんだよってこと。リリース版でも有効になればFirefox OSでも使えることになるよ。

gcc 4.9でARMv8の暗号化命令を使うときのオプションメモ

gcc 4.9だと、arm_neon.hにAESE/AESMCとかに対応したvaeseq_u8などのintrinicが追加されているんだけど、これはデフォルトの設定ではコンパイル不可。

aarch64の場合は、-march=armv8-a+cryptoが必要。
aarch32 (arm 32bit)の場合は、-mfpu=crypto-neon-fp-armv8が必要

IntelのSSEみたく-mcryptoなんて感じは使えないので、メモっておく。

この文字はカラー絵文字をつかうべきか、モノクロの絵文字をつかうべきか

Firefox 32でWindows 8.1でのカラー絵文字サポートが入っているが、今のbetaチャンネルで有効になっているので、こういうバグがファイルされた。

Bug 1054780 - Gecko picks Segoe UI Emoji over Segoe UI Symbols on Windows 8.1, leading to colored (and not-CSS-color-alterable) symbols

今のコードだとBMP外とSymbolのコードポイントの場合にSegoe UI Emojiの優先順位を上げているんだけど (該当する文字を持つフォントがCSSで指定されていない場合)、いくつかの記号がSegoe UI Emojiに含まれるから、これはカラーじゃないほうがいいんじゃないのって話だ。

これは好みが発生するところでもあるし、また、いろんな都合で逆にデフォルトがカラー絵文字になるほうがいいということもある (例: モバイル)。確かに、U+2xxxの文字はやりすぎなのもしれない。

ということで、CSS Fonts ModuleのエディタのJohnさんと議論をしたんだけど、そもそもCSSでコントロールすべきかもしれないよねってことで、Johnさんがこのような提案をするに至った。

• [css-fonts] selecting color or monochrome glyphs for emoji fonts
• [css-fonts] new generic font 'emoji'

ちなみに、議論中に日本の絵文字で存在してたアニメーションつきのフォントの場合にアニメーションを止めるとかをどうするんだという話に派生したけど、それは今回の議論には入れない。

XPS12のSSDを載せ替えた

デルのXPS12を買って一年以上経つのだけど、思ったよりSSDの容量が足りなかったし、保証も切れたので載せ替えた。

分解方法は、ftp://ftp.dell.com/Manuals/all-products/esuprt_laptop/esuprt_xps_laptop/xps-12-9q33_Owner%27s%20Manual_ja-jp.pdfにマニュアルがある。

ウルトラブックなのにmSATA載せ替え可能ってさすがDELLだった。互換バッテリとかってどっかつくってないのかな？。あとWireless LANのカードもMiniPCIぽかったので、おそらく載せ替え可能っぽい。

テスト

地図データの更新頻度

最近オフィスの近くにできる店のWebページを見て、面白いことに気づいた。

この店の地図を見ると、メルセデスベンツコネクションが交差点にあるということを書いてあるけど、実際の地図は

というように、メルセデスベンツコネクションは移転している。今まであったところは取り壊し工事中。Googleさすが。

実際ゼンリンのデータを更新されてないことが原因かと思うけど、元にBingなんかは、

こんな感じで古いデータのまま。

店の地図ってすごく重要な気がするんだけど、こういうところをチェックしない店もどうかと思うが、地図データの更新頻度は非常に大切なんだなと。同じ通りの近くに移転してるから、こういうパターンは迷うヤツだよね。交差点行っても見つからない！的な。

ちなみに、この交差点の前にあるビルに入っている会社を触れないってことは察しろ。

寿司の出来

寿司の出来で各OSのリッチさがわかるんじゃないかと思って、

iOS

Android 4.4

Windows Phone 8.1

iOSの勝ちだと思う。MicrosoftはカークランドのIzumiにでも行って、ちゃんとした寿司を食べるべきだね


おまけ。Twitter

Landed COLR/CPAL support to render Microsoft's color glyph format

2014/5/28版のNighlyからMicrosoftが提案しているカラーグリフフォーマットをサポートしたので (問題なければFirefox 32に含まれる)、その技術的な話を書こうかと。

Firefoxにおける文字ラスタライザは複数存在する。

• DirectWrite over Moz2D or Cairo (Windows)
• Windows GDI over Skia/Moz2D or Cairo (Windows)
• CoreGraphics over Moz2D or Cairo (OSX)
• FreeType over Cairo/Moz2D or Skia/Moz2D or Cairo (Linux, Android and Gonk/Firefox OS)

ただし、現在のFirefoxにおいては、ほとんどの描画をMoz2Dから行うので、純粋にCairoだけ描画されるパターンってのは通常では少ない。しいてあげればプリンタへの印刷だけ。

Firefoxでは文字をそのまま描画しているわけじゃなく、各ラスタライザはOpenTypeフォーマットのタグを解析して文字コードではなくグリフIDベースで描画しているため、そのまま文字列渡してOSのAPIで描画しているわけではない。また各種プラットフォーム用にラスタライザがいろいろ存在するため、CoreGraphicsのラスタライザであればApple形式のカラー絵文字が描画出来たり、FreeTypeのラスタライザであればAndroid形式のカラー絵文字の描画ができたりするなど、差異は存在している。

モダンブラウザではOpenTypeの機能をCSSからコントロールすることができる。 通常のOSの描画APIだけではCSSの規格で書かれていることが実現できないので、グリフレンダリングについてはより低レベルのAPIを利用している。低レベルAPIで描画が行われるので、各プラットフォーム間でほとんど表示できる機能が同じになっているのだけど、各ラスタライザの違いによってどうしても吸収できない差異に関しては若干存在はしている。

Color Glyph

今回サポートしたMicrosoftが提案しているカラー絵文字が使えるカラーグリフフォーマットというのはmpeg-OTspecに提案されているもので、投票次第になるけどおそらくISO規格として次のOpenTypeの規格に含まれるものになる予定。仕様書はmpeg-OTspecに登録すればダウンロード可能なので、誰でも入手は可能である。

また、他のフォーマット、AppleやAndroid 4.4+のフォーマットってのは単純に画像ファイル (PNG) をOpenTypeのあるテーブルに入れてそれを表示するって形式。画像ファイル持ってる場合は単純に作成可能なフォーマットだ。ただベクターフォントではないから、解像度が高いものを持つ必要がある。

また、ベクターフォントな形式としてSVG in OpenTypeってのもある。AdobeとMozillaが推している規格でFirefoxですでに利用可能になっている。これはOpenTypeのSVGテーブルにSVGを入れる形式になっていて文字としてSVGを表示できる。まさにSVG Font的なものだ。昔Acid3 Testに組み込まれていたSVG FontはおそらくSVG2で忘れ去られると思うよ。

今回のMicrosoftフォーマットはちょっと違うアイデアを利用してて、COLRテーブルとCPALテーブルの追加によってカラーグリフを提供しているということ。当然ベクターフォントである。

OpenTypeフォントってのは、CMAPテーブルで文字が一つのグリフIDにマッピングされててそのグリフIDで文字を示してる。今回のフォーマットはそのグリフIDに複数のグリフIDを割り当てて、しかも各グリフIDに色の情報を追加する仕組みになっっている。実際には、COLRテーブルには、元々のグリフIDに複数のグリフIDを割り当てられる仕組みを持っていて (BaseGlyphRecord)、またその複数のグリフIDには色を割り当てることができる (LayerRecord)。



こんな感じで一つの文字を表すのに複数のテーブルを使って文字を構成する。

このフォント形式はWindows 8.1からサポートされているのだけど重要なのはDirectWriteでしか扱えない仕組みになってる。なので従来のGDI形式の描画方式を使ったアプリケーションでは扱えない。 Windowsアプリケーションでカラー絵文字を扱いたかったらDirectWriteで描画しろってのがMicrosotの答えだ。

Render COLR/CPAL on Gecko

そろそろカラー絵文字のサポートを入れようかと考えた時、Firefoxの場合もDirectWriteラスタライザのみのサポートにしようかと考えていたのだが、結果としてOpenTypeフォントを解析すれば全プラットフォームのサポートできるんじゃない？って話になって全プラットフォームサポート可能な方向性で実装することになった。

また、描画テストを追加するためにダウンロードフォントでもこの形式をサポートするようにしている。

ダウンロードフォント利用する場合、FirefoxやChromeではotsと呼ぶサニタイザライブラリを利用している。otsはフォントデータを解析して、フォントファイルが正しいフォントかどうかをチェックして、知らないOpenTypeタグの削除したりする。ots用のサニタイザを書いてもよかったんだけど、Firefox側にサニタイザを別途用意することでフォントファイルの正確性をチェックしてる。WindowsのDirectWrite API (IDWriteFontFile::Analyze)でも同様のサニタイズをやってたりする。otsのサニタイザに関してはバグはファイルしておいたし、Google的にもやる方向で動くみたい。

なお、otsでAndroid形式のカラー絵文字のタグをサポートしてないから、FirefoxやChromeのAndroid版でダウンロードフォントでカラー絵文字が使えないって話もあるけどね！

まとめ

Firefoxではダウンロードフォントも同様にSVG in OpenTypeとMicrosoft's Color Glyphをサポートした。しかも全プラットフォームで利用可能になっている。なにか問題を発見したらbugzillaに報告してね！

David W. Chadwick先生のPKIの講演を聞いてきた

仕事がら、たまに証明書関連とかPKIのことに絡むことが多いのだけど、JPNIC主催でKent UniversityのDavid W. Chadwick先生がPKIの講演をするということで行ってきた。彼はX.500で有名な方だよね。

内容としてはX.509の現状とそれの問題点、その問題点をどう解消するか的な話なんだけど、現在だと証明書発行局が信頼できるかどうかなんてのはわからないし、実際いろんなプロセスを通じてブラウザはルート証明書を入れているけど、そのルート証明書を発行した機関は常にセキュアであるかなんてわかりはしない。DigiNotarの件が発生したプロセスを考えても、それを利用者が問題のあるプロセスが存在してたということを知る術がない。知るのは事件が発生した後だ。また問題がある証明書が存在してたとして、それを発行した会社やそのルート証明書を入れたベンダが利用者のリスクを担保してくれるわけでもない。そのため、発行機関等を信頼できるための別のメトリック・プロトコルが必要なのじゃないか的な話を解説してた。それをTrust Brokerという表現で示していた。

Chadwick先生が推奨してるTrust Brokerってモデルも難点があって、それをビジネスとして成り立たない場合にこれを運用することはないんじゃないかということ。個人的にはTrust Broker的なものはGoogleのような巨大なインターネット企業またはブラウザベンダーが用意するしかないような状況になるんじゃないかと考えるけどね

あとは、Web PKI Operation (WPKOPS)の活動についての話が興味をそそる話だった。WPKOPSでWeb PKIの使用状況について、どのように動作してて、また使われているのかを文書化する試みが行われていて、各ベンダーにアンケートを送っているが、クライアント側だとMozillaやComodoは回答済みで、GoogleとMicrosoftは回答作成中だとか、、サーバーベンダだと世界最大の某データベースベンダや、最近話題のOSSな某SSLライブラりは回答拒否だとか。そのため現状をまとめたドキュメントを作成するのがちょっと難しくなってるらしい。

この講演で触れられていたけど、FirefoxはCRLのサポートはすでに切っているので、証明書の取り消しはOCSPをサポートする必要がある。なので、ルート証明書をFirefoxに入れたいと思っているベンダはOCSPのサポートを行う必要がある。また、Chromeは失効リストをGoogleのクローラが集めてChromeに渡しているのでCRLやOCSPをサポートしない (社内のサーバーの場合失効リストを管理できないってこと？)。

authenticationとauthorisationの話とかも面白かったんだけど、まとめきれる内容はない。

という内容の濃い話だったんだけど、ここらに興味がある人が世の中に少ないんだろうなぁ。

Firefox Developers Conference 2014 in Kyotoのライトニングトークの資料

新幹線の中で書いただけの資料ですが、Firefox Developers Conference 2014 in Kyotoのライトニングトークで使ったものです。

Emoji from Makoto Kato

時間なかったから話せなかった話として、GoogleもChromeのWindows版でもMicrosoftフォーマットを使えるようにするかもしれないよってことも。

今年はLinuxデスクトップ以外はどのブラウザもほぼカラー絵文字が使えるようになるよ！ってことです。標準化は置いておいてね。

Rendering Color Emoji using Glyph with DirectWrite 1.2

Windows 8.1でカラー絵文字を表示するサンプルでTranslateColorGlyphRunを使ってグリフベースで書く方法が存在してないのでサンプルを書いた。



適当に書いたものなので動かないとは思うけど、使い方は参考になるはず。というか、Microsoft、TranslateColorGlyphRunを使ったサンプルくらい公開してよ。

emoji hell

絵文字は昔Emoticonsとか言ってたのにいつの間に世界標準語でemojiと呼ばれるようになったんだが、このフォント仕様のカオスさが面白い。たまに調べることがあるので自分用にまとめてみた。

現在主流のプラットフォームだと大体はカラー絵文字をサポートしてるのだが、すべてでサポートする仕様が異なる。どのプラットフォームもOpenTypeに新しいテーブルを追加することでサポートするようになってる。

Windows 8.1

COLRテーブルとCPALテーブルを利用。
http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/

ただしカラー絵文字を描画するには、DirectWriteのID2D1RenderTarget::DrawTextまたは、ID2D1RenderTarget::DrawTextLayout必須 (えっDrawGlyphRunではサポートしないの？) なため、IE11でもサポートされず。

なお、Glyphベースで描画するには、DWRITE_COLOR_GLYPH_RUN使えばいいらしいが。

Apple iOS / OSX 10.7

sbixテーブルを利用。そのままPNGが入ってる
http://typographica.org/typeface-reviews/apple-color-emoji/

10.7から追加されたCTFontDrawGlyphsを使うことで描画可能。CGContextShowGlyphsWithAdvancesの使用からCTFontDrawGlyphsに変えることで対応可能。

Google Android

CBDTテーブルとCBLCテーブルを利用。PNGとか非圧縮のビットマップが格納可能
https://color-emoji.googlecode.com/git/specification/v1.html

ただし、FreeType 2.5でサポートが入ってるため (from Google)、FreeTypeでレンダリングするようなアプリだとOS問わずサポート可能 (ビルドオプションの変更は必要)

Gnome 3.10 / GTK3.10 でのHiDPI

糞すぎ。スケールが整数単位だなんて、OSXの影響受けすぎでしょ、そんなにOSXマネするんだったらそれ使えばいいじゃん。

ってのは冗談で、GTK 3.10 で HiDPI とも呼ばれる DPIスケーリングがサポートされたのでその話。

去年の頭に 12インチのフルHD液晶のラップトップを買った関係で、DPIスケーリングをオンにして通常Windowsを使ってる。でFirefoxもHiDPIをサポートしているので、HiDPIをサポートしてないアプリは基本的に使いたくなくなった。

現在Windows上であってもHiDPIをまともにサポートしているブラウザはInternet ExplorerとFirefoxだけで、Chromeはいまだにサポートしてくれず (Issueはあるよ！)、Operaに至っては、OS標準のDPI Scalingをオフにしている関係で、かなり残念なことになってる。HiDPIで使ってるのに文字サイズが細かくなりすぎる。

OSX版だとみんなサポートしてくれてるんだけどね。

このDPIスケーリングはGTK3.10でやっとサポートされたため、Linuxのデスクトップでもやっと使うことができるんだが (でもスケールサイズは整数のみという残念仕様。cairo使ってるのに)、今日時点でどのブラウザもサポートできてない。GNOME標準のブラウザであってもだ！。

こんな感じでGTK3側で勝手に低解像度でスケールする仕組みになってるんだけど、せっかくcairo surfaceにそのまま描画しただけでは全然ダメだということがわかる。ChromeとFirefoxはGTK2アプリ (ChromeはAuraに移行予定らしい) なんだけど、組み込みコントロールによってスケールするしないがあって、非常に残念な結果になってる。GTK2だとすべてエミュレーションでいいのに中途半端なことし過ぎ。GTK3だとデフォで全部エミュレーション。

しかも、デフォルトで低解像度自動スケールなので、こっちがスケールしたくなくても勝手にスケールする羽目になる。調べるとcairo側にscaleするAPIを作ってそれを呼んでるらしいと。cairoへ描画してるのにピクセル単位での描画じゃなくて、スケール単位での描画なので残念な描画結果になる。GTK3の描画シグナルでスケールを無理やりオフにすると確かにスケールせずに描画できるけど、ウィンドウの高さと幅がスケール前の長さを返すので、変更が非常に面倒。Firefoxみたく内部でいろいろ計算しているアプリの場合は逆に自動スケールなんて機能が邪魔すぎる。

ということで、自動スケールをオフにするには、gdk_x11_display_set_window_scale()を呼び出してスケールを1にすればいいらしい。またGnome側が持ってるフォントサイズはスケールを考慮したサイズなので、gdk_screen_get_setting()で現在のスケール値を取得して、それを基してピクセルサイズを計算すればいいってことらしい。

昨日の夜中に突貫工事したヤツ。Work In Progress。

Firefoxだとスクロールバーなど各コントロールは自前で描画するんでその計算がまだ上手くいってない。そんな感じ。

Mozilla Location Service

現在、Firefox (デスクトップ版、モバイル版含めて) ではGoogleのLocation APIを利用して位置情報を取得しているんだけど、今テストでMozilla謹製のLocation Serviceをテストしてる。それがMozilla Location Serviceなんだけど、これの収集データの話について。

Firefox for AndroidのAuroraとNightlyのユーザーだと設定画面に以下のような「Mozilla位置情報サービス」ってものがある。

これだとどういうタイミングでデータ収集をしているかわからないのだけど、このサービス作ってるDougTが以下のように説明してる。

@EnglishMossop Nightly would only share when you do an HTML5 geolocation request. Mozsumbler is a tool to record Wi-Fi and cell around you

— Doug Turner (@dougturner) 2014, 1月 30

要は、「Mozilla位置情報サービス」を有効にすると、GeoLocation APIを利用したときにGPSとWiFiとCellの情報をMozillaのサーバーに送るよということ。なのでこれのプライバシーポリシーに同意しない場合は、有効にしないでほしい。

またこのデータ自体はMozilla Ichnaeaと呼ばれるAPIが提供されていて、実際GoogleのAPIとある程度互換性がある。様々な利用とかでGoogle APIを使いたくないのであれば、MozillaのAPIを使うことも可能だ。コードも公開されているのでライセンスを満たせばオレオレGeolocation Service Providerを立ち上げることもできる。データのSubmission APIのフォーマットも書いてあるのでどういうデータが送られるかということもそこのサイトを見ればわかる。

って感じだけど、ここからが本題。

Android版のAuroraとかNightlyを使っててGeoLocationを有効にするサービスなんて使っている人なんて、日本でおそらくすごく少ないので、現在のデータってのはデータ収集を匿名にしても匿名性は乏しくなる。

現在の日本の状況ってのはこんな感じ。もっとズームできるけど、、、えっといろんなものが特定できる気がするのであえてしません。(Webサイトから確認できるんで見たい人はそこを見ること)

東京大阪間の新幹線だけ充実してるというこの状況。なおヨーロッパとかサンフランシスコ近郊はデータが充実してるけどね！

データ収集にはこのFirefox for Android以外にMozStumblerというAndroidアプリがあって、これで詳細にマッピングが可能になってる。なのでこのLocation Serviceのデータがピンポイントに自宅を指している私みたいな人は家周辺および駅周辺をくまなくマッピングしてわからなくする必要がある気がする。削除したいのであればDougTに聞けばいいかと思うよ。

あと当然のことながらプライシー案件でもあるのでオプトアウト方法も存在する。詳しくはhttps://github.com/mozilla/MozStumbler/blob/master/src/org/mozilla/mozstumbler/SSIDBlockList.javaを見てくれればいいけど、Googleが推奨している_nomapを設定するのが一番いいかと思う。

なのでこの情報を送る場合はこういうことになるので理解して有効にするなり有効にしないなりしてほしい。

またGoogle、Apple以外の類似のサービスについてもhttps://wiki.mozilla.org/CloudServices/Location/Bootstrapにまとめてあるから、興味がある人は見るといいかもね。

Access-Control-Allow-Credentials

久々にhtml5とか勉強会に行ってみたんだけど、最後の質問の話。Access-Control-Allow-Credentialsについて。質問内容としては、XMLHttpRequest Level 2でクレデンシャルフラグがセットされた時にAccess-Control-Allow-Credentialsをtrueにしないとどうなるか。

スペックの部分はこういうことになってる。

7.2 Resource Sharing Check

1. If the response includes zero or more than one Access-Control-Allow-Origin header values, return fail and terminate this algorithm.
   
2. If the Access-Control-Allow-Origin header value is the "*" character and the omit credentials flag is set, return pass and terminate this algorithm.
   
3. If the value of Access-Control-Allow-Origin is not a case-sensitive match for the value of the Origin header as defined by its specification, return fail and terminate this algorithm.
   
4. If the omit credentials flag is unset and the response includes zero or more than one Access-Control-Allow-Credentials header values, return fail and terminate this algorithm.
   
5. If the omit credentials flag is unset and the Access-Control-Allow-Credentials header value is not a case-sensitive match for "true", return fail and terminate this algorithm.
   
6. Return pass.

ということでAccess-Control-Allow-Credentials: trueにしないとfailするってことらしい。ちなみにこれをレスポンスヘッダへ複数設定した場合もfailするとのこと