Changes

Jump to: navigation, search

Features/Font configuration

4,608 bytes added, 16:46, 10 June 2010
Current status
<noinclude>{{GoogleTrans-en}}{{TOCright}}[[Category:Feature Accepted 0.88]][[Category:Feature|Font configuration]]</noinclude>
'''Comments and Explanations:'''
There == Summary ==Distributors/deployers need a way to be able to customize the Sugar font size. == Owner ==[[User:DanielDrake|DanielDrake]] dsd@laptop.org == Current status ==* Targeted release: 0.88* Last updated: 11.01.2010* Percentage of completion: 10% The GConf keys have been implemented:* During startup, sugar-session sets the default GTK+ font based on them.* The font settings in sugar.graphics.style are comments now based on the same GConf keys.* sugar.activity.activity sets the default GTK+ font based on them. Next steps (implemented in [http://git.sugarlabs.org/projects/sugar-settings-manager sugar-settings-manager]) :* Implement an xsettings daemon (hopefully in italic-process) providing guidance .** This will eliminate the need to manually set GTK+ fonts in sugar-session and sugar.activity.activity, since GTK+ init routines will contact the settings daemon and learn of the settings.** It will also mean that activities that are not based on sugar.activity.activity have an easy way to fill find out each sectionthe font settings, and all GTK+ apps will "just work" TODO* Deprecate FONT settings in sugar.graphics.style* Add user interface == Detailed Description ==It is not possible to select a one-size-fits-all font size. Screen sizes and resolutions vary drastically, their DPI resolutions too, see and then there are also [[Features/Policy]]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'''Copy 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 source 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 page'' gconf setting named Features"font/default_face" with default value "Sans Serif" and font/''Your Feature Name'' before making changes! DO NOT EDIT THIS TEMPLATEdefault_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
<!-- All fields on this form are required These buttons will cause the default_font_size value to be accepted. We also request that you maintain the same order of sections so that all of the feature pages are uniform. -->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
<!-- The actual name Instant application of your feature page should look something like: Featuresthis change could be achieved by generating an XChangeProperty() event on the Gtk/Your Feature NameFontName xsettings property, otherwise the user could be requested to restart Sugar. This keeps all features in the same namespace -->
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. === Summary Consideration for activities === Activities should now be built around the following ideas regarding fonts:''A sentence or two summarizing * 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 feature is what the user has chosen as their preferred font size.** also use variations using pango markup e.g. <nowiki><big> <small> <b></nowiki>** If the user cannot or does not want to use pango markup in a particular scenario, Sugar could provide a helper function to scale the font size from the default for a given widget (see suggested code below)* 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 what 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 dobe run on in the field? If not, then users/distributors might file bug reports or simply reject your activity.* sugar.style.FONT_* should be deprecated. They are pointless, a NORMAL font should be what you get by default, and a BOLD font is just the default font with a bold weighting applied.** The deprecation could be done with a simple code comment for 1 release cycle, then a removal in the following one. This information should be done after an effort has been made to remove all existing users. Not (unnecessarily) messing with font sizes will just become another step in "effective Sugarization" of an activity. Here is used sample code for scaling fonts as described above: def scale_font(widget, scale_steps): if scale_steps == 0: return font = widget.get_pango_context().get_font_description() font.set_size(int(font.get_size() * pango.SCALE_LARGE * scale_steps)) widget.modify_font(font) The above function will work for any GtkWidget, allowing the font to be scaled. A scape_steps value of 0 will cause no scaling, -1 is equivalent to <nowiki><small>, 2 is equivalent to <big><big> or <span font_size="x-large">, </nowiki> etc. It works based on the fact that pango.SCALE_LARGE is the overall feature summary page scaling factor for each releasea single step up, which has value 1.2 as used in all pango font scaling (and the CSS world).'' === Additional fonts ===
== Owner ==''This should link to your home wiki page so 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 know who you are''* Name: [[User:AcountName| Your Name]]add.
''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.>=== Global scaling of other UI elements ===
== Current status ==* Targeted release: (SUGAR_VERSION)* Last updated: 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 (DATEwhich remains entirely about fonts)* Percentage of completion: XX%.
== Detailed Description ==''Expand on Solutions are being designed and developed to solve this in future, a sort of "global scale factor" for the summarywhole desktop which would effect fonts, if appropriatebutton sizes, scrollbars, etc. A couple sentences suffices I think we should wait for these solutions to explain the goal, but the more details you can provide the betterbecome available before attempting to tackle global scaling.''
== Benefit to Sugar ==
''What * Sugar is brought more in-line with the benefit 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 platform? If this is a major capability updatescreen, what has changed? If this is and a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''teacher in Paraguay expressed the desire to make the general desktop fonts bigger).
== Scope ==
''What work do the developers have * Sugar needs to accomplish adopt its default fonts from gconf.* 2 buttons need adding 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?''control panel to control one gconf setting
== How To Test ==
''This does not need to be a full# Set font settings in GConf then launch sugar -fledged document. Describe do they take effect?## To set 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 beGConf key manually, use the better the community testing can be.gconftool-2 command from Terminal ('' ''Remember that you are writing this how to for interested testers to use to check out your feature gconftool-2 --set - documenting what you do for testing is OK, but itt string /desktop/sugar/font/default_face Serif's much better to document what *I* can do to test your feature.'and ''A good "how to test" should answer these four questions:'gconftool-2 --set -t float /desktop/sugar/font/default_size 16* ''What special hardware / data / etc. is needed (if any)?* ''How do I prepare my system to test this feature? What packages ## After setting the key, you need to be installed, config files edited, etc.?restart Sugar* ''What specific actions do I perform to check that # (WARNING: This part of the Feature has not landed yet) Go into the feature is working like it's supposed to?* ''What are control panel and change the expected results of those actions?''font - whole desktop should be instantly updated.
== User Experience ==
''If this feature is noticeable by its target audience, how Users will their experiences change as a result? Describe what they will see or noticebe able to adjust the font size of the whole desktop platform.''
== Dependencies ==
''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?''None.
== Contingency Plan ==
Don''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 t implement 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.''
== Documentation ==
''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* 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 ==
''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.''be written after implementation
== 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 -->  [[Category:Feature Page Incomplete]][[Category:Feature]]----''You can add categories to tie features back to real deployments/schools requesting them, for example <nowiki>[[</nowiki>Category:Features requested by School Xyz]]''

Navigation menu