Summary: | Font selection in HTML gives unexpected results | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Carl Thompson <cet> |
Component: | khtml parsing | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ismail, murray |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Carl Thompson
2003-11-05 22:21:53 UTC
the two first cases display utopia to me and the third one is simply invalid CSS, so it's result should be fine to be undefined. BTW: it's not konqueror that's deciding it, it's Qt. Subject: Re: Font selection in HTML gives unexpected results > ------- Additional Comments From coolo@kde.org 2003-11-06 10:41 ------- > the two first cases display utopia to me Hmmm, this is weird. For me the second example normally shows up as 'ms reference sans serif' (not the requested 'ms sans serif'). However, if I change the default font in Konqueror's settings to 'ms reference sans serif' then the second example shows up as 'utopia!' I have no idea why changing the default font would have anything to do with the font used for the second example. Clearly, there is something very wrong here... > and the third one is simply invalid CSS, so it's result should be fine to > be undefined. I agree that it is invalid CSS (or invalid HTML if the 'font' tag is used). However, I have seen several sites in addition to washingtonpost.com that are requesting 'ms sans serif' in the exact same broken way so there is probably some common site building tool that generates this broken code. Since several real world sites are known to do this, Konqueror should probably display it properly. Since the font list is comma delimited anyway, it does not seem like it should be hard to handle unquoted font names the exact same way and fix the broken rendering of these sites. > BTW: it's not konqueror that's deciding it, it's Qt. I tried to test this by changing the default font used by Qt applications in my qtrc file. I cannot duplicate this type of behavior in pure Qt applications so it does seem to be Konqueror/KDE specific. In any case, Konqueror/KHTML _should_ absolutely be deciding the exact font used. Only Konqueror parses the HTML and knows the exact fonts specified by the web developers and the default font specified by the user. To reiterate what I said previously, the font used should be an exact match of one of the fonts specified by the web developer or if none match the default font specified by the user. No other font should ever be used in my opinion. Thanks, Carl By the way, I forgot mention that Mozilla and Opera both choose the fonts that I expect and act the way I've described even for the third case (invalid CSS/HTML because multi-word font name is unquoted). Internet Explorer does too (but I needed to change the test a little because 'ms sans serif' is actually on my Windows box). Konqueror is doing something different than the three "biggest" browsers and to me this means that Konqueror should be fixed to choose fonts in the same way. Subject: kdelibs/khtml CVS commit by coolo: handle invalid font families (as discussed with Dirk I'm commiting my version of the patch and will after that try to merge the safari code to handle even more cases) (this problem is the cause of many bug reports, I'm just picking one :) CCMAIL: 67348-done@bugs.kde.org M +5 -0 ChangeLog 1.106 M +24 -3 css/cssparser.cpp 1.278 --- kdelibs/khtml/ChangeLog #1.105:1.106 @@ -1,2 +1,7 @@ +2003-11-24 Stephan Kulow <coolo@kde.org> + + * css/cssparser.cpp (parseFontFamily): handle invalid font families like + font-family: ms sans serif, utopia + 2003-11-24 David Faure <faure@kde.org> --- kdelibs/khtml/css/cssparser.cpp #1.277:1.278 @@ -1518,6 +1518,27 @@ CSSValueListImpl *CSSParser::parseFontFa list->append( new CSSPrimitiveValueImpl( id ) ); else if ( value->unit == CSSPrimitiveValue::CSS_STRING || - value->unit == CSSPrimitiveValue::CSS_IDENT ) - list->append( new FontFamilyValueImpl( qString( value->string ) ) ); + value->unit == CSSPrimitiveValue::CSS_IDENT ) { + QString face = qString( value->string ); + // the grammar says we can only have comma separated strings, + // but the real life HTML contains stuff like "font-family: ms sans serif, adobe helvetica" + // so we look ahead in the list and if the next item is a string too, we concat the strings + // before we take it as item + caughtinvalid: + value = valueList->next(); + if ( value ) { + if ( value->unit == CSSPrimitiveValue::CSS_STRING || + value->unit == CSSPrimitiveValue::CSS_IDENT ) { + face += " " + qString( value->string ); + goto caughtinvalid; + } else if ( value->unit == Value::Operator && value->iValue == ',' ) { + value = valueList->next(); + } + } + list->append( new FontFamilyValueImpl( face ) ); + if ( value ) + continue; + else + break; + } else { // kdDebug( 6080 ) << "invalid family part" << endl; *** Bug 67819 has been marked as a duplicate of this bug. *** This fix works for me as expected to resolve this bug. Thank You! thanks for telling |