  |
はてなキーワード: docxとは
ファンレスCPUなので、長時間の連続運用は、特にこの季節は無理な場合もある。ファイルエクスプローラ程度でもCPUは高温となり場合によっては異常発生？
☀
64ビット化しWSLが導入できればMUAもCLI化できるし、エクスプローラも止めてbashで・・・ことができる。PDFファイルをずっと端末で眺めていると熱暴走可能性が
出てくるってことか？
☀
なるべく印刷するかもしくはEpub変換して電子リーダーで読めってことか？
☀
ブラウザだけはどうしようもないな。仕事でブラウザを長時間起動している状態ってのはサボっているって言い切れる？最近は○○などブラウザベースのものも多いし・・アップロードなどは、なるべく自宅で済ませろってことか？熱暴走覚悟でブラウズしろってことか？古いLinuxラップトップもFirefox起動はストレスフルだからな。。ストレスフリーなブラウズは・・スマホだけか？画面が狭くてストレスフルだろ？（セルフツッコミ）
☀
LINEで激しくやりとりするときは、WSLでLine-notify curl走らせろってことか・・
☀
WSLが導入されればTwitterはターミナルから可能となる・・ストレスフリーにつぶやける。右側に余計なものも表示されなくなるし（ ＾ω＾）・・・
☀
この前メールの添付文書でdocっていうワードファイルが送り付けられてきた。docxじゃなくてdocだよ！”！なに考えてんだ？pandocでmarkdown変換できねー！！クソ。
数式を含んだマークダウンからdocxへの変換をやっているがどうもマルチバイトだとバグが起こるようだ。英文だと問題ないが、日本人な宿命ゆえかマルチバイトも扱わねばならない。いっそのことソースをマークダウンからTex（テッフ）に変えちゃうか？変換先をdocxにするのは諦める必要がある。PDF一択か。Beamerを導入すれば一応スライドっぽいものも作れる。Latexmlを導入すれば、HTMLやEPUBに変換できるけど、当座数式を多く含んだ日本語文書の場合は、Beamerで良いのでそうすっか？LinuxマシンへのLatex導入は、迷う余地なしとしてもだ・・
来る日も来る日も工作人みたいな仕事（仕事と言えるのか？）疲れる。マルチバイトと相性が悪い！！inline mathとの混在が・・ダメダメだ。といって全部英語に翻訳する気力もないし（ ＾ω＾）・・・2時間だよ！！2時間も今朝こんなことに費やした。文字化けバグ除去に（ ＾ω＾）・・・もう本当ダメだな！！！＿|￣|○・・いろいろ大変だよなぁ・・・そんなことなら最初からM＄Word立ち上げてそっちで入力したほうが早いなぁ。そうだろ？どうしてもMDで保存してリポジトリに入れときたいなら、それこそdocx→md変換すればいいし・・・・
そうして、検索性を高めておこ。データベース性というべきか？文字だけしか含んでないDocx文書なんてそのままの形式で保存する意味なかろう。ただ日本文化というか奇習でしかないのだが、無意味に表組がなされているので、そのままMD変換すると、うっとおしい罫線が入りまくり、可視性が悪くなるんだよな。何とかならんもんか？Excel方眼紙よりは一億倍くらいマシだけども・・・むかしむかし表組だけを消滅させて、中身のテキストは残すVBAを書いたような気もするがあれどこいったんだろな・・・
コードブロックのところに、＄マークで囲って、docx変換してみよぅ。その後は全部TDだからSMの書籍はオフィスに差し戻せる（移動できる）。次の出勤日に携えヨーテボリ！！！！お灸でも据えてゴロゴロしたいなぁ。朝からだるい。まだ7時半前か？朝ごはんの食べ過ぎが原因のダルビッシュか？今日は木曜か？明日は金曜だなぁ。報告書の件ちっと専用サイトにアクセスし、個々のフォームに書き込まず（心の中で何をここは書き込むかだけイメージを膨らます）っていうシミュレーションやってみヨーテボリ。白紙を目の前にして申請テーマ2件思いつくようにしヨーテボリ。なんかやりたいことある？AFMは？○○番号を調べてみようよ。偶奇でなんか法則があるかもシレッサ。（じゃなくて・・イレッサ）
sourceを所持することの幸せ
--------------------------
htmlでもmarkdownでもいいけど、sourceを所持できるのは幸せだ。いかようにできる。Docxに変換して小冊子印刷もできるし、epubに変換して電子リーダーで読むこともできる。いかにしてsourceを入手するか？ホムペにアクセスするとか。本当は入手したPDFをmarkdownに変換したい。プレーンなテキストなら可能だけど、markdownとかRTFとかは無理だよな。無理ゲー？プログラミング言語系のsourceは、ギリシャ文字が使われないからよい。これがDLとかMLとかそっち系になると数式が入ってくるからギリシャ文字が来る。ギリシャ文字は文字化けする可能性細川たかし。ギリシャ文字問題なんとかしてくれ！数式は諦める。TeXニシャンだった過去を生かして手入力するわ
markdown からdocxへの変換だけど図面のサイズ指定が効かない。
似たような話がブログで展開されていた。この場合は変換先（中間状態）がTeXなので、プリアンブルに書くというテクニックが使える。
https://adbird.hatenablog.com/entry/2018/02/09/212646
考えてみたら、報告書や書籍のために作る図面だってInkscapeやGnuPlotでも仕上がりのサイズ考えて出力するし（ ＾ω＾）・・・ここはこだわるべきではないかと・・
プレゼンスライドをmarkdownから作ろうとしているが、javascriptとか学習してると間に合わないので、現実的な妥協案としてpandocでdocxに変換することにした。MSワードで最終的に改ページコマンドとかちょこちょこ追加すればOKだろうと思ってたが、なんかうまくいかない！
📽
図を挿入するとすぐ改ページしたがるのは、なぜ？図がデカいのか？ソース側にこまごまと(うるさい姑さんみたく){width=..cm}って指定する必要性？こういうのやっぱりパワポに慣れ親しんでるとダメだ。人間が劣化してきていると言えよう。
📽
やっぱりソース側で改ページを指定したくなってきた。lua-filterとかいうのがあるらしい。cabalやらなきゃいけないとかだったら やだやだやだやだ😩なぁ。pandocはとても良いけどfilter導入が難しいんだよなぁ。つい最近までcite-procでコケていた。chocolateyにpandoc cite-procのインストーラーが登録されてやっとできるようになった。
📽
pandoc-plotとかいうフィルターも便利そうだけど、インストーラーがなくて「cabalからどうぞ」。∴これも挫折中。javascriptに慣れ親しんでないからreveal.js導入できなくて、MSワード絡みで苦しんだり・（ ＾ω＾）・・・部下が出してきたパワポファイルを手作業でmarkdown化したり・・こう・・・なんというかシステマティックじゃないんだよなぁ。＞俺
📽
プロジェクトごとにGITリポジトリ作成し、1つのマスターmarkdownから報告書用・マニュアル用・仕様書用・設計書用・月報用・季報用・発表スライド用・・・てな感じでブランチングさせていければいいのだが・・pandoc, plantuml, graphvizとか駆使すれば（ ＾ω＾）・・・原理的にはできるはず
For example,
ポスター発表しなければならない。
デカいレイアウト設定して図とかテキストボックスを貼付していく
他で作った口頭講演用のパワポスライドたちを大きな紙もしくは布に印刷。
再利用性と言うことを考えると後者だが、脱パワポを計画している昨今これは採れない。というか前者なんて論外だ。
見出しや小見出しを追加し、文章を削ったり箇条書きにしたりしてから、pandocでdocxに変換。MSワードでページ区切りを設定し直し。これが現実解？
PDF化すると背景が白にならない問題があるらしいけど、reveal.js自体のインストールにすら成功してないのでなんとも（ ＾ω＾）・・・reveal.jsの学習（環境設定）コストは見合うものがあるか？
遺書といっても本当の遺書ではない。理由なく毎日ただ漠然と死にたいので、いつ死んでも平気なよう、仕事の引き継ぎのメモを「遺書」と呼んで、今年度からつど書きながら仕事している。
仕事の中身をつぶさに記録していくたびに、社会人としての私の存在価値がたった1個、多くとも数メガバイトのdocxファイルに移っていく。
月が終わり、「◯月」の欄が埋まるたびに、スカスカした達成感がある。
私は多分、自殺をしないと思うし、事故や病気で夭折することも、なんとなく叶わない気がしている。
でも、こいつがあれば、私はいつでも存在価値をただのデータに取って代わられるようなゾンビになれる。いつ死んでもいいし、生きていてもいいし、でも、死んでも困らない存在になる。
案外悪くないなと思うのだ。
