Monday 28 October 2013

Font Sizes and Display Resolution

When designing a GUI application in Gen, the controls are positioned using a pixel based co-ordinate system that specifies the position and size of the controls. In addition, fonts are specified using point sizes. A point is 1/72 inches, so for example 12 pt text is 1/6 inch high. In the 'normal or 100%' resolution on Windows desktop, the screen resolution is 96DPI (dots per inch), so 12 pt text is 16px (pixels) high.

If the user changes the screen resolution to say 120 DPI (125%), then the same 12pt text is now 20px high. However the remainder of the window design is still specified in pixels, and this can cause problems with the positioning of the text within the controls.

In the example below, notice the change in the window between 96 and 120DPI.



Window with system resolution set to 96 DPI

Window with system resolution set to 120 DPI

To support the change in DPI, the designer would need to ensure that text fields and literals are wide enough to accommodate all of the text and avoid wrapping. Web Browsers also allow the user to change the zoom factor for an application.

For Rapide Browser and Mobile applications, Rapide uses pixel based font heights rather than point based, with the conversion from points to pixels based on 96DPI. This means that a UI design that looks correct in 96DPI will scale correctly irrespective of the DPI setting or browser zoom level. 

Rapide Desktop applications still use a point based font size to ensure that fonts are scaled if the user requires a higher DPI setting.

Tuesday 15 October 2013

Understanding and editing UTF-8 files

One of the design goals of Rapide was to enable internationalisation of the applications so that the user interface could be displayed in multiple languages, with the user's locale automatically detected and the appropriate locale specific translated text strings displayed instead of the default ones.

We chose UTF-8 as the encoding standard for the files that Rapide generates and uses, for example the GUI XML definition files and the string properties files. 

Here are some links to various articles if you want to know more about UTF-8:

http://www.utf8everywhere.org/

When editing the files to create locale specific translations, you must use an editor that understands and preserves the UTF-8 encoding. For basic editing we use Notepad++ which can edit files in UTF-8 and also contains conversion utilities. On opening an existing file, always check that the encoding has been set to UTF-8. Many editors will attempt to auto-detect the encoding, but if the file only contains basic ascii characters below X'80', there is no difference between an ascii and UTF-8 file and so the editor will probably not set the encoding format to UTF-8.

One way around this is to insert a BOM (byte order mark) at the start of the file to indicate the encoding, but this is not recommended for UTF-8 and we have decided not to include a BOM in the files generated by Rapide.