Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-31 Thread Christopher Schultz

Greg,

On 3/31/22 12:17, Christopher Schultz wrote:

Greg,

On 3/29/22 13:41, gelo1234 wrote:

Have you also tried HTMLT or XHTMLT Serializers?
Default HTMLSerializer cannot handle some unicode characters: 
https://issues.apache.org/jira/browse/SLING-5973?attachmentOrder=asc 


Hmm. Are the HTMLT / XHTMLT serializers built-in? I have disabled all 
blocks during the build, so I'm just using Cocoon core.


I tried using a view, and it's not perfect but what I ended up with is 
Cocoon dumping-out the originally-generated (from the generator) XML and 
the US flag is already broken.


So it's definitely not being broken by the convoluted pipeline.

I'll try to put together an SSCCE[1]

-chris

[1] http://sscce.org/

wt., 29 mar 2022 o 19:37 gelo1234 > napisał(a):


    Hello Chris,

    I think you will not get any icon-type character on output without
    using proper font rendering - like Emoji support? Emoji might not be
    supported by default in Cocoon.
    So this might be the reason why you get HTML entities instead of
    Emoji-icons.
    Also notice:
    https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html
    

    Greetings,
    Greg



    wt., 29 mar 2022 o 18:36 Christopher Schultz
    mailto:ch...@christopherschultz.net>>
    napisał(a):

    Cédric,

    On 3/29/22 12:06, Cédric Damioli wrote:
 > Could you provide more details ?
 > How is your XML processed before outputting the wrong UTF-8
    sequence ?

    It's somewhat straightforward:

    
    https://source/ " />

    

    

    

    

    

    

    

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-31 Thread Cédric Damioli

Hi,

To help isolate the issue, could you test with a simpler pipeline with 
only generator/single simple XSLT/xml serializer ?


Cédric

Le 31/03/2022 à 17:54, Christopher Schultz a écrit :

Cédric,

On 3/29/22 12:52, Cédric Damioli wrote:

Do you use Xalan as XSLT Processor ?
If so, I remember https://issues.apache.org/jira/browse/XALANJ-2617 
which could be a cause of your issue.
I resolved it on my side years ago by compiling my own patched version 

> of Xalan.

I'm using whatever Cocoon uses natively. For example, I don't throw-in 
Jackson or StaX or whatever other options there are.


For "markers", you may use labels on your sitemap steps associated 
with a cocoon view.


Yeah, that sound familiar.

Thanks,
-chris


Le 29/03/2022 à 18:36, Christopher Schultz a écrit :

Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:

Could you provide more details ?
How is your XML processed before outputting the wrong UTF-8 sequence ?


It's somewhat straightforward:


  https://source/; />

  

  

  

  

  

  

  

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-31 Thread Christopher Schultz

Greg,

On 3/31/22 12:13, Christopher Schultz wrote:

On 3/29/22 13:37, gelo1234 wrote:

Hello Chris,

I think you will not get any icon-type character on output without 
using proper font rendering - like Emoji support? Emoji might not be 
supported by default in Cocoon.


This isn't a font-rendering issue; it's just ... wrong. Either the raw 
character should be output, or the proper set of HTML entities should be 
output. Neither is happening. It's just mojibake somewhere in the pipeline.


So this might be the reason why you get HTML entities instead of 
Emoji-icons.
Also notice: 
https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html 


I read that, and was hopeful that 2.1.13 would resolve this issue, but 
it hasn't.


Hmm... strangely, the X-Cocoon-Version header still says 2.1.11. Perhaps 
I didn't upgrade properly...


Yeah, I had Cocoon 2.1.11 as a compile-time dependency which was 
dropping cocoon-2.1.11.jar into the web application along with all the 
other artifacts from the 2.1.13 build. Whoops.


I got that all fixed-up, but the behavior is still the same. I was 
pretty hopeful that was the only thing missing.


-chris

wt., 29 mar 2022 o 18:36 Christopher Schultz 
mailto:ch...@christopherschultz.net>> 
napisał(a):


    Cédric,

    On 3/29/22 12:06, Cédric Damioli wrote:
 > Could you provide more details ?
 > How is your XML processed before outputting the wrong UTF-8
    sequence ?

    It's somewhat straightforward:

    
    https://source/ " />

    

    

    

    

    

    

    

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-31 Thread Christopher Schultz

Greg,

On 3/29/22 13:41, gelo1234 wrote:

Have you also tried HTMLT or XHTMLT Serializers?
Default HTMLSerializer cannot handle some unicode characters: 
https://issues.apache.org/jira/browse/SLING-5973?attachmentOrder=asc 


Hmm. Are the HTMLT / XHTMLT serializers built-in? I have disabled all 
blocks during the build, so I'm just using Cocoon core.


Thanks,
-chris

wt., 29 mar 2022 o 19:37 gelo1234 > napisał(a):


Hello Chris,

I think you will not get any icon-type character on output without
using proper font rendering - like Emoji support? Emoji might not be
supported by default in Cocoon.
So this might be the reason why you get HTML entities instead of
Emoji-icons.
Also notice:
https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html


Greetings,
Greg



wt., 29 mar 2022 o 18:36 Christopher Schultz
mailto:ch...@christopherschultz.net>>
napisał(a):

Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:
 > Could you provide more details ?
 > How is your XML processed before outputting the wrong UTF-8
sequence ?

It's somewhat straightforward:


    https://source/ " />

    

    

    

    

    

    

    > To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org

 >> For additional commands, e-mail:
users-h...@cocoon.apache.org 
 >>
 >

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org

For additional commands, e-mail: users-h...@cocoon.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org



Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-31 Thread Christopher Schultz

Greg,

On 3/29/22 13:37, gelo1234 wrote:

Hello Chris,

I think you will not get any icon-type character on output without using 
proper font rendering - like Emoji support? Emoji might not be supported 
by default in Cocoon.


This isn't a font-rendering issue; it's just ... wrong. Either the raw 
character should be output, or the proper set of HTML entities should be 
output. Neither is happening. It's just mojibake somewhere in the pipeline.


So this might be the reason why you get HTML entities instead of 
Emoji-icons.
Also notice: 
https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html 


I read that, and was hopeful that 2.1.13 would resolve this issue, but 
it hasn't.


Hmm... strangely, the X-Cocoon-Version header still says 2.1.11. Perhaps 
I didn't upgrade properly...


Thanks,
-chris

wt., 29 mar 2022 o 18:36 Christopher Schultz 
mailto:ch...@christopherschultz.net>> 
napisał(a):


Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:
 > Could you provide more details ?
 > How is your XML processed before outputting the wrong UTF-8
sequence ?

It's somewhat straightforward:


    https://source/ " />

    

    

    

    

    

    

    > To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org

 >> For additional commands, e-mail: users-h...@cocoon.apache.org

 >>
 >

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org

For additional commands, e-mail: users-h...@cocoon.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org



Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-31 Thread Christopher Schultz

Cédric,

On 3/29/22 12:52, Cédric Damioli wrote:

Do you use Xalan as XSLT Processor ?
If so, I remember https://issues.apache.org/jira/browse/XALANJ-2617 
which could be a cause of your issue.
I resolved it on my side years ago by compiling my own patched version 

> of Xalan.

I'm using whatever Cocoon uses natively. For example, I don't throw-in 
Jackson or StaX or whatever other options there are.


For "markers", you may use labels on your sitemap steps associated with 
a cocoon view.


Yeah, that sound familiar.

Thanks,
-chris


Le 29/03/2022 à 18:36, Christopher Schultz a écrit :

Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:

Could you provide more details ?
How is your XML processed before outputting the wrong UTF-8 sequence ?


It's somewhat straightforward:


  https://source/; />

  

  

  

  

  

  

  

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-29 Thread gelo1234
Chris,

Have you also tried HTMLT or XHTMLT Serializers?
Default HTMLSerializer cannot handle some unicode characters:
https://issues.apache.org/jira/browse/SLING-5973?attachmentOrder=asc

Greetings,
Greg


wt., 29 mar 2022 o 19:37 gelo1234  napisał(a):

> Hello Chris,
>
> I think you will not get any icon-type character on output without using
> proper font rendering - like Emoji support? Emoji might not be supported by
> default in Cocoon.
> So this might be the reason why you get HTML entities instead of
> Emoji-icons.
> Also notice:
> https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html
>
> Greetings,
> Greg
>
>
>
> wt., 29 mar 2022 o 18:36 Christopher Schultz 
> napisał(a):
>
>> Cédric,
>>
>> On 3/29/22 12:06, Cédric Damioli wrote:
>> > Could you provide more details ?
>> > How is your XML processed before outputting the wrong UTF-8 sequence ?
>>
>> It's somewhat straightforward:
>>
>> 
>>https://source/; />
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> >> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
>> >> For additional commands, e-mail: users-h...@cocoon.apache.org
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
>> For additional commands, e-mail: users-h...@cocoon.apache.org
>>
>>


Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-29 Thread gelo1234
Hello Chris,

I think you will not get any icon-type character on output without using
proper font rendering - like Emoji support? Emoji might not be supported by
default in Cocoon.
So this might be the reason why you get HTML entities instead of
Emoji-icons.
Also notice:
https://www.mail-archive.com/dev@cocoon.apache.org/msg61629.html

Greetings,
Greg



wt., 29 mar 2022 o 18:36 Christopher Schultz 
napisał(a):

> Cédric,
>
> On 3/29/22 12:06, Cédric Damioli wrote:
> > Could you provide more details ?
> > How is your XML processed before outputting the wrong UTF-8 sequence ?
>
> It's somewhat straightforward:
>
> 
>https://source/; />
>
>
>
>
>
>
>
>
>
>
>
>
>
> >> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> >> For additional commands, e-mail: users-h...@cocoon.apache.org
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> For additional commands, e-mail: users-h...@cocoon.apache.org
>
>


Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-29 Thread Cédric Damioli

Do you use Xalan as XSLT Processor ?
If so, I remember https://issues.apache.org/jira/browse/XALANJ-2617 
which could be a cause of your issue.
I resolved it on my side years ago by compiling my own patched version 
of Xalan.


For "markers", you may use labels on your sitemap steps associated with 
a cocoon view.


HTH,
Cédric

Le 29/03/2022 à 18:36, Christopher Schultz a écrit :

Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:

Could you provide more details ?
How is your XML processed before outputting the wrong UTF-8 sequence ?


It's somewhat straightforward:


  https://source/; />

  

  

  

  

  

  

  

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-29 Thread Christopher Schultz

Cédric,

On 3/29/22 12:06, Cédric Damioli wrote:

Could you provide more details ?
How is your XML processed before outputting the wrong UTF-8 sequence ?


It's somewhat straightforward:


  https://source/; />

  

  

  

  

  

  

  

Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-29 Thread Cédric Damioli

Hi Christopher,

Could you provide more details ?
How is your XML processed before outputting the wrong UTF-8 sequence ?

Regards,
Cédric

Le 29/03/2022 à 17:48, Christopher Schultz a écrit :

All,

I'm still struggling with this. I have upgraded to 2.1.13 which 
includes the fix for https://issues.apache.org/jira/browse/COCOON-2352 
but I'm still getting that American flag converted into those 4 HTML 
entities:




I would expect there to be a single (multibyte) character in the 
output with no HTML entities.


I've double-checked, and the source XML contains the flag as a single 
multi-byte character, served as UTF-8.


Any ideas for how to get this working? I'm sure I could put together a 
trivial test-case.


Thanks,
-chris

On 10/30/18 12:18, Christopher Schultz wrote:

All,

Some additional information at the end.

On 10/30/18 11:58, Christopher Schultz wrote:

All,



I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have
a servlet generating XML in UTF-8 encoding and I have a pipeline
with a few transforms in it, ultimately serializing to XHTML.



If I have a Unicode character in the XML which is outside of the
BMP, such as this one:   (that's an American flag, in case your
mail reader doesn't render it correctly), then I end up getting a
series of bytes coming from Cocoon after the transform that look
like UTF-16.



Here's what's in the XML:



Test



Just like that. The bytes in the message for the flag character
are:



f0  9f  87  ba  f0  9f  87  b8



When rendering that into XHTML, I'm getting this in the output:



Test



The American flag in Unicode reference can be found here:
https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%87%BA%F0%9F%87%

B8


  You can see it broken down a bit better here for "Regional U":
http://www.fileformat.info/info/unicode/char/1f1fa/index.htm



and "Regional S":
http://www.fileformat.info/info/unicode/char/1f1f8/index.htm



What's happening is that some component in Cocoon has decided to
generate HTML entities instead of just emitting the character.
That's okay IMO. But what it does doesn't make sense for a UTF-8
output encodin g.



The first two entities "" are the decimal numbers
that represent the UTF-16 character for that "Regional Indicator
Symbol Letter U" and they are correct... for UTF-16. If I change
the output encoding from UTF-8 to UTF0-16, then the browser will
render these correctly. Using UTF-8, they show as four of those
ugly [?] characters on the screen.



I had originally just decided to throw up my hands and use UTF-16
encoding even though it's dumb. But it seems that MSIE cannot be
convinced to use UTF-16 no matter what, and I must continue to
support MSIE. :(



So it's back to UTF-8 for me.



How can I get Cocoon to output that character (or "those
characters") correctly?



It needs to be one of the following:



 (HTML decimal entities)
 (HTML hex entities) f0 9f  87  ba
f0  9f  87  b8 (raw UTF-8 bytes)



Does anyone know how/where this conversion is being performed ion
Cocoon? Probably in a XHTML serializer (I'm using
org.apache.cocoon.serialization.XMLSerializer). I'm using
mime-type "text/html" and UTF-8 in my sitemap
for that serializer (the one named "xhtml"). I believe I've mads
very few changes from the default, if any.



I haven't yet figured out how to get from what Java sees (\uE50C
for the "S" for example) to , but knowing where the code
is that is making that decision would be very helpful.



Any ideas?



-chris


I created a text file (UTF-8) containing only the flag and read it in
using Java and printed all of the code points. There should be 2
"characters" in the file. It's 4 bytes per UTF-8 character so I
assumed I'd end up with 2 'char' primitives in the file, but I ended
up with more.

Here's the loop and the output:

 try(java.io.FileReader in = new java.io.FileReader("file.txt"))
{
 char[] chars = new char[10];

 int count = in.read(chars);

 for(int i=0; i   // Skip any trailing "characters" that are actually a part of this 
one

   if(1 < Character.charCount(cp))
 i += Character.charCount(cp) - 1;
}

Using the above code is completely encoding-agnostic, because it's
describing the Unicode code point and not some set of bytes in a
particular flavor of UTF-x.

-chris


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org



--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org



Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2022-03-29 Thread Christopher Schultz

All,

I'm still struggling with this. I have upgraded to 2.1.13 which includes 
the fix for https://issues.apache.org/jira/browse/COCOON-2352 but I'm 
still getting that American flag converted into those 4 HTML entities:




I would expect there to be a single (multibyte) character in the output 
with no HTML entities.


I've double-checked, and the source XML contains the flag as a single 
multi-byte character, served as UTF-8.


Any ideas for how to get this working? I'm sure I could put together a 
trivial test-case.


Thanks,
-chris

On 10/30/18 12:18, Christopher Schultz wrote:

All,

Some additional information at the end.

On 10/30/18 11:58, Christopher Schultz wrote:

All,



I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have
a servlet generating XML in UTF-8 encoding and I have a pipeline
with a few transforms in it, ultimately serializing to XHTML.



If I have a Unicode character in the XML which is outside of the
BMP, such as this one:   (that's an American flag, in case your
mail reader doesn't render it correctly), then I end up getting a
series of bytes coming from Cocoon after the transform that look
like UTF-16.



Here's what's in the XML:



Test



Just like that. The bytes in the message for the flag character
are:



f0  9f  87  ba  f0  9f  87  b8



When rendering that into XHTML, I'm getting this in the output:



Test



The American flag in Unicode reference can be found here:
https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%87%BA%F0%9F%87%

B8


  You can see it broken down a bit better here for "Regional U":
http://www.fileformat.info/info/unicode/char/1f1fa/index.htm



and "Regional S":
http://www.fileformat.info/info/unicode/char/1f1f8/index.htm



What's happening is that some component in Cocoon has decided to
generate HTML entities instead of just emitting the character.
That's okay IMO. But what it does doesn't make sense for a UTF-8
output encodin g.



The first two entities "" are the decimal numbers
that represent the UTF-16 character for that "Regional Indicator
Symbol Letter U" and they are correct... for UTF-16. If I change
the output encoding from UTF-8 to UTF0-16, then the browser will
render these correctly. Using UTF-8, they show as four of those
ugly [?] characters on the screen.



I had originally just decided to throw up my hands and use UTF-16
encoding even though it's dumb. But it seems that MSIE cannot be
convinced to use UTF-16 no matter what, and I must continue to
support MSIE. :(



So it's back to UTF-8 for me.



How can I get Cocoon to output that character (or "those
characters") correctly?



It needs to be one of the following:



 (HTML decimal entities)
 (HTML hex entities) f0  9f  87  ba
f0  9f  87  b8 (raw UTF-8 bytes)



Does anyone know how/where this conversion is being performed ion
Cocoon? Probably in a XHTML serializer (I'm using
org.apache.cocoon.serialization.XMLSerializer). I'm using
mime-type "text/html" and UTF-8 in my sitemap
for that serializer (the one named "xhtml"). I believe I've mads
very few changes from the default, if any.



I haven't yet figured out how to get from what Java sees (\uE50C
for the "S" for example) to , but knowing where the code
is that is making that decision would be very helpful.



Any ideas?



-chris


I created a text file (UTF-8) containing only the flag and read it in
using Java and printed all of the code points. There should be 2
"characters" in the file. It's 4 bytes per UTF-8 character so I
assumed I'd end up with 2 'char' primitives in the file, but I ended
up with more.

Here's the loop and the output:

 try(java.io.FileReader in = new java.io.FileReader("file.txt"))
{
 char[] chars = new char[10];

 int count = in.read(chars);

 for(int i=0; i

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org



Re: Getting UTF-16 encoding on dynamic content regardless of output content type

2018-10-30 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Some additional information at the end.

On 10/30/18 11:58, Christopher Schultz wrote:
> All,
> 
> I'm attempting to do everything with UTF-8 in Cocoon 2.1.11. I have
> a servlet generating XML in UTF-8 encoding and I have a pipeline
> with a few transforms in it, ultimately serializing to XHTML.
> 
> If I have a Unicode character in the XML which is outside of the
> BMP, such as this one:   (that's an American flag, in case your
> mail reader doesn't render it correctly), then I end up getting a
> series of bytes coming from Cocoon after the transform that look
> like UTF-16.
> 
> Here's what's in the XML:
> 
> Test
> 
> Just like that. The bytes in the message for the flag character
> are:
> 
> f0  9f  87  ba  f0  9f  87  b8
> 
> When rendering that into XHTML, I'm getting this in the output:
> 
> Test
> 
> The American flag in Unicode reference can be found here: 
> https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%87%BA%F0%9F%87%
B8
>
>  You can see it broken down a bit better here for "Regional U": 
> http://www.fileformat.info/info/unicode/char/1f1fa/index.htm
> 
> and "Regional S": 
> http://www.fileformat.info/info/unicode/char/1f1f8/index.htm
> 
> What's happening is that some component in Cocoon has decided to 
> generate HTML entities instead of just emitting the character.
> That's okay IMO. But what it does doesn't make sense for a UTF-8
> output encodin g.
> 
> The first two entities "" are the decimal numbers
> that represent the UTF-16 character for that "Regional Indicator
> Symbol Letter U" and they are correct... for UTF-16. If I change
> the output encoding from UTF-8 to UTF0-16, then the browser will
> render these correctly. Using UTF-8, they show as four of those
> ugly [?] characters on the screen.
> 
> I had originally just decided to throw up my hands and use UTF-16 
> encoding even though it's dumb. But it seems that MSIE cannot be 
> convinced to use UTF-16 no matter what, and I must continue to
> support MSIE. :(
> 
> So it's back to UTF-8 for me.
> 
> How can I get Cocoon to output that character (or "those
> characters") correctly?
> 
> It needs to be one of the following:
> 
>  (HTML decimal entities) 
>  (HTML hex entities) f0  9f  87  ba
> f0  9f  87  b8 (raw UTF-8 bytes)
> 
> Does anyone know how/where this conversion is being performed ion 
> Cocoon? Probably in a XHTML serializer (I'm using 
> org.apache.cocoon.serialization.XMLSerializer). I'm using
> mime-type "text/html" and UTF-8 in my sitemap
> for that serializer (the one named "xhtml"). I believe I've mads
> very few changes from the default, if any.
> 
> I haven't yet figured out how to get from what Java sees (\uE50C
> for the "S" for example) to , but knowing where the code
> is that is making that decision would be very helpful.
> 
> Any ideas?
> 
> -chris

I created a text file (UTF-8) containing only the flag and read it in
using Java and printed all of the code points. There should be 2
"characters" in the file. It's 4 bytes per UTF-8 character so I
assumed I'd end up with 2 'char' primitives in the file, but I ended
up with more.

Here's the loop and the output:

try(java.io.FileReader in = new java.io.FileReader("file.txt"))
{
char[] chars = new char[10];

int count = in.read(chars);

for(int i=0; ihttps://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvYhDgACgkQHPApP6U8
pFjPZRAAs9jgubhuIVMs52AmAEPXqVSuG8Y18t7RP7W2F5XouZ69SXqihUKmYODM
tQnOlyGghfUnXAkQ3uVNLjbx+dSKGwpuQbkb8987Po6AgzweL9stmqzowdn4Zcam
ow7aZSp8gmxa31YHbb7pphGPnjzVqr84Mz9MCCCcSMg/1ZkvayarJTWhYkBgeWip
wdxbR2nP7wYNLkEy+v4hLvIcWYI8IeuA2nWb5qNvb6zFVYkPLZZGhdOm19J06cHR
Rvxb83g+8X80ngP6Uztbg0p4/qa7vfJXlM46iCEqOM/7+eE0gMwOGk7Akbt+2Utd
sSNUChUPzgeRZkzSAbOZcnDhGLXCWodEM75GL1nDJED1N+gWtJwRDb4kfLdY337R
ghiVB9yupjFZFhho2BArWl58hx8WrQ9Lawsrn/OFOTjea9A+3/k9QYYCpMObpwJ9
rhTA1bQV9rQbbPC2CG1iajAlb5Moe7tWF1AmhJsqFXKPjMGiIwBlOKRAgcaIZxbr
rJRI4SKDkbIlCTWKOqe4cT/HgDQ/O9mBynZ353EcmSrr4Oye8k91e8SRjUh3UdLh
XfRnMcEKEwJfIzv+JZgJQK8kwERM4mxLrf3tdhvo9IUwN44Z5QKjZjQHbkYQaIT/
m58tqqNmApzH3gyWeyd6F7HqeTO8wlaRMCipBVX6/SW1Qop2Qno=
=YXAW
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org