正直一個一個比較調査は辛いので、これをこういう風に使っていて非常に良い等の情報がありましたら教えてください(ぺこり
Smart ASCII 系
--------------
setextについて
http://www.age.ne.jp/x/sf/SETEXT/
reStructuredText
http://docutils.sourceforge.net/rst.html
dW : XML : XMLの論考 reStructuredText
http://www-6.ibm.com/jp/developerworks/xml/030411/j_x-matters24.html
plain2
http://shika.aist-nara.ac.jp/products/plain2/plain2-j.html
RFC2233-JP
http://rfc-jp.nic.ad.jp/rfc-jp/RFC2223-JP.txt
Daring Fireball: Markdown
http://daringfireball.net/projects/markdown/
http://www.triptico.com/software/grutatxt.html
EtText: Documentation: Contents
http://ettext.taint.org/doc/
Stx2any
http://www.sange.fi/~atehwa/cgi-bin/piki.cgi/stx2any
Almost Free Text
http://www.maplefish.com/todd/aft.html
AsciiDoc
http://www.methods.co.nz/asciidoc/
Almost Plain Text
http://www.xmlmind.com/aptconvert.html
atx, the true structured text format
http://www.aaronsw.com/2002/atx/
--------------
DocBook
http://www.docbook.org/
SmartDoc
http://www.asahi-net.or.jp/~dp8t-asm/java/tools/SmartDoc/index_ja.html
Simple Outline XML: SOX
http://www.langdale.com.au/SOX/
明示マークアップ系
--------------
Scratch -- A Simple Text Formatting Processor
http://scratchml.sourceforge.net/
Textism Tools Textile
http://www.textism.com/tools/textile/
TeX(というかLaTeX?)は明示マークアップ系だと思いますが、
専用スレが存在しているので引き合いに出す程度が無難かなーと思います。
pdf 化の過程で LaTeX に一回落とす処理系は割と多そうなので、ほっといても関連しますので。
参照サイトとかを提示すればいいってもんじゃないんだぞ
削除依頼だしてこいな
unix のゆの字もはいってねーしな
人が真面目に立てているのに取り合えずで片付けるのは失礼じゃないですか?
単発系のスレでこれだけのリンクをはって単発質問として発言した場合のことを少しでも想像して発言してますか？
脳髄反射な削除発言は自治じゃなくて自治厨だと思います。
>>8
踊れるなら初めから自分で(ry
で、板違いだというならどの板に立てればいいのでしょうか。
ソフトでもあるし、UNIX 由来のTeX, roff と一緒に語られることもあるし、Wiki や Blog の記法としてWeb系の板で語られることもあるし。
最終的にUNIX板にしたのはGoogleで各ツール名で検索したら Unix/Linux の2板が多かったからです。
何らかの妥当な根拠を持って他の板に誘導してください。
そういうのにいちいち反応してたらきりないですよ。
で。
Linux板にDocBookスレがあるけど、いまいち伸びてない。
他にメジャーは構造化テキストとなると TeX くらい?
HTMLは「構造」なのか、と言われると微妙だし。
という現状で、総合スレを普通に伸ばそうと思ったら、
1 の方向付けが鍵なのは確か。
専用スレのないフォーマット全般を扱うつもりなのか、
各フォーマットの比較みたいなことをやるのか。
個人的には、smart ascii 系がdiffしたり、cvsしたりするのに便利なので好き。
まぁ、unix板でいいんじゃないの。diffだのcvsだのgrepだのできて
喜ぶ連中がunix板以外にたくさんいるとは思えないし。
了解
>>15
あっち見てないのでここの方が嬉しい
> 専用スレのないフォーマット全般を扱うつもりなのか、
> 各フォーマットの比較みたいなことをやるのか。
正直どっちもやりたい（＾＾；
そんなに盛り上がらないだろうから話題を制限してもね。。。
>>12
WORD 等の文書は素材として使おうとするとすげーめんどくさいです。
sed とか awk とか perl とかでプログラマブルに加工できるのはすんげー魅力的です。
>>16
同意です。
明示的なマークアップはソフトウェアの処理に向いているのでiff(interchange file format)としては良いのですが、
人にはやさしくありません。。。
> 明示的なマークアップはソフトウェアの処理に向いているのでiff(interchange file format)としては良いのですが、
> 人にはやさしくありません。。。
確かに。
そこでWikiのような簡易記法が出てくるんだろうね。
読み手としては HTML/XML 系より読みやすいけど、書き手としては至極面倒。
なにより覚えにくい
入りやすさという意味では、HTMLみたいに特殊記号使う方がいいだろうね
マークアップしてるかしてないかが明確
Texinfoなら一応構造化テキストに入ると思うけど。
ネタが無いスレなのでいいんじゃない？
wikiはたしかに方言が多く統一感も無くて混乱するし、HTTPの制限からUIがダメダメで
書きにくいと感じていたけど、howmとかを使い込んで考えがかわったよ。
ていうか、マークアップしてるかしてないか明確なものがhtml/xml/texで、
その点に注目して明示的マークアップ系とsmart ascii系を分類したのじゃないのか。
smart asciiが明示的マークアップと一緒と思うのはどういう点で同一と感じるのさ?
変換後にどうマークアップされるかを思い浮かべると同じだと感じる。
変換するなら変換後のフォーマットの話であって、それは変換前の
フォーマットとは関係ないだろ?
一般的にはそうだね。>>23の前半でwikiの話をしていたので、>>24ではそれが
念頭にあった。wikiはHTMLにしかしないから。そう断っておくべきでした。
そんなに違いはないように感じる。
構文にオプションや属性を指定する節なんかを定義する事はできるだろうが、
Smart Ascii系でそういうのってあんまり使われてないよねぇ?
perlのB<POD>はどうよ。
=head2 書き易さ
Wikiと同じくらい。覚え易さもWikiと同じくらい。
=head2 汎用性
man、html、texinfo、TeXなんかに変換するのは楽だけど
YAMLのような汎用性は無い。
=cut
構造化テキストのフォーマットとしては、Wikiスタイルが今のとこベスト？
すまん忘れてくれ
ttp://www.xmlsmartdoc.org/
メリット
. xml なので、多い日も安心
. 数式を書くのが楽(TeX互換)
. 日本語OK
. tex, html, plain text変換
デメリット
. xmlなので、そのままでは読みにくいかも
. xmlなので、タグ書き面倒(HTMLと大差ないレベル)
. 便利に使い込もうと思うと、java, make(or ant) などの知識必須
. 凝ったPDFを出力しようと思ったら、それなりにTeXの知識がいる
TeXに慣れてるひと(書き貯めたスタイルファイルを無駄にしたくないとか、
数式はTeXじゃなきゃ書けないとか)が将来の文書ハンドリングの利便性に
不安を感じたときにオススメ
・閉じタグ必須で入力がHTMLの倍は面倒
・表現力が低い。パラグラフと箇条書きだけの文書なら使えるかもしれない
・一個の記述が複数のHTML記述に対応するとかの便利さもない
・図のサポートがいまいち。
やっぱり、はじめからLaTeXで書いた方が綺麗だし何より早いと思う
ま−でも、こういう自分言語って作る方は楽しいんだろうね
いままで書く所無かったんだよ。
俺の感想はだいたい>>33-34と似たようなものだな。
・レイアウトを凝る必要が無い。
・テキストが多い。
というのに向いてそう。
支援して貰うのが前提な希ガス。
ttp://docutils.sourceforge.net/
Purpose
The purpose of the Docutils project is to create a set of tools for
processing plaintext documentation into useful formats, such as
HTML, XML, and LaTeX. Support for the following sources has been implemented:
だそうな。
lighttpdのページを見てて発見した。
reStructuredText の機能を含むが、wiki markupやらRFC822な
メールファイルにも対応してるそうだ。
Pythonなのが俺的に微妙だけど、ちょっくら試してみる。
俺は最初からSmarDocファイルで文書のレイアウトをするのはあきらめてるから。
細かいレイアウトをしたい時は生成されたLaTeXファイルを直接編集してdiffをとっとく。
sdoc文書を編集した時も、たいていはpatchで何とかなる。
...という一連の作業をMakefileで自動化しているので、なかなか快適で離れられない。
まぁデメリットに関しては >>33 の言う通りかと思う。とくにインライン数式が面倒すぎ。
ともかく、sdocにあまり文書のレイアウト情報は入れない方が精神的にも楽。
まだ既出でない SmartASCII がごろごろしているのね(^^;
Wiki のフォーマットだと、「変換前のファイル」という風味が強すぎるんで。
後はRDとか。
・・・どっちもテーブルサポートがない奴だな(w
わかりやすい解説サイトを教えれ
こんなの情報整理スレでやってりゃ良かったんだよ。
後出しじゃんけん。
なくなってしまったので参照先はWayback Machine。
http://web.archive.org/web/20041011165213/http://cvs.m17n.org/~akr/markup
ますます、増えてないか。。。
マークアップのデファクトは DocBook な気がするけど、Smart ASCII のデファクトは決まらないのかなあ。。。
ttp://www.fiercewinds.net/siki/cgi/?Node=SikiFormat
正直微妙(w
あまりにも記号的すぎて自然な感が弱い。
>自然な感が弱い。
自然な感じだと、reStructuredText使うのが素直でしょうね……アレには敵わん。
ただ、あれだと後戻りが多くてパースするのが大変な気がするけど……どうなのかね？
Lightweight Markup Language という名称は定着するのかな
お手軽メモ書きに使って
打ち合わせ資料とかでそれっぽく変換できる
日本語をそれなりに扱える
いまのところ python 関連ということもあって
reStructuredText (docutils)使おうと思ってるんですけど
最近イケてるのって何かあるんですかね?
reST のさらに wrapper で kagipdf なるものも発見
(↑とりあえず日本語文書を扱うための wrapper みたいなもん?)
ワードパッド
構造化テキストで！＞＜
欲を言うならWinとLinuxでファイルを相互更新できたらいいな
これだからマクド使いは、、、
で、現状最有力は結局XMLなの？
早くデファクトスタンダードが決まって欲しい
setext-j を微拡張した感じ。とん挫した残骸みたいだけど
ttp://www.piedey.co.jp/xetext/
（ページの一番下です）
自動的に<dt>にアンカーをつける方法ってないのかな。
↓こんな風に書けば望み通りの出力が得られるんだけど、
定義名とアンカーで2回exampleを書くのがいやだ…
example_ は例です。
.. _example:
example
説明
example_ は例です。
example
説明
xmlで出して変換しろって言うけど、そっちもやっぱり面倒で。
変換するのが良いんじゃないかと思えて来た。何と言っても wiki
フォーマットは書く為のフォーマットであるというのがグッド。
XML みたいに入力量が増えたりしないし、そのくせ適度に構造化
されているし、インデントが適当でも後で幾らでも整形出来るし、
HTML に変換するのも容易いし、勿論 wiki にもアップ出来る。
特殊なエディタのサポートを必要としないと言うのも良いね。
後は wiki->txt のツールをちょちょっとでっち上げれば完了。
問題があるとすれば、どの wiki フォーマットを使うかかな。
1. reStructuredText
2. plain2
3. 自分で作る
おいらは自作したけどね。RubyでもreStructuredText使えればなぁ。
docutils をsystem()みたく呼べばいいだけってことではないの?
それに文脈自由文法にも興味あったんで、勉強がてら俺構造化テキストを設計してみました。
まあ、RDがあまりにもアレ過ぎるっつうのもあったんだけどね。
- 見出しの中で最大見出しが一番目立たない記法ってのはおかしいだろ。
- 整形ずみ文書を字下げで表現するのはいかがなものか。エディタの支援必須になっちゃうよね。
- ((●●●))というのが多過ぎ。「見た目の装飾」と「リンク」ぐらいは分けた方が良かったと思う。
とか。
・ここをこうすればLL(1)になるんじゃね？
・これだとこういう組合せで破綻するよ
とか教えて貰えると助かります。
ttp://fiercewinds.net/siki/pub/Siki/SikiFormat/
> 記述や修正に手間のかかることが多いです
俺も RST の問題はここだと思う。
Wiki 書法よりも読み易さを重視した結果だろうけど。
RST --> http://docutils.sourceforge.net/rst.html (reStructuredText)
REST --> http://ja.wikipedia.org/wiki/REST (Representational State Transfer)
拡張子は3文字信仰が多いから rst だけど、普通 reStructuredText を RST とは言わない.
ReST、reSTなどで大文字小文字で判別する.
そんな事どうでも良くない?
もしかして何でも決めつけたがりの人?
普通っていうほど普及してるもんでもないし、拡張子の話は誰もしていないし、
公式の URL は rst.html だし、ついでに言えばディレクトリも rst になっているし、
reStructuredText の仕様書中の例題も RST という略号を使用しているし、
Wikipedia でも一番最初に RST と書いてある。だから普通なのはむしろ RST
なんだと思うけど、君が ReST や reST と書いても俺は何の文句も言わないよ。
だって、こんな些細な事、普通はどうでも良いからね。
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html
> |RST|_ is a little annoying to type over and over, especially
> when writing about |RST| itself, and spelling out the
> bicapitalized word |RST| every time isn't really necessary for
> |RST| source readability.
>
> .. |RST| replace:: reStructuredText
> .. _RST: http://docutils.sourceforge.net/rst.html
http://ja.wikipedia.org/wiki/ReStructuredText
> reStructuredText は RST、reST、ReST と略されることもある。
それよりももっと意味のある話をしようぜ。
もともと日本語って読み手・聞き手が文脈から意味を補足するのを前提にしている言語だし。
＃述語中心の構成とか
そんなことよりも>82の評価 or もっと優れた構造テキストとの比較ヨロ
発端なのに真っ赤になって書くから…
というのはさておき
------
所詮 plain text なんだから章題を「目立たせる」方法ってそんなにないので
その辺りはあまり拘っても仕方ない気がする
ReST ってガンガン書いて自分なりのルールが決まればいいんだろうけど
第何番目のレベルはどの記号だったっけ? とかがビミョ〜に面倒
(第 n.m.k 節 って書き方を auto-numbering 出来ればちょっと楽かもしれない)
あとリストの入れ子について、インデントレベルを気にして書くのも
チョイ面倒だったかな(やり方を勘違いしているのかもしれないが)
>「4文字で書くな」と決めつけたのが発端
(・∀・)ﾆﾔﾆﾔ
yes といえばいいだけのところでわざわざ RST じゃなきゃと言わんがばかりに主張してるんだから
reStructuredText rest の検索結果 約 98,300 件中 1 - 10 件目 (0.22 秒)
reStructuredText rst の検索結果 約 74,400 件中 1 - 10 件目 (0.27 秒)
reST が当たり前だというほどではないけど、rst の方が少数派なのは確かっぽい
>所詮 plain text なんだから章題を「目立たせる」方法ってそんなにないので
reStructuredTextは目立っていると思うよ。
＃とか＄とかの字面の黒い文字使ってさらに強調する手もあるけど、あれで十分じゃない？
ただ、指摘の通りアシストツールがないと結局書けなくなるよな。
参考書片手でもいいけど、そうなるとお手軽さが無くなるし……
そういや全然別の話だけど、reStructuredTextて文脈自由文法に納まっていたっけ？
> 明らかに決め付けたがりの人がどっちかは明らか
そんなに真っ赤になって書かなくても良いよ
もう諦めたら?
ついでに rest は使用頻度の高い一般名詞でもある
Google の検索結果を鵜呑みにせず、そういう所にも気を使おう
reStructuredTextのラッパ(?)でsphinxというのが出てきたそうな。
http://sphinx.pocoo.org/
python2.6のドキュメント↓もsphinxを使ってるんだと。
http://docs.python.org/dev/
reStructuredTextからのpdf生成がもっと簡単に(latexに頼らずに)
できるようになったら、自分で文書書くときはwordと決別できそう
なんだけど…
それは同意
微妙に面倒なんだよねぇ。日本語っていうのもあるけど。
http://hooktail.org/computer/index.php?kagiPDF
http://sourceforge.jp/projects/kagipdf/
というラッパもあるんだけどこれで解決するのかしら?
最初から数式が使えるし、次のバージョンでは
要求仕様／設計結果対照表みたいな左右に並べるテーブルを
簡単に記述できるようになるみたいだし。
どっちもpythonで書かれているし、いっそのこと統合して欲しいもんじゃ。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
初心者もOK! FreeBSD質問スレッド その117 (128)
【２ちゃん発】ＲＦＣ作成計画 (266)
ＵＮＩＸって何？ (600)
UNIXってエロゲーできますか？ (165)
UNIXに関する言葉のひらがな読みスレッド (434)
ハッカー教育用CD-ROMを買ってみたんだが・・・ (129)
--log9.info------------------
著作権について教えろよ！ (370)
スキルのある人材募集 (298)
スタッフロールの是非について考える会 (184)
Ｐ２Ｐ接続で６人対戦のネットＳＴＧ◆SGTA (134)
爆サイ.com 2被害目 (112)
爆サイ.com part2 (107)
Share 成年コミック専用スレ 第596巻 (845)
Share 放映中新作アニメハッシュ保管スレ 158 (285)
【KMC】極悪 Kyo Music City 撲滅完了 238【毛虫】 (812)
【ny】巨乳パイズリ動画スレPart.96【洒落BT】 (493)
【洒落】ｴﾛｹﾞｰｽﾚｯﾄﾞ10270【Share】 (253)
Perfect Dark統合スレ Part34 (368)
フォント厨隔離スレ 11pt (747)
■■■BＴで拾えるエロ動画スレ part394■■■ (292)
【洒落】裏ｴﾛｹﾞｰｽﾚｯﾄﾞ1【share】 (513)
海外アップローダー総合★90 (113)
--log55.com------------------
クスッと笑ったorナイスと思ったレス紹介（ワッチョイ) Part1
【全板集合】2chにある無駄な知識を集めるスレ286
('(ﾟ∀ﾟ∩ どようび どようび〜 のガイドライン47
クスッと笑ったorナイスと思ったレス紹介 Part255
( ﾟдﾟ )こっち見るなのガイドライン84
【全板集合】2chにある無駄な知識を集めるスレ294
シグルイのガイドライン第陸拾捌景
コマンドーのガイドライン part248