徒然なるままに

マルチプラットフォームなMarkdownエディタ Markdownを使うようになって、随分立つ。 Mac上ではkobitoやMouなどを試し、最終的にはMouにカスタマイズしたCSSを適用してPDFに吐き出している。 問題は、WindowsとLinuxの場合。 Windowsでは、Sublime Textで書いて、Markdown Preview Pluginを使用している。 ところが、LinuxではSublime Textの日本語入力がイマイチ（Pluginも入れているけれど、操作がひと手間増える）なので、最近はAtomを利用しつつある。 　少し前は、ReTextを使っていたのだけれど、CSSのカスタマイズが気持よくない。 ノート上のLinux（Ubuntu）は、CPUは遅めだけどSSDと大量のメモリのおかげで快適。でも、Atomはリソース消費が激しくて、起動にもたつく。 　DesktopのUbuntuでも起動は遅く、イラッとする。 会議の議事録や、メモなどは最近は、それぞれのマシン上で、すべてMarkdownで書いている。 それをDropboxやGoogleDrive、OneDriveで共有し、Mac上のMouでPDF化する流れ。 この最終出力が、iMacというだけで、少し面倒。 自宅で仕事しているときは、まあマシンを変えれば良いだけなので、それほど問題はない。 問題は、出先でノートを使用している場合。 一旦、自宅に帰ってMac上でMouにより最終のレンダリングを行わないと、同一の書式のPDFを得られない。 typoraを試した もちろん、Atomで書いてプレビューで作業・確認するのも、PDF出力さえなければ問題はない。 で、良い物はないかなぁ…と、いつも探している。 で、たまたま MOONGIFT で紹介されていた。 MacもWindowsもLinuxも対応している。 CSSも独自のものが使用できる。 あとは、操作感と速度。 試してみた。 Source Code Modeでこれまでと同じエディタでの作成になる。 もちろん、レンダリングした表示もOK さくさく、動作する。 もちろん、自分で

フォント指定で完了したはずだった 前回、ググって最低限の項目は設定したはずだったが、よく見るとまだ文字化けが残っていた。 キャプチャは、すでの修正済みなので正しく日本語が表示されているものの、最初は豆腐（□）だらけで…。少々残念。 さて、追加する項目は以下の通り。（ 前回の記事も参照 ） .bottom{     font-family: @font-family; } これで、文字化けは解消する。 自分で探す方法 いつも、こうやって資料が見つかればいいが、そうとは限らない。 Atomの場合、ソースコードがなくても自分で調べることが可能なので、やり方を書いておく。 メニュー→表示→開発→デベロッパーツールを選択（shift+ctrl+i） chromeと同じデベロッパーツールが表示される。（まぁベースが同じだから当たり前かw） エディタ部分もhtml+cssで処理されているので、該当箇所のタグとclass名などを探る。 スタイルシートに書き込むか、修正して表示を確認。 以上で、好きな箇所を好きな色・フォント・サイズなど触りたい放題です。 少なくともcssの知識が多少なりとも必要です。全く無いと難しいですけどね。 ubuntuでまともに動くエディタとなった 細かな修正をすることで、文字化けがなくなった。 画面構成はほぼsublime textと同じだし、色も調整可能で似たような雰囲気。 大きく異なるのは、日本語の入力がインラインで行えて、しかも「半角全角」キーでON・OFFが可能な点だ。 　変換も通常のmozcと同じ動作・表示なので違和感が全くないし、速度も早い。 Sublime Textの時は、mozc用のplugin（Sublime Mozc Input）を導入しても、結局は流用plugin（だったはず。）なので、やや操作性に問題があった。 　この改善点は大きく、日本語を扱う場合はsublime textよりもAtomの方が、快適になった。 　markdownのプレビューが表示できるし…。 codeを書くなら、sublime textの方が良い部分も有るので、使い分ければ良さそう。 もうしばらくは、日本語書き用として使

Atomがいい感じだったのに 少し前まではsublime textをメインで使用していたものの、使い勝手の良い物を探し続けている。 2013年の時点でBrackets の記事書いてたゎ… MacではSublimeとmiを多用し、UbuntuのNoteはAtomを使うようになってきた。 理由は簡単で、Ubuntu上のSublimeは日本語の入力に難があって、気持よく入力できないからだ。 もちろん、Mozc Inputを入れているけれど、使い勝手が悪い。 その点、AtomはUbuntu上で気持よく入力ができるので、最近使い続けている。 ところが、4月頃Update以降、日本語が正しく表示できなくなった。 日本語だけではなく、マルチバイトがどうもダメらしい。 すぐに修正されるだろうと思って待っていたが、一向に修正が出てこない。 実際仕事でも使用しているので、少々不便。 マークダウンのプレビューが全く表示できないのが辛い。 ちなみに、Windows上でのお気に入りはxyzzyというemacsライクなエディタです。 編集画面だけは直せた 環境設定→setting画面からFont Familyに日本語フォントを設定すれば、編集画面だけは日本語を表示してくれる。 とりあえず、これで作業はできるが、Markdown Previewが全くダメな点が、効率が悪い。 　出先ではNoteで書いて、自宅に帰ってMacでプレビュー確認しながらpdfを生成するところまでを行っているが、結構ミスをしていたりするので、書きながら確認できる方がありがたいんだけどね。 実際にはこんな感じで表示される。 左のTree Viewはフォルダ名、ファイル名が全て豆腐になるため、区別できない。 タブも豆腐で、だめ。 もちろん、Markdown Previewはひどい状態。 そこで、スタイルシートを自分で書けば直るとの情報を得て、試行錯誤しながら、ググりながら設定していく。 基本的にはCSSだがlessで書けるらしい。 要は、各スタイルに日本語のfont-familyを設定してやればOK。 フォントの設定だけしかしなかったのに、なぜか、Markdown Previewが黒バックに

準備通りに行かなかった件 専門学校でコマを受け持っていているんだけれども、HTML+PHP+MySQLの講義で、事前の準備とは裏腹に、予想を裏切る事柄があったので、今後のためにも…。 HTMLにCSSでレイアウトの説明をするために、いくつかサンプルを提示して、動作の確認を行わせている時のこと。 図のように、ブロック要素にfloatを設定して、後述の文章が回りこませる例を説明していた。 もちろん、事前にサンプルを作成し、正しく表示されることも確認済み。 そこで、文章は短いと回り込みが分からないので、適度にコピーで構わないから、テキストを入力するよう指示を行った。 ソースは以下の様に示して練習。 <p class="box1">box-1</p> <p class="box2">box-2</p> <p>文章が長い場合。…… </p> 殆どの学生は、同様なソースを作成し、フムフムと…。 しかも例示しているので、「文章が長い場合。」を連続して確認している。 ところが…。 1名だけ、動作がおかしいですと…。見ると、確かに回りこみはされず、しかも、改行を入れるとそこで改行されて表示される。 ソースをよく見たけど、設定に問題は無さそう。 そして、改行してみると<pre>でもないのに、改行されて表示される…。 chromeのDeveloper ToolでCSS等も確認してみたものの、何らサンプルと相違なし。もしやと思い、<p>aaaaaa…</p>を日本語に置き換えてみたら、正しく動作。 そう、サンプルが英字だけだったため問題が発生していたのだった。本来英語はスペースで単語を区切るため、スペースで回りこみを実行する。もちろんnowrap指定しない場合。 ところが、スペース無しで「a」だけを続けて入力したため、非常に長い単語と判断しているようだ…。改行を入れるとそこで、単語の区切りと認識するもののfloat指定したboxの隙間よりも単語が長いために、下に追いやられていたという事が判明。 おかげで、こちらも良い勉強になりましたわ。こちらの予想外のサンプルを作ってくれる学生のお