Bug 61417 - [testcase] No Umlaut entities displayed when they are in a .xml file
Summary: [testcase] No Umlaut entities displayed when they are in a .xml file
Status: CONFIRMED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: 4.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-19 09:49 UTC by Andreas Leuner
Modified: 2021-03-21 00:25 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
From this document, the (366 bytes, text/xml)
2003-07-19 09:51 UTC, Andreas Leuner
Details
The ' (366 bytes, text/html)
2003-07-19 09:53 UTC, Andreas Leuner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Leuner 2003-07-19 09:49:49 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources

In an XHTML 1.1 file umlaut character entities are not displayed at all if that file ('s name) has no .html or .xhtml ending. Test case follows
Comment 1 Andreas Leuner 2003-07-19 09:51:50 UTC
Created attachment 2027 [details]
From this document, the
Comment 2 Andreas Leuner 2003-07-19 09:53:52 UTC
Created attachment 2028 [details]
The '
Comment 3 Andreas Leuner 2003-07-19 09:57:52 UTC
both test case files are identical, but they have different content types 
Comment 4 Thiago Macieira 2003-07-19 12:16:05 UTC
Confirmed. And if I put Konqueror in Latin1 in the first file, the entity is displayed. 
Comment 5 Andreas Leuner 2003-07-21 14:22:11 UTC
That's interesting. If I changed the charset in the file there would be no
difference (i.e. no 'ü' displayed). That means a narrow condition for that
behavior. 
BTW I discovered all this when looking at http://mozilla.linuxfaqs.de/css (in
german). That's some kind of mozilla 'propaganda' site. They have a few cool
testcases there. Among other problems, you can't see the umlauts in Konqueror.
Comment 6 Nicolas Goutte 2003-12-22 01:03:21 UTC
The classical problem: as Konqueror is a HTML browser, not a XHTMl one, it does not handle the XML declaration. So the title is expected in ISO-8859-1 not in UTF-8, which is declared one line below it, incorrectly as it does not follow the HTML-compatibility guidelines of XHTML 1.0.

Have a nice day!
Comment 7 Andreas Leuner 2003-12-22 11:39:22 UTC
Sorry but my report was not specifically because of the umlauts in the title but also because of them everywhere else. The string "CSS-Menü" should also appear in a paragraph inside the document. In Konqueror the "ü" (= ü) is missing. And I wonder why a character encoding (even a wrongly set one) would affect 'my' umlauts if they were given as HTML-entities in the source code. Instead they aren't displayed at all.
Besides I couldn't see why something like <title>CSS-Men&uuml;</title> (as it appears in _both_ testcases) was against the HTML-compatibility guidelines.
And if Konqi ignored the <?xml ... ?> line (if I understood correctly) I do even less understand why some HTML entities are not displayed.
Comment 8 Andreas Leuner 2003-12-22 11:52:48 UTC
BTW I can confirm this behavior for Konqi( or KHTML)'s CVS_HEAD 20031205.
And please do not get distracted by the character encoding problems on this page. Some of the comments I made with Konqi (including this one: '
Comment 9 Nicolas Goutte 2003-12-22 12:22:23 UTC
Good, if you are using CVS HEAD, I am stopping here, as it might also be a regression.

But what may be also the case: you are serving the first test case as text/xml (not text/html, not apllication/xhtml+xml) so by default you only have the XML character references (lt, gt, amp, quot, apos.)

Have a nice day!
Comment 10 Sebastian Sauer 2005-03-21 05:43:12 UTC
Still reproducable for me with KDE 3.3.2. If I change encoding to utf-8 (from autodetect / western europe) as defined in the XML everything works as expected.
Comment 11 George Goldberg 2008-04-06 06:23:13 UTC
Bug still reproducible in svn trunk r793457.
Comment 12 Justin Zobel 2021-03-21 00:25:25 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 10 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.