Mark Dootson mark.doot...@znix.com writes:
On 30/04/2013 19:19, Johan Vromans wrote:
We may assume that the Perl string is in Perl's internal encoding.
No we may not.
In that case you'll run into all kinds of encoding problems anyway.
See e.g. perlunitut.
I kind of like the existing
Hi,
On 01/05/2013 07:34, Johan Vromans wrote:
Mark Dootson mark.doot...@znix.com writes:
On 30/04/2013 19:19, Johan Vromans wrote:
We may assume that the Perl string is in Perl's internal encoding.
No we may not.
In that case you'll run into all kinds of encoding problems anyway.
If
Octavian,
I loaded up a Windows XP system, installed ActivePerl 5.14.5, and found
the issue.
The 'Arial' font on your system is not the same as the 'Arial' font on
my Windows Vista machine. Whether this is because I have a version of MS
Office installed which comes with enhanced fonts or it
Hi Guys,
Well, this morning I'm inclined to agree that this ought to be the case.
At least for:
$orig = readline($datafile);
$line = decode( 'UTF-8', $orig );
$w = Wx::StaticText-new( ... );
$w-SetLabel($line);
On the other hand I'm reluctant to introduce something that I'm certain
Hi,
On 01/05/2013 16:49, steveco.1...@gmail.com wrote:
Well all this just serves to deepen my confusion.
1) What is the difference between:
$line = decode( 'UTF-8', $orig );
and
$line = decode( 'utf8', $orig );
Always use
decode( 'UTF-8', $orig );
'UTF-8' means what it says.
In my
Hi,
I have build errors with Wx = 0.9918. They all fail because of a
missing typemap:
0.9918 = Could not find a typemap for C type 'wxPlFontEnumerator *'
0.9919 = Could not find a typemap for C type 'wxRegionIterator *'
0.9920 = Could not find a typemap for C type 'wxRegionIterator *'
0.9921 =
Hi,
Indeed there are some missing specs in the typemap template.
Strange that yours is the only report where this bug manifests itself (
that is, 'make' decides the typemap needs to be rebuilt. )
Anyhow, attached patch for 0.9921 fixes it.
There are a few other things I wish to complete
Yep, good to know.
It would be nice if WxPerl would announce somehow that a font doesn't have
the necessary glifs (maybe with a warning).
And btw, if the constant wxVSCROLL is not necessary, (do I understood
correctly that it is not necessary under Linux either?) and if it creates
problems
Hi,
perldoc for the module Encode says:
-
CAVEAT: When you run $string = decode(utf8, $octets) , then $string
might not be equal to $octets. Though both contain the same data, the
UTF8 flag for $string is on unless $octets
Hi Guys,
I don't have anything broken in this release in the 2 languages that I
currently support (English and Portuguese). But even so, the whole utf8
process has been a bit time consuming. As we become more multilingual, I'm
thinking that a global change to rename decode to libDecode (or
Hi,
On 02/05/2013 00:17, Steve Cookson wrote:
Or just
sub libDecode ($$){
return decode(@_);
}
At least all the things that might go wrong will all be here.
You're unduly worried ( probably my fault ).
my $string = decode($encoding, $binary);
Is fine.
Cheers
Mark
Hi,
On 01/05/2013 20:14, Octavian Rasnita wrote:
Yep, good to know.
It would be nice if WxPerl would announce somehow that a font doesn't
have the necessary glifs (maybe with a warning).
Nice to have, but there is no reasonable and practical implementation I
can think of. I am aware of how
From: Mark Dootson mark.doot...@znix.com
Hi,
On 02/05/2013 00:17, Steve Cookson wrote:
Or just
sub libDecode ($$){
return decode(@_);
}
At least all the things that might go wrong will all be here.
You're unduly worried ( probably my fault ).
my $string = decode($encoding,
13 matches
Mail list logo
