[Kmymoney-devel] String pixel widths differ

[Allan]

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?

Allan