Αεροφωτογραφίες της Ελλάδας από το Υπουργείο Περιβάλλοντος, Ενέργειας και Κλιματικής Αλλαγής
Πριν λίγες μέρες ανακοινώθηκε με δελτίο τύπου από το Υπουργείο Περιβάλλοντος, Ενέργειας και Κλιματικής Αλλαγής η διάθεση αεροφωτογραφιών εξαιρετικά μεγάλης ανάλυσης.
Αυτή είναι η ανάλυση που προσφέρει αυτή τη στιγμή το Google maps για την Ομόνοια, Αθήνα.
Ενώ αυτή είναι η ανάλυση που προσφέρει το Υπουργείο μέσω υπηρεσίας από το Κτηματολόγιο Α.Ε.
Η ανάλυση για αστικές περιοχές είναι 20cm, που σημαίνει ότι ένα εικονοστοιχείο στην παραπάνω εικόνα αντιστοιχεί σε 20cm. Για τις υπόλοιπες περιοχές η ανάλυση είναι 50cm.
Μπορεί να διαπιστώσει κάποιος ότι οι δύο αεροφωτογραφίες είναι διαφορετικές· το Google προφανώς έχει συνάψει ειδική συμφωνία με τη Geomatics Ltd.
Το δελτίο τύπου δεν αναφέρει ποια είναι η άδεια διάθεσης των αεροφωτογραφιών. Αναφέρει «Δωρεάν πρόσβαση σε αεροφωτογραφίες όλης της χώρας» που δεν είναι αρκετό. Θα ήταν καλύτερο να υπήρχε αναφορά σε μια άδεια όπως Creative Commons. Με μια συγκεκριμένη άδεια θα είναι δυνατή η χρήση από έργα όπως το OpenStreetMap.
Γιατί προσφέρει το Υπουργείο Περιβάλλοντος, Ενέργειας και Κλιματικής Αλλαγής τις αεροφωτογραφίες δωρεάν; Διότι, όπως αναφέρει στο δελτίο τύπου, «η υποδομή που δημιουργεί το έργο αυτό ήδη αξιοποιείται από τον ευρύτερο δημόσιο τομέα για τη βελτίωση της αποτελεσματικότητάς του. Μπορεί επίσης να αξιοποιηθεί και από τον ιδιωτικό τομέα για την υποστήριξη υπηρεσιών και την παραγωγή νέων προϊόντων». Αυτές οι μεγάλης ανάλυσης αεροφωτογραφίες μπορούν να επιτρέψουν να ενισχυθεί η επιχειρηματικότητα στην Ελλάδα με την παροχή νέων υπηρεσιών. Όπως με το ελεύθερο λογισμικό έχουν το βασικό λογισμικό (λειτουργικό σύστημα, λογισμικό γραφείου, κτλ) σε μηδαμινό κόστος, έτσι και εδώ μπορούν να ξεκινήσουν αρκετές εμπορικές δραστηριότητες.
Διαθέτουν δωρεάν αεροφωτογραφίες άλλες χώρες; Η απάντηση είναι ότι γενικά δεν προσφέρουν, κοστίζει πολύ να αποκτήσει κάποιος εξαιρετικές αεροφωτογραφίες και τυπικά ο αγοραστής δεν έχει τα πλήρη δικαιώματα. Δηλαδή, ο αγοραστής νοικιάζει αντί να αγοράσει αεροφωτογραφίες.
Τι βλέπουν οι άλλες χώρες σχετικά με τη διάθεση γεωγραφικών δεδομένων και την επιχειρηματικότητα; Στο ΗΒ υπήρξε δημόσια διαβούλευση για το αν η υπηρεσία χαρτογράφησης (Ordnance Survey) θα συνέχιζε το καθεστώς όπου βγάζει χρήματα από άδειες (όπου περιοριζόταν η χρησιμότητα των δεδομένων), ή αν θα έκανε κάτι άλλο πρωτοποριακό. Το αποτέλεσμα ήταν να διαθέσει με ελεύθερη άδεια αρκετά από τα επεξεργασμένα γεωγραφικά δεδομένα, κάτι που είναι πρωτοποριακό.
Αυτό που χρειάζεται να κάνει το Υπουργείο είναι να καθορίσει την άδεια διάθεσης των αεροφωτογραφιών. Η γενική άδεια είναι της μορφής Creative Commons όπου επιτρέπεται η ελεύθερη εμπορική χρήση. Με το τρόπο αυτό μπορεί κάποιος με λογισμικό ΕΛ/ΛΑΚ να φτιάξει υπηρεσίες με ελάχιστο αρχικό κόστος και να βοηθήσει σε καινοτομία και επιχειρηματικότητα. Το Υπουργείο μπορεί να ακολουθήσει το παράδειγμα του Η.Β.
Ενημέρωση 23 Ιουνίου 2010
Το κείμενο της άδειας διάθεσης των απελευερωμένων γεωχωρικών πληροφοριών στο ΗΒ:
Access to and use of the Data expressly made available under this licence (the “Data”) indicates your acceptance of these terms and conditions.
This is a worldwide, royalty-free, perpetual, non-exclusive licence from the provider of the Data (the “Data Provider”) to use it subject to the conditions below.
This licence does not affect your fair dealing or fair use rights, or any other copyright or database right exceptions and limitations.
You are free to:
- copy, distribute and transmit the Data;
- adapt the Data;
- exploit the Data commercially whether by sub-licensing it, combining it with other data, or by including it in your own product or application.
You must:
- acknowledge the copyright and the source of the Data by including any attribution statement specified by the Data Provider. If no specific statement is provided please use the following: Contains [insert name of Data Provider] data © Crown copyright and database right
- include the same acknowledgment requirement in any sub-licences of the Data that you grant, and a requirement that any further sub-licences do the same;
- ensure that you do not use the Data in a way that suggests the Data Provider endorses you or your use of the Data;
- ensure that you do not misrepresent the Data or its source.
No warranty
The Data is licensed ‘as is’ and the Data Provider excludes all representations, warranties, obligations and liabilities in relation to the Data to the maximum extent permitted by law. The Data Provider is not liable for any errors or omissions in the Data and shall not be liable for any loss, injury or damage of any kind caused by its use. The Data Provider does not guarantee the continued supply of the Data.
Governing law
This licence is governed by the laws of the country in which the Data Provider has its principal place of business, unless otherwise specified by the Data Provider.
Changes to this licence
The Data Provider may amend the terms of this licence or make the Data available under a different licence. However, these terms will continue to apply to data you already license from the Data Provider.
Creative Commons
These terms have been aligned to be interoperable with any Creative Commons Attribution 3.0 Licence. This means that you may mix the information with Creative Commons licensed content to create a derivative work that can be distributed under any Creative Commons Attribution 3.0 Licence.
Google Street View enters Europe
Google Street View has entered Europe. The Wikipedia article has up to date information on the countries covered already (France, Italy, Spain). In addition, there is information of the countries that will get covered in the future.
The colored areas are the areas that Google Street View data is available. These areas appear when you drag the yellow doll from the zoom area at the left, and you hover it over the map.
Apparently, the privacy concerns did not stop Street View from entering Europe. The faces of the people and the car number plates are blurred in most cases. If you search a bit, it is possible to find cases that a traffic plate or face have not been blurred (example, example).
Converting between XKB and XML
I completed the stage that takes keyboard layout files from XKB (X.Org) and converts them to XML documents, based on a keyboard layout Relax NG schema. Then, these XML documents can also be converted back to keyboard layout files.
Here is an imaginary example of a keyboard layout file.
// Keyboard layout for the Zzurope country (code: zz).
// Yeah.
partial alphanumeric_keys alternate_group hidden
xkb_symbols "bare" {
key <AE01> { [ 1, exclam, onesuperior, exclamdown ] };
};
partial alphanumeric_keys alternate_group
xkb_symbols "basic" {
name[Group1] = "ZZurope";
include "zz(bare)"
key <AD04> { [ r, R, ediaeresis, Ediaeresis ] };
key <AC07> { [ j, J, idiaeresis, Idiaeresis ] };
key <AB02> { [ x, X, oe, OE ] };
key <AB04> { [ v, V, registered, registered ] };
};
partial alphanumeric_keys alternate_group
xkb_symbols "extended" {
include "zz(basic)"
name[Group1] = "ZZurope Extended";
key.type = "THREE_LEVEL"; // We use three levels.
override key <AD01> { type[Group1] = "SEPARATE_CAPS_AND_SHIFT_ALPHABETIC",
[ U1C9, U1C8], [ any, U1C7 ] }; // q
override key <AD02> { [ U1CC, U1CB, any,U1CA ],
type[Group1] = "SEPARATE_CAPS_AND_SHIFT_ALPHABETIC" }; // w
key <BKSP> {
type[Group1]="CTRL+ALT",
symbols[Group1]= [ BackSpace, Terminate_Server ]
};
key <BKSR> { virtualMods = AltGr, [ 1, 2 ] };
modifier_map Control { Control_L };
modifier_map Mod5 { <LVL3>, <MDSW> };
key <BKST> { [1, 2,3, 4] };
};
When converted to an XML document, it looks like
<?xml version="1.0" encoding="UTF-8"?>
<layout layoutname="zz">
<symbols>
<mapoption>hidden</mapoption>
<mapoption>xkb_symbols</mapoption>
<mapname>bare</mapname>
<mapmaterial>
<tokenkey override="False">
<keycodename>AE01</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>1</symbol>
<symbol>exclam</symbol>
<symbol>onesuperior</symbol>
<symbol>exclamdown</symbol>
</symbolsgroup>
</keysymgroup>
</tokenkey>
</mapmaterial>
</symbols>
<symbols>
<mapoption>xkb_symbols</mapoption>
<mapname>basic</mapname>
<mapmaterial>
<tokenname name="ZZurope"/>
<tokeninclude>zz(bare)</tokeninclude>
<tokenkey override="False">
<keycodename>AD04</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>r</symbol>
<symbol>R</symbol>
<symbol>ediaeresis</symbol>
<symbol>Ediaeresis</symbol>
</symbolsgroup>
</keysymgroup>
</tokenkey>
<tokenkey override="False">
<keycodename>AC07</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>j</symbol>
<symbol>J</symbol>
<symbol>idiaeresis</symbol>
<symbol>Idiaeresis</symbol>
</symbolsgroup>
</keysymgroup>
</tokenkey>
<tokenkey override="False">
<keycodename>AB02</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>x</symbol>
<symbol>X</symbol>
<symbol>oe</symbol>
<symbol>OE</symbol>
</symbolsgroup>
</keysymgroup>
</tokenkey>
<tokenkey override="False">
<keycodename>AB04</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>v</symbol>
<symbol>V</symbol>
<symbol>registered</symbol>
<symbol>registered</symbol>
</symbolsgroup>
</keysymgroup>
</tokenkey>
</mapmaterial>
</symbols>
<symbols>
<mapoption>xkb_symbols</mapoption>
<mapname>extended</mapname>
<mapmaterial>
<tokenname name="ZZurope Extended"/>
<tokeninclude>zz(basic)</tokeninclude>
<tokentype>THREE_LEVEL</tokentype>
<tokenmodifiermap state="Control">
<keycode value="Control_L"/>
</tokenmodifiermap>
<tokenmodifiermap state="Mod5">
<keycodex value="LVL3"/>
<keycodex value="MDSW"/>
</tokenmodifiermap>
<tokenkey override="True">
<keycodename>AD01</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>U1C9</symbol>
<symbol>U1C8</symbol>
</symbolsgroup>
<symbolsgroup>
<symbol>any</symbol>
<symbol>U1C7</symbol>
</symbolsgroup>
<typegroup value="SEPARATE_CAPS_AND_SHIFT_ALPHABETIC"/>
</keysymgroup>
</tokenkey>
<tokenkey override="True">
<keycodename>AD02</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>U1CC</symbol>
<symbol>U1CB</symbol>
<symbol>any</symbol>
<symbol>U1CA</symbol>
</symbolsgroup>
<typegroup value="SEPARATE_CAPS_AND_SHIFT_ALPHABETIC"/>
</keysymgroup>
</tokenkey>
<tokenkey override="False">
<keycodename>BKSP</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>BackSpace</symbol>
<symbol>Terminate_Server</symbol>
</symbolsgroup>
<typegroup value="CTRL+ALT"/>
</keysymgroup>
</tokenkey>
<tokenkey override="False">
<keycodename>BKSR</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>1</symbol>
<symbol>2</symbol>
</symbolsgroup>
<tokenvirtualmodifiers value="AltGr"/>
</keysymgroup>
</tokenkey>
<tokenkey override="False">
<keycodename>BKST</keycodename>
<keysymgroup>
<symbolsgroup>
<symbol>1</symbol>
<symbol>2</symbol>
<symbol>3</symbol>
<symbol>4</symbol>
</symbolsgroup>
</keysymgroup>
</tokenkey>
</mapmaterial>
</symbols>
</layout>
When we convert the XML document back to the XKB format, it looks like
hidden xkb_symbols "bare"
{
key <AE01> { [ 1, exclam, onesuperior, exclamdown ] };
};
xkb_symbols "basic"
{
name = "ZZurope";
include "zz(bare)"
key <AD04> { [ r, R, ediaeresis, Ediaeresis ] };
key <AC07> { [ j, J, idiaeresis, Idiaeresis ] };
key <AB02> { [ x, X, oe, OE ] };
key <AB04> { [ v, V, registered, registered ] };
};
xkb_symbols "extended"
{
name = "ZZurope Extended";
include "zz(basic)"
key.type = "THREE_LEVEL";
modifier_map Control { Control_L };
modifier_map Mod5 { <LVL3>, <MDSW> };
override key <AD01> { [ U1C9, U1C8 ], [ any, U1C7 ], type = "SEPARATE_CAPS_AND_SHIFT_ALPHABETIC" };
override key <AD02> { [ U1CC, U1CB, any, U1CA ], type = "SEPARATE_CAPS_AND_SHIFT_ALPHABETIC" };
key <BKSP> { [ BackSpace, Terminate_Server ], type = "CTRL+ALT" };
key <BKSR> { [ 1, 2 ], virtualMods = AltGr };
key <BKST> { [ 1, 2, 3, 4 ] };
};
Some things are missing such as partial, alphanumeric_keys and alternate_group, which I discussed with Sergey and he said they should be ok to go away.
In addition, we simplify by keeping just Group1 (we do not specify it, as it is implied).
I performed the round-trip with all layout files, and all parsed and validated OK (there is some extra work with the level3 file remaining, though).
Some issues that are remaining, include
- Figuring out how to use XLink to link to documents in the same folder (+providing a parameter; the name of the variant), and how to represent that in the Relax NG schema.
- Sort the layout entries by keycode value.
Today you’ll make history with Firefox
Today you'll make history with Firefox
Are you ready to make history? Are you ready to set a World Record? Today is Download Day. To become part of the official Guinness World Record you must download Firefox 3 by 17:00 18:15 UTC on June 18, 2008, or roughly 24 hours from now.
Download page with live download statistics
The sender of this email is Mozilla Corporation, 1981 Landings Drive, Bldg. K, Mountain View, CA 94043-0801.
Did you receive your notification for your pledge?
The Firefox Download Day has just started. We are already counting 1 and a half hours in the download day. See download countdown which shown until when your downloads count for the record attempt.
Mozilla.com is currently very slow due to the repeated attempts to download. I hope the issue is resolved soon.
Update +2 hours: Now it works; when you visit the download page, it now shows correctly that Firefox 3.0 is available for download.
Update +16 hours: The download count reached 5,400,000 downloads. It is good to drive it higher. You can get your national download total, and ask your friends and family to help increase it.
Update +20 hours: The download count is over 6,000,000 downloads. Due to the technical issues at the start of the record attempt, the deadline for downloads has been extended by one hour and 15 minutes.
Update +24 hours: The download count is nearing 8,000,000 downloads. We have a bit more than an hour to go (due to the technical issue that delayed the start of the downloads). Can we make it to 8 million?
Update +25 hours: We did it! 8 million downloads in 24 hours! World record!
Update +30 hours: The world record attempt has been completed. Still, the Firefox 3 downloads continue. At the moment we surpassed 9.4 million downloads and counting.
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.
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.
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.
Σπάσαν τα καλώδια
Την περασμένη εβδομάδα έγινε ένας ισχυρός σεισμός κοντά στην Ταϊβάν. Το επίκεντρο ήταν στη θάλασσα, κοντά στις νότιες ακτές του νησιού. Υπήρξε ένας αριθμός θυμάτων που ήταν σχετικά μικρός λόγω των αυστηρών πολεοδομικών κανονισμών της χώρας για ανθεκτικά κτίρια.
Ένα από τα θύματα ήταν τα καλώδια οπτικών ινών του συστήματος APCN 2 που συνδέουν την ΝΑ Ασία με τις ΗΠΑ και τον υπόλοιπο κόσμο. Έτσι, μέχρι την επισκευή των καλωδίων (~4 εβδομάδες) η σύνδεση με το Διαδίκτυο για τις χώρες της ΝΑ Ασίας είναι από αδύνατη μέχρι πολύ αργή.
Την επόμενη μέρα της καταστροφής το Google ήταν η μόνη υπηρεσία που κατάφερε να λειτουργήσει. Η εντολή traceroute έδειξε ότι τα πακέτα τερμάτιζαν στο Χονγκ Κονγκ οπότε το Google είχε προσπεράσει το πρόβλημα με τη Ταϊβάν με χρήση κάποιας άλλης γραμμής. Άλλες υπηρεσίες όπως Yahoo δεν ήταν προσπελάσιμες. Μπορούσες να συνδεθείς μόνο με δικτυακούς τόπους μέσα από στην NΑ Ασία.
Κοιτώντας το χάρτη με τη διασύνδεση των καλώδιων οπτικών ινών στην Ασία (PDF), διαπιστώνει κανείς ότι π.χ. είναι δυνατή η σύνδεση στην Αυστραλία από την ΝΑ Ασία. Πως μπορεί ένας χρήστης να συνδεθεί από ΝΑ Ασία με ΗΠΑ μέσω Αυστραλίας; Ένας εύκολος τρόπος είναι με τη ρύθμιση διαμεσολαβητή (proxy) που βρίσκεται στην Αυστραλία στο Firefox. Υπάρχει μεγάλη λίστα από anonymous proxy στο διαδίκτυο που μπορεί κάποιος να βρει εύκολα μέσω Google.
Στις τοπικές εφημερίδες διαβάζει κανείς άρθρα για τοπικούς ιστολόγους που η διαδικτυακή τους ζωή έχει ταραχθεί λόγω της αδυναμίας ιστολόγησης. Ελπίζω να διορθωθούν τα πράγματα σύντομα.
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.
Επίπεδο στάθμης της θάλασσας στην Ελλάδα
Sea level rise data at Piraeus, Greece
Ο συνδυασμός των Google Maps και υψομετρικών δεδομένων από τη NASA βοηθούν στη δημιουργία του http://flood.firetree.net/, που μπορεί να δείξει κατά πόσο θα καλυφθούν οι παράκτιες περιοχές από τη θάλασσα όταν το επίπεδο της θάλασσας αυξηθεί. Η προσομοίωση μπορεί να δείξει μέχρι 14 μέτρα αύξηση στο επίπεδο της θάλασσας.
Η φωτογραφία δείχει τον Πειραιά με το επίπεδο της θάλασσας να έχει αυξηθεί στα 7 μέτρα (σε σχέση με τώρα).
Βλέποντας την υπόλοιπη Ελλάδα, φαίνεται ότι ακόμα και μια αύξηση στο επίπεδο της θάλασσας κάτα 3m θα έχει σοβαρές επιπτώσεις στη Θεσσαλονίκη. Είναι τα υψομετρικά δεδομένα σωστά; Είναι η περιοχή γύρω από τη Θεσσαλονίκη τόσο χαμηλά, κοντά στη στάθμη της θάλασσας;
Ενημέρωση: Αν λιώσουν οι πάγοι στη Γροιλανδία, το επίπεδο της θάλασσας θα ανέβει κατά 6,5 μέτρα. Αν λιώσουν όλοι οι πάγοι στη Γη, το επίπεδο της θάλασσας θα ανέβει κατά 80 μέτρα περίπου.





