Philipp Gesang wrote:

Hi Bill.

·········

...

Am I correct in thinking the rst module does not process the "class" and "container" directives? When I wrote the module I was working with the reST spec [0] and the syntax reference [1]. It’s been a while, but afair I implemented the spec completely (with the limitations described in the manual). It does not, to my knowledge, define the directives you mention and I don’t know what they’re supposed to do.

(Btw. like much of the spec, “container” and “class” sound suspiciously HTML-specific. If that is true, they address one output markup which happens to be -- not Context! I might find the time to add a simple wrapper for the container thingy (to boxes or framed?). However, I doubt that it’s possible to replicate the behavior of HTML divs + CSS without a larger effort [2]. In this case it might be preferable to have docutils generate some XML and directly typeset the result with Context.)

Best regards Philipp

Hi Philip The .class and .container direectives are certainly there with *ML in mind but I think there might be analog situatins in ConTeXt. .. class:: classname blah, blah, blah exists to stick a class name on the following element for styling with an external stylesheet of some sort. CSS/CSS3 are probably the primary examles but other XML-bases markus apply just as well .. class::classname blab, blab, blab could yield <p class=classname>blab, blab, blab</p> <h2 class=classname>blab. blab, blab</h2> or anything else that can take a class name attribute. .. container:: containername Foo, bar, baz bunch of stuff yields <div class=containername> foo, bar, baz bunch of stuff </div> I would think ",, class:: " ought to map quite well in ConTeXt: \setupsomething [classname] [attributelist] \startclassname Whatever \stopclassname for suitable values of "something" .. container:: probably maps to something like \frame[containername] although frames as such cannot cross page boundaries. Perhaps there is (or could be) a more suitable construct. I'm trying to be exemplary not directive. :) ConTeXt environment files are certainly analogus to CSS files and are used with the same end goals in mind. "styling" markup elements through "class=" or equivalent is rapidly becoming the order of the day for a wide variety of documents. Certainly (X)HTML, epub2, epub3, ODT, DOCX and an increasing horde of others are either there or heading there very soon. Am I way off base here? -- Bill Meahan Westland, Michigan USA

On Tue, 12 Mar 2013, Philipp Gesang wrote:

Nevertheless, I added some code to handle container directives: at the moment they simply map to macros of the same name. Existence of the macro is tested for at runtime, so you can place the definitions in your preamble. Example:

·································································

This is a paragraph.

.. container:: xyzzy

whatever

foo **bar** baz

This is another paragraph.

·································································

This will generate the output:

·································································

\startparagraph This is a paragraph. \stopparagraph

\ifcsname xyzzy\endcsname% \csname xyzzy\endcsname% {whatever foo {\sc bar} baz}% \else {whatever foo {\sc bar} baz}% \fi

\startparagraph This is another paragraph. \stopparagraph

·································································

A better way to handle this is to provide macros \startRSTcontainer ... \stopRSTcontainer and translate the above to \startRSTcontainer[xyzzy][...settings ....] .... \stopRSTcontainer It should be responsiblility of the document author to make sure that the containers work correctly. Depending on what containers are supposed to do (I have not read the links posted in this thread), providing such a container might be as simple as \let\startRSTcontainer=\startframedtext \let\stopRSTcontainer=\stopframedtext or \let\startRSTcontainer=\startparagraph \let\stopRSTcontainer=\stopparagraph Aditya

On Tue, 12 Mar 2013, Philipp Gesang wrote:

·········

...

On Tue, 12 Mar 2013, Philipp Gesang wrote:

A better way to handle this is to provide macros \startRSTcontainer ... \stopRSTcontainer and translate the above to

I considered adding a generator \defineRSTcontainer with the usual interface (e.g. [command=\framed,frame=on]). This won’t work because the output is supposed to be a self-contained document. The goal is for the output to consist of ordinary Context macros only so it can be imported without loading further code. (I’m undecided regarding the requirement of the “\RST...” prefix, though.)

Personally, I think that it is reasonable to expect the users to import a module.

Honestly, I have no idea. Depending on the style sheet a div can be a float or aligned or have a shaded background. The current approach leaves the implementation to the user.

Another option is to change the generated output to \start[xyzzy] .... \stop When the environment xyzzy exists, this is (supposed to be, see below) equivalent to \startxyzzy .... \stopxyzzy otherwise, this is equivalent to \bgroup .... \egroup This way, you maintain your goal of having output that runs out of the box, but at the same time generate readable code. It can then be left upto the user to define the xyzzy environment (Of course, this method does not support passing arguments to environment, but then neither does your proposed solution). @Hans, there is a bug in core-sys.mkiv: There is a missing \expandafter, and currentstartstop should be changed to m_syst_start_stop. \def\syst_start_yes[#1]% {\edef\m_syst_start_stop{#1}% \ifx\m_syst_start_stop\empty \let\syst_stop_indeed\donothing \else\ifcsname\e!start\m_syst_start_stop\endcsname \expandafter\let\expandafter\syst_stop_indeed\csname\e!stop\m_syst_start_stop\endcsname \csname\e!start\m_syst_start_stop\expandafter\expandafter\expandafter\endcsname \else \let\syst_stop_indeed\donothing \fi\fi} Aditya

Reposting this, as I think that it was missed in the previous thread. It is still present in the current beta. On Tue, 12 Mar 2013, Aditya Mahajan wrote:

@Hans, there is a bug in core-sys.mkiv: There is a missing \expandafter, and currentstartstop should be changed to m_syst_start_stop.

\def\syst_start_yes[#1]% {\edef\m_syst_start_stop{#1}% \ifx\m_syst_start_stop\empty \let\syst_stop_indeed\donothing \else\ifcsname\e!start\m_syst_start_stop\endcsname \expandafter\let\expandafter\syst_stop_indeed\csname\e!stop\m_syst_start_stop\endcsname \csname\e!start\m_syst_start_stop\expandafter\expandafter\expandafter\endcsname \else \let\syst_stop_indeed\donothing \fi\fi}

Aditya

·········

On Tue, 12 Mar 2013, Philipp Gesang wrote:

...

·········

...

On Tue, 12 Mar 2013, Philipp Gesang wrote:

A better way to handle this is to provide macros \startRSTcontainer ... \stopRSTcontainer and translate the above to

I considered adding a generator \defineRSTcontainer with the usual interface (e.g. [command=\framed,frame=on]). This won’t work because the output is supposed to be a self-contained document. The goal is for the output to consist of ordinary Context macros only so it can be imported without loading further code. (I’m undecided regarding the requirement of the “\RST...” prefix, though.)

Personally, I think that it is reasonable to expect the users to import a module.

...

Honestly, I have no idea. Depending on the style sheet a div can be a float or aligned or have a shaded background. The current approach leaves the implementation to the user.

Another option is to change the generated output to

\start[xyzzy] .... \stop

When the environment xyzzy exists, this is (supposed to be, see below) equivalent to

\startxyzzy .... \stopxyzzy

otherwise, this is equivalent to

\bgroup .... \egroup

Now that it’s fixed: Thanks for the pointer. I’ve been using \start...\stop as a synonym for grouping for ages but never realized it could take an argument. Philipp

On 3/14/2013 6:40 PM, Marco Patzer wrote:

On 2013–03–14 Philipp Gesang wrote:

...

I’ve been using \start...\stop as a synonym for grouping for ages but never realized it could take an argument.

You're not alone :)

I'm pretty sure that there's more that is unknown ... ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------