2014-09-23 15:52 GMT+03:00 Allan <agande...@gmail.com>: > On 23/09/14 01:26, Jack wrote: >> >> On 2014.09.22 18:12, Allan wrote: >>> >>> On 22/09/14 22:25, Jack wrote: >>>> >>>> On 2014.09.22 15:17, Allan wrote: >>>>> >>>>> On 22/09/14 19:04, Jack wrote: >>>>>> >>>>>> On 2014.09.22 13:08, Allan wrote: >>>>>> [snip....] >>>>>>> >>>>>>> I don't think it really matters what font the system is using, as >>>>>>> long as that font is available. I'm using DejaVu Sans at the >>>>>>> moment, but I understand that if that is not available, the system >>>>>>> will substitute a similar one. >>>>>> >>>>>> >>>>>> I'm not sure you understand my question. If the system is displaying >>>>>> a font other than the one you specify but doing the size calculation >>>>>> based on the font you specified, then the calculation may not match >>>>>> the display. I'm just trying to be sure the size calculations are >>>>>> being done with whatever font is actually being displayed. >>>>> >>>>> >>>>> As I specify the same font for both, wouldn't that avoid the situation >>>>> you foresee? >>>> >>>> Not necessarily. You specify font X for display, but the system uses >>>> font Y. You specify font X for doing font matrix calculations, and my >>>> question is whether you know for sure that it is doing those >>>> calculations on font X or on font Y. Since those calculations are not >>>> necessarily tied to the active display, I can imagine the system not >>>> doing the font substitution. >>> >>> >>> My non-expert view is that, if I specify font X, but the system >>> substitutes font Y, then the system would only have cause to do that >>> if font X was not available. So, I don't see how, some nano-seconds >>> later, font X has suddenly become available and now gets used. I hope >>> I don't need to keep checking? >> >> I'm no more an expert than you, but I take a slightly paranoid approach >> here. First, I don't know that non-availability is the only reason for >> a system to use a font other than the one requested. I can imagine a >> use case where user preference takes precedence, for example. (Think >> css.) I can also imagine that when asked for font metrics for a >> non-available font, the system might use some defaults, and not >> necessarily those for the font it substituted in a particular instance. >>>> >>>> >>>>> So far, all looks well on both systems now. The column widths are >>>>> identical, and the only difference is in the overall width of the >>>>> tableWidget. That, I believe, comes from the margins, which do >>>>> differ, but I have already taken that into account. The aspect ratios >>>>> of the two screens are different, too. >> >> Again, taking the paranoid view, I'm not sure "both systems" is a >> sufficient sample. I take Cristian's view here that it is generally not >> a good idea to override the user's choice of system default font. Think >> of a vision impaired user who has chosen a particularly large font, or a >> font chosen specifically for readability. If you can query what font >> was actually used, and then use that to request the metric calculations, >> shouldn't that give equivalent results? >>> >>> >>>> Are the fonts identical? >>> >>> >>> I take it you mean between my two systems? Again, my non-expert view >>> is that if the two fonts have the same name, then the are identical. >>> Otherwise, they would not be the same font. >> >> I accept that - but if those two systems are both using the font you >> requested, then what happens when a system does not have that font >> available? >>> >>> >>>> If not, then why should the column widths be identical? >>> >>> >>> If the columns contain the same data and use the same font, then that >>> gives me the information needed to calculate/obtain the pixel width, >>> and therefore I use that to set the column width. >> >> Again, the question is whether you can be sure that is the font that >> will always be used? New train of thought - what about non-Roman >> character sets? Greek? Cyrillic? Arabic? It may be that the >> procedure you use will set up appropriate column widths, but if that is >> the case, then what have you actually gained from specifying a font? >>> >>> >>>> I assume the point is for the column to display the text in it >>>> without clipping and without wasting space. To me, different fonts >>>> are likely to need different column widths. >>> >>> >>> Yes, that was exactly the problem I had, which led me to specify the >>> actual font to use for both calculations and display, within the >>> plugin, to avoid the idiosyncrasies of different distros. It seems to >>> be working. >>> >> While my argument is certainly more academic than practical, the >> minimalist in me asks why you would specify more than you need to. My >> paranoid self asks whether your font specification has really done what >> you expect, or if it simply happens to achieve the expected results in >> the cases you have tested. (Just for context, I have several friends >> that would call this exchange a "violent agreement.") >> >> Jack > > > To cut a long story short, perhaps we should "violently agree" on a font > selector button on the first wizard page, opening a small window with > suitable combo boxes?
Are you serious? I didn't read the above dialog completely. Regards, Cristian > > Allan > > > > _______________________________________________ > KMyMoney-devel mailing list > KMyMoney-devel@kde.org > https://mail.kde.org/mailman/listinfo/kmymoney-devel _______________________________________________ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
