wxHtmlPrintout::RenderPage() renders the body first and then the header
and footer through m_RendererHdr, calling
m_RendererHdr.Render(x, y);
which leaves wxHtmlDCRenderer::Render()'s "to" parameter at its INT_MAX
default. The header is therefore free to draw the full height of its
HTML, not just the header area -- and an HTML background colour drawn by
the header covers the body that was rendered underneath it.
Pass the header and footer heights, which RenderPage() already knows, as
the bound.
The test renders a page with a body background colour and a header into a
wxMemoryDC and checks that a pixel well inside the body still has the
body's colour.
Closes#26915.
Assisted-by: Claude
The test used a font with a fixed size in pixels and passed its point size
to SetStandardFonts() in order to be independent of the DPI, but this only
works if wxFont uses the same DPI for the pixel to point conversion as the
one used when rendering the text later, which is not the case under wxGTK,
where wxFontInfo(wxSize(10, 16)).GetPointSize() returns 9 and not the
expected 12, resulting in smaller text and hence fewer pages than expected.
Compute the point size corresponding to the desired pixel size ourselves,
using the PPI of the DC the text is going to be rendered on, and also set
the printer PPI to the screen one, on all platforms and not just wxGTK3,
to ensure that the fonts are not scaled when rendering.
Store BODY BGCOLOR in the wxHTML parser state even when there is no
window interface, then carry the parsed colour onto the renderer root
cell so wxHtmlDCRenderer fills printed pages with it instead of white.
Add a renderer regression test covering BODY BGCOLOR output.
Fixes#20652.
Closes#26677.
For some reason, the height of a text line is 15px there and not 18px as
locally, so 400px high image still fit on the second page in the last
test. Make it higher to ensure that it doesn't.
Set the "printer" PPI explicitly for wxMemoryDC used in the test to
ensure that it's the same in all ports: currently wxGTK3 stands out
because it uses 72 DPI unlike wxMSW and wxGTK2, which use 96.
The standard margins, expressed in millimeters, could result in the
usable page space being much smaller than 1000px used for the DC size
when using higher DPIs, which means that the test checking that a 2400px
image took only 3 pages could fail, as it could require 4 of them in
this case.
Fix this by getting rid of the margins, as this should ensure that the
page height is exactly 1000px now, independently of the actual DPI.