You can subscribe to this list here.
Showing
7
results of 7
<html>
<head>
</head>
<body>
<p align="center"><font style="font-size: 11pt" face="Courier">Did you miss out on NNCO, UP 233% IN JUST 2 DAYS?</font></p>
<p align="center"><font style="font-size: 11pt" face="Courier">If so, Here's another pick - Another Short Play</font></p>
<p align="center"><b><a href="">CLICK HERE</a></b></p>
<p align="center"><img border="0" src=""></p>
<p align="left"> </p>
<p align="left"> </p>
<p align="center"><font size="2">I no longer wish to receive your newsletter <a href="mailto:notforme2002@...?subject=takeoff"><b>click here</b></a></font></p>
</body>
</html>
pebhbbitdcsbwkdwupypicsrswbycuwyia
On 22 October 2002, David Goodger said:
> The sources on the web site still say "Docutils 0.2.4". The current
> version is 0.2.7. Not pushed out yet?
Correct -- I'm just playing on my development web server.
> You can set the <tt> style back to its initial value::
>
> tt { background-color: transparent }
Yup, that works.
> In fact, I think I'll remove the "a.target" style from the project's
> default.css. It was useful for diagnostics, but implies meaning where
> there really is none. And it's distracting. ... Gone now.
OK, I'll cvs up and stop worrying about the "a" styles then.
Thanks!
Greg
--
Greg Ward - software developer gward@...
MEMS Exchange
[David]
>> I don't think you should transform the tree at this point, since
>> you're traversing the tree. It's like modifying a list while looping
>> over it: dangerous.
[Aahz]
> Yup. This would be a separate transform step, just like
> ``docutils.transforms.references.Footnotes``. Do you still think
> calling a nested walkabout is better?
If a writer-specific transform seems more natural, then that would be OK
too. Except that the transform should not violate the doctree structure as
expressed in spec/docutils.dtd. In other words: no footnotes inside
paragraphs. The writer has to receive a standard doctree, and the other
transforms (that are not writer-specific) depend on the doctree being
standard. Having said that, if the writer were to apply its own transforms
just before the final "translation" (which is merely an extreme transform),
then no problem, anything goes. The doctree belongs to the writer at that
point.
In fact, the entire Writer framework could be changed. The Visitor pattern
and Translator classes were just the way that worked for me with the HTML
writer. I make no claims that it's an ideal solution.
I'm almost finished ripping the guts out of the old transform system and
replacing it with something better. The code is almost stable, and I'll
probably be checking it in by the weekend.
>.
Understood; that's why it's in the sandbox. I didn't realize I *was*
commenting on the coding *style*, actually. Just commenting on and asking
questions about the logic, in a sincere attempt to understand the code and
assist you in reaching your goal. No need to take any of it personally. I
hope and trust you're interested in *improving* the code?
> Side note: eventually OOwriter will split into two classes, because I've
> got stuff in there (like the ``include-output`` directive) specific to
> my book that belongs in a subclass rather than the main OpenOffice.org
> writer.
Not sure exactly what you mean here. If you mean that the "include-output"
directive should be independent of the writer, I agree completely. If it's
general-purpose, it should become a part of the parser.
--
David Goodger <goodger@...> Open-source projects:
- Python Docutils:
(includes reStructuredText:)
- The Go Tools Project:
I'll get back to the rest later, but I wanted to make a quick comment.
On Tue, Oct 22, 2002, David Goodger wrote:
> .
Yup. This would be a separate transform step, just like
``docutils.transforms.references.Footnotes``. Do you still think
calling a nested walkabout is better?.
I do appreciate the additional info about how reST works.
Side note: eventually OOwriter will split into two classes, because I've
got stuff in there (like the ``include-output`` directive) specific to
my book that belongs in a subclass rather than the main OpenOffice.org
writer.
--
Aahz (aahz@...) <*>
Project Vote Smart:
grubert@... wrote:
> you are talking from the internal represantation i am talking of the
> output structure.
We started out talking about internationalization, doing lookups in
language modules. That smells like internal representation to me.
The point is, when you have a document which begins with this::
:Author: John Doe
:Web Site:
The internal document (fragment) tree looks like this::
<docinfo>
<author>
John Doe
<field>
<field_name>
Web Site
<field_body>
<paragraph>
<reference refuri="">
The structures for the "Author" field (specific) and the "Web Site"
field (generic) are completely different, and therefore require
different processing. You can't ignore that.
> "Web site" and "Author" both end up in the documents docinfo.
> this means: if i donot want to put formatting information
> into two places one needs a function for it.
Fine, separate the formatting into a separate method. Just don't do
language lookups for fields that don't need them. Do the language
lookup, and send the *result* to the formatting method.
>>> the pre (literal) environment in latex is verbatim. how does one
>>> get the input with parsing: astext() removes the reST markup ?
>>
>> I don't understand the question. Examples, please.
>
> ::
> This is *some* thing
>
> this.astext() gives the text without stars.
Untrue. Perhaps the lack of a blank line after "::" is causing
trouble? Literal blocks do not touch the characters inside::
$ quicktest.py << EOF
> ::
>
> This is *some* thing
> EOF
<document source="<stdin>">
<literal_block xml:
This is *some* thing
The astext() method doesn't touch the characters either. However,
astext() should only be used sparingly and carefully. If there is any
structure in the node, ``node.astext()`` will ignore it.
Why are you using astext() anyway? Just let the tree traversal do the
work. From latex2e.py's LaTeXTranslator class::
def visit_literal_block(self, node):
self.use_verbatim_for_literal = 1
if (self.use_verbatim_for_literal):
self.body.append('\\begin{verbatim}\n')
self.body.append(node.astext())
self.body.append('\n\\end{verbatim}\n')
raise nodes.SkipNode
else:
self.body.append('{\\obeylines\\obeyspaces\\ttfamily\n')
I don't see why you need to short-circuit the traversal. The "if"
statement is not really conditional: it will always evaluate to true.
That should be cleaned up. Shouldn't
``self.body.append(node.astext())`` also call ``self.encode()``? That
may be the source of the problem.
This is exactly the kind of bug that arises when the tree traversal
isn't allowed to complete properly. Look at the html4css1.py writer;
``raise nodes.SkipNode`` is only used 5 times, and each time there is
a good reason. I've added some comments where it may have been
unclear. Could you add comments wherever you ``raise nodes.SkipNode``
in latex2e.py, justifying the exceptions?
--
David Goodger <goodger@...> Open-source projects:
- Python Docutils:
(includes reStructuredText:)
- The Go Tools Project:
[David]
>> The docs look good. Please note that if you regenerate the docs with
>> the latest Docutils (which I recommend you do, to take advantage of
>> the improvements to the HTML produced)
[Greg]
> OK, done.
The sources on the web site still say "Docutils 0.2.4". The current
version is 0.2.7. Not pushed out yet?
>> you should also replace the stylesheet. ... I recommend extracting
>> your modifications into a separate .css file and using the
>> "@import" statement to cascade the stylesheets. See
>> for details.
>
> OK, tried that. Problem: the main modification I made was to
> completely *remove* your styles for the 'a' and 'tt' tags. (I think
> link colouring should be up to the browser, and I don't like a
> background on inline literals.)
>
> So how do I override your stylesheet with removal information?
You can set the <tt> style back to its initial value::
tt { background-color: transparent }
As for the <a> tags, these are the styles specified::
a.target {
color: blue }
a.toc-backref {
text-decoration: none ;
color: black }
The first is easily undone::
a.target {
color: inherit }
In fact, I think I'll remove the "a.target" style from the project's
default.css. It was useful for diagnostics, but implies meaning where
there really is none. And it's distracting. ... Gone now.
I don't know of any way to undo the second set of styles
("a.toc-backref"). But they're only applied to back-links from
section headers to a table of contents. If you have no table of
contents, or specify "--no-toc-backlinks" (or "toc_backlinks: none" in
the config file), that style will have no effect. These styles remove
the typical hyperlink formatting (color + underline), to make the
back-linked section headers look like regular section headers. An
approximation to undoing the style would be::
a.toc-backref {
text-decoration: underline ;
color: blue }
However, the browser itself or user settings may specify a different
initial color and/or decoration, and the color should change once the
hyperlink is visited. These can also be specified (using the ":link"
and ":visited" pseudo-classes), but that just makes the whole thing
even more complicated.
Is there any way to *disable* styles that don't inherit? Any way to
say "use or restore the *initial* value for this style, ignoring any
later explicit styles"? I can't find any.
--
David Goodger <goodger@...> Open-source projects:
- Python Docutils:
(includes reStructuredText:)
- The Go Tools Project:
Looking at your examples and the OpenOffice.org XML DTD and
specification docs [*]_, I see that OpenOffice XML requires footnotes
themselves to be embedded inside the paragraph at the point of
reference, as does DocBook and, I believe, TeX. This makes sense for
processing (easier), but not for reading since the whole point of a
footnote is to remove the extra text from the main flow.
.. [*] Available from. DTD files are at (text.mod
has the most significance here) and the specification is.
[Aahz]
>>> What I really ought to do is call for a walkabout on the footnote
>>> node, but I can't quite figure out how to do that.
[David]
>> I assume you're already *doing* a walkabout. Just let it continue.
>> You're short-circuiting the process artificially. The internal
>> document tree is well-formed: an end-tag (depart_tag) for every
>> start-tag (visit_tag), and all elements arranged as the DTD
>> describes. (If they're not, it's a bug.) Trust in the docree.
. Having seen the context, I now think your first
idea was correct, to force a traversal of the footnote when you reach
the first footnote reference. However, note that there may be
multiple references to the same footnote, so only the *first*
reference should have its footnote traversed; others should use the
<text:footnote-ref> element I believe.
In general, doing a traversal on a subtree is simple. Say we want to
do a traversal starting at the "footnote" node::
# Use our own class to get a clone of ourselves:
visitor = self.__class__(self.document)
# Traverse the subtree rooted at "footnote":
footnote.walkabout(visitor)
# Collect the results (assumes uniform treatment of output):
self.body.extend(visitor.body)
But there's a tricky issue in the OpenOfficeTranslator class::
def visit_footnote(self, node):
raise nodes.SkipNode
This is fine for the outer traversal, but it clobbers the inner
traversal. Perhaps change this to::
def visit_footnote(self, node):
if self.handle_footnotes:
... handle footnotes
else:
raise nodes.SkipNode
How to set ``self.handle_footnotes``?
* It could be a parameter to the __init__ method, but we'd still have
to watch for nested footnotes (a footnote reference within a
footnote body).
* Start out with ``self.handle_footnotes`` true, and set it false in
``visit_document``? If nested traversals need to be done for any
other elements, this could backfire.
* Check for an empty ``self.body``? That might be the simplest and
best way::
def visit_footnote(self, node):
if self.body:
raise nodes.SkipNode
else:
... handle footnotes
Update: the DTD says "text:footnote and text:endnote elements may not
contain other text:footnote or text:endnote elements". Docutils
documents *can* have nested footnotes though, which complicates
matters. Either a workaround has to be devised, or we place a
*documented* restriction on Docutils wrt the OpenOffice writer. The
latter would be acceptable for now.
Let's take a look at the ``visit_footnote_reference`` method::
def visit_footnote_reference(self, node):
name = node['refid']
Why are you calling this the "name"? I find it misleading, since
there are "name" attributes on many elements. I'd use "refid" or
"footnote_id" instead.
Continuing::
id = node['id']
number = node['auto']
for footnote in self.document.autofootnotes:
if name == footnote['name']:
break
The ``if name == footnote['name']:`` test relies on an accident and
may not always work. IDs are derived from names, and simple names are
equal to their IDs, but more complicated names are not. For example,
the name "a name" turns into the ID "a-name". ID's can't have spaces
or anything apart from alphanumerics and "-" (see
docutils.nodes.make_id; 32 lines of docstring for a 3-line function!).
In any case, there's a much easier way to get the footnote node::
footnote = self.document.ids[name]
(Although it shouldn't be "name" but "refid".)
Since a footnote should only be rendered once, you should check if
it's already happened here. Something like::
if hasattr(footnote, 'rendered'):
self.body.append('<text:footnote-ref text:ref-name="%s"'
' text:'
% ???)
...
else: # proceed as before
...
footnote.rendered = 1
I don't know what should replace the "???" above. The OpenOffice XML
spec says that "Footnotes, endnotes, and sequences are assigned names
by the application used to create the OpenOffice.org XML file format
when the document is exported." However, I can't find a "name"
attribute on <text:footnote> elements or subelements in the DTD. Does
it mean the "id" attribute? You should verify with some actual
OpenOffice output.
The text of the footnote reference can be traversed normally, then the
end-tag inserted by ``depart_footnote_reference``. But since there's
a conditional here, there are two ways to proceed:
1. Store the end-tag on an internal stack (like the "context" stack of
the HTML writer's HTMLTranslator class), and pop it off in
``depart_footnote_reference``. This approach is recommended.
2. Process the entire <text:footnote-ref> tag in the ``visit_...``
method, using ``self.astext()`` to get the label text. Insert the
end-tag, and finish with a ``raise nodes.SkipNode``. I don't
recommend this, because it complicates processing (makes the flow
hard to understand with a special case; uniform is better) and it
will break if the contents of a footnote_reference element ever
gets more complicated. This technique *cannot* be used on any
element with a content model more complicated than "(#PCDATA)", so
it's best not to use it at all.
Continuing with ``visit_footnote_reference``::
self.body.append('<text:footnote text:\n' % id)
self.body.append('<text:footnote-citation text:string-value='
'"%s"/>\n' % number)
I don't see a "string-value" attribute in the DTD. I do see a "label"
attribute though. Either the DTD is wrong or out of date, or you have
the wrong attribute name. Also, I don't understand how you're using
the Docutils <footnote-reference> "auto" attribute here (in variable
"number").
Continuing::
self.body.append('<text:footnote-body>\n')
self.body.append(self.start_para % '.body')
for child in footnote.children:
if isinstance(child, nodes.paragraph):
self.body.append(child.astext())
self.body.append(self.end_para)
I'd replace most of the above with a nested tree traversal. Finally::
self.body.append('</text:footnote-body>\n')
self.body.append('</text:footnote>')
raise nodes.SkipNode
--
David Goodger <goodger@...> Open-source projects:
- Python Docutils:
(includes reStructuredText:)
- The Go Tools Project: