Re: cvs commit: www/share/sgml templates.usergroups.xsl

From: Pav Lucistnik <>
Date: Thu, 01 Dec 2005 15:23:44 +0100
Hiroki Sato pÝ╣e v Ŕt 01. 12. 2005 v 23:16 +0900:
> Pav Lucistnik <> wrote
>   in <>:
> pa> But there is a
> pa>
> pa> <meta http-equiv="Content-Type" content="text/html;
> pa> charset=ISO-8859-1" />
> pa>
> pa> inside variable header1, so output should be iso8859-1 too.
>  No.  This line will be silently ignored (and replaced).  xsltproc
>  actually outputs a <meta> based on "encoding" attribute in
>  <xsl:output> when the output method is HTML or XHTML.
>  The XSLT 1.0 specification also says the following:
>   |The encoding attribute specifies the preferred encoding to be used.
>   |If there is a HEAD element, then the html output method should add
>   |a META element immediately after the start-tag of the HEAD element
>   |specifying the character encoding actually used. For example,
>   |
>   | <HEAD>
>   | <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
>   | ...
>  So, we cannot output a bogus charset= line when the output is
>  HTML or XHTML.  When we need to change it, we must use <xsl:output>
>  by using the language-dependent customization layer.

Aha. So should the <meta> line be removed from the header1 variable?
It surely confused me.

To avoid a duplication of xsl files in share/sgml/ and en/, would some
kind of mechanism to pass encoding parametr to xsltproc from en/Makefile
ja/Makefile etc be useful? I thought about passing it in --stringparam
or somesuch.

Also, is there any problem with &uacute; and others in xml source when
outputting into other charsets, like euc-jp?

Pav Lucistnik <>

Eat when you are hungry, sleep when you are tired.
Chase butterflies when you want some fun.

Received on Thu Dec 01 2005 - 14:23:48 UTC