Εναλλακτικές διατάξεις πληκτρολογίου για ελληνικά
Ο Νίκος Μουτσανάς έφτιαξε δύο εναλλακτικές διατάξεις πληκτρολογίου που μπορεί να φανούν χρήσιμες σε όσους
- γράφουν συχνά σε διάφορες λατινικές (ευρωπαϊκές) διατάξεις πληκτρολογίου και θέλουν μια κοινή συγκεντρωτική διάταξη
- θέλουν μια ελληνική διάταξη που να επιτρέπει και αγγλικά με τη χρήση του AltGr (δηλαδή μια διάταξη για ελληνικά και αγγλικά)
Είναι πιθανό κάποιες από τις παραπάνω εκδοχές να μπορούν να υλοποιηθούν με χρήση παραμέτρων στη ρύθμιση πληκτρολογίου.
Ωστόσο, για τώρα, δείτε τις οδηγίες του Νίκου για τη ρύθμιση των δύο εναλλακτικών διατάξεων πληκτρολογίου. Διατηρήστε αντίγραφα ασφαλείας των αρχείων που θα τροποποιήσετε, σε περίπτωση που θέλετε επαναφέρετε τις προηγούμενες ρυθμίσεις. Δυστυχώς δεν υπάρχει ακόμα κάποιο σύστημα όπου να μπορούμε να προσθέτουμε εύκολα διατάξεις πληκτρολογίου στη διανομή μας.
Workaround for bad fonts in Google Earth 5 (Linux)
Update Jan 2010: The following may not work anymore. Use with caution. See relevant discussions at http://forum.ubuntu-gr.org/viewtopic.php?f=5&t=15607 and especially http://kigka.blogspot.com/2010/11/google-6.html
Older post follows:
So you just installed Google Earth 5 and you can't figure out what's wrong with the fonts? If your language does not use the Latin script, you cannot see any text?
Here is the workaround. The basic info comes from this google earth forum post and the reply that suggests to mess with the QT libraries.
Google Earth 5 is based on the Qt library, and Google is using their own copies of the Qt libraries. This means that the customisation (including fonts) that you do with qtconfig-qt4 does not affect Google Earth. Here we use Ubuntu 8.10, and we simply installed the Qt libraries in order to use some Qt programs. You probably do not have qtconfig-qt4 installed, so you need to get it.
So, by following the advice in the post above and replacing key Qt libraries from Google Earth with the ones provided by our distro, solves (read: workaround) the problem. Here comes the science:
If you have a 32-bit version of Ubuntu,
cd /opt/google-earth/ sudo mv libQtCore.so.4 libQtCore.so.4.bak sudo mv libQtGui.so.4 libQtGui.so.4.bak sudo mv libQtNetwork.so.4 libQtNetwork.so.4.bak sudo mv libQtWebKit.so.4 libQtWebKit.so.4.bak sudo ln -s /usr/lib/libQtCore.so.4.4.3 libQtCore.so.4 sudo ln -s /usr/lib/libQtGui.so.4.4.3 libQtGui.so.4 sudo ln -s /usr/lib/libQtNetwork.so.4.4.3 libQtNetwork.so.4 sudo ln -s /usr/lib/libQtWebKit.so.4.4.3 libQtWebKit.so.4
If you have the 64-bit version of Ubuntu, try
cd /opt/google-earth/
sudo getlibs googleearth-bin
sudo mv libQtCore.so.4 libQtCore.so.4.bak
sudo mv libQtGui.so.4 libQtGui.so.4.bak
sudo mv libQtNetwork.so.4 libQtNetwork.so.4.bak
sudo mv libQtWebKit.so.4 libQtWebKit.so.4.bak
sudo ln -s /usr/lib32/libQtCore.so.4.4.3 libQtCore.so.4
sudo ln -s /usr/lib32/libQtGui.so.4.4.3 libQtGui.so.4
sudo ln -s /usr/lib32/libQtNetwork.so.4.4.3 libQtNetwork.so.4
sudo ln -s /usr/lib32/libQtWebKit.so.4.4.3 libQtWebKit.so.4
Requires to have getlibs installed, and when prompted, install the 32-bit versions of the packages as instructed.
Now, with qtconfig-qt you can configure the font settings.
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?
Parsing XKB files with antlr
antlr (well, antlr3) is an amazing tool that replaces lex/flex, yacc/bison.
One would use antlr3 if they want to deal with Domain-Specific Languages (DSL), an example of which are the text configuration files.
In our case, we use antlr3 to parse some of the XKB configuration files, those found in /etc/X11/xkb/symbols/??.
Our aim is to be able to easily read and write those configuration files. Of course, once we have them read, we do all sorts of processing.
The stable version of antlr3 is 3.0.1, which happened to give lots of internal errors. It has not been very useful, so I tried a few times the latest beta version 3.1b, and eventually managed to get it to work. If I am not mistaken, 3.1 stable should be announced in a few days.
When using antlr, you have the choice of several target languages, such as Java, C, C++ and Python. I am using the Python target, and the latest version that is available from the antlr3 repository.
Here is the tree of the gb layout file,
tree = (SECTION (MAPTYPE (MAPOPTIONS partial default alphanumeric_keys xkb_symbols) (MAPNAME "basic")) (MAPMATERIAL (TOKEN_INCLUDE "latin") (TOKEN_NAME Group1 (VALUE "United Kingdom")) (TOKEN_KEY (KEYCODEX AE02) (KEYSYMS 2 quotedbl twosuperior oneeighth)) (TOKEN_KEY (KEYCODEX AE03) (KEYSYMS 3 sterling threesuperior sterling)) (TOKEN_KEY (KEYCODEX AE04) (KEYSYMS 4 dollar EuroSign onequarter)) (TOKEN_KEY (KEYCODEX AC11) (KEYSYMS apostrophe at dead_circumflex dead_caron)) (TOKEN_KEY (KEYCODEX TLDE) (KEYSYMS grave notsign bar bar)) (TOKEN_KEY (KEYCODEX BKSL) (KEYSYMS numbersign asciitilde dead_grave dead_breve)) (TOKEN_KEY (KEYCODEX LSGT) (KEYSYMS backslash bar bar brokenbar)) (TOKEN_INCLUDE "level3(ralt_switch_multikey)"))) (SECTION (MAPTYPE (MAPOPTIONS partial alphanumeric_keys xkb_symbols) (MAPNAME "intl")) (MAPMATERIAL (TOKEN_INCLUDE "latin") (TOKEN_NAME Group1 (VALUE "United Kingdom - International (with dead keys)")) (TOKEN_KEY (KEYCODEX AE02) (KEYSYMS 2 dead_diaeresis twosuperior onehalf)) (TOKEN_KEY (KEYCODEX AE03) (KEYSYMS 3 sterling threesuperior onethird)) (TOKEN_KEY (KEYCODEX AE04) (KEYSYMS 4 dollar EuroSign onequarter)) (TOKEN_KEY (KEYCODEX AE06) (KEYSYMS 6 dead_circumflex NoSymbol onesixth)) (TOKEN_KEY (KEYCODEX AC11) (KEYSYMS dead_acute at apostrophe bar)) (TOKEN_KEY (KEYCODEX TLDE) (KEYSYMS dead_grave notsign bar bar)) (TOKEN_KEY (KEYCODEX BKSL) (KEYSYMS numbersign dead_tilde bar bar)) (TOKEN_KEY (KEYCODEX LSGT) (KEYSYMS backslash bar bar bar)) (TOKEN_INCLUDE "level3(ralt_switch)"))) (SECTION (MAPTYPE (MAPOPTIONS partial alphanumeric_keys xkb_symbols) (MAPNAME "dvorak")) (MAPMATERIAL (TOKEN_INCLUDE "us(dvorak)") (TOKEN_NAME Group1 (VALUE "United Kingdom - Dvorak")) (TOKEN_KEY (KEYCODEX BKSL) (KEYSYMS numbersign asciitilde)) (TOKEN_KEY (KEYCODEX AE02) (KEYSYMS 2 quotedbl twosuperior NoSymbol)) (TOKEN_KEY (KEYCODEX AE03) (KEYSYMS 3 sterling threesuperior NoSymbol)) (TOKEN_KEY (KEYCODEX AE04) (KEYSYMS 4 dollar EuroSign NoSymbol)) (TOKEN_KEY (KEYCODEX LSGT) (KEYSYMS backslash bar)) (TOKEN_KEY (KEYCODEX AD01) (KEYSYMS apostrophe at)))) (SECTION (MAPTYPE (MAPOPTIONS partial alphanumeric_keys xkb_symbols) (MAPNAME "mac")) (MAPMATERIAL (TOKEN_INCLUDE "latin") (TOKEN_NAME Group1 (VALUE "United Kingdom - Macintosh")) (TOKEN_KEY (KEYCODEX AE02) (KEYSYMS 2 at EuroSign)) (TOKEN_KEY (KEYCODEX AE03) (KEYSYMS 3 sterling numbersign)) (TOKEN_INCLUDE "level3(ralt_switch)")))
When traversing the tree, we can then pretty-print the layout at wish:
partial default alphanumeric_keys xkb_symbols "basic" {
name[Group1] = "United Kingdom";
include "latin"
include "level3(ralt_switch_multikey)"
key <AE02> = { [ 2 , quotedbl , twosuperior , oneeighth ] };
key <AE03> = { [ 3 , sterling , threesuperior , sterling ] };
key <AE04> = { [ 4 , dollar , EuroSign , onequarter ] };
key <AC11> = { [ apostrophe , at , dead_circumflex , dead_caron ] };
key <TLDE> = { [ grave , notsign , bar , bar ] };
key <BKSL> = { [ numbersign , asciitilde , dead_grave , dead_breve ] };
key <LSGT> = { [ backslash , bar , bar , brokenbar ] };
};
... snip ...
The code is currently hosted at code.google.com (keyboardlayouteditor) and I intend to move it shortly to FDO.
The Google Highly Open Participation Contest
One more initiative by Google to reach out to the community and promote free and open-source software is the The Google Highly Open Participation Contest 2007/2008.
The purpose of the competition is to enable young students older than 13 years old but have not entered yet the tertiary education, to participate in open-source development.
To get started, read the Official Contest Rules and the Frequently Asked Questions (FAQ) pages.
There are ten projects to choose to work from, one of which is GNOME, the desktop environment found in Linux distributions such as Ubuntu Linux and Fedora.
The current list of items to work on for GNOME include several documentation and translation tasks. If there is interest to work on the Greek localisation, leave a comment at this post. The direction I propose is to help with translating the documentation of GNOME applications.
Open-source software progresses by having more people contributing. This effort by Google and also previous efforts (Google Summer of Code) help tremendously towards the wider participation.
Localisation issues in home directory folders (xdg-user-dirs)
In new distributions such as Ubuntu 7.10 there is now support for folder names of personal data in your local language. What this means is that ~/Desktop can now be called ~/Επιφάνεια εργασίας. You also get a few more default folders, including ~/Music, ~/Documents, ~/Pictures and so on.
This functionality of localised home folders has become available thanks to a new FreeDesktop standard, XDG-USER-DIRS. xdg-user-dirs can be localised, and the current localisations are available at xdg-user-dirs/po.

A potential issue arises when a user logs in with different locales; how does the system switch between the localised versions of the folder names? For GNOME there is a migration tool; as soon as you login into your account with a different locale, the system will prompt whether you wish to switch the names from one language to another. This is available through the xdg-user-dirs-gtk application.
Another issue is with users who use the command line quite often; switching between two languages (for those languages that use a script other than latin) tends to become cumbersome, especially if you have not setup your shell for intelligent completion. In addition, when you connect remotely using SSH, you may not be able to type in the local language at the initial computer which would make work very annoying.
Furthermore, there have been reports with KDE applications not working; if someone can bug report it and post the link it would be great. The impression I got was that some installations of KDE did not read off the filesystem in UTF-8 but in a legacy 8-bit encoding. This requires further investigation.
Moreover, OpenOffice.org requires some integration work to follow the xdg-user-dirs standard; apparently it has its own option as to which folder it will save into any newly created files. I believe this will be resolved in the near future.
Now, if we just installed Ubuntu 7.10 or Fedora 8, and we got, by default, localised subfolders in our home directory (which we may not prefer), what can we do to revert to non-localised folders?
The lazy way is to logout, choose an English locale as the default locale for the system and log in. You will be presented with the xdg-user-dirs-gtk migration tool (shown above) that will give you the option to switch to English folder names for those personal folders.
Clarification: It is implied for this workaround (logout and login thing), you then log out again, set the language to the localised one (i.e. Greek) and log in. This time, when the system asks to rename the personal folders, you simply answer no, and you end up with a localised desktop but personal folders in English. Mission really accomplished.
If you are of the tinkering type, the files to change manually are
$ cat ~/.config/user-dirs.locale
el_GR
$
and
$ cat ~/.config/user-dirs.dirs
# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.
#
XDG_DESKTOP_DIR="$HOME/Επιφάνεια εργασίας"
XDG_DOWNLOAD_DIR="$HOME/Επιφάνεια εργασίας"
XDG_TEMPLATES_DIR="$HOME/Πρότυπα"
XDG_PUBLICSHARE_DIR="$HOME/δημόσιο"
XDG_DOCUMENTS_DIR="$HOME/Έγγραφα"
XDG_MUSIC_DIR="$HOME/Μουσική"
XDG_PICTURES_DIR="$HOME/Εικόνες"
XDG_VIDEOS_DIR="$HOME/Βίντεο"
Personally I believe that having localised names appear under the home folder is good for the majority of users, as they will be able to match what is shown in Locations with the actual names on the filesystem.
There will be cases that software has to be updated and bugs fixed (such as in backup tools). As we proceed with more advanced internationalisation/localisation support in Linux, it is desirable to follow forward, and fix problematic software.
However, if enough popular support arises with clear arguments (am referring to Greek-speaking users and a current discussion) for default folder names in the English languages, we could follow the popular demand.
Also see the relevant blog post New Dirs in Gutsy: Documents, Music, Pictures, Blah, Blah by Moving to Freedom.
OOXML voting process and controversy
By the end of this month, the ITC 1/SC 34 Technical Committee (ISO) will be voting on whether to accept or not OOXML as an ISO standard.
The voting countries (Participating countries) are
In addition, the following countries have observer status (Observer countries),
The observer countries, though the cannot vote, they can submit comments.
The current stage that OOXML is at, is 40.20, which means is the period that leads to the voting whether to accept or not as an ISO standard.
This proposed document format is controversial because an existing document format exists, the OpenDocument document format, ISO/IEC 26300, Open Document Format for Office Applications (OpenDocument) v1.0, since 2006.
OOXML is a controversial document format. Read more on this regarding OOXML.
In addition, see the Technical White Paper on OpenDocument and OOXML by the ODF Alliance UK Action Group. Another whitepaper, ODF/OOXML technical white paper by Edward Macnaghten.
Open Malaysia is also valuable resource (includes blog contributions relating to open standards). For example, in spreadsheets in OOXML one cannot write dates before the 1st March 1900!
Finally, Achieving Openness: A Closer Look at ODF and OOXML by Sam Hiser.
Update #1: Microsoft is Outmuscling OOXML Opposition in Spain
Update #2: It is important to vote NO rather than abstain. It is sad that Spain decided to abstain rather than voting NO. UPDATE: Spain is an observer, thus cannot cast a vote. Somewhat lost en la traduccion.
Update #3: Czech comments on OOXML.
Translating OLPC software
The core OLPC software is developed at http://dev.laptop.org/ using the GIT source code management system.
For the tasks of the translator, one needs to look into the different projects and locate any po/ subdirectory. The existence of this subdirectory show that the piece of software is internationalised (=can be translated).
For example, the core component sugar can be translated. In the main sugar page, and locate the po/ subdirectory that shows up. Click on it and you get the sugar po/ subdirectory with a few translations. Specifically, Yoruba, Hausa, Igbo and Italian. The italian translation is sadly useless. The translator made a mistake; he saw
msgid "Hello"
msgstr ""
and changed to (WRONG)
msgid "Ciao"
msgstr ""
instead of (CORRECT)
msgid "Hello"
msgstr "Ciao"
Normally, one would need to regenerate the Template PO (POT) file before translating, instead of working on one of the existing translated files. To do so, one needs to download the source code of sugar using the git tool and then use intltool-update -P to create the fresh sugar.pot file.
Translating the OLPC
In a previous post, we covered how to install fonts and enabling writing support on the OLPC. The OLPC contains a limited number of applications that are available to be translated. These applications include
- NetworkManager, part of the GNOME project (HEAD, extras)
- alsa-utils, ???
- aspell, external
- atk10, part of the GNOME project (GNOME 2.18, developer)
- chkconfig, part of the Fedora Project
- diffutils, external
- glib20, part of the GNOME project (GNOME 2.18, developer)
- gst-plugins-base-0.10, external
- gst-plugins-good-0.10, external
- gstreamer-0.10, external
- gtk20-properties, part of the GNOME project (GNOME 2.18, developer)
- gtk20, part of the GNOME project (GNOME 2.18, developer)
- hal, external
- initscripts, part of the Fedora Project
- libc, part of the Translation Project (reduced version?)
- libuser, part of the Fedora Project
- libwnck, part of the GNOME Project (GNOME 2.18, desktop)
- stardict, external
- vte, part of the GNOME Project (GNOME 2.18, desktop)
- wget, part of the Translation Project
The links provided point to the latest available version. The versions that the OLPC using are not the latest with the upstream project, therefore keep in mind that the translated files may differ. It would be good to establish the exact .PO files from the OLPC project (URL to source?).
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.
Διάθεση των γραμματοσειρών DejaVu 2.8
Πριν από λίγο ανακοινώθηκε η νέα έκδοση των γραμματοσειρών DejaVu 2.8.
Μεταξύ των βελτιώσεων είναι η προσθήκη hinting στη DejaVu Sans Bold για τα ελληνικά. Όπως ήταν μέχρι τώρα, είχαμε hinting μόνο στη DejaVu Sans.
Το hinting στη DejaVu Sans Bold έγινε από τον Ben Laenen ενώ για τη DejaVu Sans από τον Keenan Pepper.
Είναι πολύ σημαντικό που έχουμε τις DejaVu Sans (Book) και DejaVu Sans Bold με πληροφορίες hinting διότι αυτές οι δύο είναι οι πιο βασικές γραμματοσειρές στο γραφικό περιβάλλον στο Linux. Στους τίτλους των παραθύρων καθώς και στους τίτλους στο Evolution εμφανίζονται χαρακτήρες στη μορφή bold. Τώρα, οι ελληνόφωνοι χρήστες θα έχουν ένα ποιοτικό αποτέλεσμα σε ένα τυπικό γραφικό περιβάλλον. Δίχως πληροφορίες hinting στην ίδια τη γραμματοσειρά, οι ελληνικοί χαρακτήρες bold φαίνονται αχνοί σε οθόνες TFT (π.χ. φορητοί) όταν το μέγεθος της γραμματοσειράς είναι ~12pt ή μικρότερο.
Αυτό το θάμπωμα στους χαρακτήρες προέρχεται από το αυτόματο hinting που κάνει το σύστημα οπότε αν δεν μπορείτε να αναβαθμίσετε, δοκιμάστε να μειώσετε το επίπεδο αυτόματου hinting που κάνει το σύστημα από Σύστημα/Προτιμήσεις/Γραμματοσειρά/Λεπτομέρειες.../Hinting (από Πλήρες σε π.χ. Ελαφρύ).
Άλλη σημαντική προσθήκη στις γραμματοσειρές DejaVu είναι η προσθήκη περισσότερων dingbats στη DejaVu Sans Mono.
Στη Fedora Core 6 κατά πάσα πιθανότητα θα μπει η DejaVu LGC 2.8, που δεν περιλαμβάνει κάποιο μέρος από τους χαρακτήρες (αραβικά). LGC σημαίνει Latin, Greek και Cyrillic.

