Bug 73965 - [testcase] problems rendering HP LaserJet Web Pages (regression)
Summary: [testcase] problems rendering HP LaserJet Web Pages (regression)
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml renderer (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-01 17:51 UTC by djoham
Modified: 2004-02-11 17:34 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
tar.gz of a recreation demonstrating the problem (1.53 KB, application/octet-stream)
2004-02-01 17:52 UTC, djoham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description djoham 2004-02-01 17:51:34 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc 3.2.2 
OS:          Linux

Hello all!

In my "other life", when I'm not working with the HierMenus dude, I design and develop web content
for HP LaserJet Printers. Up until now, KHTML has been able to render the XHTML 1.0 strict and the CSS that I use to draw
some of my tabs just fine with the exception of some minor z-index issues (described in bug
43546).

However, KHTML from current CVS has some more serious issues with this tabs. I've attached a quick
XHTML test case.

The basic problem seems to be that <a> tags with margins seem to be mucking around with the
relative positioning of <img> elements surrounding them. In the test case, if you remove the
margin-left and margin-right CSS rules from a.hpSelectedTabLabel, then the tab renders as it
should - sans the margins of course.

For what it's worth, I think Safari (pre 1.0) had this problem as well. Safari 1.0 did not have
the problem, but I have no idea what they did to fix it.


If someone could look at this, I would greatly appreciate it. There are a *lot* of LaserJets out there with this code and I
don't want their web pages to look goofy in Konqueror - especially since they used to work.

Also, if there is anything else that I can do to help debug the problem, please let me know.

Best regards,

David
Comment 1 djoham 2004-02-01 17:52:56 UTC
Created attachment 4473 [details]
tar.gz of a recreation demonstrating the problem

Compare rendering with Mozilla and Konq 3.1x please and you'll see the
regression.
Comment 2 Germain Garand 2004-02-11 14:43:51 UTC
CVS commit by ggarand: 

Activate/merge alternate code path for inline boxes
 construction and painting. 
Whitespace count consistency (justification).

CCMAIL: 44092-done@bugs.kde.org,51163-done@bugs.kde.org
CCMAIL: 73965-done@bugs.kde.org,73823-done@bugs.kde.org,62283-done@bugs.kde.org


  M +29 -0     ChangeLog   1.203
  M +168 -194  rendering/bidi.cpp   1.180
  M +6 -6      rendering/font.cpp   1.25
  M +1 -1      rendering/render_block.h   1.14
  M +28 -5     rendering/render_box.cpp   1.226
  M +2 -2      rendering/render_box.h   1.73
  M +32 -11    rendering/render_line.cpp   1.12
  M +12 -8     rendering/render_object.cpp   1.249
  M +7 -2      rendering/render_object.h   1.177
  M +3 -3      rendering/render_replaced.cpp   1.160
  M +2 -2      rendering/render_replaced.h   1.70
  M +5 -5      rendering/render_table.h   1.101
  M +22 -127   rendering/render_text.cpp   1.237
  M +7 -6      rendering/render_text.h   1.105



Comment 3 djoham 2004-02-11 17:34:32 UTC
I can confirm this fixes the problem. Thank you!