Hi Jonathan,
First of all, I appologize if my style seemed rude. By saying "stone age", I didn't mean to convey that your needs aren't important. I'm all for keeping this discussion on purely technical grounds.
There's no IME on my Linux distribution. I dont' use Gnome and I don't useIME language information is a feature of the XKB extension, not of GNOME or KDE. You can configure XKB with standard X11R6 tools such as 'xsetxkb' (high-level configuration loader) and 'xkbcomp' (low-level compiler). You retrieve information from the XKB extension by linking with Xlib (not GNOME or KDE libs!).
KDE and I don't see why OOo should be dependent on either Gnome or KDE.
OOo should be self-sufficient.
You can also load the Xkb mapping through graphical tools provided by your desktop environment. Those graphical tools might simply spawn the "setxkb" utility; so can you.
In short, Xkb is an X11 extension, described in the X11R6, both the protocol and the API. There's nothing fancy-shmancy GNOME/KDE about it. It's entirely at the X11 level.
Of course we should have a way to override the directionality of a text snippet, via some keyboard shortcut (if the HIG people find it important enough to have its own shortcut :-) or through some Format dialog.If a user's Israeli keyboard's Hebrew group calls itself "Afrikaans", we
wouldn't detect it,
but that classifies as a broken configuration anyway. Besides, we *can*
detect it if we inspect the
mapping itself (ie. look for Hebrew characters among the characters
which the mapping generates).
This is not a good heuristic. It means that when I write mathematical
papers in English, OOo might think that they are Hebrew because I use
ALEPH to indicate a countable infinity.
Along with that, we have a goal of making Writer do the right thing on the common desktop for the common secretary (or software developer, in my case -- I also write specs :) by default.
The language markup I refer to, is the language markup you define through Writer's "Format --> Character" (the "Language" combo-box for "Western text font"). For instance, when you write "Halo welt", you can mark it as German and the speller would no longer complain. There's no other way Writer could detect German: "Halo" is valid in both English and German.Don't we already save language markup for the speller's sake? This
information could be
No.
I think this detail gives me a pretty fat clue that OpenOffice *does* remember the language of the characters you type in.
There's no IME and the speller has it's own heuristic for guessing Hebrew"Heuristics"? I bet it simply calls any word which's all made of Hebrew letters as "Hebrew". What if it's an Yiddish word, which's made of the same Hebrew letters, belonging to the same Unicode block?
words.
In any case, as I've proved, we *do* have language information.
Language information can be useful for both:
- knowing which Speller Dictionary to load,
- knowing which base direction a set of characters is (by wrapping a consequitive set of characters written in an RLM language in <RLE> - <PDF>; or in an LRM languages - in <LRE> - <PDF>).
Knowing the IME language helps us mark the text with the correct language *by default*. But this language markup can be changed through athe Format | Character dialog.
Also, for cases when you use Hebrew characters in a formula, we should have a manual direction override. Something for the scientists, not the secretaries :-)
That's right: the user is the master. We don't want to look like one of those apps that considers the user stupid and takes control out of his hands.You propose we replace a solution that does what the user intends in
most cases without a single
extra key press, with a system that requires the user to be actively
involved?
From Human Interface Guidelines perspective, that sounds like a step in
the wrong direction?
No, it's a step in the right direction because it does not try to guess what the user intended.
However, a good slave will try and guess what his master will want.
It lets the user indicate it explicitly. RememberLet's take a common case in my technical correspondence at work (which is done in Microsoft Outlook, using Microsoft Word as the email editor):
that we are talking about short sequences like English book titles
(LTR) inside of Hebrew paragraphs (RTL), Hebrew Bible verses (RTL) inside
of English (LTR) paragraphs.
OUR OFFICE SUITE IS WRITTEN IN c++ AND IS MULTIPLATFORM.
Now, imagine writing C++ repeatedly in a technical dispute. Ignore the fact that the capital letter 'C' can be produced on an Israeli keyboard even in the Hebrew group (by holding Shift); it might've been "c++" as well, and that'd force you to switch to the English group.
So I switch to the English group, to write "c++". I've already done ONE consent operation, and being a lazy user, I don't want to do any more of them!
If my application would mind the IME language, it would do what I expect(!) and place the "++" on the right side of the 'C'.
I don't live in the stone age, I just don't use desktop systems like Gnome
or KDE, and I don't want OOo to be dependent on those systems.
Hell no. No GNOME or KDE depdencies of any kind. We're CDE/TWM-ready.
And Hebrew University too :-)Remember that there are a several hundres folks out there at the Technion who need Hebrew OpenOffice on their "stone age" X stations
Hopefully those stations have the XKB extension. That's all they'd need.
Heck, even without the XKB extension, we could inspect their xmodmap mapping to detect their keymap.
There are also a lot of non-Jewish Bible scholars who contact me toWe're not tying anything to the OS. In my scheme, Writer simply does the expected thing by default on properly configured stations (which are using a stock installation of a modern-enough X11 system -- not some special Hebrew-modified X11).
help them get OOo working in Hebrew on their non-Hebrew OS's. So we should
be doing everything to avoid tying OOo language support to the OS.
============================================================== To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe hebrew" in the message body.
