docutils-develop — For developer discussions of the implementation.

[Docutils-develop] Re: Archives of this list

[Michael H. <mw...@py...>]

David Goodger <go...@py...> writes:

> Moore, Paul wrote:
> > (SF's new mailing list pages are a lot better than the old
> > ones, but still not ideal).
> 
> I find GMANE better still:
> 
> * http://news.gmane.org/thread.php?group=gmane.text.docutils.devel
> * http://news.gmane.org/thread.php?group=gmane.text.docutils.user
> * http://news.gmane.org/thread.php?group=gmane.text.docutils.cvs
> 
> But these only go back so far; they're not complete.

I presume *you* have most of the mails.  Gmane will add them for you.

...

OE for Mac?  Never mind that one, then :)

Cheers,
M.

-- 
  I don't have any special knowledge of all this. In fact, I made all
  the above up, in the hope that it corresponds to reality.
                                            -- Mark Carroll, ucam.chat

Re: [Docutils-develop] Re: Building the Docutils community

[Fred L. D. Jr. <fd...@ac...>]

Mark Nodine writes:
 >                              I'm leaning towards naming the
 > tool 'trip' (Transforming reStructuredText In Perl); 
 > unfortunately, the same acronym works for Python...

Or the names could be "tripper" (for Perl) and "trippy" (for Python).
;-)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

Re: [Docutils-develop] Re: Building the Docutils community

[Mark N. <no...@so...>]

David Goodger wrote:
> I agree that a tool or the tools should be installed.  But what should
> it (or they) be called?  What form should it/they take?  If we go the
> "rst2html.py" route, there may be many tools.  The other extreme would
> be a "docutils rst standalone html" tool.

I have opted for the Perl version of docutils to have a single
program that parses RST but can have many Writers. the default 
one of which produces HTML.  I'm leaning towards naming the
tool 'trip' (Transforming reStructuredText In Perl); 
unfortunately, the same acronym works for Python...

	--Mark

RE: [Docutils-develop] Archives of this list

[Moore, P. <Pau...@at...>]

From: David Goodger [mailto:go...@py...]
>> Is there anywhere a mbox-format archive of the list (and maybe also
>> docutils-users) that I could download and read offline at my leisure?

> I don't know of any.  Perhaps adding your voice to this feature =
request
> (or starting a new one) will make a difference:
> =
<http://sf.net/tracker/?func=3Ddetail&atid=3D350001&aid=3D312281&group_id=
=3D1>.

Done.
Paul.

Re: [Docutils-develop] German User Documentation

[David G. <go...@py...>]

[Diedrich Vorberg]
> Has anyone worked on a translation?

I don't think so.

> If not so I'd start working rightaway and translate "A
> ReStructuredText Primer" and "Quick reStructuredText".

That would be great!

> What format would be convenient?

[Richard Jones]
> I'd say it'd be best to keep the primer in ReST format (the original
> source is docs/rst/quickstart.txt).

Agreed.

> The Quick reStructuredText document would probably
> be too difficult to do in anything other than HTML.

ISTR discussing reworking quickref.html as reStructuredText a few months
ago.  A single directive (like, "rst-example") ought to be enough; it would
duplicate its input, one copy processed as a literal block and the other
processed as usual, and insert them in a specialized table.  But as I
recall, there are a few nasty edge cases, like section titles.

But simply translating the HTML would be fine for now.  Properly-translated
text is the important thing; we can always migrate the text to another
format later.

[Diedrich Vorberg]
> Whom do I have to contact to submit the files?

That would be me.  When you have something, please send it to me as a
tarball, and include the encoding of any files that have more than 7-bit
ASCII (put in comments in reStructuredText files).  Thanks!

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] German User Documentation

[Richard J. <rj...@ek...>]

On Mon, 13 Jan 2003 9:20 am, Diedrich Vorberg wrote:
> I need German user documentation for the re-Structured Text markup for
> a CMS (Zope/Plone) I am working on right now. Has anyone worked on a
> translation? If not so I'd start working rightaway and translate "A
> ReStructuredText Primer" and "Quick reStructuredText".
>
> What format would be convenient?

I'd say it'd be best to keep the primer in ReST format (the original source is 
docs/rst/quickstart.txt). The Quick reStructuredText document would probably 
be too difficult to do in anything other than HTML.


   Richard

Re: [Docutils-develop] DocFactory : effective parsing of text for faulty characters

[David G. <go...@py...>]

Pierre-Yves Delens wrote:
> Docfactory is nice enough to provide a debugger, but ...
> for so far as I can see, the debugger doesnt give the line number of the
> faulty character while parsing.

This is not a Docutils/DocFactory problem.  The behaviour comes from Python:

>>> u = '\n' * 10 + u'\u2020' + '\n'
>>> u
u'\n\n\n\n\n\n\n\n\n\n\u2020\n'
>>> s = u.encode('utf-8')
>>> s.decode('ascii')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII decoding error: ordinal not in range(128)

The Python UnicodeError doesn't tell us the line number of the faulty
character, so Docutils can't either.

> When working on heavy legacy texts, or texts provided by 3d party
> contributors (Word, Word on Mac ....) , it would be good to be able to
> pre-parse aga    inst some critical defaults, like encoding or characters sets
> problems.

You could always simply use this:

>>> filename = 'whatever'
>>> encoding = 'latin-1'
>>> open(filename, 'r').decode(encoding)

or:

>>> import codecs
>>> codecs.open(filename, 'r', encoding)

If you get an error, the file is not encoded properly.  If you don't get an
error, the file may still have problems:

>>> u = u'\u2020'
>>> u
u'\u2020'
>>> s = u.encode('utf-8')
>>> s.decode('latin-1')
u'\xe2\x80\xa0'

Basically, you have to know the encoding of your input file.  If you don't
know, it's not always possible to find out (at least, not with software).

> I searched the web with no result
> (although I do know some texttools modules ..)
> Do you know about tools or libs doing the parsing needed ?

No, sorry.

> But 1st of all, could you explain me :
> What is the very condition the parser should be able to parse against ?

I don't understand the question.

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

[Docutils-develop] German User Documentation

[Diedrich V. <die...@tu...>]

Hallo,

I need German user documentation for the re-Structured Text markup for
a CMS (Zope/Plone) I am working on right now. Has anyone worked on a
translation? If not so I'd start working rightaway and translate "A
ReStructuredText Primer" and "Quick reStructuredText".

What format would be convenient? Whom do I have to contact to submit 
the files?

Any input is very welcome...

Diedrich

Re: [Docutils-develop] Re: Building the Docutils community

[Richard J. <rj...@ek...>]

On Sat, 11 Jan 2003 3:07 pm, bb...@ma... wrote:
> I like the idea of a 'docutils' command that encapsulates the
> functionality.
>
> But I would do something like:
>
>      docutils [options] output [options] <format> [options]
>
> Where each [options] is specific to the noun/verb preceding it.

+1


> I wish I had more time.   But, the PyObjC project is quickly moving to
> using ReST for everything.   Including the web site.

I did this with Roundup at the prompting of Engelbert, and it's been a real 
help. Not everything is ReST, but the bulk (all documentation and some PR 
type documents).



     Richard

Re: [Docutils-develop] Re: Building the Docutils community

[<bb...@ma...>]

On Friday, Jan 10, 2003, at 20:32 US/Eastern, David Goodger wrote:
> So please take notes of the stumbling blocks you encounter and feed
> them back to the project, in whatever form.

Will do -- I'm going to do a code review of my writer to jog my 
memory....

>>      The current set of tools is relatively hard to use to someone
>> new to DocUtils.  The module doesn't self install into a directly
>> usable state [previous post covered that].  Easily fixed;
>
> I agree that a tool or the tools should be installed.  But what should
> it (or they) be called?  What form should it/they take?  If we go the
> "rst2html.py" route, there may be many tools.  The other extreme would
> be a "docutils rst standalone html" tool.  See
> <http://docutils.sf.net/spec/notes.html#front-end-tools>.

I like the idea of a 'docutils' command that encapsulates the 
functionality.

But I would do something like:

     docutils [options] output [options] <format> [options]

Where each [options] is specific to the noun/verb preceding it.

In the end, it doesn't really matter what is installed as long as it 
provides relatively easy access to the different outputs along with 
some decent debugging / structure analysis tools (like pseudoxml -- 
which is really just a writer?).

>>      - more conversion modules that "just work" (i.e. can handle all
>> of test.txt)
>
> I hope these will come with time & volunteers.  A how-to for Writer
> modules would be useful too.  Engelbert Gruber has some notes at
> <http://docutils.sf.net/sandbox/grubert/making_a_writer.html>.

Except that the 'The Simplest Writer' section is empty. :-)

Seriously -- that document has the potential to be very useful.

Engelbert:  If you don't mind, I would be willing to add some 
information to the document based on my experiences.

>> - an example that shows using a custom writer to produce a document
>> with a custom look-n-feel will help convince people that ReST is not
>> just for producing docs w/our look-n-feel, but they can do it
>> themselves
>
> Care to volunteer?

I wish I had more time.   But, the PyObjC project is quickly moving to 
using ReST for everything.   Including the web site.   We have a fairly 
nice look and feel for the site right now -- see pyobjc.sf.net -- but 
it is implemented in PHP [recycling at its best -- compare it to 
fink.sf.net].   We would like to move the site content-- at least, the 
documentation and examples sections (which haven't been implemented 
yet) to ReST.

At this point, it is just an idea and may be a bad one.

>> - some GUI tools.   I'll eventually build a ReST tool for OS X using
>> PyObjC and Cocoa...
>
> Have you looked at DocFactory yet (sandbox/gschwant/docfactory/)?  It
> has great promise.  It uses wxWindows, which I believe now works under
> OS X.

Will check it out....

b.bum

Re: [Docutils-develop] Archives of this list

[David G. <go...@py...>]

Moore, Paul wrote:
> (SF's new mailing list pages are a lot better than the old
> ones, but still not ideal).

I find GMANE better still:

* http://news.gmane.org/thread.php?group=gmane.text.docutils.devel
* http://news.gmane.org/thread.php?group=gmane.text.docutils.user
* http://news.gmane.org/thread.php?group=gmane.text.docutils.cvs

But these only go back so far; they're not complete.

> Is there anywhere a mbox-format archive of the list (and maybe also
> docutils-users) that I could download and read offline at my leisure?

I don't know of any.  Perhaps adding your voice to this feature request
(or starting a new one) will make a difference:
<http://sf.net/tracker/?func=detail&atid=350001&aid=312281&group_id=1>.

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] Re: Building the Docutils community

[David G. <go...@py...>]

Thank you, Bill, for your kind words of support.

Bill Bumgarner wrote:
> First -- the code:
> 
>      Yes-- the code is 'bad' in that it is hard to understand and
> hard to approach.  I was and still am fairly baffled by how the
> whole thing works.  I still have no clue why *my* settings broke
> when they are taken directly from html4css.py.
> 
>      But do not take that as a criticism.

Not at all -- I appreciate the input.  Specifics would be even more
appreciated: ask questions and I will answer, and those answers will
make their way into the docs.  I would really like to make the inner
workings of Docutils more easily understood.

Docutils *is* a complex system.  Having limited time, my approach has
been to write docs only when *I* have felt a need, internally or
externally.  Since I'm so close to the code, I can't see the
difficulties newcomers will have when trying to understand it.  I need
you and others to ask questions, which shows me where docs are needed.
Doc patches and new document contributions are even better.  When
Dethe Elza wrote a how-to on directives, it was great -- it
demonstrated a need and even suggested ways to improve the code.

So please take notes of the stumbling blocks you encounter and feed
them back to the project, in whatever form.

While I hope that the Docutils code complexity is actually inherent
and not only apparent or artificial, I know that there are many places
that could be cleaned up.  There's some code duplication and other
candidates for refactoring.

[I couldn't remember the opposite for "inherent complexity", Googled,
and found a link to `Out of Control` by Kevin Kelly, a book I read
many years ago.  Excellent book; I highly recommended it.  It's even
readable online: <http://www.kk.org/outofcontrol/>.]

> I will try to add documentation to the plain HTML writer
> in the coming days.

Great!

>      The current set of tools is relatively hard to use to someone
> new to DocUtils.  The module doesn't self install into a directly
> usable state [previous post covered that].  Easily fixed;

I agree that a tool or the tools should be installed.  But what should
it (or they) be called?  What form should it/they take?  If we go the
"rst2html.py" route, there may be many tools.  The other extreme would
be a "docutils rst standalone html" tool.  See
<http://docutils.sf.net/spec/notes.html#front-end-tools>.

>      - more conversion modules that "just work" (i.e. can handle all
> of test.txt)

I hope these will come with time & volunteers.  A how-to for Writer
modules would be useful too.  Engelbert Gruber has some notes at
<http://docutils.sf.net/sandbox/grubert/making_a_writer.html>.

> Finally, the whole thing needs spit and polish.  Not surprising --
> it is only version 0.2!

Sure.

> - once multiple writers are done, having the documentation / web
> site available in source + all other formats as an example would be
> helpful

Agreed.

> - an example that shows using a custom writer to produce a document
> with a custom look-n-feel will help convince people that ReST is not
> just for producing docs w/our look-n-feel, but they can do it
> themselves

Care to volunteer?

> - some GUI tools.   I'll eventually build a ReST tool for OS X using
> PyObjC and Cocoa...

Have you looked at DocFactory yet (sandbox/gschwant/docfactory/)?  It
has great promise.  It uses wxWindows, which I believe now works under
OS X.

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

[Docutils-develop] Archives of this list

[Moore, P. <Pau...@at...>]

I just discovered this list, and the fact that it has more going on than
the doc-sig list :-(

I'd like to browse some of the previous messages, so I don't rehash old
discussions if I start joining in, but I find reading mails via the
web painful (SF's new mailing list pages are a lot better than the old
ones, but still not ideal). Is there anywhere a mbox-format archive of
the list (and maybe also docutils-users) that I could download and read
offline at my leisure?

Thanks,
Paul.

[Docutils-develop] Re: Building the Docutils community

[<bb...@ma...>]

On Thursday, Jan 9, 2003, at 15:21 US/Eastern, 
doc...@li... wrote:
> In order to build a more active community around Docutils, should I be
> writing sloppier code?  I can see the relation: bad code in a good
> project generates bug reports and patches from potential contributors,
> and provides a gradual path to greater involvement.
>
> Or is my code bad enough already?

I'm probably at an ideal point in my experiences w/DocUtils to comment 
to this.   That is, I'm still fairly new to the project, but have 
tackled a relatively 'deep' problem (creating a Writer) and have been 
using ReST to document a number of different things and to write 
articles.

Good code in a modular project provides a much greater degree of 
plug-n-play extensions/contributions.  DocUtils does a great job at 
that -- look at the breadth of projects in the sandbox at this early 
stage of development!

First -- the code:

     Yes-- the code is 'bad' in that it is hard to understand and hard 
to approach.  I was and still am fairly baffled by how the whole thing 
works.  I still have no clue why *my* settings broke when they are 
taken directly from html4css.py.

     But do not take that as a criticism.

     What has become abundantly clear is that the problem DocUtils has 
solved [my success alone indicates to me that DocUtils is way beyond 
the 'attempt' stage] is a very difficult one -- and to solve it in a 
fashion that keeps the parsing, processing, and writing of the 
documents as well separated as the implementation indicates is quite an 
achievement.

     With everything that has been learned so far, maybe-- just maybe-- 
it could be razed and rewritten to something a bit more approachable... 
but not likely.  A better path is to provide some minimal, but useful, 
examples of how to do fairly common tasks.  To that end, I will try to 
add documentation to the plain HTML writer in the coming days.

     The idea is a 1.0beta -- the code is beyond 0.2, but not quite a 
0.9.

     Bottom line:   The code works and works pretty well.

Next-- the community:

     To build a community, we need to build momentum.  To build 
momentum, we need users.   To attract users, we need two things:

     - a much more approachable/usable ReST->Output engine

     The current set of tools is relatively hard to use to someone new 
to DocUtils.   The module doesn't self install into a directly usable 
state [previous post covered that].   Easily fixed;  if the module were 
'fixed' to work "out of the box" after 'python setup.py install', then 
it would make things like Fink, Debian, and RPM packages trivial to 
build-- immediately increasing the accessibility of the toolkit to 
almost every Linux or OS X users to a simple UI.   For windows and 
other platforms, it reduces installation to a single command.

     - more conversion modules that "just work" (i.e. can handle all of 
test.txt)

	I haven't run through the sandbox, but I know from playing with the 
PDF writer that it can currently only handle producing PDF from a very 
small subset of the overall ReST specification.   Not a criticism -- I 
have been through the process and fully appreciate the tedium required 
to create a fully capable writer (and I was only doing HTML, not 
something as complex as PDF).

     If we had fully compliant writers for Text, plain HTML, HTML + CSS, 
PDF or RTF, DocBook or some other form of XML, PseudoXML (excellent 
debugging tool), and maybe some variants or other formats, it would 
make comprehension of the value of the tool a lot easier to grasp.

     If the user can see a simple Text document turned into a beautiful 
PDF document, a readable HTML document, and a nicely formatted pure 
text document, they will immediately grasp the value of the tool!

Finally, the whole thing needs spit and polish.  Not surprising -- it 
is only version 0.2!

- once multiple writers are done, having the documentation / web site 
available in source + all other formats as an example would be helpful

- an example that shows using a custom writer to produce a document 
with a custom look-n-feel will help convince people that ReST is not 
just for producing docs w/our look-n-feel, but they can do it themselves

- some GUI tools.   I'll eventually build a ReST tool for OS X using 
PyObjC and Cocoa...

b.bum

  
    

[Docutils-develop] call for existing interpreted text art

[David G. <go...@py...>]

I am formulating a to-do list for interpreted text roles, and I would
like to include existing examples, as compatibly as possible (but no
guarantees).  The list so far is here:

    http://docutils.sf.net/spec/notes.html#interpreted-text

Could anybody who has written code for the old interpreted text
implementation, or written text actually *using* interpreted text,
please send me the code or examples?  Jason and Aahz, I believe you
have both done one or the other (could you answer the questions that I
asked in our last exchanges?).  Anybody else?

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

[Docutils-develop] Docutils update: "interpreted text" reimplemented

[David G. <go...@py...>]

I have checked in a preliminary reimplementation of the interpreted
text system.  A newly-expanded description of the interpreted text
implementation is here:

    http://docutils.sf.net/spec/notes.html#interpreted-text

A description of the "roles" currently supported is here:

    http://docutils.sf.net/spec/rst/interpreted.html

This change will break 3rd-party and sandbox code, as new doctree
elements (node types) have been introduced, with more to come.  The
core HTML writer will be kept up to date.

The snapshot has all the latest code:

    http://docutils.sf.net/docutils-snapshot.tgz

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] DocFactory : Special characters from Word files

[David G. <go...@py...>]

Pierre-Yves Delens wrote:
> ------------------
> Special characters
> ------------------
>=20
> further than setting the output-encoding to ISO-8859-1
> (OK for =E9=E0=E8 [éàè], ...)
>=20
> How can I manage the import of a Word Document containing some
> "? [€]", or "=91 [Œ]" ?

[I added XML character entities in brackets in case the encoding
gets messed up.]

Do you know the encoding of the Word document (or output)?  Set the
--input-encoding of Docutils to the same encoding and you should be
fine.  If it's Windows, CP1252 or similar may be it.

> The same problem is arising with some control characters from
> Windows, although we carefully import through a plain text editor
> first.

I can't help without specifics.

--=20
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] DocFactory : Newbie's Questions : Settings in conf file

[David G. <go...@py...>]

Pierre-Yves Delens wrote:
> ------------------
> docutils.conf
> ------------------
> When trying to edit a project's local docutils.conf file,
> I'm refering to the sourcefourge../docs/tools.htm,
> wich gives a table with entries AND commandline options.
> 
> I'm stuck when departing fom default settings : the commandline
> syntax --date, or date seems unsuitable for the conf file

The --date option actually changes the "datestamp" setting, which
contains a format string for Python's ``time.strftime``.  See the time
module documentation:

    http://www.python.org/doc/current/lib/module-time.html

(I've added this link to docs/tools.txt.)

There is no command-line option to directly pass a strftime-format
string.

> *********
> idem for
> ********* 
> 
> footnote_references = footnote-references
> footnote_references = --footnote-references

I don't understand this.  Please explain.

-- 
David Goodger  <go...@py...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] Building the Docutils community

[Aahz <aa...@py...>]

On Thu, Jan 09, 2003, David Goodger wrote:
> Aahz wrote:
>> On Wed, Jan 08, 2003, David Goodger wrote:
>>>
>>> Or is my code bad enough already?
>> 
>> Yes.
> 
> I appreciate the candor.
> 
>> -- 
>> Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/
>> 
>> There may or may not be a smiley above.
> 
> The question now is, was that last line intentional, or was Disraeli simply
> due for retirement?

Yes, it was intentional.  Seriously, I wouldn't call your code "bad", but
it is definitely difficult.  It's still not clear to me (even after
working with the code off-and-on for several months, mostly off) to what
extent that's simply due to the complexity of the problem you're trying
to solve versus design/documentation issues versus being incomplete and
rough versus Brooks's "write one to throw away".  One of these days I'll
get a better grip on XML in general; then I think I'll be able to better
evaluate what you're doing.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"I used to have a .sig but I found it impossible to please everyone..."  --SFJ

[Docutils-develop] DocFactory : effective parsing of text for faulty characters

[Pierre-Yves D. <py....@li...>]

Docfactory is nice enough to provide a debugger,
but ...
for so far as I can see, the debugger doesnt give the line number of the
faulty character while parsing.

So, is there a better setting about this ?

When working on heavy legacy texts, or texts provided by 3d party
contributors (Word, Word on Mac ....) , it would be good to be able to
pre-parse aga	inst some critical defaults, like encoding or characters sets
problems.

I searched the web with no result
(although I do know some texttools modules ..)
Do you know about tools or libs doing the parsing needed ?
But 1st of all, could you explain me :
What is the very condition the parser should be able to parse against ?

Thank you for your help

___________________________________________________
P-Y Delens, Manager

LIENTERFACES - PY Delens, sprl

Avenue Dolez, 243  -  1180   Bruxelles

phone : 32 2 375 55 62
fax :      32 2 374 75 74
mail :   py....@li...
web : www.lienterfaces.be
___________________________________________________

[Docutils-develop] DocFactory : Special characters from Word files

[Pierre-Yves D. <py....@li...>]

------------------
Special characters
------------------

further than setting the output-encoding to ISO-8859-1
(OK for =E9=E0=E8, ...)

How can I manage the import of a Word Document containing some "=80", or =
"=8C" ?

I was thinking all French problemw were OK with ISO-8859-1.

Do you know of a better encoding, for french ?

Sorry for this unspecific question, but perhaps there is a part of the
answer outside of the encoding option.

The same problem is arising with some control characters from Windows,
although we carefully import through a plain text editor first.

Thanks on forward

___________________________________________________
P-Y Delens, Manager

LIENTERFACES - PY Delens, sprl

Avenue Dolez, 243  -  1180   Bruxelles

phone : 32 2 375 55 62
fax :      32 2 374 75 74
mail :   py....@li...
web : www.lienterfaces.be
___________________________________________________

[Docutils-develop] DocFactory : Newbie's Questions : Settings in conf file

[Pierre-Yves D. <py....@li...>]

Bonjour,

------------------
docutils.conf
------------------
When trying to edit a project's local docutils.conf file,
I'm refering to the sourcefourge../docs/tools.htm, 
wich gives a table with entries AND commandline options.

I'm stuck when departing fom default settings : 
the commandline  syntax --date, or date seems unsuitable for the conf file

*********
idem for
********* 

footnote_references = footnote-references
footnote_references = --footnote-references

___________________________________________________
P-Y Delens, Manager

LIENTERFACES - PY Delens, sprl

Avenue Dolez, 243  -  1180   Bruxelles

phone : 32 2 375 55 62
fax :      32 2 374 75 74
mail :   py....@li...
web : www.lienterfaces.be
___________________________________________________
 

Re: [Docutils-develop] latex writer

[<gr...@us...>]

On Wed, 18 Dec 2002, Richard Jones wrote:

> On Wed, 18 Dec 2002 11:58 am, David Goodger wrote:
> > gr...@us... wrote:
> > > the generated pdf:
> > > http://docutils.sourceforge.net/sandbox/grubert/tools.pdf
> >
> > Looking good!
>
> I agree - great stuff. I've just run latex.py over the Roundup documentation -
> and it's come out looking really good (see http://roundup.sf.net/doc-0.5/). I
> can't run it over the cusomtizing.txt file because of the number of heading
> levels - it ends up generating a \subsubsubsection which there's no handler
> for.
>
> My other random comments:
>
> 1. There seems to be a missing line break in definition lists after the term,
>    possibly only when the definition is a list - for an example, see
>      http://roundup.sf.net/doc-0.5/features.pdf

this is a feature not a bug.
i think of definition and option lists as latex-description not as a table
and the description allows to continue on the same line. i like this more
for short texts for longer definitions it does no harm to have an extra
line break. must think about it.


> >  There are two things I notice though:
> >
> > 1. There's no vertical space between paragraphs in table cells.
>
> I'm not sure I have a problem with this. I think it looks OK as it is...
>

this seams to be a generic latex problem, i tried several directions but
without luck up to now.


-- 
 BINGO: a commitment to serving customer
 --- Engelbert Gruber -------+
 SSG Fintl,Gruber,Lassnig   /
 A6410 Telfs Untermarkt 9  /
 Tel. ++43-5262-64727 ----+

Re: [Docutils-develop] Building the Docutils community

[David G. <go...@py...>]

Aahz wrote:
> On Wed, Jan 08, 2003, David Goodger wrote:
>> Or is my code bad enough already?
> 
> Yes.

I appreciate the candor.

> -- 
> Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/
> 
> There may or may not be a smiley above.

The question now is, was that last line intentional, or was Disraeli simply
due for retirement?

-- David Goodger    go...@py...

Re: [Docutils-develop] Building the Docutils community

[Aahz <aa...@py...>]

On Wed, Jan 08, 2003, David Goodger wrote:
>
> Or is my code bad enough already?

Yes.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

There may or may not be a smiley above.