[Petal] Re: CPAN daily update

[Jean-Michel Hiver]

William McKee wrote:

>On Tue, Jan 13, 2004 at 10:03:27AM +0000, Jean-Michel Hiver wrote:
>  
>
>>Ooops! Sorry I've been lazy :)
>>    
>>
>
>Probably more busy than lazy if you are still working on the MKDoc
>migration!
>  
>
That's a huge job which will probably be complete when Perl 6 comes out :/

However that's the right way to do it... it's nice to have a bunch of 
independant modules rather than a monstro monolithic thing.

>>Great to hear your problem has been fixed.
>>    
>>
>
>Well, I spoke too soon. I ran the webpages that were showing the
>incorrect character and did not see it so assumed things were fixed.
>However, running the test case that I created and posted to the list
>still results in an error when run with Petal::Parser::HTB and does not
>produce any visible output when run without it. Shouldn't the nbsp
>entity be getting changed to something?
>  
>
But it is! OK try this in your template:

Hello         World

You should see in your browser:

Hello         World

Rather than

Hello World

>Would you take a patch to the testsuite that checks for these problems?
>I'm wondering if it's a setup issue on my systems or something in Petal.
>Last time I'll ask (for today<g>), have you run the test I posted a
>couple weeks ago? Do you see the invalid character being printed?
>  
>
Ahh.. sorry... lost in the flood of emails. Can you re-send the test?

Also I must admit that I am not super-keen on maintaining 
Petal::Parser::HTB for one reason: I *never* use it, and it's just a 
dead weight for me. Is anybody other than William using this dinausor?

>>At the moment the way it's set is that if either your $Petal::INPUT or 
>>$Petal::OUTPUT (or the associated options in the constructor) are set to 
>>'HTML', then Petal will decode the HTML entities.
>>    
>>
>
>Using MKDoc::XML::Decode::XHTML?
>  
>
Yes - and also MKDoc::XML::Decode::Numeric


>>And actually &nbsp; should be converted to a character with the code 
>>decimal 160 (Or A0) which corresponds to a non breaking space white. So 
>>the &nbsp; disappears but is replaced by a "real" non breaking space 
>>character.
>>    
>>
>
>Should that be visible in a terminal? Running my tests in the terminal
>window do not reveal a character being inserted in place of the &nbsp;.
>  
>
Ok, this is what I get on my box at home with Linux RH 9 in a UTF-8 
terminal:

[jhiver at future jhiver]$ export LC_ALL=C
[jhiver at future jhiver]$ perl -e 'print chr(160)'
?[jhiver at future jhiver]$

As you can see when I switch to this locale, the terminal clearly shows 
that there is a weird character going on. Now try the same thing with 
the right locale:

[jhiver at future jhiver]$ export LANG=en_GB
[jhiver at future jhiver]$ export LC_ALL=en_GB.UTF-8
[jhiver at future jhiver]$ perl -e 'print chr(160)'
 [jhiver at future jhiver]$

Surprise! As you can see, a unicode non breaking space in a UTF-8 
terminal appears as... a non breaking space!

>Yeah, that's nice. I thought there was mention of support for these
>entities. I wonder why it's not working for me?
>  
>
Well you need to run tests by varying the following parameters:

echo $LANG
echo $LC_ALL
perl -v (try with perl 5.6.1 and perl 5.8)
Petal::Parser::HTB and Petal

You also need to know if you are using a UTF-8 terminal or a latin1 
terminal...

Then I might be able to give a hand... Sorry if I'm not very responsive, 
but you know "it works for me" and "i'm busy" and "excuse #352"... If 
you tell me exactly what's going wrong I'll try to take a look though :)


Cheers,
Jean-Michel.