> goodger@... wrote:
>> fixed encoding/charset values in "html_prolog" & "html_head" parts,
>> which should not have been interpolated
>> Modified: trunk/docutils/docs/api/publisher.txt
>> + themselves. The "Content-Type" meta tag's "charset" value is left
>> + unresolved, as "%s"::
>> + <meta http-equiv="Content-Type" content="text/html; charset=%s" />
>> + The interpolation should be done by client code.
> Could explain the motivation for this?
docutils.core.publish_parts returns Unicode text, unencoded. If the
client code wants/needs to encode the text, it should also indicate
the encoding in the appropriate places.
> Why would you want to make Docutils create output in a different
> charset than what you will be using in the final document?
publish_parts doesn't need to know what final encoding will be used.
> (And after all, in such [rare?] cases one could also replace the
> charset with another charset using a regex.)
That would be a kludge at best.
> Requiring the user to do the string-interpolation himself seems like
> an unnecessary inconvenience to me (but maybe I'm missing a use case
> for that).
The alternative would be to supply publish_parts with the intended
final encoding in the settings_overrides parameter. But since no
actual encoding will be done by publish_parts, requiring the encoding
to be supplied would be premature.
Looking at the output of publish_parts, I see that "meta" and "whole"
should be uninterpolated too. (to do)
David Goodger <http://python.net/~goodger>