Mi blog lah! Το ιστολόγιό μου

22Jul/1020

Ubuntu Font Beta and Greek

Update: All open bugs for this font at https://bugs.launchpad.net/ubuntufontbetatesting/+bugs File your bug. Currently there bugs relating to Greek, 1. Letter γ ((U03B3) has an untypical style 2.  In letters with YPOGEGRAMMENI, YPOGEGRAMMENI is expected to be under not on the right and 3. Many Greek small letters have untypical style

Here we see some samples of Greek with Ubuntu Font Beta.

Ubuntu Font supports both Greek and Greek Polytonic.

In the following we compare between DejaVu Sans (currently the default font in Ubuntu) and the proposed Ubuntu Font Beta.

Screenshot Waterfall DejaVuSans

This is DejaVu Sans, showing the Greek Unicode Block. This means, modern Greek and Coptic.

Screenshot Waterfall UbuntuBeta Greek

This is Ubuntu Font Beta, showing the Greek Unicode Block. Coptic is not covered as it was not part of the requirements for this version of the font (actually Coptic currently uses a separate new Unicode Block so the Coptic here are too low of a priority).

Screenshot-Waterfall DejaVu Polytonic

This is DejaVu Sans showing the Greek Polytonic Unicode Block coverage. We show the second part of the Unicode Block which has the most exotic characters with up to three accents.

Screenshot Waterfall UbuntuFont Beta Polytonic

Same thing with Ubuntu Font Beta.

Note that those characters that appear as empty boxes are characters that either were not designed by the font designers, or are reserved characters that have not been defined yet.

Antigoni text in DejaVu Sans and Ubuntu Font Beta (PDF, 12pt)

Antigoni text in DejaVu Sans and Ubuntu Font Beta (PDF, 10pt)

If there are things to be fixed, this is the time to do them. Post a comment and we can take if further.

Traditionally, the letters γ and ν tend to have a unique form. In this case, in Ubuntu Font Beta, γ looks different to what a Greek user is accustomed to. I attach an SVG file of γ; if you have suggestions for enhancement, please use Inkscape, this gamma_UbuntuBeta-Regular file and make your suggestion!

(see top of post for link to bug reports)

18Jul/080

Éńĥãǹčīṅǧ·ẗḧë·ẃṛīťıñĝ·ṩụṗṗọṙẗ·ıń·ǦŤḰ+

These are the presentation slides of my talk on improving the writing support in GTK+. It relates to several posts I have in my other (now not used anymore) blog at http://blogs.gnome.org/simos/2008/07/23/guadec-2008-presentation-slides/.

Enhancing the writing support in GTK+

Note: The title may not appear properly because I use a fancy effect that does not support the full range of Unicode characters. It's a drawback of being trendy. The title says “Éńĥãǹčīṅǧ·ẗḧë·ẃṛīťıñĝ·ṩụṗṗọṙẗ·ıń·ǦŤḰ+”.

3Jul/081

Keyboard layout editor UI concept

(click for bigger image)

At the top we select the keyboard layout file, the variant, and set the corresponding verbose name.

The keyboard layout editor shows a standard keyboard, where each keyboard key can show up to four levels. When you select a key, the bottor-left window shows the characters that have been set (here we use four levels). In this bottom-left window we can drag and drop characters (from Unicode blocks) and dead keys that are found from the right of the image. Dead keys are shown in red boxes.

The user is also able to include existing keyboard layout files in the current layout.

At this stage I am thinking how to easily draw the keyboard in a PyGTK application. It would be important not to draw it manually. It would be cool to have a GTK+ keyboard key widget, that you can specify the size, and the text that appears on it, then build a keyboard in Glade. Another option would be to have the basic keyboard as an SVG file (already exists), then draw over it with Cairo. I am inclined for the second option.

28May/083

Looking into the symbol files

In the previous post, we talked about the ANTLR grammar that parses the XKB layout files.

The grammar is available at http://code.google.com/p/keyboardlayouteditor/source/browse. I'll rather push to the freedesktop repository once the project is completed. Now it's too easy for me, just doing svn commit -m something.

Below you can see the relevant layout files for each country (and in some cases, language), and how the grammar deals with them. First column is filenames from the CVS XKB symbols subdirectory (to be moved eminently to GIT). Last's week discussion with Sergey helped me figure out issues with the symbol files, simplify what information is needed, and what can be eliminated. Second column has Not OK if something is wrong. Third column tries to explain what was wrong.

ad
af
al
altwin
am
ara
az
ba
bd
be
bg
br
braille
bt
by
ca
capslock
cd
ch
cn
compose
ctrl
cz
de
dk
ee
epo
es
et
eurosign
fi
fo
fr
gb NOK Non-UTF8
ge
gh
gn
gr
group NOK virtualMods= AltGr
hr
hu NOK Non-UTF8
ie
il NOK key.type="FOUR_LEVEL" (typically: key.type[something]=....)
in NOK key.type="FOUR_LEVEL" (typically: key.type[something]=....)
inet
iq
ir
is
it
jp NOK key <BKSP> {
type="",   // empty?
symbols[Group1]= [ bracketright, braceright ]
};
keypad NOK overlay1=<KO7> }; // what's "overlay"?
kg
kh
kpdl
kr
kz
la
latam
latin
level3 NOK virtual_modifiers LAlt, AlGr; virtualMods= Lalt
level5
lk
lt
lv
ma
mao
me
mk
mm
mn
mt
mv
nbsp NOK Non-UTF8
ng
nl
no
np
olpc
pc NOK key <AA00> { type=”SOMETHING” } instead of { type[Group1]=”SOMETHING” }
pk
pl
pt
ro
rs
ru
se
shift NOK actions [Group1] = [
si
sk
srvr_ctrl NOK key <AA00> { type=”SOMETHING” } instead of { type[Group1]=”SOMETHING” }
sy
th
tj
tr
ua

Non-UTF-8 are the files that have characters that are not UTF-8 (are iso-8859-1).

Some layouts have key.type = "something" and others key.type[SomeGroup] = "something". Apparently, the format allows to infer which is the group that the type acts upon? That's weird. Would it be better to put the group information? Is it required that the group is not set?

Some files have virtualMods, which I do not know what it is. Is it used?

15Mar/081

How to easily modify a program in Ubuntu (updated)?

Some time ago we talked about how to modify easily a program in Ubuntu. We gave as an example the modification of gucharmap; we got the deb source package, made the change, compiled, created new .deb files and installed them.

We go the same (well, similar) route here, by modifying the gtk+ library (!!!). The purpose of the modification is to allow us to type, by default, all sort of interesting Unicode characters, including ⓣⓗⓘⓢ , ᾅᾷ, ṩ, and many more.

The result of this exercise is to create replacement .deb packages for the gtk+ library that we are going to install in place of the system libraries. Because these new libraries will not be original Ubuntu packages, the update manager will be pestering us to rollback to the official gtk+ packages. This is actually good in case you want to switch back; you will have the enhanced functionality for as long as you postpone that update.

There is a chance we might screw up our system, so please make backups, or have a few drinks first and come back. I take no responsibility if something bad happens on your system. If you are having any second thoughts, do not follow the next steps; use the safer alternative procedure. You may try however this guide just for the kicks; up to the dpkg command below, no changes are being made to your system.

We use Ubuntu 7.10 here. This should work in other versions, though your mileage may vary.

The compilation procedure takes time (about 30 minutes) and space. Make sure you use a partition with >2GB of free space. We are not going to use up 2GB (a bit less than 1GB), but it's nice not to fill up partitions.

We are going to use the generic instructions on how to recompile a debian package by ducea.

First of all, install the development packages,

sudo apt-get install devscripts build-essential

Next, we use the apt-get source command to get the source code of the GTK+ 2 library,

cd /home/ubuntu/bigpartition_over2GB/
apt-get source libgtk2.0-0

We then pull in any dependencies that GTK+ may require. They are normally about a dozen packages, but we do not have to worry for the details.

apt-get build-dep libgtk2.0-0

At this stage we need to touch up the source code of GTK+ before we go into the compilation phase. Visit the bug report #321896 – Synch gdkkeysyms.h/gtkimcontextsimple.c with X.org 6.9/7.0 and download the patch (look under the Attachment section). You should get a file named gtk-compose-update.patch. If you have a look at the patch, you will notice that it expects to find the source of gtk+ in a directory called gtk+. Making a link solves the problem,

ln -s libgtk2.0-0 gtk+

We then attempt to apply the patch (perform a dry run), just in case.

patch -p0 --dry-run < /tmp/gtk-compose-update.patch

If this does not show an error message, you can the command again without the --dry-run.

patch -p0 < /tmp/gtk-compose-update.patch

Finally, we are ready to build our fresh GTK+ library.

cd libgtk2.0-0
debuild -us -uc

This will take time to complete, so go and do some healthy cooking.

At the end of the compilation, if all went OK, you should have about a dozen .deb files created. These are one directory higher (do a "cd .."). To install, use dpkg,

dpkg -i *.deb

If you have any other deb files in this directory, it's good to move them away before running the command. If all went ok, the .deb files should install without a hitch.

The final step is to restart your system. To test the new support, see the last section at this post. Use Firefox and OpenOffice.org to type those Unicode characters.

If you managed to wade through all these steps, I would appreciate it if you could post a comment.

Good luck!

3Feb/082

Typing squiggles and dots in GNOME and GTK+ applications

Garrett asks how to type squiggles and dots in GNOME; that is, how to type characters such as á à ä ã â ą ȩ ę ő ǰ ǩ ǒ ġ ṅ ȯ ṁ ė.

There are several ways, and one can choose depending on how frequently they need to type them or how much time they need to invest learning.

① One option is to start the Character Map (Applications/Accessories/Character Map), pick the character, copy and paste it. This is good for rare characters and weird situations such as

┏━━━━━━━━━━━━━━━━━━━━━━━┓

⟁⟁⟁⟁♥♀★★▶◀☆♀░░░▒▒▒▓▓▓▙▚▛▙▙▙▞

The Unicode standard, apart from defining characters for languages, it also defines symbols, dingbats and all sort of things. If your distribution is based on the DejaVu fonts (such as Ubuntu), then you are probably covered for many of these symbols. If you do not have a suitable font, or you use Windows, you will be wondering what the hell I am talking about.

② Another option is to use the Character Palette applet which shows an applet on the panel with a configurable small repertoire of characters such as áàéíñó½©ث€. You select one of the characters with the mouse, and wherever you middle-click, this character is typed. This is an improvement over ①, and good when you want to type often rare characters. It is not convenient to type characters found normally on a keyboard layout.

③ To type characters normally found in a specific language(s), it is good to setup a suitable keyboard layout. For this, it is good to add the Keyboard Indicator applet; right click on the panel, click Add to panel... and choose the Keyboard Indicator from the Utilities section. The US English keyboard layout (Default variant) does not provide any interesting characters apart from those shown printed on the keys of a US Keyboard.
Keyboard layout US Intl with dead keys
The US English International (with dead keys) variant might be a better option,

Keyboard layout GB

Or the United Kingdom layout.

You can get a similar image for your layout when you right-click on the Keyboard Indicator applet, then click Show Current Layout.

Each key in the images contain up to four letters. Starting from bottom-left and going clock-wise, these are the keys produced when

ⓐ you press the key

ⓑ you press the key with Shift (or Caps Lock)

ⓒ you press the key with AltGr and Shift (or Caps Lock)

ⓓ you press the key with AltGr

For example, with the UK keyboard layout, the key G produces g, G, Ŋ, ŋ.

If AltGr + Shift + letter does not work for you, see the FDO Bug #2871 Different results for shift-altgr and altgr-shift.

Using the appropriate keyboard layout is the way to go when writing text that require squiggles. You can either choose a layout with dead keys (meaning that some keys lose their normal functionality), or you can pick a layout that still allows you to have dead keys but are available when you press AltGr + key. For example, in the UK Keyboard layout - Default variant, AltGr + ; + a produces á, or AltGr+Shift+]+e produces ē.

OLPC showing the keyboard

Photo by titanas.

The OLPC uses those four level for the keyboard layout. You can see the all the variations printed on the keyboard. Click on the image, choose Large size for the details.

④ Another option to produce more characters on the keyboard is to enable the compose key, and use compose sequences. A compose sequence looks similar to what we described above (i.e. AltGr+Shift+]+e to ē) but the idea is that we use it for characters we want to be available across different keyboard layouts that you may have enabled.
Configuring the compose key
The compose key is very powerful functionality, thus it is not enabled by default, and lays hidden in the Layout Options tab. I prefer to set it to Menu, but every person has their own preference.

For example,

  • Compose key + - + a produces ã,
  • Compose key + < + c produces č
  • Compose key + 1 + s produces ¹ (Superscript on 1. Try to replace 1 with 2.)
  • Compose key + + + - procudes ±

Currently, GTK+ provides 640 such compose sequences involving the Compose key, and hopefully soon it will increase to over 3000.

The Compose key is known as Multi_key in the source code (Xorg, GTK+, etc).

The Compose key compose sequences offer the ability to define smart mnemonics on how to produce characters. It is much easier to type ComposeKey + 1 + s rather than remembering the codepoint value of ¹ (1 superscript). As with many things open-source, there are too many options, and with the Compose key there is the issue of which shall we pick as a sensible default, and how to make it prominent for those who might want to use it.

It appears to me that there should be more effort to promote the functionality that is provided with the standard keyboard layouts (choose a better keyboard layout, produce characters provided in the third and fourth levels, etc). In this respect, Compose key compose sequences should complement after the main discussion on keyboard layouts take place.

⑤ There is a last issue on switching keyboard layouts to cover in a separate post.

11Apr/074

Firefox shortcuts in Linux on non-us keyboard layout, and Greek

You tried to use the common keyboard shortcuts in the Linux version of Firefox, with a keyboard layout other than us, and you realised they do not work. For example, Ctrl-C does not work when the Greek keyboard layout is active because Firefox receives Ctrl-Ψ (which is undefined).
This is a well-known problem affecting keyboard shortcuts in many languages.
How can someone solve the problem; Should Firefox for Linux be configured so that internally it would consider Ctrl-C and Ctrl-Ψ correspond to the same keyboard shortcut (perhaps in the language pack)? Well, the problem is that one would prefer a solution that is independent of the keyboard layout. You might be running a Greek localisation of Firefox with an active layout for Hindi.
The optimal solution is to have Firefox associate the keyboard shortcuts to physical keys (whatever that means) instead of the characters they are producing. Bug #69230/Mozilla has been there for quite some time although an acceptable solution is available in both GTK+ (GNOME) and OpenOffice.org. For example, in a GNOME application, both Ctrl-C and Ctrl-Ψ are equivalent.
So, what can we do now with the Linux versions of Firefox? Well, it is possible to write a Firefox extension that would intercept keys being pressed in a local layout and convert to the standard keyboard shortcuts Firefox likes.
Such a workaround is available for the Greek language, written by Athanasios Lefteris, at Mozilla και συντομεύσεις πληκτρολογίου σε Linux.
Currently the extension exists in the sandbox of the Mozilla add-ons, meaning that you are required to register (free) and also configure your profile to allow the view of sandboxed extensions (=in early stage of development, about to get accepted). It is desired to to try out the extension and write a short review. This will help to get the extension accepted as official add-on to the masses.

Many thanks to Athanasios!

p.s.
There is an existing Russian version of the extension. It is expected that other languages will follow.

23Feb/0713

Video playback problems (black) after installing Beryl (or Compiz)

Note: Here we describe a workaround. The proper solution is to fix the graphics drivers and the X.Org X server. Such work is taking place, and for several cases you do not need this workaround. Especially with newer versions of Linux.

You just installed your 3D Linux desktop and you are really enthusiastic about it. But when you try to play some videos, you get a strange black output. What's going on?
The common software video players that come with the Linux desktop are able to display the video stream to several types of output devices. This includes several types of output for the graphical interface, and also obscure output devices such as text mode, using ASCII characters.
The default output device is XVideo (or Xv) for players such as those based on GStreamer (totem) and VLC.
As you guessed, there is a bug with XVideo when using Beryl/Compiz. Therefore, to fix, you need to switch to another output device that works.
For GStreamer players (such as totem, the default movie player in GNOME, Ubuntu and so on), you need to run from the command line the command
gstreamer-properties
(with older distributions such as Ubuntu 6.06 there is an option in System/Preferences for this).
and pick
Video, then for Default Video Plugin choose X Window System (No Xv). Click on test to verify that it actually works. Click Close and you are set.
VLC is not installed by default in Ubuntu 6.10. You need to install manually using the Synaptic Package Manager (under System/Administration), once you have activated the Universe repository in Repositories.
Start VLC and click on Settings, then Preferences. Expand Video and then expand Output modules. You will notice several options for output device. How do we actually choose which one should be the active output device? Well, it appears it's a bit tricky. Select the item Output modules, and notice the checkbox at the bottom right that says Advanced options. Check the box, and now you have the option to select a different output device. Pick X11 video output, click on Save and you are set!

Update (17 Jun 2007): Added section at UbuntuGuide.org, How do I fix black windows during video playback.

8Jan/070

The OLPC and Greek

(oh, I am writing this through a lousy Net connection; thanks Engelados)

I tried out the latest OLPC image, specifically build 218, on Qemu and my aim was to get Greek support configured, if it was not there already.

The OLPC does not currently come with a good set of Greek fonts; you will need to install a set of fonts such as DejaVu or GFS Didot.
Installing means adding the font files in the directory /usr/share/fonts/. The current font configuration files in the OLPC favour Bitstream Vera, therefore you would need to move the bitstream subdirectory outside the fonts directory. DejaVu is based on Bitstream Vera and therefore you will not notice any change once you upgrade. Also, Fedora Core 6 and Ubuntu Linux are based on DejaVu. You need DejaVu, as Bitstream Vera does not currently support Greek. Both DejaVu and GFS Didot are free and open-source fonts.

Note: This screenshot shows DejaVu Sans, not GFS Didot. Sorry for the typo.
This is the OLPC running the cut-down version of the Abiword wordprocessor. Click on the image to view the full size.

This is the OLPC showing the same document above with GFS Didot. The font looks quite nice and similar to old greek textbooks. There is a small issue however, it does not have the character coverage of DejaVu. For example, notice that the Euro sign is missing from GFS Didot. Also, other glyphs such as fancy bullet characters are missing as well. Normally, the OLPC software should replace those missing characters with the correct characters from another font. Apparently something is wrong here and needs further investigation.

Writing support for the Greek language has to be configured separately in the OLPC. The case with other languages appears to be that the default layout is that of the language; apparently there is no need to switch between Brazilian Portuguese and English. For the Greek language it appears that it is good to be able to switch between Greek and English.

There are several places that you can add Greek writing support. The most common is in /etc/X11/xorg.conf. Having gone through the configuration files, I think that /etc/X11/Xkbmap is also a good place and saves us from touching the core Xorg configuration file.

To write the full set of Greek letters, one needs to set the extended variant for the Greek layout, and also try to set the Compose key (for ano teleia). These things should be simplified...

I am not sure how the OLPC looks like (the only photos I saw where not focusing on the keyboard). Perhaps it would be useful to have a test machine at my disposal (hint, hint).
Jim Gettys wrote at his blog about the different languages that the first generation of the OLPC should support. Both Kinyarwanda and Kiswahili use the latin alphabet, therefore there are no significant issues with font support or writing support.

p.s.
Greece will carry out a pilot with OLPC laptops next September.

12Oct/061

The Junicode Greek Project

Specimen of Wilson's Greek Type

What's Junicode? Well,

Junicode (short for Junius-Unicode) is a Unicode font for medievalists. The current version is a beta; the selection of characters and the arrangement of the Private Use Area are subject to change. Your comments, suggestions and bug reports will be a great help to me as I complete the project.

Source: http://junicode.sourceforge.net/

If you look at the font coverage of Junicode, you will notice that Greek is missing. There is a new project to add Greek support in Junicode, and the font designer asks for feedback from Greek-speaking users,

You can help with this project, if you know Greek better than I do, by providing feedback. Some questions that occur to me:

  • Wilson's font does not have the k-style kappa. Should I include this, or just use the x-style kappa?
  • The shapes of zeta, rho, phi and perhaps others differ markedly from what one usually sees in modern Greek fonts. Should these be modernized, or will they do as-is?

I welcome any and all suggestions. Please write to the address below.

Source (and contact e-mail): http://junicode.sourceforge.net/greek.html

The new (experimental) Greek glyphs look like

9Jun/061

How to easily modify a program in your Ubuntu?

Suppose we want to change the functionality of an Ubuntu application but we do not want to go into all the trouble of finding the source code, installing in /usr/local/, breaking dependencies with original versions and so on.

Let's change Character Map (gucharmap), and specifically change the default font size from 20pt to 14pt, so that when you start it there is more space in the character window. Currently Character Map does not offer an option to save this setting.

We get the source code of Character Map,

# apt-get source gucharmap

Then,

cd gucharmap-1.4.4/

and now we edit the file gucharmap/main.c

We know what to edit because we visited the GNOME CVS Website, at http://cvs.gnome.org/viewcvs/gucharmap/

and we examined the logs for the file http://cvs.gnome.org/viewcvs/gucharmap/gucharmap/main.c?view=log

which show that for Revision 1.69, the following change took place,

Log:

2004-02-01  Noah Levitt

* gucharmap/gucharmap-table.c: Improve square size.

* gucharmap/main.c: Increase default font size.

When we click on the link Diff to previous 1.68 of the above page, we pinpoint the change,

version 1.68, Sun Feb 1 03:46:21 2004 UTC version 1.69, Mon Feb 2 00:48:05 2004 UTC
Line 93 main (gint argc, gchar **argv)
Line 93 main (gint argc, gchar **argv)

gint default_size = PANGO_PIXELS (1.5 * pango_font_description_get_size (window->style->font_desc));

gint default_size = PANGO_PIXELS (2.0 * pango_font_description_get_size (window->style->font_desc));

The change in the multiplier (from 1.5 to 2.0) changes the font size from 15pt to 20pt.

20pt is too big for us, therefore we edit the file gucharmap/main.c and change the 2.0 to 1.4 (14pt).
At this point we can compile the package using the command line

$ dpkg-buildpackage -rfakeroot -uc -b

dpkg-buildpackage: source package is gucharmap
dpkg-buildpackage: source version is 1:1.4.4-1ubuntu1
dpkg-buildpackage: source changed by Sebastien Bacher
dpkg-buildpackage: host architecture i386
fakeroot debian/rules clean

..........

At this point it is possible that you will get an error that an essential package is missing. The above command line will name the missing files, therefore you can simply install by

# apt-get install package-name

In case you do not have the basic compiler packages, you would need to install the build-essential meta-package. Do

# apt-get install build-essential

Finally, after the dpkg-buildpackage command completes, it will create one or more .deb packages in the directory above gucharmap.

# cd ..

# ls -l *.deb

gucharmap_1.4.4-1ubuntu1_i386.deb

libgucharmap4_1.4.4-1ubuntu1_i386.deb

libgucharmap4-dev_1.4.4-1ubuntu1_i386.deb
#

You can now install them (over the original packages) by running

# dpkg -i gucharmap_1.4.4-1ubuntu1_i386.deb libgucharmap4_1.4.4-1ubuntu1_i386.deb libgucharmap4-dev_1.4.4-1ubuntu1_i386.deb

Now we start the Character Map from Applications/Accessories/ and we get the default character size of 14pt!

Is there something we should pay attention on top of this? Yes, we should investigate the GNOME Bugzilla in case there is relevant work on this issue. We visit

http://bugzilla.gnome.org/

and specifically we click on the link Browse.

There, we select the package gucharmap (how do we know that Character Map is gucharmap? We either click on Help/About in Character Map which shows the internal name, or we run ps ax at a Applications/Accessories/Terminal while Character Map is running; the name gucharmap will pop up at the end of the long list.).

gucharmap is under the Desktop heading in the Browse list; or click on this direct link of bug reports on gucharmap.
If you start perusing the gucharmap bugs list, you will notice Bug #140414, titled remember settings. This report describes a superset of the problem we tried to solve above. That is, the bug report asks to enable Character Map to use the GNOME configuration database (gconf) so that it saves/remembers the user settings. However, this specific bug report is still pending.

The correct way to solve the configuration settings issue of gucharmap is to implement what is described in Bug #140414. If you have Ubuntu 6.06, you most likely have a very recent version of the source code of gucharmap. Therefore, the differences would be rather minimal. You can give it a go and try to get the gconf functionality in place.

You compile, install and test. If it works, you can make a patch of your changes; visit another directory and download a fresh copy of the source code using the apt-get source packagename command. Rename gucharmap-1.4.4 to gucharmap-1.4.4.ORIGINAL

# mv gucharmap-1.4.4 gucharmap-1.4.4.ORIGINAL

and make sure you clean the original gucharmap-1.4.4/ directory from compiled files (enter the directory were you did the source code changes and run make clean).

Finally, create a diff file,

# diff -ur ~/tmp/gucharmap-1.4.4.ORIGINAL ~/gucharmap-1.4.4/ > remember-settings.patch

In ideal terms, it is preferable if you could produce a patch for the latest version of gucharmap. That is, the version of gucharmap you get from http://cvs.gnome.org/viewcvs/gucharmap/. By doing so, the developers will love you because they will be able to simply apply the patch and limit the burden of adding the feature. Indeed, if it is too much effort to get a build system running, you can start off with simple patches and if you feel you are doing well with it, make the extra mile to have a build system. More on this in a future post.

1May/060

How to write special characters in Xorg and GNOME

There is functionality in Xorg that allows type special characters, without having to switch to a specific keyboard layout. To enable,

  • Click System, Preferences, Keyboard.
  • Under Layout Options, expand on Compose key position.
  • Choose Right-Win key is compose, click Close.

Now you can type extended characters using the RightWin key (next to AltGr), according to this keyboard settings file. Specifically, the lines that start with GDK_Multi_key are those that we can use here. The Compose key is actually GDK_Multi_key in the above file.
Some examples,

  • RightWin + C + = produces
  • RightWin + = + C produces
  • RightWin + C + O produces ©
  • RightWin + O + C produces ©
  • RightWin + a + ' produces á
  • RightWin + a + " produces ä
  • RightWin + a + ` produces à
  • RightWin + a + ~ produces ã
  • RightWin + a + * produces å
  • RightWin + a + ^ produces â
  • RightWin + a + > produces â
  • RightWin + a + , produces ą
  • RightWin + e + - produces ē
  • RightWin + S + 1 produces ¹
  • RightWin + S + 2 produces ²
  • RightWin + S + 3 produces ³

For more tips, see EasyLinux - Ubuntu Dapper.

Switch to our mobile site