105
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − '''Comments and Explanations:''' − − There are comments (in italic) providing guidance to fill out each section, see also [[Features/Policy]]. '''Copy the source to a ''new page'' named Features/''Your Feature Name'' before making changes! DO NOT EDIT THIS TEMPLATE.''' − − <!-- All fields on this form are required to be accepted. − We also request that you maintain the same order of sections so that all of the feature pages are uniform. --> − − <!-- The actual name of your feature page should look something like: Features/Your Feature Name. This keeps all features in the same namespace --> − ''A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release.''+ − ''This should link to your home wiki page so we know who you are''+ − * Name: [[User:AcountName| Your Name]] − − ''Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved'' − * Email: <your email address so we can contact you, invite you to meetings, etc.> Line 26:
Line 14: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − ''What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''+ + + − ''What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?''+ + − ''This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be.''+ − + − ''Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.'' − − ''A good "how to test" should answer these four questions:'' − − * ''What special hardware / data / etc. is needed (if any)? − * ''How do I prepare my system to test this feature? What packages need to be installed, config files edited, etc.? − * ''What specific actions do I perform to check that the feature is working like it's supposed to? − * ''What are the expected results of those actions?'' − ''If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.''+ − ''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like python?''+ − + − ''Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved.''+ + + − ''The Sugar Release Notes inform end-users about what is new in the release. An Example is [[0.84/Notes]]. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.''+ − + − ---- − ''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''
Features/Font configuration (view source)
Revision as of 04:10, 21 August 2009
, 04:10, 21 August 2009no edit summary
<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
== Summary ==
== Summary ==
Distributors/deployers need a way to be able to customize the Sugar font size.
== Owner ==
== Owner ==
[[User:DanielDrake|DanielDrake]] dsd@laptop.org
== Current status ==
== Current status ==
== Detailed Description ==
== Detailed Description ==
''Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better.''
It is not possible to select a one-size-fits-all font size. Screen sizes and resolutions vary drastically, their DPI resolutions too, and then there are also factors such as quality of eyesight of the user and the distance they are seated from the display. There needs to be the possibility of customization.
Currently, Sugar uses 2 base font sizes: one defined in the GTK+ RC file, and another defined in style.py. Distributors shipping an alternative gtkrc is just-about possible cleanly, but as style.py is part of the Sugar package, it can only be changed with hacky methods.
Another current possibility is to falsify the DPI value of the whole desktop, but this has various disadvantages such as working against freetype's visual optimizations (designed for truthful DPI values) as well as being a strange and confusing concept - if you want bigger fonts, the usual thing to do is to use bigger fonts, as opposed to changing the number of dots per inch of the screen which they are rendered upon.
The proposed solution is one similar to the solutions used in GNOME and KDE: allow customization of the base font size used across the entire desktop platform.
=== Solution for distributors ===
Sugar will have a new gconf setting named "default_font_face" with default value "Sans" and "default_font_size" with value "10." This font would be used across the desktop in the places where the current default from the gtkrc and the value in style.py are used now (both are currently "Sans 10" as distributed).
Distributors can then customize the font size by shipping different gconf defaults (as already happens for various other Sugar settings).
=== Solution for users ===
Somewhere in the control panel, 2 new buttons will be added:
# Increase font size
# Decrease font size
These buttons will cause the default_font_size value to move incrementally up and down through these values: 5 6 7 8 9 10 11 12 13 14 16 18 20 22 24 26 28 32 36 40 48
When clicking, font size changes will be instantly applied.
FIXME: describe exactly how this is implemented in GNOME
I am not proposing a UI design for changing font face, I think that is unnecessary and am trying to keep this feature request simple (but could certainly be added later).
The UI for changing font sizes can be implemented independently after the solution for distributors has been implemented. I would argue that the solution for distributors is a requirement and the UI part of this feature request is optional, but others have expressed strong desires in seeing a UI too, so I include the above design suggestions as part of this feature.
=== Consideration for activities ===
Activities should now be built around the following ideas regarding fonts:
* In general, font sizes should never be specified. Use the default Sugar font (e.g. which is what you get if you create a gtk.Label), as this is what the user has chosen as their preferred font size.
** also use variations using pango markup e.g. <nowiki><big> <small> <b></nowiki>
** FIXME: document how the point sizes of<nowiki> <big> and <small></nowiki> can be read by an activity (I think it's just based on scale factor 1.2) and maybe propose helper functions to make these values dead-easy to retrieve.
* There may be exceptional cases where applications want to scale a font to fit nicely in a given space. In this situation, they should use the standard Pango rendering pipelines to render text offscreen (using a sensible seed size value), measure the resultant pixel size, and then retry the rendering based on a new font size if the result was too big or too small.
** The Memorize activity is one example of this - it dynamically chooses a font size which causes the text to fit nicely within the tiles of the game.
* There may be exceptional cases where activities do want to use a fixed font size (in terms of physical dimensions). They can do this by adjusting the font on any applicable UI elements to a hardcoded point size (e.g. Sans 12).
** They should assume that the DPI value is correct, so rendering at size 12 will always cause the resultant glyphs to be about 12/72" in size.
** This may come with downsides for the activity in question -- can you be sure that size 12 looks sensible on the display it will be run on in the field? If not, then users/distributors might file bug reports or simply reject your activity.
Not (unnecessarily) messing with font sizes will just become another step in "effective Sugarization" of an activity.
=== Additional fonts ===
I believe the simplicity of the Sugar desktop only requires selection of a single font sufficient for the entire desktop (with the simple variations that can be generated: <nowiki><big>, <small>, </nowiki>bold/underline, etc). However, if this changes we could add further gconf keys in future that allow customization of any additional font selections that we add.
=== Global scaling of other UI elements ===
This feature is about fonts, but there are clearly desires for scaling of the UI in-general. For example, increasing font size may make text look uncomfortably large in the gtk.Button where it is displayed. This is an unsolved problem in the Linux desktop world and I am not attempting to tackle it in this simple feature request (which remains entirely about fonts).
Solutions are being designed and developed to solve this in future, a sort of "global scale factor" for the whole desktop which would effect fonts, button sizes, scrollbars, etc. I think we should wait for these solutions to become available before attempting to tackle global scaling.
== Benefit to Sugar ==
== Benefit to Sugar ==
* Sugar is brought more in-line with the desktop world
* Distributors like OLPC will be able to select font sizes without ugly hacks.
* Users will be able to customize font size to suit their needs (I have seen this requested during my field experience: one Ethiopian teacher who had eyesight trouble had to move his face relatively close to the screen, and a teacher in Paraguay expressed the desire to make the general desktop fonts bigger).
== Scope ==
== Scope ==
* Sugar needs to adopt its default fonts from gconf.
* 2 buttons need adding to the control panel to control one gconf setting
== How To Test ==
== How To Test ==
# Set font settings in GConf then launch sugar - do they take effect?
# Go into the control panel and change the font - whole desktop should be instantly updated.
== User Experience ==
== User Experience ==
Users will be able to adjust the font size of the whole desktop platform.
== Dependencies ==
== Dependencies ==
None.
== Contingency Plan ==
== Contingency Plan ==
''If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Sugar will not be in jeopardy.''
Don't implement it.
== Documentation ==
== Documentation ==
* http://dev.laptop.org/ticket/9324
* http://dev.sugarlabs.org/ticket/954
* https://www.redhat.com/archives/fedora-olpc-list/2009-August/msg00030.html
== Release Notes ==
== Release Notes ==
to be written after implementation
== Comments and Discussion ==
== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[{{TALKPAGENAME}}|discussion tab for this feature]]
[[Category:Feature Page Incomplete]]
[[Category:Feature Page Incomplete]]
[[Category:Feature]]
[[Category:Feature]]