Index: jrst2/src/test/org/codelutin/jrst/textHeader.rst diff -u jrst2/src/test/org/codelutin/jrst/textHeader.rst:1.1 jrst2/src/test/org/codelutin/jrst/textHeader.rst:1.2 --- jrst2/src/test/org/codelutin/jrst/textHeader.rst:1.1 Mon May 14 14:41:07 2007 +++ jrst2/src/test/org/codelutin/jrst/textHeader.rst Wed May 23 17:16:20 2007 @@ -1,6 +1,7 @@ :authors: Benjamin POUSSIN ; Sylvain LETELLIER :organization: Code Lutin -:address: 6 chemin des Orans 44240 La Chapelle sur Erdre +:address: 6 chemin des Orans + 44240 La Chapelle sur Erdre :version: 2.1 :status: a finir :revision: 51 @@ -10,5 +11,3 @@ avec meme un para :copyright: © 2007. JRST - Code Lutin - GPL - ------------------- Index: jrst2/src/test/org/codelutin/jrst/test3.rst diff -u /dev/null jrst2/src/test/org/codelutin/jrst/test3.rst:1.5 --- /dev/null Wed May 23 17:16:25 2007 +++ jrst2/src/test/org/codelutin/jrst/test3.rst Wed May 23 17:16:20 2007 @@ -0,0 +1,93 @@ +====================== +Introduction to Prest +====================== +:Author: Mark Nodine +:Contact: mnodine@alum.mit.edu +:Revision: $Revision: 1.5 $ +:Date: $Date: 2007/05/23 17:16:20 $ +:Copyright: This document has been placed in the public domain. + +.. contents:: + +-------------- + Introduction +-------------- + +This document gives an introduction to the ``prest`` program, which is +a Perl implementation of a reStructuredText_ parser (and writers) and +gives a map of the documentation. + +.. _reStructuredText: http://docutils.sourceforge.net/rst.html + +reStructuredText_ is an easy-to-read, what-you-see-is-what-you-get +plaintext markup syntax and parser system. It is useful for inline +program documentation (such as Python docstrings), for quickly +creating simple web pages, and for standalone documents. This web +page was generated from reStructuredText. The original implementation +of a reStructuredText parser is that of the docutils_ project, written +in Python. The "prest" name is an acronym for "***P***\ erl +***reS***\ tructured\ ***T***\ ext". + +.. _docutils: http://docutils.sourceforge.net + +--------------- + Documentation +--------------- + +Since prest is a re-implementation of a reStructuredText parser, it has +diverged from the original Python version, both because the Python +version has made changes not tracked by the Perl version and because +the Perl version has added some innovations of its own. So the +documentation references have potentially three versions: the prest +version, the Docutils version, and a difference between the two. +The difference is based on the latest Docutils version available when +the prest documentation was compiled. + +======================================== ================= ==================== ====== +A ReStructuredText Primer `docutils version`__ +Quick reStructuredText `docutils version`__ +An Introduction to reStructuredText `prest version`__ `docutils version`__ diff__ +reStructuredText Markup Specification `prest version`__ `docutils version`__ diff__ +reStructuredText Directives `prest version`__ `docutils version`__ diff__ +reStructuredText Interpreted Text Roles `prest version`__ `docutils version`__ diff__ +Usage of Prest `prest version`__ +Internals of Prest `prest version`__ +How to Extend Prest `prest version`__ +Prest Release Notes `prest version`__ +======================================== ================= ==================== ====== + +__ http://docutils.sourceforge.net/docs/rst/quickstart.html + +__ http://docutils.sourceforge.net/docs/rst/quickref.html + +__ introduction.html +__ http://docutils.sourceforge.net/docs/ref/rst/introduction.html +__ introduction_diff.html + +__ reStructuredText.html +__ http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html +__ reStructuredText_diff.html + +__ directives.html +__ http://docutils.sourceforge.net/docs/ref/rst/directives.html +__ directives_diff.html + +__ roles.html +__ http://docutils.sourceforge.net/docs/ref/rst/roles.html +__ roles_diff.html + +__ prest_usage.html + +__ prest_internals.html + +__ prest_extend.html + +__ prest_releases.html + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + End: Index: jrst2/src/test/org/codelutin/jrst/test.rst diff -u /dev/null jrst2/src/test/org/codelutin/jrst/test.rst:1.5 --- /dev/null Wed May 23 17:16:25 2007 +++ jrst2/src/test/org/codelutin/jrst/test.rst Wed May 23 17:16:20 2007 @@ -0,0 +1,318 @@ +===================================== + An Introduction to reStructuredText +===================================== +------------------------------------------------- + Markup Syntax and Parser Component of Docutils +------------------------------------------------- + +:Author: David Goodger +:Contact: goodger@python.org +:Revision: $Revision: 1.5 $ +:Date: $Date: 2007/05/23 17:16:20 $ +:Copyright: This document has been placed in the public domain. + +reStructuredText_ is an easy-to-read, what-you-see-is-what-you-get +plaintext markup syntax and parser system. It is useful for inline +program documentation (such as Python docstrings), for quickly +creating simple web pages, and for standalone documents. +reStructuredText_ is a proposed revision and reinterpretation of the +StructuredText_ and Setext_ lightweight markup systems. + +reStructuredText is designed for extensibility for specific +application domains. Its parser is a component of Docutils_. + +This document defines the goals_ of reStructuredText and provides a +history_ of the project. It is written using the reStructuredText +markup, and therefore serves as an example of its use. For a gentle +introduction to using reStructuredText, please read `A +ReStructuredText Primer`_. The `Quick reStructuredText`_ user +reference is also useful. The `reStructuredText Markup +Specification`_ is the definitive reference. There is also an +analysis of the `Problems With StructuredText`_. + +ReStructuredText's web page is +http://docutils.sourceforge.net/rst.html. + +.. _reStructuredText: http://docutils.sourceforge.net/rst.html +.. _StructuredText: + http://www.zope.org/DevHome/Members/jim/StructuredTextWiki/FrontPage +.. _Setext: http://docutils.sourceforge.net/mirror/setext.html +.. _Docutils: http://docutils.sourceforge.net/ +.. _A ReStructuredText Primer: ../../user/rst/quickstart.html +.. _Quick reStructuredText: ../../user/rst/quickref.html +.. _reStructuredText Markup Specification: restructuredtext.html +.. _Problems with StructuredText: ../../dev/rst/problems.html + +.. contents:: + +Goals +===== + +The primary goal of reStructuredText_ is to define a markup syntax for +use in Python docstrings and other documentation domains, that is +readable and simple, yet powerful enough for non-trivial use. The +intended purpose of the reStructuredText markup is twofold: + +- the establishment of a set of standard conventions allowing the + expression of structure within plaintext, and + +- the conversion of such documents into useful structured data + formats. + +The secondary goal of reStructuredText is to be accepted by the Python +community (by way of being blessed by PythonLabs and the BDFL [#]_) as +a standard for Python inline documentation (possibly one of several +standards, to account for taste). + +.. [#] Python's creator and "Benevolent Dictator For Life", + Guido van Rossum. + +To clarify the primary goal, here are specific design goals, in order, +beginning with the most important: + +1. Readable. The marked-up text must be easy to read without any + prior knowledge of the markup language. It should be as easily + read in raw form as in processed form. + +2. Unobtrusive. The markup that is used should be as simple and + unobtrusive as possible. The simplicity of markup constructs + should be roughly proportional to their frequency of use. The most + common constructs, with natural and obvious markup, should be the + simplest and most unobtrusive. Less common constructs, for which + there is no natural or obvious markup, should be distinctive. + +3. Unambiguous. The rules for markup must not be open for + interpretation. For any given input, there should be one and only + one possible output (including error output). + +4. Unsurprising. Markup constructs should not cause unexpected output + upon processing. As a fallback, there must be a way to prevent + unwanted markup processing when a markup construct is used in a + non-markup context (for example, when documenting the markup syntax + itself). + +5. Intuitive. Markup should be as obvious and easily remembered as + possible, for the author as well as for the reader. Constructs + should take their cues from such naturally occurring sources as + plaintext email messages, newsgroup postings, and text + documentation such as README.txt files. + +6. Easy. It should be easy to mark up text using any ordinary text + editor. + +7. Scalable. The markup should be applicable regardless of the length + of the text. + +8. Powerful. The markup should provide enough constructs to produce a + reasonably rich structured document. + +9. Language-neutral. The markup should apply to multiple natural (as + well as artificial) languages, not only English. + +10. Extensible. The markup should provide a simple syntax and + interface for adding more complex general markup, and custom + markup. + +11. Output-format-neutral. The markup will be appropriate for + processing to multiple output formats, and will not be biased + toward any particular format. + +The design goals above were used as criteria for accepting or +rejecting syntax, or selecting between alternatives. + +It is emphatically *not* the goal of reStructuredText to define +docstring semantics, such as docstring contents or docstring length. +These issues are orthogonal to the markup syntax and beyond the scope +of this specification. + +Also, it is not the goal of reStructuredText to maintain compatibility +with StructuredText_ or Setext_. reStructuredText shamelessly steals +their great ideas and ignores the not-so-great. + +Author's note: + + Due to the nature of the problem we're trying to solve (or, + perhaps, due to the nature of the proposed solution), the above + goals unavoidably conflict. I have tried to extract and distill + the wisdom accumulated over the years in the Python Doc-SIG_ + mailing list and elsewhere, to come up with a coherent and + consistent set of syntax rules, and the above goals by which to + measure them. + + There will inevitably be people who disagree with my particular + choices. Some desire finer control over their markup, others + prefer less. Some are concerned with very short docstrings, + others with full-length documents. This specification is an + effort to provide a reasonably rich set of markup constructs in a + reasonably simple form, that should satisfy a reasonably large + group of reasonable people. + + --David Goodger (goodger@python.org), 2001-04-20 + +.. _Doc-SIG: http://www.python.org/sigs/doc-sig/ + + +History +======= + +reStructuredText_, the specification, is based on StructuredText_ and +Setext_. StructuredText was developed by Jim Fulton of `Zope +Corporation`_ (formerly Digital Creations) and first released in 1996. +It is now released as a part of the open-source "Z Object Publishing +Environment" (ZOPE_). Ian Feldman's and Tony Sanders' earlier Setext_ +specification was either an influence on StructuredText or, by their +similarities, at least evidence of the correctness of this approach. + +I discovered StructuredText_ in late 1999 while searching for a way to +document the Python modules in one of my projects. Version 1.1 of +StructuredText was included in Daniel Larsson's pythondoc_. Although +I was not able to get pythondoc to work for me, I found StructuredText +to be almost ideal for my needs. I joined the Python Doc-SIG_ +(Documentation Special Interest Group) mailing list and found an +ongoing discussion of the shortcomings of the StructuredText +"standard". This discussion has been going on since the inception of +the mailing list in 1996, and possibly predates it. + +I decided to modify the original module with my own extensions and +some suggested by the Doc-SIG members. I soon realized that the +module was not written with extension in mind, so I embarked upon a +general reworking, including adapting it to the "re" regular +expression module (the original inspiration for the name of this +project). Soon after I completed the modifications, I discovered that +StructuredText.py was up to version 1.23 in the ZOPE distribution. +Implementing the new syntax extensions from version 1.23 proved to be +an exercise in frustration, as the complexity of the module had become +overwhelming. + +In 2000, development on StructuredTextNG_ ("Next Generation") began at +`Zope Corporation`_ (then Digital Creations). It seems to have many +improvements, but still suffers from many of the problems of classic +StructuredText. + +I decided that a complete rewrite was in order, and even started a +`reStructuredText SourceForge project`_ (now inactive). My +motivations (the "itches" I aim to "scratch") are as follows: + +- I need a standard format for inline documentation of the programs I + write. This inline documentation has to be convertible to other + useful formats, such as HTML. I believe many others have the same + need. + +- I believe in the Setext/StructuredText idea and want to help + formalize the standard. However, I feel the current specifications + and implementations have flaws that desperately need fixing. + +- reStructuredText could form part of the foundation for a + documentation extraction and processing system, greatly benefitting + Python. But it is only a part, not the whole. reStructuredText is + a markup language specification and a reference parser + implementation, but it does not aspire to be the entire system. I + don't want reStructuredText or a hypothetical Python documentation + processor to die stillborn because of over-ambition. + +- Most of all, I want to help ease the documentation chore, the bane + of many a programmer. + +Unfortunately I was sidetracked and stopped working on this project. +In November 2000 I made the time to enumerate the problems of +StructuredText and possible solutions, and complete the first draft of +a specification. This first draft was posted to the Doc-SIG in three +parts: + +- `A Plan for Structured Text`__ +- `Problems With StructuredText`__ +- `reStructuredText: Revised Structured Text Specification`__ + +__ http://mail.python.org/pipermail/doc-sig/2000-November/001239.html +__ http://mail.python.org/pipermail/doc-sig/2000-November/001240.html +__ http://mail.python.org/pipermail/doc-sig/2000-November/001241.html + +In March 2001 a flurry of activity on the Doc-SIG spurred me to +further revise and refine my specification, the result of which you +are now reading. An offshoot of the reStructuredText project has been +the realization that a single markup scheme, no matter how well +thought out, may not be enough. In order to tame the endless debates +on Doc-SIG, a flexible `Docstring Processing System framework`_ needed +to be constructed. This framework has become the more important of +the two projects; reStructuredText_ has found its place as one +possible choice for a single component of the larger framework. + +The project web site and the first project release were rolled out in +June 2001, including posting the second draft of the spec [#spec-2]_ +and the first draft of PEPs 256, 257, and 258 [#peps-1]_ to the +Doc-SIG. These documents and the project implementation proceeded to +evolve at a rapid pace. Implementation history details can be found +in the `project history file`_. + +In November 2001, the reStructuredText parser was nearing completion. +Development of the parser continued with the addition of small +convenience features, improvements to the syntax, the filling in of +gaps, and bug fixes. After a long holiday break, in early 2002 most +development moved over to the other Docutils components, the +"Readers", "Writers", and "Transforms". A "standalone" reader +(processes standalone text file documents) was completed in February, +and a basic HTML writer (producing HTML 4.01, using CSS-1) was +completed in early March. + +`PEP 287`_, "reStructuredText Standard Docstring Format", was created +to formally propose reStructuredText as a standard format for Python +docstrings, PEPs, and other files. It was first posted to +comp.lang.python_ and the Python-dev_ mailing list on 2002-04-02. + +Version 0.4 of the reStructuredText__ and `Docstring Processing +System`_ projects were released in April 2002. The two projects were +immediately merged, renamed to "Docutils_", and a 0.1 release soon +followed. + +.. __: `reStructuredText SourceForge project`_ + +.. [#spec-2] The second draft of the spec: + + - `An Introduction to reStructuredText`__ + - `Problems With StructuredText`__ + - `reStructuredText Markup Specification`__ + - `Python Extensions to the reStructuredText Markup Specification`__ + + __ http://mail.python.org/pipermail/doc-sig/2001-June/001858.html + __ http://mail.python.org/pipermail/doc-sig/2001-June/001859.html + __ http://mail.python.org/pipermail/doc-sig/2001-June/001860.html + __ http://mail.python.org/pipermail/doc-sig/2001-June/001861.html + +.. [#peps-1] First drafts of the PEPs: + + - `PEP 256: Docstring Processing System Framework`__ + - `PEP 258: DPS Generic Implementation Details`__ + - `PEP 257: Docstring Conventions`__ + + Current working versions of the PEPs can be found in + http://docutils.sourceforge.net/docs/peps/, and official versions + can be found in the `master PEP repository`_. + + __ http://mail.python.org/pipermail/doc-sig/2001-June/001855.html + __ http://mail.python.org/pipermail/doc-sig/2001-June/001856.html + __ http://mail.python.org/pipermail/doc-sig/2001-June/001857.html + + +.. _Zope Corporation: http://www.zope.com +.. _ZOPE: http://www.zope.org +.. _reStructuredText SourceForge project: + http://structuredtext.sourceforge.net/ +.. _pythondoc: http://starship.python.net/crew/danilo/pythondoc/ +.. _StructuredTextNG: + http://www.zope.org/DevHome/Members/jim/StructuredTextWiki/StructuredTextNG +.. _project history file: ../../../HISTORY.html +.. _PEP 287: ../../peps/pep-0287.html +.. _Docstring Processing System framework: ../../peps/pep-0256.html +.. _comp.lang.python: news:comp.lang.python +.. _Python-dev: http://mail.python.org/pipermail/python-dev/ +.. _Docstring Processing System: http://docstring.sourceforge.net/ +.. _master PEP repository: http://www.python.org/peps/ + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + End: Index: jrst2/src/test/org/codelutin/jrst/GutterColor.java diff -u jrst2/src/test/org/codelutin/jrst/GutterColor.java:1.1 jrst2/src/test/org/codelutin/jrst/GutterColor.java:1.2 --- jrst2/src/test/org/codelutin/jrst/GutterColor.java:1.1 Tue May 22 09:24:00 2007 +++ jrst2/src/test/org/codelutin/jrst/GutterColor.java Wed May 23 17:16:20 2007 @@ -130,7 +130,7 @@ if (bColors.length>row+1){ if (bColors[row+1]){ g2d.setColor(Color.RED); - g2d.fill3DRect(1, i+3, 20, 15, false); + g2d.fill3DRect(1, i+3, rhWidth-4, 15, false); white=true; } Index: jrst2/src/test/org/codelutin/jrst/text.rst diff -u jrst2/src/test/org/codelutin/jrst/text.rst:1.17 jrst2/src/test/org/codelutin/jrst/text.rst:1.18 --- jrst2/src/test/org/codelutin/jrst/text.rst:1.17 Tue May 15 10:46:49 2007 +++ jrst2/src/test/org/codelutin/jrst/text.rst Wed May 23 17:16:20 2007 @@ -10,7 +10,11 @@ .. sectnum:: -.. contents:: sommaire + +------------------ + + +.. contents:: Sommaire :depth: 3 @@ -102,11 +106,11 @@ avec un autre para sur plusieurs lignes:: - + Et meme avec *des* ligne a - + preserver tel quelles sont @@ -132,7 +136,7 @@ Un autre encore plus mini qui ne sera pas afficher dans le sommaire ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' - + Litteral -------- @@ -190,7 +194,7 @@ ===== ===== ====== Inputs Output ------------ ------ - A B A or B + A B AorB ------------ ------ A B A or B ===== ===== ====== @@ -228,7 +232,7 @@ .. admonition:: And, by the way... You can make up your own admonition too. - + :field1: autre def1 :field2: autre def2 @@ -275,7 +279,7 @@ This theory, that is mine, is mine. -- Anne Elk (Miss) - + DOCTEST BLOCK ------------- @@ -284,7 +288,7 @@ LINE BLOC --------- - + | A one, two, a one two three four | | Half a bee, philosophically, @@ -316,33 +320,14 @@ .. header:: Ceci est une page de test +.. footer:: Cree par **LETELLIER Sylvain** + OPTION ------ --a Output all. --b Output both (this description is - quite long). --c arg Output just arg. ---long Output all day long. - --p This option has two paragraphs in the description. - This is the first. - - This is the second. Blank lines may be omitted between - options (as above) or left in (as here and below). - ---very-long-option A VMS-style option. Note the adjustment for - the required two spaces. - ---an-even-longer-option - The description can also start on the next line. - --2, --two This option has two variants. - --f FILE, --file=FILE These two options are synonyms; both have - arguments. - -/V A VMS/DOS-style option. +-a command-line option "a" +-1 file, --one=file, --two file + Multiple options with arguments. FOOTNOTES --------- @@ -356,14 +341,15 @@ [#]_ is a reference to footnote 3. + HYPERLINK --------- it's an anonymous-hyperlink__ and this one is an simple hyperlink_ -__ anonymous-hyperlink +__ http://www.google.fr -.. _hyperlink: www.google.fr +.. _hyperlink: http://www.google.fr COMMENT ------- @@ -383,7 +369,7 @@ /home/letellier/PROJET/jrst2/src/test/org/codelutin/jrst/textLiteral.txt la derniere ligne. - + Index: jrst2/src/test/org/codelutin/jrst/definition.rst diff -u /dev/null jrst2/src/test/org/codelutin/jrst/definition.rst:1.1 --- /dev/null Wed May 23 17:16:26 2007 +++ jrst2/src/test/org/codelutin/jrst/definition.rst Wed May 23 17:16:20 2007 @@ -0,0 +1,14 @@ +term 1 + Definition 1. + +term 2 + Definition 2, paragraph 1. + + Definition 2, paragraph 2. + +term 3 : classifier + Definition 3. + +term 4 : classifier one : classifier two + Definition 4. + Index: jrst2/src/test/org/codelutin/jrst/testEntier.rst diff -u /dev/null jrst2/src/test/org/codelutin/jrst/testEntier.rst:1.1 --- /dev/null Wed May 23 17:16:26 2007 +++ jrst2/src/test/org/codelutin/jrst/testEntier.rst Wed May 23 17:16:20 2007 @@ -0,0 +1,382 @@ +============== +Le grand titre +============== + +---------- + subtitle +---------- + +:authors: Benjamin POUSSIN ; Sylvain LETELLIER +:organization: Code Lutin +:address: 6 chemin des Orans + 44240 La Chapelle sur Erdre +:version: 2.1 +:status: a finir +:revision: 51 +:date: $date: 28/10/2006$ +:Un champs: au milieu + de null part + + avec meme un para +:copyright: © 2007. JRST - Code Lutin - GPL + +------------------ + +.. sectnum:: + +.. contents:: sommaire + :depth: 3 + + + +L'abstract de l'article + +Le premier titre +================ + +Un paragraphe + +Un autre paragraphe + +Un sous titre +------------- + +Un para de la sous section + +Un autre sous titre +------------------- + +Un autre para + +Le *deuxime* titre +================== + +*avec* un para sur **plusieurs +ligne** histoire de *voir* + +et un autre ``para aussi **sur +plusieurs lignes** mais sans gras`` + +LISTES +------ + +- une petite liste +- qui contient +- plusieurs elements + et meme sur plusieur ligne + + voir meme avec plusieurs paragraphe + et des liens http://www.codelutin.com + + encore un petit + +- et la suite de la liste +- pour finir + +3. et meme + +4. des enum + +#. pour voir + +I) de tout + +II) sorte + +(a) pour tout + +(b) tester + +(#) vraiment tout + +FIELD +----- + +:un peu: de field + ca ne fait pas + de mal + + +:field1: avec un + petit texte + + - et meme un + - debut + - de list +:field2: todo + +DEFINITIONS +----------- + +un autre mot + une autre definition + +le mot : la classe + la definition + + avec un autre para + sur plusieurs lignes:: + + Et meme + avec *des* + ligne a + + preserver + tel quelles + sont + +le mot : la classe 1 : la classe 2 + la definition + + +SEPARATION +---------- + +avant + +----------------------------- + +apres + +Un tire +------- + +Un mini titre +~~~~~~~~~~~~~ + +Un autre encore plus mini qui ne sera pas afficher dans le sommaire +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +Litteral +-------- + +:: + + public int unread(String [] lines, boolean addNewLine) { + int result = 0; + for (String line : lines) { + result += unread(line, addNewLine); + } + return result; + } + +un para 0 + + un para pluie + de 2 + +TABLE COMPLEXE +-------------- + ++------------------------+------------+----------+----------+ +| Header row, column 1 | Header 2 | Header 3 | Header 4 | +| (header rows optional) | | | | ++========================+============+==========+==========+ +| body row 1, column 1 | column 2 | column 3 | column 4 | ++------------------------+------------+----------+----------+ +| body row 2 | Cells may span columns. | ++------------------------+------------+---------------------+ +| body row 3 | Cells may | - Table cells | ++------------------------+ span rows. | - contain | +| body row 4 | | - body elements. | ++------------------------+------------+---------------------+ + ++------------------------+------------+---------------------+ +| body row 3 | Cells may | - Table cells | ++------------------------+ span rows. | - contain | +| body row 4 | | - body elements. | ++------------------------+------------+---------------------+ + +TABLE SIMPLE +------------ + +================ ============================================================ +Bullet list * items begin with "-", "+", or "*" +Enumerated list 1. items use any variation of "1.", "A)", and "(i)" + #. also auto-enumerated +Definition list Term is flush-left : optional classifier + Definition is indented, no blank line between +Field list :field name: field body +Option list -o at least 2 spaces between option & description +================ ============================================================ + + +===== ===== ====== + Inputs Output +------------ ------ + A B AorB +------------ ------ + A B A or B +===== ===== ====== +False False Second column of row 1. +True False Second column of row 2. +True 2 - Second column of row 3. + - Second item in bullet + list (row 3, column 2). +===== ===== ====== + +IMAGE +----- + +The |the big: biohazard| symbol must be used on containers used to dispose of medical waste. + +.. |the big: biohazard| image:: biohazard.png + +LIEN INLINE +----------- + +Une *petit* phare `pour avoir `_ un lien inline + +FIELD +----- + +:field1: def1 +:field2: def2 + +:field1: autre def1 +:field2: autre def2 + +ADMONITIONS +----------- + +.. admonition:: And, by the way... + + You can make up your own admonition too. + + :field1: autre def1 + :field2: autre def2 + +.. Attention:: All your base are belong to us. + You can make + +.. WARNING::The "raw" role is a stop-gap measure allowing the author to bypass:: + reStructuredText's markup. It is a "power-user" feature that + should not be overused or abused. The use of "raw" ties documents + to specific output formats and makes them less portable. + + If you often need to use "raw"-derived interpreted text roles or + the "raw" directive, that is a sign either of overuse/abuse or that + functionality may be missing from reStructuredText. Please + describe your situation in a message to the Docutils-users mailing + list. + + +.. admonition:: The "raw" role is a stop-gap measure allowing the author to bypass:: + reStructuredText's markup. It is a "power-user" feature that + should not be overused or abused. The use of "raw" ties documents + to specific output formats and makes them less portable. + + If you often need to use "raw"-derived interpreted text roles or + the "raw" directive, that is a sign either of overuse/abuse or that + functionality may be missing from reStructuredText. Please + describe your situation in a message to the Docutils-users mailing + list. + + + +.. Attention:: Derrière toi c'est horrible ! + + +.. admonition:: Ceci est un avertissement. + + Je vous demande de vous arrêtez. + +BLOCK QUOTE +----------- + +As a great paleontologist once said, + + This theory, that is mine, is mine. + + -- Anne Elk (Miss) + +DOCTEST BLOCK +------------- + +>>> print 'this is a Doctest block' +this is a Doctest block + +LINE BLOC +--------- + +| A one, two, a one two three four +| +| Half a bee, philosophically, +| must, *ipso facto*, half not be. +| But half the bee has got to be, +| *vis a vis* its entity. D'you see? +| +| But can a bee be said to be +| or not to be an entire bee, +| when half the bee is not a bee, +| due to some ancient injury? +| +| Singing... + +SIDEBAR +------- + +.. sidebar:: Title + :subtitle: If Desired + + Body. + +TOPIC +----- + +.. topic:: Title + + Body. + +.. header:: Ceci est une page de test + + +.. footer:: Cree par **LETELLIER Sylvain** + + +OPTION +------ + +-a command-line option "a" + -1 file, --one=file, --two file + Multiple options with arguments. + +FOOTNOTES +--------- + +[#]_ is a reference to footnote 1, and [#]_ is a reference to +footnote 2. + +.. [#] This is footnote 1. +.. [#] This is footnote 2. +.. [#] This is footnote 3. + +[#]_ is a reference to footnote 3. + +HYPERLINK +--------- + +it's an anonymous-hyperlink__ and this one is an simple hyperlink_ + +__ anonymous-hyperlink + +.. _hyperlink: www.google.fr + +COMMENT +------- + +.. + Ceci est un commentaire + +INLINE +------ + +``literal``, *emphasis*, **STRONG**, http://www.reference.com, letellier@codelutin.com + + +la derniere ligne. + + + + +