Op donderdag 15 augustus 2019 06:52:45 CEST schreef David T.: > 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?
I appreciate your user perspective on this and I can see the usefulness of strictly defining only the plot size in some way. While obvious from the outside it's unfortunately much less so when trying to implement this. Assuming we define the plot size only, then where should the legend be rendered ? On-screen you could argue the canvas size is infinite so it can go next to the plot even beyond the borders of the window. But what should happen with it when printed ? Note the choice for pixels is historical. Nowadays people are more interested in millimeters or inches. That adds the challenge of getting proper screen resolutions from the system to convert this back to pixels on-screen. And there are plenty more technical challenges. I believe most likely all can be solved, but it requires some thorough analysis of the report use cases, wishes and constraints. > 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 presume "Plot width" was the most dense the original author of that code could come up with a long time ago. Or originally there were no legends for the charts. Or we have changed chart rendering engines three times by now (and four times soon). Perhaps the original rendering engine did it differently. > 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.... It will first require someone to clearly describe the exact requirements of such an improved method of rendering. Feel free to focus your thoughts in an enhancement request! Geert _______________________________________________ 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.
