Geert,
I was beginning to understand this point as well. Not that it makes
sense in any way. Why would a user choose to define an image along with
its accompanying text box by pixel? Further: the setting is "Plot width"
--and not "Width of pie and accompanying text box" or something equally
dense but accurate. "Plot" to me means "the image portion of this report."
I won't even go into the odd ways that these reports get jammed into a
multi column report, since I can't begin to understand what the various
factor are there. Suffice to say the result is not predictable or expected.
Now that I understand the idiosyncrasy, I will let the matter drop.
Maybe someday someone will investigate an improved method for rendering
these reports....
Thanks,
David T.
On 8/14/2019 6:44 PM, Geert Janssens wrote:
Your screenshot doesn't show this, but did you report also display a legend ?
I believe the legend and chart together are fitted into the dimensions you
set. If the text in the legend varies from report to report, that my explain
why the charts themselves vary as well.
Geert
Op dinsdag 13 augustus 2019 10:47:43 CEST schreef David T. via gnucash-user:
I'm pretty sure that this code isn't making sizing decisions based on
readability-- at least not in my experience. It is perfectly happy to cram
huge amounts of data into tiny on screen areas... Percentages default to
100%, but remember previously stored values.
On Tue, Aug 13, 2019 at 13:24, Adrien
Monteleone<adrien.montele...@lusfiber.net> wrote: I could see how more
actual slices (regardless of how many accounts were chosen) would maybe
trigger a larger size than a really small one specified for readability.
But still, that should be only a default behavior and should not override a
specified size.
I think yes, the percentage is based on the width of the ???printable??? area of
the report. (and it looks like the default is 100% or else it just
remembers what I used last)
Regards,
Adrien
On Aug 13, 2019, at 2:45 AM, David T. <sunfis...@yahoo.com> wrote:
I will try using percentages, although why a percentage (based off what?
Window dimensions?) would be more reliable is beyond my ability to
comprehend.
As for number of slices, they all are set to the same value; it's just
that the number of matching accounts is limited. Again, why that would
affect overall pie size goes beyond my comprehension.
David
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information. -----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information. -----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
