Re: Bizarre Bug - Progress (sorta)

[Terry Steichen <te...@net-frame.com>]

Turns out that when I change the input.encoding back to the default
"ISO-8859-1" (instead of UTF-8) the files will load.  However if the
output.encoding is not set to UTF-8, there are a fair number of question
marks (character interpretation errors).

With this configureation (with input set to 8859-1 and output to UTF-8) some
pages (with the offending embedded characters) are rendered with no errors.
In other cases there is a displayed error ('?') when the offending character
is in a template but no error when the same character is in a string, and
yet other cases which are the opposite.

I must admit this has me quite confused.  The good news, however, is that
with the above configuration, Velocity will find and include all the HTML
files.

I'll keep digging and let you all know if anything new emerges.  Please do
the same.

Regards,

Terry

----- Original Message -----
From: "Terry Steichen" <te...@net-frame.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Monday, June 03, 2002 3:53 PM
Subject: Re: Bizarre Bug


> This is hex 95 . , hex 96 -, and hex 97 -  Don't know if they'll get
through
> the e-mail, but maybe you can try them.  Also, I've attached a copy of an
> HTML page with hex 95 in it (you can find it a bit after the location of
the
> string "From Our Advertisers" in the page).
>
> Regards,
>
> Terry
>
> ----- Original Message -----
> From: "Bill Boland" <bo...@attbi.com>
> To: "'Velocity Users List'" <ve...@jakarta.apache.org>
> Sent: Monday, June 03, 2002 3:38 PM
> Subject: RE: Bizarre Bug
>
>
> > Terry,
> >
> > I think the default.contentType is only defined for the VelocityServlet
> > so that wouldn't help you. I tried to simulate your problem with the
> > VelocityServlet on 1.3rc1 with the encoding options you specified and
> > could not get it to fail #include'ing those characters from a text file.
> > I may not be simulating it properly or it may be some other
> > environmental or version difference. :(
> >
> > bill
> >
> >
> >
> > -----Original Message-----
> > From: Terry Steichen [mailto:terry@net-frame.com]
> > Sent: Monday, June 03, 2002 11:54 AM
> > To: Velocity Users List
> > Subject: Re: Bizarre Bug
> >
> > Bill,
> >
> > No, I'm using a different framework (Enhydra).  However, I did try your
> > suggestion by adding 'default.contentType=text/html; charset=utf-8' to
> > the
> > velocity properties file.
> >
> > Unfortunately, this resulted in no change.
> >
> > Regards,
> >
> > Terry
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>


----------------------------------------------------------------------------
----


> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Bizarre Bug - Progress (sorta)

[Terry Steichen <te...@net-frame.com>]

There are two hex 96 characters in the attached page, located immediately
after the dateline (ALBANY, NY).  Hope they make it through.

Regards,

Terry
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@adeptra.com>
To: <ve...@jakarta.apache.org>
Sent: Tuesday, June 04, 2002 8:17 AM
Subject: Re: Bizarre Bug - Progress (sorta)


> On 6/3/02 6:45 PM, "Terry Steichen" <te...@net-frame.com> wrote:
>
> > Turns out that when I change the input.encoding back to the default
> > "ISO-8859-1" (instead of UTF-8) the files will load.  However if the
> > output.encoding is not set to UTF-8, there are a fair number of question
> > marks (character interpretation errors).
> >
> > With this configureation (with input set to 8859-1 and output to UTF-8)
some
> > pages (with the offending embedded characters) are rendered with no
errors.
> > In other cases there is a displayed error ('?') when the offending
character
> > is in a template but no error when the same character is in a string,
and
> > yet other cases which are the opposite.
> >
> > I must admit this has me quite confused.  The good news, however, is
that
> > with the above configuration, Velocity will find and include all the
HTML
> > files.
> >
> This is still wacky.  The '?' is simply that the output encoding couldn't
> figure out what to do with the character.
>
> Where do you get the original data from?  You said you attached one
example
> to the list, but I don't think it made it.  Could you resend?
>
>
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>

Re: Bizarre Bug - Progress (sorta)

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 6/3/02 6:45 PM, "Terry Steichen" <te...@net-frame.com> wrote:

> Turns out that when I change the input.encoding back to the default
> "ISO-8859-1" (instead of UTF-8) the files will load.  However if the
> output.encoding is not set to UTF-8, there are a fair number of question
> marks (character interpretation errors).
> 
> With this configureation (with input set to 8859-1 and output to UTF-8) some
> pages (with the offending embedded characters) are rendered with no errors.
> In other cases there is a displayed error ('?') when the offending character
> is in a template but no error when the same character is in a string, and
> yet other cases which are the opposite.
> 
> I must admit this has me quite confused.  The good news, however, is that
> with the above configuration, Velocity will find and include all the HTML
> files.
> 
This is still wacky.  The '?' is simply that the output encoding couldn't
figure out what to do with the character.

Where do you get the original data from?  You said you attached one example
to the list, but I don't think it made it.  Could you resend?


-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>