Bug 105145 - The top of a line of text in HTML is cut off when the line above it is highlighted
Summary: The top of a line of text in HTML is cut off when the line above it is highli...
Alias: None
Product: konqueror
Classification: Applications
Component: khtml renderer (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
: 122673 (view as bug list)
Depends on:
Reported: 2005-05-05 16:36 UTC by Roey Katz
Modified: 2007-01-07 20:48 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:

3.5rc1 screenshot (114.74 KB, image/png)
2005-11-17 14:58 UTC, Tommi Tervo
css line-height scale (1.82 KB, patch)
2006-01-24 22:55 UTC, Ivor Hewitt
Snapshot from Konqueror 3.5.1. (57.19 KB, image/jpeg)
2006-02-25 15:24 UTC, Yann Villessuzanne

Note You need to log in before you can comment on or make changes to this bug.
Description Roey Katz 2005-05-05 16:36:07 UTC
Version:           3.4.0 (using KDE 3.4.0, Debian Package 4:3.4.0-0pre3 (3.1))
Compiler:          gcc version 3.3.5 (Debian 1:3.3.5-8)
OS:                Linux (i686) release 2.6.11-1-686-smp

The top of a line of text in HTML is cut off when the line above it is highlighted.

To repeat this:

- browse to http://www.securityfocus.com/columnists/320
- set font to Bitstream Vera Sans/Serif
- Zoom in a lot by holding Control as you scroll up on the mouse. 

You can see the result in the file "20050504 01 securityfocus.com.jpg"
in the directory at "http://roey.freeshell.org/mystuff/kde/" 
For comparison, please see the Firefox rendering in the file 
"20050504 02 securityfocus.com.jpg"

Sometimes when I don't feel like sluching forward all the way to read the teeny tiny text on the monitor, I increase the font size so that I can read it leaning back in my chair far away from the screen. This rendering messup happens with a lot of sites, and it does not seem to affect firefox.

- Roey
Comment 1 Roey Katz 2005-05-05 16:36:46 UTC
This should be in KHTML, not Konqueror, my bad
Comment 2 Wolfgang Scheicher 2005-11-17 14:02:49 UTC
looks like this happens a lot on pages that use css to set font-size and line-height.
Maybe the line height isn't scaled correctly with the font size when zooming in and out?
Comment 3 Roey Katz 2005-11-17 14:33:09 UTC
Recently changed paths to the screenshots:

How Konqueror displays the page:   http://roey.freeshell.org/mystuff/kde/konq/20050504-01-securityfocus.com.jpg
Here's Firefox's rendering:    http://roey.freeshell.org/mystuff/kde/konq/20050504-02-securityfocus.com.jpg
Comment 4 Tommi Tervo 2005-11-17 14:58:10 UTC
Created attachment 13509 [details]
3.5rc1 screenshot

3.5rc1 scales page like firefox on my computer
Comment 5 Josh Metzler 2005-11-17 15:04:53 UTC
3.5rc1 scales the body of the story correctly for me, but not the paragraph synopsis between the headline and the body.  For that paragraph, I get the selection overwriting text from the line above it.
Comment 6 Thiago Macieira 2005-11-29 02:13:23 UTC
Konqueror 3.5 r477777 and Firefox 1.0.4 render the page alike, even at absurd zoom levels.
Comment 7 Ivor Hewitt 2006-01-24 22:55:35 UTC
Created attachment 14374 [details]
css line-height scale

This patch applies the same zooming logic to CSS_PROP_LINE_HEIGHT as is applied
to CSS_PROP_FONT_SIZE which fixes the problem with this page.
Comment 8 Germain Garand 2006-01-25 09:18:27 UTC
patch looks fine to me.
Though you should keep the original wording of 'view && view->part()' for efficiency ('view' is a member of CSSStyleSelector that caches a pointer to the view during the style selection and is meaningful at this point)
Comment 9 Ivor Hewitt 2006-01-25 12:32:04 UTC
Hi Germain,
For consistency I used the same getDocument()->view()->part wording as used in the FONT_SIZE clause. I'll change back to the original wording and commit. I guess the  FONT_SIZE clause should also be updated to view->part too.
Comment 10 Germain Garand 2006-01-25 15:46:22 UTC
> I guess the  FONT_SIZE clause should also be updated to view->part too. 

it would look a lot better for sure... go ahead :)
Comment 11 Ivor Hewitt 2006-01-26 08:48:27 UTC
*** Bug has been marked as fixed ***.
Comment 12 Tommi Tervo 2006-02-25 13:27:13 UTC
*** Bug 122673 has been marked as a duplicate of this bug. ***
Comment 13 Yann Villessuzanne 2006-02-25 15:22:59 UTC
It seems that this bug is still present in KDE 3.5.1. 
I include a snapshot of the same page.

See also the description of Bug 122673.
Comment 14 Yann Villessuzanne 2006-02-25 15:24:18 UTC
Created attachment 14867 [details]
Snapshot from Konqueror 3.5.1.
Comment 15 Tommi Tervo 2006-02-25 16:44:52 UTC
It's fixed for 3.5.2
Comment 16 Roey Katz 2006-04-02 17:52:21 UTC
The following web sites also exhibit this buggy rendering when selecting text:


Note:  my DPI is 100x100, my screen resolution is 1920x1200, and Konqueror has Minimum fonts at 16 and Medium at 18.
Comment 17 Thiago Macieira 2006-04-05 09:25:18 UTC
Roey: have you tested KDE 3.5.2? I can't reproduce the problem on those two pages.
Comment 18 Roey Katz 2006-07-28 17:14:46 UTC
Thiago, this happens with many more pages for me (still).  For examples, please see http://roey.freeshell.org/mystuff/kde/konq/ from the month of July (files beginning with 200607*). 
Comment 19 Marko Burjek 2007-01-07 11:28:31 UTC
Konqueror 3.5.5
http://www.securityfocus.com/columnists/320 OK
http://gizmodo.com/gadgets/home-entertainment/squeezebox-3-drops-133026.php  OK
http://www.israelnationalnews.com/article.php3?id=6048 OK
http://digg.com/offbeat_news/What_happens_when_a_waterfall_freezes_over Some problems with number of diggs and title
http://www.vmware.com/products/server/ It looks messed up too

All pages were viewed at maximum zoom. I don't think that on both pages that weren't OK is this Konqueror's rendering problem. I think that rendering is OK but pages aren't intendet to be viewed under that much zoom.
Comment 20 illogic-al 2007-01-07 20:48:20 UTC
The problem described in the topic "top of a line of text in HTML is cut off when the line above it is highlighted" doesn't seem to be an issue in 3.5.5. 
The other aesthetic problems described are simply the result css styleing and render similarly on firefox ones I tested (vmware and digg page). Marking as fixed.