99032 - xsl:output "encoding="attribute is ignored.

Status: RESOLVED WONTFIX

(Core :: XSLT, enhancement)

Description

[Walter Schmid]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID:    0.9.2

The "encoding=" attribute of the XSL:OUTPUT statement has no effect when 
transformation output is generated. The characters are always UTF-8 encoded.

Reproducible: Always
Steps to Reproduce:
1.Add <xsl:output method="html" encoding="iso-8859-1"/> to your stylesheet
2.Do transformation and generate output
3.Set the browser encoding to ISO-8859-1


Actual Results:  After XSL transformation all characters are UTF-8 encoded, 
even if the stylesheet specifies the output to be ISO-8859-1 (Latin1).

Expected Results:  Characters must be ISO-8859-1 encoded.

Comment 1

[Henri Sivonen (:hsivonen) (on vacation)]

Does it make sense to have one component output non-Unicode only to be converted
back to Unicode?

Comment 2

[Walter Schmid]

Isn't it the aim of a language to be a base for ONE common understanding ? 

Comment 3

[Peter Van der Beken [:peterv]]

Walter, please don't speak in riddles. First of all, this is for the standalone
Transformiix build, right? Second, we are not required to support all the
encodings so "Characters *must* be ISO-8859-1 encoded" is wrong. The attribute
is not ignored, we fall back to UTF-8 if we don't support the preferred encoding
(as the specification requires). I doubt we'll get support for a lot of
encodings soon, the two required ones are UTF-8 and UTF-16 and afaik we only
support UTF-8 now.

Comment 4

[Keyser Sose]

Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.

Comment 5

[Christopher Hoess (gone)]

reopening

Comment 6

[Christopher Hoess (gone)]

confirming, Future based on comments. Maybe eventually ftang can hook you up
with some encoders.

Comment 7

[Peter Van der Beken [:peterv]]

The structure to support additional encoding went in with the patch for bug 96647.

Comment 8

[Axel Hecht]

we probably aren't going to implement a whole lotta converters soon, but we 
should definitly start by changing the standalone output handlers to talk to a 
string sink.
I for one didn't manage to transform into a string, as Win's stdlib seems bad.
And module may wanna use those handlers for the transformToString methods.

So going there give double benefits.

Comment 9

[Jan Machac]

Having UTF-8 xml and UTF-8 xsl stylesheet results in iso-8859-1 page even if the
<xsl:output method="html" encoding="UTF-8"> used.

The page is perfectly legible, but the problem is that the form data is sent
back in the iso-8859-1 encoding. It's also impossible to change the encoding
using the view->character coding menu.

Content types of the stylesheet and xml are both specifying the UTF-8 and when I
transform it on the server (Tomcat) I get a perfect UTF-8 html... Obviously
there are no encoding problems then...

Comment 10

[Peter Van der Beken [:peterv]]

1) This bug is about the standalone version of Transformiix, not the module
integrated inside Mozilla.
2) You didn't post a version number, please make sure you're not seeing bug
190302 and file a new bug if it doesn't work with a recent nightly.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Jan: you're talking about bug 190302 which has now been fixed. If you're still
having problems with a recent build please comment in there.

Comment 12

[Jan Machac]

Sorry, my fault...

bug 190302 seems to be my problem... If it is fixed, there is no problem at all...

Thanx for help!

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:peterv, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 14

[Peter Van der Beken [:peterv]]

We don't support a standalone version of our XSLT processor anymore.