[Kmymoney-devel] DPI Setting

[Allan]

On 06/11/14 16:43, Jack wrote:
> On 2014.11.06 07:22, Allan wrote:
>> I'm working on  [Bug 340656] New: The csv importer dialog display is
>> broken on high DPI screens.
>>
>> Originally, on my system, I had not specified a specific setting for
>> DPI, and I was using the default, which I think was 96.  The OP
>> reported "This happens on a high DPI screen for which I had to force
>> the fonts DPI to 168.", and I am not at the moment clear if he
>> intended/needed to use that setting, or actually had to resort to
>> that.  I found there was certainly a problem at 168, so I'm assuming
>> that that was the setting he wanted to use.
>>
>> I've now have it working at this setting, but if I go above that then
>> problems return, and font sizes need to be reduced.  In some places,
>> this responds to the new font size setting, but in some cases the
>> original size remains and recompilation is needed.
>>
>> So, what setting is reasonable for me to use?  The higher settings
>> look like it might be good for making posters.
>>
>> Allan
>
> As has been said before, you should not need to (and generally should
> not) specify such things.

Perhaps I didn't make myself clear.  Whilst I did mention font size, 
that is not the issue.

In the past, I've never needed to think about DPI settings, except when 
dealing with image files/printers, or if I did, it was many, many moons 
ago.  I'm trying to fix the user's problem, where, for whatever reason, 
he needed/chose to use a high-ish setting, the result of which is that 
the characters displayed become larger and take up more visual space.

So, I need to ensure that I allow for that.  So, I set my system DPI 
setting to some higher value, not a font setting.  I can test for the 
168 DPI value, but while I'm at it, and we know what will happen next - 
another user will need higher, so how much further is it sensible to go? 
  The provided choices go up to 1000DPI.  So just for fun, I've just 
used that.  Now, I can't get to the choice of importer as the KMM 
opening screen has just six text lines filling the screen, with a few 
tiny icons interspersed.  The text characters are too big, and this is 
the point where I tried a choice of reducing the font size.  The 
smallest choice is still useless.

So, I suspect that the largest DPI settings are for use if one has a 
huge screen for use in a huge room.

It looks like I have to 'suck it and see'.  If KMM gives a 
reasonable/usable result, I'll go with that, probably.

Allan

>  The issue with fonts is that there are often
> subtle misconfiguration of display systems.  A monitor has a real size
> (inches or mm), a real number of pixels, and a DPI.  You really only get
> to specify two, and from those calculate the third.  Since the first two
> are physical attributes of the monitor, they (in theory at least) should
> take priority.  However, for various reasons, DPI is sometimes
> specified, potentially leading to conflicts - i.e., it's sometimes not
> true that size of display in inches X DPI = number of pixels.
>
> The problem with fonts is that you can specify them in pixels or by
> physical size (72 points = 1 inch, an old printers measure).  Only if
> all three of the above parameters are actually correct will this work.
> In addition, specifying either size or pixels for a font will simply be
> wrong on some display.  10 point type may be too large on a phone or
> small tablet, and will probably be too small on a 35 inch display.
> Likewise if you specify pixels.  You really have to assume the user has
> the display configured correctly, and that the default font size will be
> appropriate.  You can then specify "smaller" or "larger," but both are
> relative to the default font, not to any fixed baseline.
>
> Unless you query this display parameters, I believe any attempt to
> specify font sizes will be wrong for some set of users.  By specifying a
> font family (serif v. sans, roman v. italic, bold v. plain, narrow v.
> normal or wide) you can get a particular look, and might even get a good
> idea of the aspect ratio of what you are displaying, but beyond that
> lies trouble.
>
> For the specific user you refer to, it doesn't really tell us anything
> that he needed 168 DPI.  It depends on his monitor size and resolution,
> and whether they were set correctly.  Adjusting DPI is simply a post-hoc
> way of getting a useful output when something was specified in a way
> that was not appropriate for that display.  Setting your own display to
> 168 DPI doesn't really change the display, it just changes the
> calculations used to draw the fonts - and that depends on whether the
> underlying font being displayed is actually specified by pixels (any
> bit-mapped font) or in inches/points (true-type fonts, for example, if I
> remember correctly.)
>
> I apologize if this sounds like a rant, but as displays have gotten both
> large and small, and unless you actually have a way of knowing about the
> display you are currently running on, and using that information, font
> size is likely to remain a problem.  Projection devices are yet another
> twist, since pixels are fixed but actual size depends on distance from
> the projector to the screen, and sizes can't be thought of in the usual
> way, since the people viewing the display are at a distance - so a true
> 10point type would be miniscule.
>
> I suspect this is also at least peripherally related to the system
> choosing which size icon to use, and why most icons are created and
> installed in a range of sizes.  In general, you do not specify which
> size icon to use on a particular screen or dialog, but let the system
> choose the appropriate size.  I wonder if we will ever get icons
> specified by rendering (e.g., svg) rather than bitmapped.  If so, the
> issues become more parallel to fonts.
>
> Jack