Report Charts

Geert Janssens geert.gnucash at kobaltwit.be
Fri Dec 9 06:54:23 EST 2016


Bob,

I was looking into this just now.

I had made the same observation that setting the parent elements (html and 
body) to 100% height would resize the chart to full height and then some.

I haven't looked further in that direction though as I found a possible other 
way to get around this.

It appears a missing or invalid DOCTYPE header makes browsers behave 
differently. That's why your code worked before. The DOCTYPE header has been 
invalid since March this year.

By dropping the DOCTYPE header, the chart suddenly does size to 100% height 
*without* the scroll bars. So this seems to put browsers in a  quirksmode that 
doensn't require parent elements to have a 100% height.

I've checked some modern websites on the net. Most content management based 
sites (like based on drupal or wordpress) don't include this header at all. 
Others like google and mozilla reduce it to <!doctype html>.

The latter unfortunately is considered a valid doctype header and restricts 
the chart to 300px again.

For our purposes, the doctype shouldn't matter that much, as long as the 
document is rendered the way we want. So for now I have just dropped the 
DOCTYPE header completely.

I'm not sure we could work around this by explicitly sizing the html and body 
elements. jqplot does a lot of size calculations for the internal objects.

I found it's jqplot itself that makes the chart 300px high. You can observe 
this when you open an exported report with	firefox and then examine the live 
dom tree using firebug. While the html file itself has height: 100%, the live 
dom tree will have height: 300px; position: relative.
So that would be the point to investigate. Why is jqplot rewriting this to 
300px ? Where does this really come from ?

Geert

Op vrijdag 9 december 2016 11:09:46 CET schreef Robert Fewell:
> Drats, looks like the report pages I attached did  not get through, but I
> think I have answered my question.
> To set a percentage height, its parent element(*) must have an explicit
> height
> 
> It looks like this can be fixed by using viewport units, vh,vw, all modern
> browsers and IE>=9 support the new CSS units relative to viewport height
> (vh) and viewport width (vw):
> 
> or
> 
> the <html> and <body> need to have height:100%, "<style>html, body {
> height: 100%; width: 100%; margin: 0; }</style>"
> 
> In both cases, the chart is displayed full view but with a vertical scroll
> bar for some reason which hope fully can be fixed.
> 
> Questions before I look further ...
> 
> Is there a preference for which setting to use ?
> And also should all the css style sheets works with the charts ?
> 
> Bob
> 
> On 8 December 2016 at 16:02, Robert Fewell <14ubobit at gmail.com> wrote:
> > Hi,
> > 
> > Just rebuilt with master and the report changes I made do not present the
> > charts in the same way, the width is 100% and can be varied but the height
> > turns out to be 300 pixels even though it is set to 100%.
> > 
> > 
> > I have traced this back to a commit from Geert,
> > https://github.com/Gnucash/gnucash/commit/e38fd5b5e5fc219cf2634382badf56
> > c8327ccf13 which changes the report header.
> > 
> > I have attached a pie chart report that has the two different headers for
> > you to see the difference.
> > 
> > Any ideas on how to fix this, seen this before ?
> > 
> > Bob
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




More information about the gnucash-devel mailing list