[Kst] [Bug 221749] Clearer font size definition

[Nicolas Brisset]

https://bugs.kde.org/show_bug.cgi?id=221749





--- Comment #1 from Nicolas Brisset <nicolas brisset eurocopter com>  2010-01-08 11:26:53 ---
I'm happy you bring up the topic again... though it is not so easy to define
clearly what we need to do. But let's try it!

After your quick explanation I understand a couple of things a bit better, and
I wonder whether doing away with D really is what we want. As you say, the
concept is actually powerful and maybe it's just a UI/usability issue in the
end...

So instead of giving a definitive answer to what we should do, let me just
highlight a couple of important points:
1) I find it is nice if the fonts scale down when the number of plots increases
(resp. when the size of a plot decreases, for whatever reason: maximze, window
resized, plot resized, etc...) -> a completely fixed font size (S) does not
sound good
2) my biggest gripe against the current system is that changing fonts sometimes
requires a lot of trial and error and results in quite some confusion, as
described in bug #109469. In fact, the relative font size concept is hard to
grasp, especially when it has no effect (i.e. the user expects that changing
the value in the spin box will change the font size by one point, and it's not
what happens) and the value in the spinbox can't be correlated to anything (has
no "unit" if I dare say so)
3) font sizes can't be decreased infinitely -> we need to keep a minimum font
size (preferably set to something that should suit all, but possibly that does
not exist and should be settable from the UI as today)
4) in the typical KDE4 approach, I'd say we should strive to find good defaults
and remove some confusing options from the UI (e.g. the reference view size,
with apparently defaults to 12 cm x 16 cm: ???). I think there are a couple of
things kst should be able to find out by itself: whether we are printing (and
then on which media size), or displaying on screen (and then with which
resolution). Based on that it should be feasible to determine an appropriate
font size. Maybe only offer the user an option between small fonts / medium
fonts / large fonts?
5) in the end I think it is a matter of proportions. Instead of specifying a
font size, we should determine how big a font must be relative to the plot, and
compute the font size from that of the plot.

One thing which is not clear to me is what we should do for windows where the
plots have different sizes: I believe it would be better to have homogeneous
font sizes, but that breaks a bit the central concept in point 5)...

So, now that I've written all this, this is how I would imagine the way
forward:
- we keep the current concept of a scaling font size and minimal font, but hide
all that we can from the user. Typically, the user should only be offered a
choice between small / medium / large fonts in the general settings.
- we determine the "ideal" size for text labels relative to that of the plot,
and compute font sizes automatically based on the space available, which
changes whenever the plot size (or medium) changes
- when a user chooses to override defaults, we could offer the same size offset
spinboxes as today, but with values like -50% -40% ... -10% standard +10% ...
+50% and called something explicit like "Font size adaptation"
- for "floating" text boxes (like legends and text view items) resizing in
layout mode should be allowed and the font size computed to fill out exactly
the box drawn by the user. That is much more convenient than the current
approach with font size offsets! Plus, they should scale with the plot(or the
window) containing them.

Idea: in a subsequent step we may add font size toggle buttons (a bit like in
PowerPoint but there they are not toggles) to make fonts bigger or smaller on
individual text objects you subsequently click. All axis number labels would
always keeping a same font size, of course. This would be a sort of "font
tuning" mode where you select bigger or smaller and then click all the objects
you want to adapt. They would change their size by one step on each click. This
would be cool but it is certainly a bit more complex and hopefully not required
in a first step.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.