Hiroki Sato píše v čt 01. 12. 2005 v 23:16 +0900: > Pav Lucistnik <[EMAIL PROTECTED]> wrote > in <[EMAIL PROTECTED]>: > > 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 ú and others in xml source when
outputting into other charsets, like euc-jp?
--
Pav Lucistnik <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Eat when you are hungry, sleep when you are tired.
Chase butterflies when you want some fun.
signature.asc
Description: Toto je digitálně podepsaná část zprávy
