Re: cvs commit: www/share/sgml templates.usergroups.xsl
Hiroki Sato pÝ╣e v Ŕt 01. 12. 2005 v 23:16 +0900:
> Pav Lucistnik <pav_at_FreeBSD.org> wrote
> in <1133442525.95515.22.camel_at_pav.hide.vol.cz>:
> pa> But there is a
> pa> <meta http-equiv="Content-Type" content="text/html;
> pa> charset=ISO-8859-1" />
> 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
Also, is there any problem with ú and others in xml source when
outputting into other charsets, like euc-jp?
Pav Lucistnik <pav_at_oook.cz>
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