Hi Simos, How you doing?
Hello to everybody else, Ed Trager, you still there? I'm sure I'm forgetting some of you. Sorry. It's me, Elvis, the guy who had problems with xkb last year. You were all a great help. I could never have fixed the problems myself. My system still works, better than ever.. Sorry, I have to add to this thread after all. The message I sent yesterday did not end up in my inbox, so I can't even respond to myself. Here's what I said: ------------- attached below ------------- This would be my reply: Funny thing happened to me today. When I opened Mozilla I saw it was using the SuSE Free Serif again! I don't know how that happened. It was using the Microsoft TNR. When I go into Edit/Preferences I get a bewildering array of font selections, and no positive feedback, so I couldn't get the TNR back. Not to worry: it's still there, I can select it in Open Office. But I decided to try out the character map program again, this time with the SuSE font, and yes, it too supports polytonic Greek. In fact, the curior monospace also does polygreek. Unusual, the ones that don't. That reminds me why I couldn't use the SuSE free serif: it's too fat. I mean it takes up too much space, so I couldn't fit my dictionary pages on the PDF I created in Open Office. Did you know why Adobe calls it "Portable Document Format"? It's because the PDF actually contains a subset of the font used to create the document. The mini-font travels around the world with the document, so your recipient sees exactly what you send, even if he doesn't have the special font. Speaking of exotic fonts, I like your Greek fonts, they look great. But I don't understand why you call them "Greek" fonts, or why some people call them "Unicode" fonts, for that matter. Any font is a Greek font if it renders the Greek characters, and any font should be usable with any characer set, as long as that internal glyph index maps the character set to the glyphs. So, do you think you can combine the mono and polytonic Greek alphabets into a single character keymap? Joe PS Here's what I said: ---------------- Hello. I've been experimenting with polygreek too, but I hesitate to add to your already established thread... I took the Times New Roman ttf of a Windows XP system and installed it on my SuSE 9.2 at home. To my surprise, I see this font supports polygreek, so I tried setting a couple entries from a popular dictionary of modern Greek: http://modern-greek-verbs.tripod.com/home.html#unicode With this font, I can capture the entire entry, no problems, pointing fingers, arrows, boxes, tiny-elvises, polygreek etymology... There is virtually nothing I cannot do with the Unicode character set alone. I'm using the character map program to capture the data. I know the Times font is working, because if I select another font, like the SuSE free fonts, or even the Microsoft Arial, which I also ripped off, the polygreek characters are not rendered. I was wondering, since the font worked so unexpectedly well, maybe the monogreek keymap would too. But how would I know? I gather from your correspondence that no polygreek keymap is currently available, but I'm hoping the monogreek map might already do something reasonable with poly greek. True, the monogreek tonos is not the same as the polygreek accents, but it should be possible to combine the two alphabets in a single keymap, just like their part of the same font. This would spare me tha agony of changing keymaps using the what-ever-you-call-it, the xkb "accelerator" key. (Going from Greek to English is already a pain in the ass.) Would it be possible to extend the monogreek keymap to do polygreek? You'd have one less module to distribute, and one less thing to install. Getting back to the font: The Linux Mozilla displays this document properly on my system at home, but when I go to a MS system at the University, and use Internet Explorer, the polygreek and some, but not all, of the special characters are rendered by little boxes. The Firefox on the XP system is a little better, all the glyphs display, but not very nicely, at least not as nice as the Linux Mozilla, which is perfect. There seems to be some kind of glyph substitution going on. I assume the font contains a table which maps the integer-valued unicode character (which comes from the utf-8 byte stream) to a glyph index inside the font. This table must be created somehow when the font is designed, so I can't get at it, but I was wondering why the same font, Microsoft Times New Roman, would behave differently in different application programs, even if they are running on different platforms. Any guesses? Thanks. Joe PS I was very happy with the Font installation program which is part of the KDE desktop. You just open the font directory with Konqueror and click the "Install" button. Congratulations to whoever did it. (Only I could not figure out how to install the fonts on Gnome. It's probably just a matter of copying the font files to the right directory, but which one?) I assume X windows has its own font api, so Microsoft ttfs should not work right out of the box on an X system. Maybe that's the job of the "font server", to convert one interface to another. I have no idea where it is running, as a separate process, as a module linked to the X server, nor do I care... But, my compliments to that guy too, who ever he was. ------------- On 1/30/06, Simos Xenitellis <[EMAIL PROTECTED]> wrote: > O/H Jan Willem Stumpel έγραψε: > > Simos Xenitellis wrote: > > > > > >> You can have a look at this document, > >> http://planet.hellug.gr/misc/polytonic/ Although it is in Greek, it > >> should be feasible to discern the combinations proposed. For example, > >> "Νεκρό πλήκτρο" is "Dead key" in the list. If there are queries, feel > >> free to refer to me. > >> > > > > Very interesting. Is this a proposal, or has it been implemented? > > According to Babelfish, you say "Your distribution of Linux that > > has been published after October 2005 should include the renewed system > > that we describe here." Mine does not, but I don't trust the Babelfish > > translation.. > > > The referenced document is indeed a proposal. > You are correct about October 2005. Several distributions were released > in October (Ubuntu, OpenSUSE) so the plan was to have the changes > upstream by the end of the summer so that they move to the new > distributions as they appear. > However, this plan did not work out and we still did not submit these > changes. > Konstantinos Pistiolis is working on this subject. > > As far as I can see, it would not be difficult to implement it. Nothing > > would have to be changed in the binaries, only in the xkb and Compose > > files. > > > > I noticed you only want to use 'two level' keys (normal and shift), not > > using AltGr. Is this some kind of standard? (e.g. Greek national > > standard, or some other kind of standard)? The present pc/gr file in xkb > > uses 'three level' keys. > > > As far as I know there is no national standard for Greek polytonic. > Windows XP support Greek polytonic, > however, there is an inherent disadvantage that you cannot stuck more > than one dead key; due to this > quite a lot of keys have to be used as dead keys. In addition, if a > character accepts more than one diacritic, > then you need three dead keys to cover all the cases (diacritic A, > diacritic B, diacritic A+B). > > Regarding the usage of AltGr. There have been quite a few discussions on > whether to use or not. I do not have the full details at my disposal. > Kostas, would you like to chip in for this? > > BTW I suppose when you say that tonos/oxia is on the ; key, you mean the > > key which is ; on US keyboards, not the key which is ; on Greek keyboards? > > > Indeed, ; it is the physical key according to the US keyboard. > The proposal document does not include a specific dead key to produce > oxia. In the Windows XP layout there is such a dead key, > in an uncomfortable location however, for those end-users who would like > to use it. > > > >> The "Compose" file should be broken in smaller files per script > >> rather than having a big monolithic file. > >> > > > > What advantage would this bring? If we have many small pieces of the > > Compose file, how is the user (or the system) supposed to decide when to > > use which piece? Wouldn't this create another configuration problem? > > > The configuration mechanism of Xorg would shield the end-user from this > complexity. I am referring to the needs of the developers. > For example, suppose a lesser known language wants to make an > installable package that adds writing support. The way this could be > done is by dropping (adding) the appropriate files in the appropriate > directory. Otherwise, there would be need to patch the monolithic file. > In addition, the Polytonic section in the Compose file is suitable to be > auto-generated from a script as the multiple diacritics on vowels bring up > combinations. > > UTF-8 allows using one system for all languages and scripts, without > > changing locales. There is only one, IMHO unavoidable, but small, > > disadvantage: some files (like fonts, and the Compose file) tend to > > become rather big. But memory and disk space are not as expensive as > > they used to be. And the user does not notice anything of this. She just > > thinks: wow! I can input any language anywhere, at any time! > > > As I mention above, the splitting of the files would be an advantage for > the developers. > The end-user would only see a GUI configuration tool. No setxkbmap or > editing of xorg.conf. > >> There is increasing interest in updating this area of Xorg > >> (http://community.livejournal.com/xkbconfig/) and I hope it gets done > >> soon. > >> > > > > Hmm.. "xkb" and "Compose" are two completely different mechanisms. One > > is input to the other. People often complain about xkb being > > 'mysterious' or 'arcane'. Since xfree86 4.3 and x.org came around, it > > isn't anymore. It just lacks user-level documentation. Recently, thanks > > to this list, I have come close enough to enlightenment to attempt a > > user-level description on my utf-8 page, sections 6.1 and 6.2 > > (http://www.jw-stumpel.nl/stestu). > > > Thanks for this. > We need to put effort so that gswitchit (Keyboard Indicator applet in > GNOME) gets more and more advanced and ubiquitous. > The plan is for gswitchit to be used for KDE as well. > This is the proper direction so end-users are happy that their settings > just work. > > Simos > > > -- > Linux-UTF8: i18n of Linux on all levels > Archive: http://mail.nl.linux.org/linux-utf8/ > >
