Version: (using KDE Devel) Installed from: Compiled sources The chat conversation consistently (all the time) uses font sizes larger than what Kopete is configured to use in the Appearance->Colours & Fonts configuration. My Kopete is configured for 'helvetica 12', but chats look more like 'helvetica 14'. I can offset this by adding 'text-size: 90%;' in the XSLT style.
which styles have this problem?
All of them...any style lacking my text-size CSS, at least.
On February 4, 2005 07:44 pm, Luke-Jr wrote: > The chat conversation consistently (all the time) uses font sizes larger > than what Kopete is configured to use in the Appearance->Colours & Fonts > configuration. My Kopete is configured for 'helvetica 12', but chats look > more like 'helvetica 14'. I can offset this by adding 'text-size: 90%;' in > the XSLT style. _______________________________________________ Can you "File->Save As".. a chat as HTML, and post the information inside the <style> tags of that HTML document here?
body{margin:4px;background-color:#ffffff;font-family:helvetica;font-size:12pt;color:#000000;background-repeat:no-repeat;background-attachment:fixed}td{font-family:helvetica;font-size:12pt;color:#000000}a{color:#0000c0}a.visited{color:#0000c0}a.KopeteDisplayName{text-decoration:none;color:inherit;}a.KopeteDisplayName:hover{text-decoration:underline;color:inherit}.KopeteLink{cursor:pointer;}.KopeteLink:hover{text-decoration:underline}.highlight{color:#000000;background-color:#ffdd76}
Well, as you can see right there, the style says to use 12 pt. If it appears to you that it is not 12 pt, well, I dont know what to tell you. Maybe you should post the entire HTML page as an attachment and we will re-direct to KHTML.
Created attachment 9433 [details] Kopete chat in HTML -- discussing Kopete styles and such Example of the problem
On Saturday 05 February 2005 03:29, Luke-Jr wrote: > Kopete chat in HTML -- discussing Kopete styles and such > > Example of the problem If I change the font-size in that document from 12pt to 30pt, the text gets bigger, as I would expect. So either it should be 12pt (in which case there's no bug here), or it shouldn't (in which case the CSS is being incorrectly generated), or it's rendering differently in the Kopete chatwindow to in Konqueror...
in my experience , this bug is in kopete since ... i started using kopete the first time ! this is a konqueror and kopete problem , i think its a khtml problem it can be kinda of fixed using the right dpi for the Xserver. i start the Xserver with -dpi 96 ( this kinda makes the sizes correct ) if you use a dpi of 100 or more , the fonts will be smaller , and if you use a size of dpi 75 , the fonts will be much larger !
On Saturday 05 February 2005 12:13, Iori Yagami wrote: > this is a konqueror and kopete problem , i think its a khtml problem > > it can be kinda of fixed using the right dpi for the Xserver. > > i start the Xserver with -dpi 96 ( this kinda makes the sizes correct ) > > if you use a dpi of 100 or more , the fonts will be smaller , and if you > use a size of dpi 75 , the fonts will be much larger ! That's expected behaviour. 1pt is a 72th of an inch, so if you change the number of dots per inch the X server believes there are, you should expect the font size to change!
Em Sábado, 5 de Fevereiro de 2005 13:08, o Richard Smith escreveu: > That's expected behaviour. 1pt is a 72th of an inch, so if you change the > number of dots per inch the X server believes there are, you should expect > the font size to change! no , you didnt understand ( perhaps i did not explain well ) the fonts get much larger , but the fonts on the chatwindow . in 75 dpi , the fonts in the chatwindow will be much larger than the fonts , ... for example , in the input box. ( and the rest of the kde , like menu's , titlebar , etc )
On Saturday 05 February 2005 13:18, Iori Yagami wrote: > Em Sábado, 5 de Fevereiro de 2005 13:08, o Richard Smith escreveu: > > That's expected behaviour. 1pt is a 72th of an inch, so if you change the > > number of dots per inch the X server believes there are, you should > > expect the font size to change! > > no , you didnt understand ( perhaps i did not explain well ) > > the fonts get much larger , but the fonts on the chatwindow . > > in 75 dpi , the fonts in the chatwindow will be much larger than the > fonts , ... for example , in the input box. ( and the rest of the kde , > like menu's , titlebar , etc ) Maybe some of the font settings are being stored in pt, and the rest are being stored in px? If you change the dpi, do the fonts in the chat window change size, or the fonts everywhere else? (Or both, and if so by how much?)
Em Sábado, 5 de Fevereiro de 2005 13:31, o Richard Smith escreveu: > Maybe some of the font settings are being stored in pt, and the rest are > being stored in px? If you change the dpi, do the fonts in the chat window > change size, or the fonts everywhere else? (Or both, and if so by how > much?) if i change the dpi , the global KDE fonts change , but the kopete chatwindow font is always the same. that is why i figured the 96 dpi setting is more or less ( a little more i guess , maybe 94 or 93 ) is the dpi setting that makes all the fonts look like the same size. it seems by changing the dpi , all the fonts change size , except the khtml rendered fonts
KHTML bug. Reassigning.
On Saturday 05 February 2005 14:40, Iori Yagami wrote: > if i change the dpi , the global KDE fonts change , but the kopete > chatwindow font is always the same. [...] > it seems by changing the dpi , all the fonts change size , except the khtml > rendered fonts From khtml/rendering/font.cpp: void Font::update( QPaintDeviceMetrics* devMetrics ) const [...] const int lDpiY = kMax(devMetrics->logicalDpiY(), 96); Oh dear. This line is the cause of your bug. Basically: KHTML doesn't respect vertical DPY less than 96.
Likewise, from khtml/css/cssstyleselector.cpp: void CSSStyleSelector::applyRule( int id, DOM::CSSValueImpl *value ) [...] float toPix = paintDeviceMetrics->logicalDpiY()/72.; if (toPix < 96./72.) toPix = 96./72.; Presumably there's a good reason why vertical dpi less than 96 is ignored.
yes, last time I worked on that area I was totally puzzled by this line. I left it out of thinking "there must be an obscure reason", but since it breaks things, it shall go.
Sounds like it's that... My DPI is (IIRC) 75, and for good reason ;)
its a IE quirk. most webdesigners assume that everybody uses windows font sizes, and windows uses by default 96dpi. and there is really no display around anymore supported by KDE that has a dpi of less than 96dpi. if you have less than 96 dpi then most likely there is an error in your x configuration.
.. and I agree that it is a bit weird for kopete, but it fixes most broken websites out there so we cannot easily remove it. IMHO the setups of those users should be fixed who use broken dpi settings and way-too-big fonts.
I set my DPI to 75 to automatically adjust KDE's fonts to something sane. If I use X's default DPI (100?), everything in KDE is huge.
Em Sábado, 5 de Fevereiro de 2005 21:07, o Dirk Mueller escreveu: > its a IE quirk. most webdesigners assume that everybody uses windows font > sizes, and windows uses by default 96dpi. and there is really no display > around anymore supported by KDE that has a dpi of less than 96dpi. i didnt know that we as kde users should suffer from the bugs of IE. do we also break khtml all over to support bad websites like IE ?!
Actually, it's not even an IE bug. From the sound of it, certain web designers are specifying font sizes assuming that everybody has a 96 DPI display.
Actually, isn't the point of having this stuff relative to DPI so that it looks the same on the monitor? In which case, if someone has a <96DPI display, they would *want* it to be fewer pixels than on a 96DPI display...
e #18: mmh, I don't get the logic of it. There are many displays with more than 96 dpi nowadays (UXGA laptops come to mind), so sites specifying fonts in absolute pixel sizes will still be broken for those. Quite inconsistent. Also, what about specific situations such as giant screens where the dpi would be very low? It really sounds to me as a turnaround for broken X configurations... and if it's broken, it should be at least consistenty broken. IMHO, we shouldn't try to address that ourselves ;(
it was one of the most reported bugs in KDE 2.[1-2] times that konqueror's font sizes were way too small. and this is why.
Fonts specified in pixels aren't a problem, as far as I'm aware... KHTML doesn't mind adjusting for DPIs over 96... the problem is only for DPIs below 96. Also, if a webpage is seriously broken, there is always the zoom buttons...
Perhaps add an option to KHTML to use either X's DPI or to override it?
sorry, a lot more will be broken if your X dpi settings are wrong, so trying to remove a working solution ("hack") for that is not a good reason imho. e.g. all "show in original size" applications, like kpdf, ghostview, kword, openoffice etc will be wrong.
While it may be true that sites break, saying DPI < 96 is broken configuration is just plain wrong. A 17" monitor running at 1024x768 is ~80 dpi. Worse if you have a lower resolution (think of 800x600). In my setup, I told X my monitor's real dimensions. It calculates the DPI from that. What's wrong in that? But I digress... I guess this is probably a WONTFIX.
There should at least be an option somewhere to disable this hack for those of us who actually have a DPI under 96. While this may be technically a X misconfiguration on my part (some JavaScript DPI calculator says my DPI should be 96.4), I am running at the maximum resolution my monitor will support. Logically, any sane resolution (with over 60 Hz refresh rates) would be a <96 DPI configuration.
On Saturday 05 February 2005 23:13, Thiago Macieira wrote: > But I digress... I guess this is probably a WONTFIX. If that's the final decision on this, please reassign back to Kopete so we can put in a hack to munge the font size we give to KHTML so it renders correctly (using pixel size not point size would do the job).
On Saturday 05 February 2005 21:08, Dirk Mueller wrote: > .. and I agree that it is a bit weird for kopete, but it fixes most > broken websites out there so we cannot easily remove it. It seems like you're saying that: 1) Windows uses 96 DPI by default (this is configurable, of course, but that's rare in practice). 2) A lot of websites assume that 96 px == 72 pt (which is not necessarily 1 inch, since DPI may well be incorrect). 3) Allowing fonts in HTML pages to be smaller than the author intended (in pixels) causes breakage. Presumably there're no problems with fonts being unexpectedly large, since the current hack doesn't affect that. 4) Therefore, if the DPI in X is less than 96, KHTML assumes it is 96. This seems like a poor solution to a stupid situation, and it's certainly a KHTML bug. At the very least there should be a way to turn this off (in code if nothing else).
Em Sábado, 5 de Fevereiro de 2005 23:32, o Richard Smith escreveu: > If that's the final decision on this, please reassign back to Kopete so we > can put in a hack to munge the font size we give to KHTML so it renders > correctly (using pixel size not point size would do the job). this is done just to fix faulty windows users websites ( that even probably break khtml ) and by doing so , we break all the kde apps that use khtml ! its a fair trade off .... dont care about the apps on our system , just to appease ppl that dont care nothing about us !
sorry, we're not breaking ALL KDE applications. we're working around people who use broken distributions which ship broken x servers and use KDE software to use websites that can be viewed correctly on every windows machine.
On Sunday 06 February 2005 00:11, Dirk Mueller wrote: > we're working around people who use broken distributions which ship broken x > servers and use KDE software to use websites that can be viewed correctly on > every windows machine. If you want to detect the DPI not configured case, check for DPI == 75. That's what Qt does.
i am mentioning breaking all kde applications that use khtml. because apps like kopete , that use khtml , will have a font size in one space and another font size in another ( like the chatwindow and the input box ...) has anyone notice that mozilla has this very option ?! to choose the system dpi ?! a simple equal option would sufice ! now , i dunno why having a diferent dpi than 96 is wrong , but if you say so .. i wont bug post anymore ... this bug hack makes me have to hack the Xserver , but there are worse things in the world
Since it doesn't seem likely that this bug will be fixed, can some way to work around the brokenness be introduced? It was suggested to me that a KHTML-specific CSS attribute to respect the DPI value could be added, and this seems a reasonable way forwards.
Did this bug suddenly go on everyone's forgotten-list? What is the argument against an option to respect the correct DPI?
Did this just get worse? Now all my new Konqueror windows are using the same huge, annoying font size that was originally just Kopete :(
An interesting note-- Akregator still shows the correct font sizes, while Konqueror and Kopete are broken.
Created attachment 9918 [details] proposed patch implementing suggestion #35 restrict the hack to the only case where it might help
Created attachment 9921 [details] same as #9918 ; corrected copy/paste error
Still not in stable release in 3.5. After 4 releases no solution. I don't care about bad web designers. If a site isn't displayed properly, _they_ will have to take the heat, not the folks who made a proper html renderer. Since when doesn't the community stand up for pointing at fsck-ups? I haven't seen anyone suggest making cp1251 default encoding just because "IE or some loser web designers assume it".
I've got a DPI of 93 - 1920x1200 on a 24" TFT and I really think that the 96dpi-minimum forcement makes no sense. Is this still the case? Any update?
Gecko also does max(96dpi, system setting), but includes a "hidden" preference that can override that and use the actual system setting, or use a user specified DPI. Opera permits DPI to be manually set as well. http://mrmazda.no-ip.com/auth/dpi-screen-window.html offers an easy opportunity to check for DPI error.
The way the standard is being reformulated now there is always a spec DPI on 96. If you want to scale according to monitor resolution you now scale both pt and px. This way there is always the same relationship between pt and px in HTML/CSS, but both are relative to system DPI. Many laymen however find the scaling of px to be infuriating.
Btw. reading system dpi is also a problem. Since some stupid programs (read GNOME) change the system dpi to 96 rather than ignoring it. The bug has been closed as WONTFIX in GNOME svn, and means we can never rely on the DPI reported by X11 if the user runs GNOME applications.
There is not supposed to be a fixed scale between pt and px. 'pt' is a real-world unit, and 'px' is a display unit. 'px' should never be used for anything other than where it must-- mainly non-scalable image sizes. Who cares if GNOME won't fix bugs? Yet another reason to never touch GNOME junk... I like KHTML and prefer it over Gecko because it is more standards-compliant and does things the right way regardless of the "supports broken websites" way. What's wrong with patch 9921? It gives the correct behaviour whenever possible, and only fixes at 96 DPI when the correct DPI cannot be determined...
Actually px is not absolute unit, not even in the old standard. It has always been supposed to be scaled for high DPI devices (like 600DPI printers). The new interpretation used in CSS 2.1 is that px is always scaled. This way it is consistent in both low DPI and high DPI devices. To give you an idea of what kind of "broken websites" that assume a dpi of 96, I can mention one: The acid2 test. We get many bug-reports from distributions where konqueror doesn't pass the acid2 test because they have messed with the dpi.
*** Bug 118275 has been marked as a duplicate of this bug. ***
*** Bug 110250 has been marked as a duplicate of this bug. ***
Message from the Bugsquad and Konqueror teams: This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore. If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report. Thank you for your understanding.