[Kmymoney-devel] String pixel widths differ

[Allan]

On 23/09/14 14:00, Cristian Oneț wrote:
> 2014-09-23 15:52 GMT+03:00 Allan <agander93 at 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

Well, there was a fair amount of to-ing and fro-ing!  So far as I am 
concerned, what it boiled down to is this.  You have expressed more than 
once the inadvisability of hard coding values, and I totally understand 
that, especially having had to contend with font variations.  I now have 
got that sorted, but only by 'hard coding' the font.  I tried using 
QApplication::font(), but I have no idea what that will produce on 
different systems, although it appears to produce non-identical results 
here.  QWidget::font() looks the same.

I mentioned half-jokingly that a Chinese user might not be too happy, 
and Jack mentioned other non-Roman fonts.  I really have no idea what 
one of these might produce.

So, I was fairly serious in what I said, but it sounds like you may 
think otherwise.

Allan