332225 - Rendering type overlaps rendered schematic

Status: NEW

(Core :: Layout: Floats, defect)

Description

[John Jeffers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Rendering type overlaps rendered schematic (Getting Four Output lines out of an ISA Bus LG March issue)

Just below this headline

This is yet another example for testing.  

Reproducible: Always

Steps to Reproduce:
1.go to Linux Gazette March 2006 issue
2.Read article 1200x1024 pixels full screen
3.Source code overlaps onto http://linuxgazette.net//current/misc/dutta/cir_out.jpg 580x700 pixels

Actual Results:  
[root@thelinuxmaniac~]# cat /proc/ioports
0000-001f: dma1
0020-0021: pic1
0040-0043: timer0
cat /proc/ioports overlaps onto jpeg schematic
ca

Expected Results:  
cat /proc/ioports should not overlap onto schematic jpeg

I would expect ("User Expectation") rendering engine to either double line the source code which may be in certain circles bad form or inject white space to get the offending line of source code to fall below the jpeg.

I find a number of double bind decisions (and this is) for the rendering engine for it not to pick the decision I might have hand crafted.  While understandable for example there would be two layout decisions that most often would be undertaken.

1) Push the Jpeg smaller and/or up or down.
2) Inject white space to keep the indicated source code together and in such a position that one can cut and paste to compile source code with gcc. 

I report this to add additional test data for test plan.  Linux Gazette is tradional "Magazine Format" available in gz format crafted with some care so user expectation will be understood by most people.  This is a typical example of interference between picture and text told to keep together.

Comment 1

[:Mook]

Attachment: reduced test case

Reduced testcase.  View with window at something less than 1500px wide.
It appears the <pre> tag makes it overlap; normal text does not.

I have not yet looked for dupes or specs relating to this; not counting this as triaged yet.

Comment 2

[Daniel.S]

Attachment: different testcase

Comment 3

[Daniel.S]

The problem doesn't seem to be the pre-element but the white-space property (if set to pre, didn't test other values).

Safari renders the same we do. In Opera the text overlaps on any element. In IE8, no element does overlap (which is correct I guess).

This could be related to bug 25888, but to be honest, I don't know how white-space would influence the rendering here.