RE: [*Mostly* SOLVED] RE: Help with Japanese rendering in Zope...?
Erik wrote:
Okay, Japanese properties are rendering well, but ...
Now I have this odd "None" appearing as the first line of every page, as shown in the "kiru2" attachment. The results of dump_obj run on standard_html_header are also attached, and you'll notice that _v_cooked is "None". I've messed with the order of the elements in the header, thinking maybe the dtml calls wanted to be in the header, before it, or maybe in the body, but all to no avail -- the "None" won't go away.
Incidentally, the <dtml-var "u''"> bit appears to be unnecessary, as removing it doesn't have any effect on my object property views (thankfully). So the culprit appears to be the first line, <dtml-var "RESPONSE.setHeader('content-type', 'text/html; charset=UTF-8')">. Getting rid of this gets rid of the "None", but turns my properties back into gibberish.
Any ideas? I have no clue about what _v_cooked is...
Sorry, my mistake. You have to use dtml-call not dtml-var. The setHeader() function doesn't really return anything (=None), and dtml-var (unlike dtml-call) will include whatever is returned in the output. I'd still keep <dtml-var "u''"> in there. It may work fine now, but I think you may have trouble with some documents where Japanese or Unicode text shows up further into the document; at that point ZPublisher may already have started writing something out and by that time it's too late to switch the encoding. Bye, -- Bjorn
On Thursday 11 December 2003 06:24, Bjorn Stabell wrote:
I'd still keep <dtml-var "u''"> in there. It may work fine now, but I think you may have trouble with some documents where Japanese or Unicode text shows up further into the document; at that point ZPublisher may already have started writing something out and by that time it's too late to switch the encoding.
Position of <dtml-var "u' '"> is not important - Your method will have computed the whole document before ZPublisher starts to return anything to the client. The real reason for it is to *ensure* that the return value from your dtml is unicode. DTML will return a unicode object if any of its components are unicode, but a plain string otherwise. (and ZPublishers encoding process wont kick in unless it recieves a unicode object from your method). This throw-away unicode object guards against degenerate cases (for example, maybe an *empty* search results page) where your DTML might otherwise never see a unicode object. -- Toby Dickenson
participants (2)
-
Bjorn Stabell -
Toby Dickenson