headers
SourceForge.net | 6 Mar 2006 00:41
Picon
Favicon

[ docutils-Bugs-1443774 ] support unicode box characters for table markup

Bugs item #1443774, was opened at 2006-03-06 10:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=422030&aid=1443774&group_id=38414

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Trent W. Buck (trentbuck)
Assigned to: Nobody/Anonymous (nobody)
Summary: support unicode box characters for table markup

Initial Comment:
See first attachment.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=422030&aid=1443774&group_id=38414

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Olson | 8 Mar 2006 02:15
Picon

Potential LaTeX writer enhancements

I've been using reStrucutedText for a little bit now and like it a lot.
I've been generating html and pdfs via the latex writer.  There are a few
things that would make my life easier.  I can implement them myself, but
thought I'd get some feedback from you guys first to see if there is any
interest.

The first thing I would like to do is add a '--usepackages' option to the
rst2latex.py command line.  This is primarily because I greatly prefer the
times font to computer modern for onscreen reading.  I can't add the times
package via the raw directive because it needs to go in the preamble.  This
option would take the form '--usepackages=x,y,z' and would output:

/usepackage{x}
/usepackage{y}
/usepackage{z}

In the preamble.  I'm sure there are other benefits to having this option
other than changing the font.

The second thing I'm interested in doesn't have to do so much with latex per
se, but what happens when I generate both html and latex from the a source
document that includes .png files.  If I specify the height and width as
pixels, things look fine in the html document, but they're way too big in my
pdf output.  It looks like my latex generation is assuming that the image
should be 96 dpi, and decides (for example) that a 960 pixel wide image is
10 inches.  10 inches is too big for a normal sheet of letter paper, but 960
pixels isn't for the screen.  Now if I specify inches for the height and
width, it ends up shrinking the images and causing scaling ugliness in the
browser.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Toni Alatalo | 8 Mar 2006 14:47

Re: Potential LaTeX writer enhancements

On Wednesday 08 March 2006 02:15, Grant Olson wrote:

just a quick reaction

> I've been using reStrucutedText for a little bit now and like it a lot.
> I've been generating html and pdfs via the latex writer.  There are a few

me too - i in fact wrote my master thesis like that, and still have some
formatting to do, so am very glad to see activity in the area!

feel free to see http://an.org/gradu2/ - has both the source
http://www.an.org/gradu2/gradu2.rst and result
http://www.an.org/gradu2/gradu2.pdf - once the latex/pdf is finalized i will
put a html up too, but have not bothered with that yet (do trust it to work
well)

> The first thing I would like to do is add a '--usepackages' option to the
> rst2latex.py command line.  This is primarily because I greatly prefer the

why not .. altho i guess they can be in a conf file too or whatever.

> per se, but what happens when I generate both html and latex from the a
> source document that includes .png files.  If I specify the height and

ah that's a classic

> I'd appreciate any feedback you have to offer,

i have many other probs, like citations..
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan G Isaac | 8 Mar 2006 17:42
Picon
Favicon

Re[2]: Potential LaTeX writer enhancements

On Wed, 8 Mar 2006, Toni Alatalo apparently wrote: 
> i have many other probs, like citations.. 

Yes; the citation situation sucks.
Keys need to be understood as pointing to values
in a biblography, but for now they are just internal links.
This is a very serious problem.

You can get some mileage out of bibstuff's addrefs utility
http://www.pricklysoft.org/software/bibstuff.html

Good luck,
Alan Isaac

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
Grant Olson | 8 Mar 2006 23:48
Picon

RE: Potential LaTeX writer enhancements


> > option would take the form '--usepackages=x,y,z' and would output:
> >
> > /usepackage{x}
> > /usepackage{y}
> > /usepackage{z}
> 
> why cant you use the stylesheet option ?
> 

Chalk that one up to me being an idiot.  I swear I've tried to figure out
how to do this more than once and never got it.  I might send a doc patch
your way though.  Even after knowing that I was looking for something like
"restructuredtext latex stylesheet", google didn't return the best results.

-Grant

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
Felix Wiemann | 9 Mar 2006 22:32
Picon

Python compatibility (was: r4376 - in branches/directives/docutils/docutils/parsers/rst: __init__.py directives/__init__.py directives/html.py states.py)

fwiemann <at> users.berlios.de wrote:

> +False = 0
> +True = 1

IIRC we've had consensus that we want to drop Python 2.1 compatibility
with Docutils 0.5.  Are there any objections to requiring Python 2.2.1+
instead of 2.2+?  That would spare us from having to define True and
False in every module where it's used, because True and False were added
in 2.2.1.

--

-- 
For private mail please ensure that the header contains 'Felix Wiemann'.

"the number of contributors [...] is strongly and inversely correlated with the
number of hoops each project makes a contributing user go through."      -- ESR

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 2 comments |
headers
David Goodger | 9 Mar 2006 22:47
Favicon

Re: Python compatibility (was: r4376 - in branches/directives/docutils/docutils/parsers/rst: __init__.py directives/__init__.py directives/html.py states.py)

On 3/9/06, Felix Wiemann <Felix.Wiemann <at> gmx.net> wrote:
> fwiemann <at> users.berlios.de wrote:
>
> > +False = 0
> > +True = 1
>
> IIRC we've had consensus that we want to drop Python 2.1 compatibility
> with Docutils 0.5.  Are there any objections to requiring Python 2.2.1+
> instead of 2.2+?  That would spare us from having to define True and
> False in every module where it's used, because True and False were added
> in 2.2.1.

+1.  2.2.1 it is.
I was about to comment on that change anyhow. A better way to do it
would have been:

try:
    True
except NameError:
    True = 1
    False = 0

--
David Goodger <http://python.net/~goodger>
Permalink | Reply | 1 comment |
headers
Felix Wiemann | 9 Mar 2006 23:12
Picon

Refactoring the directive interface

(FYI, David and I have talked at PyCon about refactoring the directive
interface towards a more OO-oriented approach.)

I've created a directives branch::

    svn diff svn+ssh://svn.berlios.de/svnroot/repos/docutils/branches/directives -r4375:HEAD

I have added a "parsers.rst.Directive" base class on the "directives"
branch.  I didn't want to call it "parsers.rst.directives.Directive,
because I have the notion that the directives themselves are extensions
to reStructuredText (which just happen to be shipped with core Docutils)
and thus logically belong into a separate directory, whereas the
"Directive" interface is an extension point [1]_ which belongs to the
core of the reST parser.  After all, states.py knows about that
interface.

David, could you please have a look at the code?  If you think it's OK,
I'll refactor the rest of the directives.

.. [1] The term "extension point" is mentioned here:
   http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=286

--

-- 
For private mail please ensure that the header contains 'Felix Wiemann'.

"the number of contributors [...] is strongly and inversely correlated with the
number of hoops each project makes a contributing user go through."      -- ESR

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Goodger | 9 Mar 2006 23:30
Favicon

Re: Refactoring the directive interface

[Felix Wiemann]
> I have added a "parsers.rst.Directive" base class on the
> "directives" branch.  I didn't want to call it
> "parsers.rst.directives.Directive,
...

I thought about that too; your choice seems fine to me.

> David, could you please have a look at the code?  If you think it's
> OK, I'll refactor the rest of the directives.

The refactored directive looks fine.  So far it's just moving the code
out of a "directive" function into the Directive.run method, and
adding "self." as appropriate, right?

The modified docutils.rst.states.Body.parse_directive_block doesn't
support the new required_arguments, optional_arguments, &
final_argument_whitespace attributes yet though.  I'm sure you would
have discovered this quickly ;-)

--

-- 
David Goodger <http://python.net/~goodger>
Permalink | Reply | 1 comment |
headers
Beni Cherniavksy | 10 Mar 2006 15:43
Gravatar

Re: Python compatibility

David Goodger wrote:
> On 3/9/06, Felix Wiemann <Felix.Wiemann <at> gmx.net> wrote:
>> fwiemann <at> users.berlios.de wrote:
>>
>>> +False = 0
>>> +True = 1
>> IIRC we've had consensus that we want to drop Python 2.1 compatibility
>> with Docutils 0.5.  Are there any objections to requiring Python 2.2.1+
>> instead of 2.2+?  That would spare us from having to define True and
>> False in every module where it's used, because True and False were added
>> in 2.2.1.
> 
> +1.  2.2.1 it is.
> I was about to comment on that change anyhow. A better way to do it
> would have been:
> 
> try:
>     True
> except NameError:
>     True = 1
>     False = 0
> 
This one is not needed if we require 2.2.1.  But if we have any more
cruft like this, I think it's best to put it a module and just say::

     from docutils.backport import *

Then we can easily use newer features (`enumerate`, `set`, whatever) as
we wish.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane