headers
David Goodger | 1 Mar 2004 02:05
Favicon

Re: Re: "blurbs"

Aahz wrote:
[Aahz]
 > Well, I don't want HTML to be the tail that wags the dog.  What do
 > you (plural -- this isn't David's responsibility) suggest other
 > writers do?

I describe in terms of HTML merely because I know it better than LaTeX
or OpenOffice.org XML.  Perhaps I should also describe in terms of
DocBook, which I know pretty well.  DocBook's "literallayout" element
applies well, except perhaps for line wrapping; it's similar to HTML's
"pre".  Perhaps "<simplelist type='vert' columns='1'>" would provide
the best rendering (although it could be considered misuse).

An alternative output approach for HTML would be to insert "<br />"
tags between lines, and other Writers could do the same thing in their
own way.  That doesn't handle nesting/indentation though.  DocBook
doesn't seem to have an equivalent to "<br />".

--

-- 
David Goodger                               http://python.net/~goodger
For hire: http://python.net/~goodger/cv

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Mar 2004 21:51
Picon
Picon
Favicon
Gravatar

Sprint/nested inline markup


I can't be at the sprint because I have to be on the other side of the
world (literally) at another conference.  That's why I sprinted by
myself, several weeks ago, on the problem of supporting nested inline
markup.  This is just a small and general appeal that someone hold a
sprint session on that code (in the "nesting" branch of CVS).  All of
the changes are in docutils/docutils/parsers/rst/states.py and in the
corresponding tests.  Dave G. has been understandably busy, and I'd
hate to see my work relegated to the dustbin of history...

Cheers,
Dave

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
Permalink | Reply | 2 comments |
headers
Mark Nodine | 1 Mar 2004 23:13
Picon

Re: Re: "blurbs"

David Goodger wrote:
> I understand where you're coming from.  I'm trying to figure out how
> "blurbs" (temporary name only!) fit in with the rest of the
> reStructuredText constructs and the Docutils doc tree.  They seem so
> similar to line blocks, and I see so little intrinsic "list-ness" that
> I'm loathe to add a new object.  Perhaps line blocks could be refined
> to add the two properties they currenly lack:
> 
> A) long lines wrap nicely
> B) HTML output doesn't look like program code in non-CSS web browsers

In my opinion, blurbs are significantly different from line blocks
because of these two issues.  Don't make point (B) HTML-specific;
a line-block should (IMO) be implemented as a monospaced font by
whatever writer, because I believe the intent is that things should
(mostly) line up in a line block (give or take the fact that inline
markup will add extra characters to some lines).

> First, syntax....
> Note that the "nested" list does not have nested syntax (the "|" are
> not further indented); the leading whitespace would still be
> significant somehow (more below).

I'm not happy with this proposal (more below).

>      | John Doe
>      | Founder, President, Chief Executive Officer, Cook, Bottle
>        Washer, and All-Round Great Guy
>      | SuperDuper Corp.
>      | jdoe <at> example.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Goodger | 2 Mar 2004 07:17
Favicon

Re: "blurbs"

[David Goodger]
 >> A) long lines wrap nicely
 >> B) HTML output doesn't look like program code in non-CSS web browsers

[Mark Nodine]
 > In my opinion, blurbs are significantly different from line blocks
 > because of these two issues.  Don't make point (B) HTML-specific;
 > a line-block should (IMO) be implemented as a monospaced font by
 > whatever writer, because I believe the intent is that things should
 > (mostly) line up in a line block (give or take the fact that inline
 > markup will add extra characters to some lines).

Are you perhaps confusing line blocks with literal blocks (or parsed
literal blocks)?  Line blocks, which are intended for addresses and
poems etc., have never used a monospaced typeface.  Only the
beginnings of lines have ever lined up in line blocks.  Literal
blocks, intended for program code examples and such, have always used
monospace.  Text can be expected to line up in literal blocks.

 >> First, syntax....
 >> Note that the "nested" list does not have nested syntax (the "|"
 >> are not further indented); the leading whitespace would still be
 >> significant somehow (more below).
 >
 > I'm not happy with this proposal (more below).

 > However, I wouldn't represent the rST syntax for this parse the
 > way you did.  I'd prefer something like ::
 >
 >      | But can a bee be said to be
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Goodger | 2 Mar 2004 07:35
Favicon

Re: Sprint/nested inline markup

David Abrahams wrote:
> I'd hate to see my work relegated to the dustbin of history...

It won't be, don't worry.  It may take a while, but eventually (if
nobody beats me to it) I **will** get to it.  The topic is already
listed for potential sprinting, and I've added a note about the branch
(http://www.python.org/cgi-bin/moinmoin/DocutilsSprint).

I would gladly support anyone who wants to sprint on this topic.

-- David Goodger

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
Permalink | Reply | 1 comment |
headers
David Goodger | 3 Mar 2004 01:38
Favicon

Re: "blurbs"

[Reply to off-list message, quoted with permission]

Mark Nodine wrote:
 > David Goodger wrote:
 >>
 >> [David Goodger]
 >>>> A) long lines wrap nicely
 >>>> B) HTML output doesn't look like program code in non-CSS web
 >>>> browsers
 >>
 >> [Mark Nodine]
 >>> In my opinion, blurbs are significantly different from line blocks
 >>> because of these two issues.  Don't make point (B) HTML-specific;
 >>> a line-block should (IMO) be implemented as a monospaced font by
 >>> whatever writer, because I believe the intent is that things
 >>> should (mostly) line up in a line block (give or take the fact
 >>> that inline markup will add extra characters to some lines).
 >>
 >> Are you perhaps confusing line blocks with literal blocks (or
 >> parsed literal blocks)?
 >
 > Mea culpa.  Yes, I was thinking of parsed literal.
 >
 >>>> I don't know what to do about even more complex line blocks:
 >>>>
 >>>>      |     Indented
 >>>>      | Not indented
 >>>>      |   Indented a bit
 >>>>      |     A bit more
 >>>>      |  Only one space
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Abrahams | 3 Mar 2004 17:53
Picon
Picon
Favicon
Gravatar

Re: Sprint/nested inline markup

David Goodger <goodger <at> python.org> writes:

> David Abrahams wrote:
>> I'd hate to see my work relegated to the dustbin of history...
>
> It won't be, don't worry.  It may take a while, but eventually (if
> nobody beats me to it) I **will** get to it.  The topic is already
> listed for potential sprinting, and I've added a note about the branch
> (http://www.python.org/cgi-bin/moinmoin/DocutilsSprint).

OK.  Do you understand the basic principle behind what I did?  

Wow, I now wish I had commented better.  Here goes a small attempt at
explanation:

See _push_end_string().  

When searching for a nested inline markup end-string, you also have to
be willing to find a new start-string, so the end-string pattern will
be based on the one used to find start strings.  We break the current
pattern up with comments '(?##)' so we can find the places to make
modifications.

Because of the way you want to respond to malformed input:

        a *b **c d* e** f

   grouped as:

        a *(b **c d)* e** f
(Continue reading)

Permalink | Reply | 0 comments |
headers
Moore, Paul | 4 Mar 2004 12:25

RE: Re: Sprint/nested inline markup

From: David Abrahams
> That's why you'll see allends being built as an expression like
>
>        y z? | z
>
> or
>
>        x (yz?|z)? | (yz?|z)
>
> or
>
>        w ( x(yz?|z)?|(yz?|z) ) | ( x(yz?|z)?|(yz?|z) )
>
>
> etc.  Unfortunately very complicated, but this is the only way to say:
>
>   match 'w?x?y?z?' but don't match the empty string.
>
> using Python regular expressions, AFAICT.

I'm not sure if it's better, but

    (?=w|x|y|z)w?x?y?z?

should work as well. Match w, x, y, or z but don't consume it. If you
have one, *then* match w?x?y?z? (which will pick up the bit that the
lookahead saw but didn't consume).

Paul
(Continue reading)

Permalink | Reply | 501 comments |
headers
David Abrahams | 4 Mar 2004 14:22
Picon
Picon
Favicon
Gravatar

Re: Re: Sprint/nested inline markup

"Moore, Paul" <Paul.Moore <at> atosorigin.com> writes:

> From: David Abrahams
>> That's why you'll see allends being built as an expression like
>>
>>        y z? | z
>>
>> or
>>
>>        x (yz?|z)? | (yz?|z)
>>
>> or
>>
>>        w ( x(yz?|z)?|(yz?|z) ) | ( x(yz?|z)?|(yz?|z) )
>>
>>
>> etc.  Unfortunately very complicated, but this is the only way to say:
>>
>>   match 'w?x?y?z?' but don't match the empty string.
>>
>> using Python regular expressions, AFAICT.
>
> I'm not sure if it's better, but
>
>     (?=w|x|y|z)w?x?y?z?
>
> should work as well. Match w, x, y, or z but don't consume it. If you
> have one, *then* match w?x?y?z? (which will pick up the bit that the
> lookahead saw but didn't consume).
(Continue reading)

Permalink | Reply | 501 comments |
headers
b.bum | 12 Mar 2004 08:21
Picon
Gravatar

Alternate CSS??


Anyone know of a repository of CSS aimed at publishing 
technical/scientific papers?

Compatible w/DocUtils would be ideal, but tweaking the classes is 
pretty trivial....

b.bum

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Permalink | Reply | 4 comments |

Gmane