[Kmymoney-devel] String pixel widths differ

[Cristian Oneț]

2014-09-23 16:54 GMT+03:00 Allan <agander93 at gmail.com>:
> 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.

So now the advice of not to hardcode fonts is used as an argument to
add a font selector on the first page of the CVS importer? Why not add
then a resolution selector while we're at it.

Now seriously, why don't we simply trust the system configuration
which is under the user's control? Why do we have to doubt everything
and conceive impossible scenarios to handle when the common use case
is not polished?

Regards,
Cristian

>
> Allan
>
>
>