Index: src/src/resources/start_here/start_here.html
===================================================================
--- src/src/resources/start_here/start_here.html (revision 2473)
+++ src/src/resources/start_here/start_here.html (working copy)
@@ -1,10 +1,10 @@
-<?xml version="1.0" encoding="iso-8859-1"?>
+<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title></title>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style type="text/css">
a { background-color: inherit; color: blue; }
a:visited { background-color: inherit; color: blue; }
History
Fix for this bug.
http://developer.berlios.de/bugs/?func=detailbug&bug_id=7208&group_id=5358
The start here page now uses the utf-8 file encoding. This change is harmless, and is probably better. C::B uses Unicode so why not the start here page. :D
Fix for this bug.
http://developer.berlios.de/bugs/?func=detailbug&bug_id=7208&group_id=5358
The start here page now uses the utf-8 file encoding. This change is harmless, and is probably better. C::B uses Unicode so why not the start here page. :D
>This change is harmless, and is probably better.
>C::B uses Unicode so why not the start here page.
Did you verify whether this is really harmless?
ISO-8859-1 is perfectly "harmless", too, in fact it is what wxHTML sets as standard in non-Unicode builds.
I would be very careful with a "bugfix" for a phenomenon which is equally likely a bad setup as an actual bug, and which may break it for many people (everybody using a non-Unicode build?). In a "good" wxWidgets installation, ISO-8859-1 is certainly supported.
I am not against using UTF-8 as the encoding in general, but before making that change, you should at least thoroughly test in a non-Unicode capable environment.
wxHTML is a home-brewn class that displays a little HTML, and does a lot of voodoo which is not necessarily obvious at once. For example, it handles input and output encodings in non-Unicode builds, but uses wxFont and wxString conversion functions in Unicode build. It is not immediately obvious from looking at the sources what is supported and what is not, in either case.
First off I have one question why no e-mail on reply?
No I did not verify it is harmless at first, but I did just now (with the help of Lieven's nightlies.)....
I get an error message with wx 2.6.2
ANSI (tried it with Lieven's nightly build).
The document display's fine. :P
I know for a fact it works fine with wx 2.6.2 unicode (tried it with Lieven's nightly build), and wx 2.6.3 unicode (my own build from SVN trunk). I have not tested wx 2.6.3 ANSI (yet).
FTR I have wxMSW.
So not as harmless as I originally thought. My bad. :P
So, is this harmless or not?
Well noooo. Not exactly. :P
Now an error message would appear in wx 2.6.2 (assuming wx 2.6.3 ANSI too haven't tested it) ANSI builds now.
It works fine in wx 2.6.2/wx 2.6.3 Unicode builds.......
Oh well.
The bug this patch fixes (#7208) has been already fixed in trunk.
Requesting to be closed.