|Summary:||FC4 Release Notes appear to have bad encoding|
|Product:||[Fedora] Fedora Documentation||Reporter:||Bevan Bennett <bevan>|
|Component:||release-notes||Assignee:||Karsten Wade <kwade>|
|Status:||CLOSED UPSTREAM||QA Contact:||Tammy Fox <tammy.c.fox>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-08-18 19:18:39 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Bevan Bennett 2005-06-14 16:10:17 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4 Description of problem: Using default FC3+Firefox in ISO-8859-1 or UTF-8 encoding, the new release notes contain a number of odd characters that make the page readable, but ugly. I suspect that this is some sort of export problem, as I often see the same sort of garbage when exporting .doc files to HTML. These characters appear in the HTML source, not just the rendered HTML. The copyright symbol should also probably properly be represented as "©. As a nit while we're on the subject, the w3c validator suggests that this page should be labelled as HTML 4.01 Transitional rather than Strict, because it's not legal 4.01 Strict... Version-Release number of selected component (if applicable): NA How reproducible: Always Steps to Reproduce: 1. FC3, Western Encoding, Firefox 2. Browse to http://fedora.redhat.com/docs/release-notes/fc4/ 3. Expected Results: Release notes displayed without garbage Additional info: While it's not a crasher bug, if more people see the release notes like this it's not going to be good PR. Ooo, trying to submit this is generating internal server errors. I'll try removing my examples and sending them as an attachment instead
Comment 1 Bevan Bennett 2005-06-14 16:19:43 UTC
It looks like "smart quotes" are once again the most common culprit.
Comment 2 Bevan Bennett 2005-06-14 16:33:08 UTC
Created attachment 115416 [details] "Corrected" HTML I used the chart at http://cliki.tunes.org/HTML%20special%20characters%20and%20symbols to do a quick search and replace, using ™ — etc instead of the extended symbols.
Comment 3 Miloslav Trmač 2005-06-14 16:40:32 UTC
*** Bug 160346 has been marked as a duplicate of this bug. ***
Comment 4 Miloslav Trmač 2005-06-14 16:40:43 UTC
*** Bug 160347 has been marked as a duplicate of this bug. ***
Comment 5 Miloslav Trmač 2005-06-14 16:40:56 UTC
*** Bug 160348 has been marked as a duplicate of this bug. ***
Comment 6 Karsten Wade 2005-06-14 20:49:33 UTC
Adding common blocking tracker bug, as specified.
Comment 7 Karsten Wade 2005-06-14 21:10:01 UTC
There are a number of layers happening here. I think the primary situation is using UTF-8 envar on the build system, in this case, my laptop. This is not bad, but it has problems when you combine it with the situation we had on fedora.redhat.com up until this morning. The PHP includes did not have a charset attribute in the <META> tag, and presumably httpd was using the default ISO-8859-1 from /etc/httpd/conf/httpd.conf. We added charset=utf-8 to the include so all pages on f.r.c are served using utf-8. Now this breaks a few other docs that I will rebuild using UTF-8 and hope they work out. Interested if the release notes look better now. Long term, we need to coordinate the documentation better from writing to publishing.
Comment 8 Bevan Bennett 2005-06-14 21:13:37 UTC
Changing the stated character set has indeed resolved this from the perspective of my browser.
Comment 9 Karsten Wade 2005-08-18 19:18:39 UTC
Making the global changes to the fedora.redhat.com pages was sufficient. This is now consistent with a default install of FC.