cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Freeman \(saurik\)" <>
Subject [PATCH] Good Fix for Encoding Issue :)
Date Sun, 25 Mar 2001 21:59:16 GMT

It turns out this has nothing to do with the default encoding on the system.
I finally figured out that it was ISO-8859-1 for me anyway, not UTF-8, which
pretty much closed off that area of research.  I traced the encoding back
far enough until I noticed that Xerces was being left in charge of it.  The
default we are looking for isn’t the system default, but the Xerces
OutputFormat default.  This is where the solution lies:

Index: src/org/apache/cocoon/formatter/
RCS file:
retrieving revision 1.5
diff -u -r1.5
--- src/org/apache/cocoon/formatter/      2001/03/07
22:32:16     1.5
+++ src/org/apache/cocoon/formatter/      2001/03/25
@@ -88,6 +88,8 @@
         encoding = (String) conf.get("encoding");
         if (encoding != null) {
+        } else {
+            encoding = format.getEncoding();

         doctypePublic = (String) conf.get("doctype-public");

Even if you don’t set the encoding on an OutputFormat, it can come with
something already set inside of it.  This causes a disparity between the
encoding String member and the getEncoding() property of the format
OutputFormat member.  Of course, this comes after backing out the changes.

BTW, why do we even have the encoding variable there?  Wouldn’t it make more
sense to just have AbstractFormatter.getEncoding() return
format.getEncoding() ?  Are we using it really often in other areas of the
code?  It seems bad that there are two different ways to get access to the
same value if they can go out of sync like this.

Jay Freeman (saurik) <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message