Timezones, clock applet and marketing dangers
It is great to receive feedback from users that try out the development versions of distributions (such as Ubuntu and Fedora). Usually, these are small bugs that can easily get fixed. However, there is this bug that looks potent to lead to political dissatisfaction and bad publicity to GNOME.
The clock applet (gnome-panel) now shows the timezones of cities that one selects. You click on the Edit button, you select the city (it comes from Locations.xml - libgweather, which has the coordinates of each city entry), and the applet makes a guess of what is your timezone (each timezone comes with longitude information).
So, if a city is far away from the capital city of your country (and closer to the capital city of a neighboring country), then the applet often proposes the wrong timezone. Considering that in some (=many) cases there is some animosity between neighboring countries, this makes users unhappy.
Launchpad bug report: Bug #185190, Clock applet chooses wrong timezone for many cities (eg Pittsburgh, Beijing)
GNOME Bugzilla bug report: Bug 519823 – Cities associated with wrong timezone
Updated (8Apr2008): The bug has been fixed upstream (thanks Dan!) and most likely makes it in GNOME 2.22.1, which means Ubuntu 8.04 and other distributions will get the update as well. Some countries with regions that have more than one timezone may want to check that the correct timezone is selected for each region.
Important MO file optimisation for en_* locales, and partly others
During GUADEC, Tomas Frydrych gave a talk on exmap-console, a cut-down version of exmap that can work well on mobile devices.
During the presentation, Tomas showed how to use the tool to find the culprits in memory (ab)use on the GNOME desktop. One issue that came up was that the MO files taking up space though the desktop showed English. Why would the MO translation files loaded in memory be so big in size?
gtk20.mo : VM 61440 B, M 61440 B, S 61440 B atk10.mo : VM 8192 B, M 8192 B, S 8192 B libgnome-2.0.mo : VM 28672 B, M 24576 B, S 24576 B glib20.mo : VM 20480 B, M 16384 B, S 16384 B gtk20-properties.mo : VM 128 KB, M 116 KB, S 116 KB launchpad-integration.mo : VM 4096 B, M 4096 B, S 4096 B
A translation file looks like
msgid "File"
msgstr ""
When translated to Greek it is
msgid "File"
msgstr "Αρχείο"
In the English UK translation it would be
msgid "File"
msgstr "File"
This actually is not necessary because if you leave those messags untranslated, the system will use the original messages that are embedded in the executable file.
However, for the purposes of the English UK, English Canadian, etc teams, it makes sense to copy the same messages in the translated field because it would be an indication that the message was examined by the translation. Any new messages would appear as untranslated and the same process would continue.
Now, the problem is that the gettext tools are not smart enough when they compile such translation files; they replicate without need those messages occupying space in the generated MO file.
Apart from the English variants, this issue is also present in other languages when the message looks like
msgid "GConf"
msgstr "GConf"
Here, it does not make much sense to translate the message in the locale language. However, the generated MO file contains now more than 10 bytes (5+5) , plus some space for the index.
Therefore, what's the solution for this issue?
One solution is to add to msgattrib the option to preprocess a PO file and remove those unneeded copies. Here is a patch,
--- src.ORIGINAL/msgattrib.c 2007-07-18 17:17:08.000000000 +0100
+++ src/msgattrib.c 2007-07-23 01:20:35.000000000 +0100
@@ -61,7 +61,8 @@
REMOVE_FUZZY = 1 << 2,
REMOVE_NONFUZZY = 1 << 3,
REMOVE_OBSOLETE = 1 << 4,
- REMOVE_NONOBSOLETE = 1 << 5
+ REMOVE_NONOBSOLETE = 1 << 5,
+ REMOVE_COPIED = 1 << 6
};
static int to_remove;
@@ -90,6 +91,7 @@
{ "help", no_argument, NULL, 'h' },
{ "ignore-file", required_argument, NULL, CHAR_MAX + 15 },
{ "indent", no_argument, NULL, 'i' },
+ { "no-copied", no_argument, NULL, CHAR_MAX + 19 },
{ "no-escape", no_argument, NULL, 'e' },
{ "no-fuzzy", no_argument, NULL, CHAR_MAX + 3 },
{ "no-location", no_argument, &line_comment, 0 },
@@ -314,6 +316,10 @@
to_change |= REMOVE_PREV;
break;
+ case CHAR_MAX + 19: /* --no-copied */
+ to_remove |= REMOVE_COPIED;
+ break;
+
default:
usage (EXIT_FAILURE);
/* NOTREACHED */
@@ -436,6 +442,8 @@
--no-obsolete remove obsolete #~ messages\n"));
printf (_("\
--only-obsolete keep obsolete #~ messages\n"));
+ printf (_("\
+ --no-copied remove copied messages\n"));
printf ("\n");
printf (_("\
Attribute manipulation:\n"));
@@ -536,6 +544,21 @@
: to_remove & REMOVE_NONOBSOLETE))
return false;
+ if (to_remove & REMOVE_COPIED)
+ {
+ if (!strcmp(mp->msgid, mp->msgstr) && strlen(mp->msgstr)+1 >= mp->msgstr_len)
+ {
+ return false;
+ }
+ else if ( strlen(mp->msgstr)+1 < mp->msgstr_len )
+ {
+ if ( !strcmp(mp->msgstr + strlen(mp->msgstr)+1, mp->msgid_plural) )
+ {
+ return false;
+ }
+ }
+ }
+
return true;
}
However, if we only change msgattrib, we would need to adapt the build system for all packages.
Apparently, it would make sense to change the default behaviour of msgfmt, the program that compiles PO files into MO files.
An e-mail was sent to the email address for the development team of gettext regarding the issue. The development team does not appear to have a Bugzilla to record these issues. If you know of an alternative contact point, please notify me.
Update #1 (23Jul07): As an indication of the file size savings, the en_GB locale on Ubuntu in the installation CD occupies about 424KB where in practice it should have been 48KB.
A full installation of Ubuntu with some basic KDE packages (only for the basic libraries, i.e. KBabel - (ls k* | wc -l = 499)) occupies about 26MB of space just for the translation files. When optimising in the MO files, the translation files occupy only 7MB. This is quite important because when someone installs for example the en_CA locale, all en_?? locales are added.
The reason why the reduction is more has to do with the message types that KDE uses. For example,
msgid ""
"_: Unknown State\n"
"Unknown"
msgstr "Unknown"
I cannot see a portable way to code the gettext-tools so that they understand that the above message can be easily omitted. For the above reduction to 7MB, KDE applications (k*) occupy 3.6MB. The non-KDE applications include GNOME, XFCE and GNU traditional tools. The biggest culprits in KDE are kstars (386KB) and kgeography (345KB).
Update #2 (23Jul07): (Thanks Deniz for the comment below on gweather!) The po-locations translations (gnome-applets/gweather) of all languages are combined together to generate a big XML file that can be found at usr/share/gnome-applets/gweather/Locations.xml (~15MB).
This file is not kept in memory while the gweather applet is running.
However, the file is parsed when the user opens the properties dialog to change the location.
I would say that the main problem here is the file size (15.8MB) that can be easily reduced when stripping copied messages. This file is included in any Linux distribution, whatever the locale.
The po-locations directory currently occupies 107MB and when copied messages are eliminated it occupies 78MB (a difference of 30MB). The generated XML file is in any case smaller (15.8MB without optimisation) because it does not include repeatedly the msgid lines for each language.
I regenerated the Locations.xml file with the optimised PO files and the resulting file is 7.6MB. This is a good reduction in file space and also in packaging size.
Update #3 (25Jul07): Posted a patch for gettext-tools/msgattrib.c. Sent an e-mail to the kde-i18n-doc mailing list and got good response and a valid argument for the proposed changes. Specifically, there is a case when one gives custom values to the LANGUAGE variable. This happens when someone uses the LANGUAGE variable with a value such as "es:fr" which means show me messages in Spanish and if something is untranslated show me in French. If a message has msgid==msgstr for Spanish but not for French, then it would show in French if we go along with the proposed optimisation.
Mentoring facility available in Launchpad, Ubuntu
Is there a bug report in Launchpad.net (Ubuntu) that you are confident you can help someone to fix but do not have the time to fix yourself?
Now Launchpad provides the facility for contributors to offer mentoring support to bug reports and blueprints, so that users can apply and receive mentoring. With mentoring you help someone else solve a problem. Ubuntu is benefited, and also the new user gets help in resolving bugs.
For the Greek language there is an Ubuntu team called Ubuntu Greek Testers. Users interested for the Greek language in Ubuntu can subscribe to team. Then, for any bug report that relates to the Greek language support, we subscribe the team as a member. The system is configured in such a way so that any activity on those bug reports is mailed to each member. This makes it easy to track the status of reports.
You can see the current list of pending reports for the Greek language in Ubuntu.
One of the bug reports is about the Broken context-sensitive spell check in evolution (Greek, Russian, etc) GNOME #344008.
This report has been there for around 2 years and it should be fixed soon. I am not sure what the best course of action should be. Well, the typical course of action would be to compile GNOME manually (jhbuild), locate the code in Evolution that deals with gnome-spell and put printf()s that show what's going on when this part of the code is reached. Any takers?
Update: Just offered mentorship for https://bugs.launchpad.net/evolution/+bug/10713
I understand the direction to work on but do not know what exactly is going on.
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.
Multimedia support in Ubuntu Linux 6.10
This is a follow-up to the article Multimedia support in Ubuntu Linux 6.06 on how to add extended multimedia support to the Ubuntu Linux distribution.
The new version of Ubuntu Linux, 7.04, has a new functionality to help add multimedia support in a seamless way; when you try to play a media file that requires a new codec, you will be asked to install it at that time. The new functionality was made available thanks to the work on the gstreamer multimedia library (bug #161922 - script to provide plugin installation info), and work with the Ubuntu distribution. It is important to note that the new version of Fedora Linux 7 has a similar mechanism of automatic multimedia support installation.
In Ubuntu 6.10, start System/Administration/Synaptic Package Manager. Under Settings/Repositories, select the universe and multiverse repositories. Click ok, then Reload to update your package cache.
Subsequently, click on Search and type in
gstreamer-0.10
You will get quite a few results; you can install packages found apart from those which names end with -dev (development packages, not normally required) and -dbg (debug packages, not normally required).
Finally, the w32codecs package (do a new search for this) adds support to other binary codecs that no native Linux software exists yet.
Επιστροφή από GUADEC 2006
Σήμερα το πρωί επέστρεψα από το συνέδριο GNOME User and Developer European Conference (GUADEC).
Το συνέδριο ήταν μια πολύ καλή ευκαιρία για να συναντηθούν τα άτομα που εργάζονται στο ίδιο το γραφικό περιβάλλον GNOME και αλλά σημαντικά έργα όπως το Xorg.
Οι πρώτες δύο μέρες ήταν για warm up και υπήρχαν θέματα γενικά για το ελεύθερο λογισμικό. Υπήρξαν αναφορές για τοπικοποίηση ελεύθερου λογισμικού όπως OOo και Mozilla. Ο οργανισμός SIL International έκανε επίδειξη την δουλειά που κάνει με τη βιβλιοθήκη graphite, που επιτρέπει την απεικόνιση περίπλοκων γραφών (ινδικά, κτλ) καθώς και τη γραφή με τη χρήση combining marks. Για το τελευταίο, όταν π.χ. κάποιος γράφει ελληνικά μπορεί να χρησιμοποιήσει είτε χαρακτήρες precomposed (με τα σημάδια ήδη επάνω τους) είτε τους χαρακτήρες της αλφαβήτου με τα combining marks. Δοκιμάστε να γράψετε σε GNOME
α + Ctr-Shift-301 παράγει ά
Δηλαδή υπάρχει διαφορά στην κωδικοποίηση των ά και ά καθώς και μικρή διαφορά στην εμφάνιση τους. Σε παραδείγματα με πιο περίπλοκα σημάδια, το πρόβλημα αυτό είναι ακόμα πιο φανερό.

Με τη μηχανή graphite είναι δυνατό να αποδοθούν οι κατάλληλες πληροφορίες στις γραμματοσειρές για να γίνει η σωστή απεικόνιση.
Ακόμα, η βιβλιοθήκη KMFL επιτρέπει το εύκολο γράψιμο σε άλλες γλώσσες. Σε Ubuntu είναι διαθέσιμη ως συστατικό του SCIM.
Ο Federico Mena Quintero έκανε μια βασική παρουσίαση για τα πρώτα βήματα στο προγραμματισμό και στη δημιουργία επιρραμμάτων (patches). Στόχος της παρουσίασης ήταν να κάνει την τοπική κοινότητα να ξεκινήσει τον προγραμματισμό.
Την πρώτη ημέρα του Guadec ο Jeff Waugh άνοιξε το συνέδριο με παρουσίαση των βασικών στόχων του έργου GNOME. Στο προσκήνιο είναι ο Dave Neary.
![]()
Ο Alex Graveley παρουσίασε το Gimmie, ενός προγράμματος που μπορεί να αντικαταστήσει το ταμπλώ στο GNOME. Υπάρχει τώρα και ελληνική μετάφραση του πακέτου.
Ο Miguel κάθεται στα δεξιά (πράσινο t-shirt).
Η Kathy Sierra έκανε μια παρουσίαση με τίτλο How to make passionate users. Η παρουσίαση αυτή ήταν από της καλύτερες του συνεδρίου διότι παρουσίασε προβλήματα στη σωστή προβολή και διάδοση ελεύθερου λογισμικού. Συγκεκριμένα, πρέπει να υπάρχει μια ροή κατά τη διάρκεια της εκμάθησης ενός νέου πακέτου λογισμικού ώστε να γίνει η μετατροπή ενός νέου χρήστη σε ένα παθιασμένο χρήστη.
O Behdad έκανε μια παρουσίαση για το pango και τις γραμματοσειρές. Υπάρχει ένα ζήτημα για το θέμα της σωστής υποστήριξης ελληνικών στη διανομή Fedora Core Linux. Αυτή τη στιγμή η πιο κατάλληλη ελεύθερη γραμματοσειρά είναι η DejaVu. Δεν έγινε αναφορά στο ζήτημα αυτό, σε αυτό το σημείο.
O Robert Love έκανε μια παρουσίαση για το NetworkManager, που επιτρέπει εφαρμογές να διατηρούν μια σωστή σύνδεση με το δίκτυο. Το πακέτο αυτό είναι ιδιαίτερο σημαντικό όταν υπάρχουν πολλαπλά access points και θέλετε να υπάρχει αυτόματη ρύθμιση δικτύου. Στην ίδια παρουσίαση, ο Robert αναφέρθηκε και το πακέτο FUSE που επιτρέπει στους χρήστες να γράφουν τα δικά τους συστήματα αρχείων σε κατάσταση χρήστη (userspace).
Ο Damien Sandras παρουσίασε το Ekiga, πρόγραμμα επικοινωνίας μέσω φωνής και βίντεο. Φαίνεται ότι υπάρχει ανάγκη για βοήθεια στο θέμα της προώθησης του λογισμικού (μάρκετινγκ).
Ο Alexander Larsson παρουσίασε το νέο API για εκτυπώσεις σε GTK+. Υπήρξε συζήτηση για κάποιες επιλογές με το ενδεχόμενο να υπάρχουν άλλες επιλογές. Πάντως έγινε αναφορά ότι για τώρα δεν είναι εύκολη η αντιγραφή και επικόλληση του κειμένου μέσα από το νέο API.
Έπειτα, ο Federico έκανε το μεσημεριανό keynote με τίτλο How Much Faster? περιγράφοντας τις στρατηγικές βελτιστοποίησης του λογισμικού ώστε να μην υπάρχει παράξενα κολλήματα κατά τη χρήση (ζητήματα ροής από την παρουσίαση της Kathy). Υπάρχει ένα σημαντικό θέμα στην ανάλυση πακέτων λογισμικού όπως Evolution και Firefox για τη βελτιστοποίηση της χρήσης μνήμης και της διαδραστικότητάς τους.
O Glynn Foster παρουσίασε το πακέτο DTrace που επιτρέπει τον έλεγχο της λειτουργίας λογισμικού (χρειάζεται αλλαγές στον πυρήνα). Το DTrace είναι διαθέσιμο σε Solaris και FreeBSD. Είναι αρκετά καλό να το χρησιμοποιήσει κάποιος για την κατανόηση των προβλημάτων μνήμης/ταχύτητας των πακέτων ελεύθερου λογισμικού.
Την επόμενη μέρα, ο Lluis Sanchez παρουσίασε το MonoDevelop και τα νεώτερά του χαρακτηριστικά. Το MonoDevelop επιτρέπει την εύκολη δημιουργία εφαρμογών σε Mono αλλά και για άλλες γλώσσες.
Ο Jim Gettys παρουσίασε το έργο OLPC και αναφέρθηκε στις πληροφορίες που μπορεί να βρει κάποιος και από το www.laptop.org. Έβγαλα φωτογραφίες με τις διαφάνειες και θα τις βάλω κάπου σύντομα.
Ο Lluis Villa έκλεισε το συνέδριο GUADEC με μια πολύ δυνατή παρουσίαση. Ο Lluis ήταν bugmaster στο bugzilla.gnome.org και έχει προσφέρει αρκετά. Τώρα ξεκινά πτυχίο για δικηγόρος με αποτέλεσμα να είναι εκτός της σκηνής για τα επόμενα 4 χρόνια. Χρησιμοποίησε το στοιχείο αυτό για να αναφερθεί στο 2010 και σε τι πιστεύει να έχει γίνει μέχρι τότε. Το μήνυμά του ήταν ότι GNOME is about people.
Οι επόμενες δύο μέρες ήταν της μορφής After Hours workshop.
Υπήρξε μια συζήτηση για το OLPC από τον Jim Gettys. Έγινε αναφορά στην τοπικοποίηση και στα τυχόν προβλήματα καθώς και στο ζήτημα της ανάγκης hinting στις γραμματοσειρές.
Ακόμα, έγινε μια συζήτηση για το θέμα των γραμματοσειρών στη διανομή Fedora. Όπως είναι τώρα, όταν κάποιος εγκαταστήσει ελληνικά, έχει ένα αποτέλεσμα που μοιάζει με αυτό το χάλι. Ο λόγος για τον οποίο δεν έχει μπει άμεσα η γραμματοσειρά DejaVu στη διανομή Fedora είναι διότι η γραμματοσειρά αυτή περιλαμβάνει αραβικούς χαρακτήρες και μπορεί εν δυνάμει να δημιουργήσει πρόβλημα στους χρήστες από αραβικές χώρες. Ωστόσο, το ίδιο ζήτημα το έχουμε στα ελληνικά, και η πραγματική λύση είναι η επέκταση του υποσυστήματος fontconfig για να επιτρέπει τη μη-χρήση χαρακτήρων σε συγκεκριμένες γραμματοσειρές μέσω του αρχείου ρυθμίσεων /etc/fonts/fonts.conf
Ο Keith Package δήλωσε ότι θα δεχτεί επίρραμμα (patch) για την προσθήκη της νέας λειτουργίας, που θα απενεργοποιεί μια και καλή περιοχές χαρακτήρως σε συγκεκριμένες γραμματοσειρές. Κάτι τέτοιο είναι καλό για τα ελληνικά. Από την πλευρά του, οι Nicholas και Jay (sun.com) ετοίμασαν ένα επίρραμμα που υλοποιεί κάτι παραπλήσιο αλλά επιτρέπει εκείνους τους κακούς χαρακτήρες να είναι χρησιμοποιήσιμοι με απευθείας επιλογή. Κάτι τέτοιο ίσως είναι πιο θεμιτό διότι για π.χ. το κοινό που γράφει CJK και θέλουν τα ελληνικά που υπάρχουν στις γραμματοσειρές τους.
Ο Behdad από την πλευρά του δήλωσε ότι θα δεχτεί την DejaVu LGC. Τώρα είμαστε στο σημείο να κλείσει το ζήτημα με την επιλογή μιας ή και των δύο επιλογών.
Έκανα μια παρουσίαση για το θέμα της γραφής στο GNOME και συγκεκριμένα ότι είναι θεμιτό (desirable) να υπάρχει η δυνατότητα να μπορούν οι χρήστες να γράφουν ακόμα περισσότερους χαρακτήρες που υποστηρίζει το Unicode και οι γραμματοσειρές.
Η επιστροφή ήταν θεαματική. Προλάβαμε το αεροπλάνο με περιθώριο ~10 λεπτά. Το μέρος (venue) ήταν πολύ όμορφο και υπήρξε παραλία αρκετά κοντά...
Ένας από τους προσκεκλημένους ήταν από την Μογγολία. Του δώρισαν ένα βιβλίο για το Mono (εκείνο το μπλε βιβλίο) και έβαλε και τον Miguel να το υπογράψει ![]()
Το επόμενο Guadec θα γίνει στο Birmingham, στο H.B. Όσοι είστε στην Αγγλία αξίζει να πάτε.
Τι είναι το mugshot.org;
Τι είναι το mugshot.org;
Είναι ένας δικτυακός τόπος που επιτρέπει τη δημιουργία κοινωνικών ομάδων (social groups) με κοινά ενδιαφέροντα μέσω Διαδικτύου.
Αυτή τη στιγμή επιτρέπει το διαμοιρασμό με τα υπόλοιπα μέλη της ομάδας σας τους τίτλους της μουσικής που ακούτε αλλά και συνδέσμους που που βρίσκετε ότι έχουν ενδιαφέρον. Η διαμοίραση αυτή είναι άμεση, μέσω εφαρμογής που εγκαθιστάτε (Windows, Linux/i386 για τώρα) και ο καθένας βλέπει το στοιχείο που έχει διαμοιραστεί μέσω μιας ειδοποίησης (notification - baloon).
Ένα ενοχλητικό πρόβλημα με το mugshot είναι ότι δε χρησιμοποιεί Unicode σε αυτή τη φάση με αποτέλεσμα να μην δέχεται ελληνικά. Πιστεύω ότι θα διορθωθεί σύντομα, μιας και έχει καταγραφεί το πρόβλημα στο http://bugzilla.mugshot.org/.
Το βασικό ενδιαφέρον με το mugshot είναι ότι προέρχεται από τη δουλειά της Red Hat (χρηματοδότηση από Yahoo! και Amazon).
Έτσι, μπορείτε να φανταστείτε ότι η ομάδα σας δρα ως σμήνος (swarm) σε νέες πληροφορίες που στέλνουν τα μέλη.
Για να πάρετε λογαριασμό πρέπει να δηλώσετε το ενδιαφέρον σας στο http://www.mugshot.org/. Διαφορετικά κάποιος που έχει ήδη λογαριασμό μπορεί να σας στείλει μια πρόσκληση. Εγώ εξάντλησα τις προσκλήσεις μου, οπότε μπορείτε να ενοχλήσετε τα άτομα που κάλεσα (παίρνουν οι ίδιοι μια σειρά από προσκλήσεις).
Στείλτε εδώ σχόλιο αν θέλετε να δημιουργήσετε λογαριασμό στο mugshot.org.
Can you read Coptic?

Coptic is the most recent phase of ancient Egyptian. It is the direct descendant of the ancient language written in Egyptian hieroglyphic, hieratic, and demotic scripts. The Coptic alphabet is a slightly modified form of the Greek alphabet, with some letters (which vary from dialect to dialect) deriving from demotic. As a living language of daily conversation, Coptic flourished from ca. 200 to 1100. The last record of its being spoken was during the 17th century. Coptic survives today as the liturgical language of the Coptic Orthodox Church. Egyptian Arabic is the spoken and national language of Egypt today.
Source: Wikipedia on Coptic Language
Coptic, as used today, has signs of influence from the Greek language. If you speak Greek, you should be able to recognise every entry in the screenshot (it comes from the dictionary that is available from http://copticlang.bizhat.com/).
There is a Coptic Unicode block and there are at least three Unicode fonts available with Coptic glyphs.
I am not aware of a keyboard definition to write Unicode Coptic; Coptic uses several combining diacritical marks (accents) and appears to surpass even Ancient Greek/Polytonic in this respect. An easy way to create (easy to write with?) method would be to start from the Greek keyboard layout and replace the codepoints with the Coptic ones. For the 9 combining diacritical marks, three keys should be dedicated, accessible through 1) pressing as is, 2) pressing with shift, 3) pressing with Alt. To avoid using dead keys, there would be a requirement to type first the letter and then the diacritical mark.
In modern Greek we use the ";:" key (on the right of L) to produce the acute and the diaeresis (with Shift) accents. The second suitable key could be the ' " key while the third the "/?" (debateable).
There are several efforts to convert non-Unicode fonts distributed by the Coptic Church. website. Moheb added the Coptic glyphs to the Freefonts. There is more work required to get them added by default to Linux distros. There is a discussion forum on Coptic.
Therefore, the most important task is to create a keyboard layout so that one can write in Unicode Coptic.
Then, existing (non-Unicode) text should be converted to Unicode Coptic so that there is material available. Moheb created support for this in iconv (glibc). There should be a bug report at http://sources.redhat.com/bugzilla/ under product glibc, component libc.

Source: Wikipedia (Coptic script)
There exist free Unicode fonts already to have the text displayed. The conversion of the Coptic Church fonts to Unicode would be beneficial as well. To have them included in Linux distros, the distribution license should be set to one of the FLOSS licenses. An option could be to add to the DejaVu fonts (allowed by the license) so that there is a general purpose open font that is easy to work with.
I, for one, would love to write Greek using a Coptic keyboard layout and a Coptic Unicode font.
Update: Screenshot that demonstrates how well Unicode Coptic fonts behave when combining marks are used.

Update #2: You can test the above on your system by opening this OpenDocument file using OpenOffice.org or any other OpenDocument-compatible application. OpenOffice.org was verified that it can show combining marks. Your mileage may vary, your comments will be appreciated.
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
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.
Δοκιμή της Fedora Core 5 test 3

Η γραμματοσειρά είναι η DejaVu 2.3 (ελεύθερη). Αυτό είναι το ελληνικό GNOME 2.13.x, που από τις προσπάθειες του Κώστα Παπαδήμα το βασικό του κομμάτι είναι πλήρως μεταφρασμένο.
Μπορείτε να δείτε ότι με την προσθήκη της μικροεφαρμογής για τις Καιρικές Συνθήκες, επιλέγει αυτόματα την Αθήνα.
Ακόμα, λόγω της πρόσφατης αλλαγής στο ελληνικό locale της glibc, τώρα η ώρα στην Ελλάδα ακολουθεί τη μορφή του 12-ωρου ρολογίου (μπορείτε να το αλλάξετε από τις ρυθμίσεις στην μορφή 24-ώρες).
Η διανομή Fedora Core 5 παρέχει επιτάχυνση υλικού για την κάρτα γραφικών.
Η διανομή Fedora Core 5 βρίσκεται σε ανάπτυξη (test 3) πριν την έκδοση της νέας έκδοσης στα μέσα Μαρτίου. Δεν είμαι σίγουρος κατά πόσο θα μπουν ορισμένες αλλαγές για να είναι καλή η χρήση των ελληνικών από τη διανομή. Μόλις χτες έκανα την εγκατάσταση και δοκιμή. Όπως είναι τώρα, πρέπει να κάνετε εγκατάσταση την γραμματοσειρά dejavu και να την καθορίσετε στις ρυθμίσεις της επιφάνειας εργασίας. Ακόμα, φαίνεται ότι η Fedora δεν έχει τα πιο πρόσφατα αρχεία σχετικά με την υποστήριξη πληκτρολογίου (με αποτέλεσμα να χρειάζονται μερικές ρυθμίσεις με το χέρι ;-() και ένας από τους βασικούς προγραμματιστές του έργου δεν έχει πειστεί για αυτό. Πρέπει να διαπιστώσω αν έχω εγώ δίκιο ή ο προγραμματιστής. Όντως υπήρξε χτες βράδυ ένα ανανεωμένο πακέτο xorg-x11-xkbdata, ωστόσο πιστεύω ότι δε διόρθωσε το πρόβλημα.
OpenOffice.org και ελληνικές γραμματοσειρές
Το OpenOffice.org εμφανίζει πρόβλημα στις ελληνικές γραμματοσειρές, σε ορισμένα συστήματα. Σε εκείνα τα συστήματα που οι βασικές γραμματοσειρές δεν περιλαμβάνουν ελληνικούς χαρακτήρες, για παράδειγμα σε τυπική εγκατάσταση Linux.
Αυτό που συμβαίνει είναι το OOo να επιλέγει ελληνικά από ιαπωνικές/κορεάτικες γραμματοσειρές που τυχαίνει να έχουν μερικούς ελληνικούς χαρακτήρες.

Αυτή η ιαπωνική γραμματοσειρά (γραμμές 1, 3-6) έχει πλήρες πλάτος (full width) με αποτέλεσμα να φαίνονται οι χαρακτήρες αραιοί σε εμάς. Ακόμα, δεν περιλαμβάνει χαρακτήρες για τα περισσότερα φωνήεντα. Το αντίστοιχο κείμενο με την FreeSans (γραμμές 2, 7-10) δείχνει πως πρέπει να εμφανίζονται οι προγούμενες γραμμές.
Γιατί γίνεται χρήση των ιαπωνικών γραμματοσειρών; Μάλλον σχετίζεται με το σφάλμα #4639/freedesktop. Το OOo έχει μια δική του υλοποίηση της λίστα προτεραιότητας στις γραμματοσειρές και έχεις εκείνες τις ιαπωνικές σε μεγαλύτερη προτεραιότητα. Στην αναφορά σφάλματος #57426/openoffice.org περιγράφουμε το πρόβλημα και αναζητούμε την λύση, ποιο αρχείο εσωτερικά στο OOo έχει να κάνει με την προτίμηση γραμματοσειρών.
Το σημαντικό σημείο είναι ότι διανομές όπως το Ubuntu διατίθενται με καλές ελληνικές γραμματοσειρές, FreeFonts (FreeSans, FreeSerif, FreeMono) και MgOpen (MgOpen Canonica, MgOpen Moderna, MgOpen Modata, MgOpen Cosmetica) που μπορούν να χρησιμοποιηθούν στην προεπιλεγμένη εγκατάσταση. Τώρα συμπεριλαμβάνονται στο βασικό πρώτο CD του Ubuntu Linux 5.10! Όπως, το OOo δεν τις επιλέγει για να εμφανίσει ελληνικά.
Το θέμα των ελληνικών γραμματοσειρών μάς είχε ταλαιπωρήσει και παλαιότερα, με την αναφορά σφάλματος #2374/Ubuntu.
Υπάρχει ένα αρχείο στο OOo, το VCL.xcu, που επιτρέπει την επιλογή γραμματοσειρών ανάλογα με την γλώσσα του εγγράφου. Εδώ δεν υπάρχει ενότητα για την ελληνική γλώσσα, που εξηγεί ένα μέρος του προβλήματος. Στο ελληνικό κομμάτι μπορούμε να βάλουμε ελληνικές γραμματοσειρές και το ΟΟο θα τις δείξει. Όμως, το ίδιο πρέπει να κάνουμε και για κάθε άλλη γλώσσα (π.χ. Αγγλικά, Γερμανικά, κτλ), που δείχνει ότι είναι μεν μια σωστή κίνηση, δεν είναι η πλήρης λύση. Αυτό είναι το πρόβλημα που θέλουμε να λύσουμε.
Το πρόβλημα με τις ελληνικές γραμματοσειρές
Εγκαταστήσατε μια ελεύθερη διανομή Linux με επιλογή εμφάνισης του ελληνικού περιβάλλοντος εργασίας και το αποτέλεσμα μοιάζει με
- Αίσχος, ε; Πρέπει να βάλουμε τα mscorefonts για να δούμε σωστά ελληνικά στο Linux;
- Όχι, υπάρχουν σωστές ελεύθερες ελληνικές γραμματοσειρές, το λάθος είναι αλλού!
Για το γραφικό περιβάλλον GNOME, που χρησιμοποιεί το υποσύστημα fontconfig, υπάρχει μια λίστα προτεραιότητας για την εύρεση και χρήση των ελληνικών χαρακτήρων. Κάθε διανομή έρχεται με τις δικές της γραμματοσειρές ενώ ο χρήστης μπορεί να προσθέσει περισσότερες. Πως γίνεται η επιλογή;
<blockquote>
<family>sans-serif</family>
<prefer>
<family>Bitstream Vera Sans</family>
<family>Verdana</family>
<family>Arial</family>
<family>Albany AMT</family>
<family>Luxi Sans</family>
<family>Nimbus Sans L</family>
<family>Helvetica</family>
<family>Nachlieli</family>
<family>Kochi Gothic</family>
<family>AR PL KaitiM GB</family>
<family>AR PL KaitiM Big5</family>
<family>MS ゴシック</family>
<family>Baekmuk Dotum</family>
<family>SimSun</family>
<family>FreeSans</family>
</prefer>
... με τη λίστα προτεραιότητας γραμματοσειρών. Αν έχετε μια πρόσφατη διανομή, το αρχείο /etc/fonts/fonts.conf έχει μια παράγραφο όπως την παραπάνω. Για την απεικόνιση ελληνικών, το υποσύστημα fontconfig κοιτάει αν η πρώτη γραμματοσειρά, Bitstream Vera Sans περιλαμβάνει ελληνικούς χαρακτήρες. Αν ναι, τους χρησιμοποιεί. Αν όχι, κοιτάει την επόμενη υποψήφια γραμματοσειρά.
Όπως είναι τώρα η λίστα, αν κάποιος έχει εγκαταστήσει τα mscorefonts, αυτά θα δουλέψουν δίχως πρόβλημα διότι τα ελληνικά λαμβάνονται από την Verdana (ή αν δεν υπάρχει, από την Arial).
Μια τυπική ελεύθερη διανομή Linux δεν περιλαμβάνει τις περισσότερες από αυτές τις γραμματοσειρές, περιλαμβάνει όμως την FreeSans (πακέτο FreeFonts) που είναι ικανοποιητική γραμματοσειρά. Όμως, γιατί συχνά δεν επιλέγεται και τα ελληνικά μοιάζουν με τερατούργημα;
Διότι οι γραμματοσειρές Kochi Gothic, AR PL KaitiM GB, AR PL KaitiM Big5, MS ゴシック και Baekmuk Dotum περιλαμβάνουν ελληνικά. Η δε νέες διανομές Linux εγκαθιστούν τις γραμματοσειρές αυτές για να μπορούν οι χρήστες να εμφανίζουν κάθε σελίδα του Web δίχως πρόβλημα. Για παράδειγμα, δεν είναι δυνατόν να τις απεγκαταστήσει κάποιος από το Ubuntu Linux Breezy διότι υπάρχει εξάρτηση με το πακέτο ubuntu-desktop.
Γιατί έχουν οι ασιατικές αυτές γραμματοσειρές ελληνικά; Διότι λόγω των προτύπων στην Ιαπωνία (και ίσως σε Κίνα και Κορέα) JIS X 0208:1983, JIS X 0212 και
JIS X 0213, μια επίσημη γραμματοσειρά πρέπει να έχει και ελληνικά, για τη σωστή απεικόνιση μαθηματικών, κτλ. Οι ασιατικές αυτές γραμματοσειρές είναι πλήρους πλάτους (full width), με αποτέλεσμα να φαίνονται πολύ άσχημα σε κείμενα με λατινικούς χαρακτήρες/τυπικά ελληνικά.
Οπότε η λύση είναι να αλλάξει η σειρά προτεραιότητας στο fonts.conf.
Έγινε μια τέτοια αναφορά σφάλματος, Freedesktop Bug #4639 που ανεβάζει την προτεραιότητα των FreeFonts και προσθέτει και τις MgOpen.
Υπάρχει το ζήτημα, ποια γραμματοσειρά να επιλέξουμε από MgOpen (Modata, Moderna και Cosmetica) και FreeSans. Πρέπει να είναι τύπου sans-serif, που χρησιμοποιεί το περιβάλλον εργασίας του Linux.
Σε SuSE 9.3 Professional το πιο εμφανισιακό αποτέλεσμα το είχα με την MgOpen Modata, δείτε http://simos.info/blog/?p=419 και επέλεξα αυτήν.
Έχετε κάποια αντιπρόταση; Η τυπική αντιπρόταση θα μπορούσε να είναι η FreeSans.
Θα ήθελα να ευχαριστήσω τον Γιώργο Λογιωτατίδη που αναφέρθηκε στο θέμα (Αναφορά Σφάλματoς Ubuntu 15108.
Ενημέρωση: Η διανομή Ubuntu Linux Dapper (6.06) διαθέτει τη γραμματοσειρά DejaVu που περιλαμβάνει ελληνικά και είναι αρκετά καλή για τις ανάγκες μας.



