Version: 2.0.0_devel (using unspecified) OS: Linux Currently, font sizes in kst are defined in the following way: -In the settings dialog, a reference page size, and a corresponding reference font size 'D' is specified. -Elsewhere, where text is actually defined, an offset size 'S' is defined. So: if a page is the same size as the reference page size, then the font will be of size D+S points. The fonts will scale with the size of the 'page'. If D is changed, then all text sizes will change throughout kst. This is powerful, but confusing. A clearer, but less flexible approach would be do do away with 'D' altogether, and only define 'S'. Benefit: a much clearer and more intuitive interface. Cost: it would be less clear how to change all of the fonts in kst at once (this is rare though) I think we should do this. Thoughts? Other suggestions?
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.
Based on your comments, here is my new proposal: -Remove reference font size from the settings. All font sizes will be absolute relative to the reference page size. -Change the default reference page size to Letter or A4, and have a pull down list of common sizes (maybe Letter, A4, 1 column Journal plot, Custom). -Add 'increase all fonts' and 'decrease all fonts' actions to scale everything. -Add check box options to re-scale all fonts when plots are added to a tab. On Friday 08 January 2010 05:26:55 Nicolas Brisset wrote: > 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 Kst 1.x did this. The problem is that it became very difficult to make fonts the same size if the plots were different sizes, as font sizes were relative to the plot not the window. The compromise I have tried with the data wizard is that if you add plots to a window that already has plots, it resizes the fonts of all plots in the tab. This is dangerous if someone has already crafted font sizes, but often does what you want. Suggestion: have a check box wherever you add plots to a tab to optionally resize the fonts of all plots in the tab, but keep the general calculations relative to the page, not the plot, so consistency remains easy. > 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. This is mainly do to the reference font size issue. > 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) It is points. P = S + D. But on some systems, the font sizes are/were quantized quite coarsely in Qt, so you may not see a change. Because I intimately understand what is going on, it is easy for me to understand what happens, but the fact that, as far as I can tell, no one else does informs me that the interface is pretty broken :-) > 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) It is in the setting dialog along with the reference font size and reference plot size. > 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: ???). A reference plot size is absolutely critical for publication. You want to say that when the plot is published as a 12x16 cm plot in a journal, the font will be 12 pt, or whatever. The default reference size has not had much thought though. IIRC, the size I used what from taking a ruler to a plot in a paper that happened to be on my desk. > 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)... In 2.x, size is relative to the page not the plot. This is important I think.
(In reply to comment #2) > Based on your comments, here is my new proposal: > -Remove reference font size from the settings. All font sizes will be > absolute relative to the reference page size. OK, so e.g. a size of 12 will result in 12 pt on A4 if A4 is the reference size. Is that correct? That should work, though I think it has to be documented clearly so that people understand it. > -Change the default reference page size to Letter or A4, and have a pull > down > list of common sizes (maybe Letter, A4, 1 column Journal plot, Custom). Yes, that would be very much better. I vote for A4, but I'm biased. And it does not really matter if it's a setting you have to change only once. And from the other comment (to publications) I understand the requirement for an explicit reference size better. > -Add 'increase all fonts' and 'decrease all fonts' actions to scale > everything. > -Add check box options to re-scale all fonts when plots are added to a tab. Sounds OK. > Suggestion: have a check box wherever you add plots to a tab to optionally > resize the fonts of all plots in the tab, but keep the general calculations > relative to the page, not the plot, so consistency remains easy. [...] > In 2.x, size is relative to the page not the plot. This is important I think. I think we need to be able to rescale fonts, and the idea sounds good. Page consistency is important (hence my initial comment that also went in this direction). However, I'm slightly confused: you talk about page-based font size, but we clearly need to scale the fonts down when adding more plots in a given page. So it can't really be page-based. Could you elaborate on that a bit? And I'd also like to have your thoughts on the last two points, which you haven't commented on: - 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. Especially the second one is a must, I think.
On Friday 08 January 2010 09:21:28 Nicolas Brisset wrote: > OK, so e.g. a size of 12 will result in 12 pt on A4 if A4 is the reference > size. Is that correct? Yes > That should work, though I think it has to be > documented clearly so that people understand it. Tool tip and What's This. > However, I'm slightly confused: you talk about page-based font size, but we > clearly need to scale the fonts down when adding more plots in a given > page. So it can't really be page-based. Could you elaborate on that a bit? There will be a check box in dialogs where one would add a plot '[ ] Rescale fonts in existing plots' If checked, it will rescale all of the fonts in plots already on the page to make room for the new plots. If not checked, it will leave the existing fonts as they are, and just shrink the plots. If rescaled, the label tab of the plot dialog will show the new smaller font size, still relative to the page. > And I'd also like to have your thoughts on the last two points, which you > haven't commented on: > - 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" I prefer to use explicit font sizes. People know from Word or PPT what '36pt font' will give them, and it makes it really easy to match font sizes with other documents. > - 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. > Especially the second one is a must, I think. Under some definitions of 'must' :-) It would be arguably easier to make something close, but harder to make something exact. I will leave consideration of this point as a future exercise - it should be opened as its own wishlist item.
(In reply to comment #4) OK, it is more or less all clear now. No more comment means I agree :-) Just a couple smaller things still: > I prefer to use explicit font sizes. People know from Word or PPT what '36pt > font' will give them, and it makes it really easy to match font sizes with > other documents. I understand your point. However the issue I have with that is that you get 12 pt only if the reference size is right (and as I have never understood the concept properly before, I had never set a correct reference size!). Plus, you prepare the plot on screen and then print it on a media with a different size. So if we want to have something close to WYSISWYG, we have to pay attention to that. Setting a 12 cm x 16 cm reference size on a 21" display will certainly lead to some problems (not even mentioning the portrait/landscape and margin issues when printing). Do you actually have a clear concept how to go from screen to printed media without breaking the fonts? > > - 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. > > Especially the second one is a must, I think. > > Under some definitions of 'must' :-) It would be arguably easier to make > something close, but harder to make something exact. I will leave > consideration of this point as a future exercise - it should be opened as its > own wishlist item. I don't think they are exclusive: when the box is resized, you compute a font size and indicate it in the dialog. And the other way could also work if you really want a precise font size: when you set a different font size in the dialog, the box could be resized.
On Friday 08 January 2010 11:23:20 Nicolas Brisset wrote: > Just a couple smaller things still: > > I prefer to use explicit font sizes. People know from Word or PPT what > > '36pt font' will give them, and it makes it really easy to match font > > sizes with other documents. > > However the issue I have with that is that you get > 12 pt only if the reference size is right.... > Do you actually have a clear concept how to go from screen to printed media > without breaking the fonts? Think about Power Point. You specify a 36 point font. It sure isn't 36 points on the 120" projector screen... But it is relative to the reference size, which for PPT is probably Letter. Or think about word. If you specify a 12 point font, you do so under the assumption you are going to print on A4. Maximized on your 32" mega-monitor, it won't be that, but you sort of understand why. If you shrink your display in half, the Word fonts cut in half, but it still makes sense. We would do exactly the same thing (except that we can also change the aspect ratio, which makes the scaling a little more ambiguous...) By defaulting to a more obvious reference size (namely A4 or Letter) and using explicit point sizes, this will make a lot more sense to people who actually care, and be close to right for people who don't... I hope! > > > - for "floating" text boxes [...] when the box is resized, you compute a > font size and indicate it in the dialog. And the other way could also work > if you really want a precise font size: when you set a different font size > in the dialog, the box could be resized. I agree. Make a wishlist for that as a separate item.
OK, I'm convinced enough that I feel we should try it. Maybe some improvements will appear while testing it for real, but discussion further probably won't bring so much (at least as far as I'm concerned). Now I'm curious to know: how much effort do you think it is to implement that? I have absolutely no idea... Should it be part of 2.0.0 or done after? (Personally, I think such a visible change should rather be done before but it also depends on how long it takes, hence the question).
SVN commit 1078211 by netterfield: CCBUG: 221749 Define reference page sizes in the settings dialog. Specify fonts in points everywhere. Note: your dialog defaults for font sizes will now almost certainly be wrong, because font sizes are absolute, rather than relative. The first time you make a plot, set them to something sensible, and select the 'save as default' check box in the plot dialog. Still need tooltips, and code to optionally rescale fonts when new plots are added from curvedialog, etc. M +10 -0 devel-docs/Kst2Specs/FixedBugs M devel-docs/Kst2Specs/Fonts.pdf M +0 -9 devel-docs/Kst2Specs/Wishlist M devel-docs/Kst2Specs/src/Fonts.odt M +7 -19 src/libkstapp/applicationsettings.cpp M +3 -7 src/libkstapp/applicationsettings.h M +0 -2 src/libkstapp/applicationsettingsdialog.cpp M +6 -4 src/libkstapp/arrowitem.cpp M +2 -11 src/libkstapp/datawizard.cpp M +65 -11 src/libkstapp/generaltab.cpp M +4 -3 src/libkstapp/generaltab.h M +29 -39 src/libkstapp/generaltab.ui M +55 -47 src/libkstapp/labelcreator.ui M +4 -3 src/libkstapp/labelitem.cpp M +54 -46 src/libkstapp/labelpropertiestab.ui M +1 -1 src/libkstapp/labelrenderer.cpp M +18 -11 src/libkstapp/labeltab.ui M +1 -1 src/libkstapp/legenditem.cpp M +2 -2 src/libkstapp/legendtab.ui M +84 -76 src/libkstapp/overridelabeltab.ui M +5 -5 src/libkstapp/plotitem.cpp M +10 -14 src/libkstapp/view.cpp M +1 -1 src/libkstapp/view.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1078211
SVN commit 1080809 by netterfield: CCBUG: 221749 optionally scale fonts when adding plots to pages. M +5 -1 libkstapp/commandlineparser.cpp M +3 -0 libkstapp/csddialog.cpp M +3 -0 libkstapp/curvedialog.cpp M +6 -13 libkstapp/datawizard.cpp M +3 -0 libkstapp/equationdialog.cpp M +3 -0 libkstapp/histogramdialog.cpp M +3 -0 libkstapp/imagedialog.cpp M +0 -1 libkstapp/labelrenderer.cpp M +1 -1 libkstapp/labelrenderer.h M +3 -0 libkstapp/powerspectrumdialog.cpp M +23 -0 libkstapp/view.cpp M +2 -0 libkstapp/view.h M +25 -5 libkstmath/psd.cpp M +3 -0 widgets/curveplacement.cpp M +2 -0 widgets/curveplacement.h M +11 -1 widgets/curveplacement.ui M +0 -3 widgets/labelbuilder.ui WebSVN link: http://websvn.kde.org/?view=rev&revision=1080809
SVN commit 1081517 by netterfield: CCBUG: 221749 Only one default font now. Font handling almost done.... I think all we need is tooltips. M +11 -11 libkstapp/applicationsettingsdialog.cpp M +5 -25 libkstapp/datawizard.cpp M +2 -3 libkstapp/datawizard.h M +126 -136 libkstapp/datawizardpageplot.ui M +101 -11 libkstapp/defaultlabelpropertiestab.cpp M +14 -0 libkstapp/defaultlabelpropertiestab.h M +106 -37 libkstapp/defaultlabelpropertiestab.ui M +0 -98 libkstapp/generaltab.cpp M +0 -12 libkstapp/generaltab.h M +10 -85 libkstapp/generaltab.ui M +12 -0 libkstapp/labelpropertiestab.cpp M +2 -1 libkstapp/labelrenderer.cpp M +2 -3 libkstapp/plotitem.cpp M +4 -0 libkstapp/view.cpp M +13 -1 libkstmath/labelparser.cpp M +3 -2 libkstmath/labelparser.h M +15 -0 widgets/labelbuilder.cpp M +14 -0 widgets/labellineedit.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1081517
SVN commit 1083715 by netterfield: Finish up UI changes for revised font specifications BUG: 221749 Change \_ to _ in data mode line display. Demo of setting print mode from the command line (syntax will likely change) CCBUG: 216746 M +1 -2 devel-docs/Kst2Specs/Bugs M +8 -0 devel-docs/Kst2Specs/FixedBugs M +26 -0 devel-docs/Kst2Specs/Wishlist M +7 -1 src/libkst/namedobject.cpp M +2 -1 src/libkst/namedobject.h M +9 -7 src/libkstapp/applicationsettings.cpp M +7 -1 src/libkstapp/commandlineparser.cpp M +4 -2 src/libkstapp/commandlineparser.h M +0 -1 src/libkstapp/defaultlabelpropertiestab.cpp M +17 -1 src/libkstapp/defaultlabelpropertiestab.ui M +15 -16 src/libkstapp/generaltab.ui M +9 -3 src/libkstapp/mainwindow.cpp M +1 -1 src/libkstapp/mainwindow.h M +2 -2 src/libkstapp/plotrenderitem.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1083715
Change version from 2.0.0_devel to 2.0.0 to simplify version numbering.
These bugs are solved with 2.0.0