Stephane - I think that this old Epydoc bug should be addressed in the new 3.0 beta 1 release. Do you still have a test case around that you could check against?
Upstream says: The intended behavior is that epydoc should *not* ignore the encoding of the source code, but it *should* always generate ascii xhtml file output. In particular, when epydoc reads in documentation, it converts them to unicode strings using whatever encoding is appropriate for the given source file. When it writes the documentation, it writes it as ascii, but encodes all non-ascii characters using xhtml character references to the appropriate unicode codepoints. On any browser that supports xhtml unicode character references, this should result in correctly displayed html output. (Hopefully that's all browsers -- but I haven't done extensive testing). One of the reasons that I chose this design is that the output files can sometimes mix text that originates from multiple source files; and those source files might be encoded using different encodings. So the only sensible thing to do is to convert everything to a common encoding. It would be possible, if desired, to add an option to epydoc that allows an 'output encoding' to be specified. Any characters that could be encoded in that encoding would be; and any characters that could not be encoded would be represented using xhtml character references. So I have two questions: a) is the current design (encoding everything w/ character references) insufficient? If so, why? (e.g., because browsers xyz don't handle charrefs correctly) b) if the current design is insufficient, would adding an option to specify the output encoding be sufficient? What do you think?? KEN -- Kenneth J. Pronovici <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
