[Kmymoney-devel] String pixel widths differ

Tue Sep 23 15:00:21 UTC 2014

FWIW, I stopped using Qt Designer because it kept adding font settings
and other stuff whenever I edited a .ui file.
In the end, I ended up editing files with a plain text editor, so I
know what is actually being changed.

IMHO, we shouldn't set fonts other than the ones defined by the KDE
theme. Specially for setting a specific width.

But overall, please try to keep it civil. I know this discussion has
been going for a long time, and we are all tired and want to move on
to something else.

Let's step back a little and try to figure a solution that works for everyone.

Regards,
Alvaro

On Tue, Sep 23, 2014 at 11:32 AM, Cristian Oneț <onet.cristian at gmail.com> wrote:
> 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
>>
>>
>>
> _______________________________________________
> KMyMoney-devel mailing list
> KMyMoney-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kmymoney-devel