KO> The whole difference is that just as any Arab understands that various
KO> combinations of glyphs are still separate characters,
KO> it's kinda hard to persuade me at least that é is more than one character. The
KO> whole point about combining characters (at least accents for roman alphabets,
On piątek 20 grudzień 2002 09:15 am, Philipp Reichmuth wrote:
> | LGB>> One glyph that thakes 64 bits to encode...
>
> LGB> | But not for any *technical* purpose. For all purposes of string
> LGB> | processing, such as indexing, concatenation etc., this is *two*
> LGB> | characters, not one.
>
> LG
On piątek 20 grudzień 2002 10:01 am, Philipp Reichmuth wrote:
> LGB> | Sorry, I don't understand. The length of the string U+0065 U+0301
> LGB> | certainly is 2, regardless of how the rendering engine displays
> this. LGB> | Of course, the rendering engine should render it as "é"
> because U+0301 L
LGB> | Sorry, I don't understand. The length of the string U+0065 U+0301
LGB> | certainly is 2, regardless of how the rendering engine displays this.
LGB> | Of course, the rendering engine should render it as "é" because U+0301
LGB> | is a combining character, but the string length is still 2.
LGB
Philipp Reichmuth <[EMAIL PROTECTED]> writes:
| | LGB>> One glyph that thakes 64 bits to encode...
>
| LGB> | But not for any *technical* purpose. For all purposes of string
| LGB> | processing, such as indexing, concatenation etc., this is *two*
| LGB> | characters, not one.
>
| LGB> Finding the
| LGB>> One glyph that thakes 64 bits to encode...
LGB> | But not for any *technical* purpose. For all purposes of string
LGB> | processing, such as indexing, concatenation etc., this is *two*
LGB> | characters, not one.
LGB> Finding the length of the string...
Sorry, I don't understand. The len
On Fri, Dec 20, 2002 at 02:55:15PM +0100, Andre Poenitz wrote:
> I had played around with automatic "paragraph inset" <-> "line inset" <->
> character inset conversion, i.e only the paragraph with the cursor is
> broken into individual chars, otherwise there is a per-line overhead of
That sounds
On Fri, Dec 20, 2002 at 01:29:13PM +, John Levon wrote:
> We couldn't get away with that for normal text I don't think. If we're
> really going to have word-based insets for layout they'd have to be
> ultra-thin
I had played around with automatic "paragraph inset" <-> "line inset" <->
charact
On Fri, Dec 20, 2002 at 09:31:55AM +0100, Andre Poenitz wrote:
> > what about storage ?
>
> I think it does not matter too much. For small docs, LyX itself eats more
> memory than the doc, if math is involved, we are already wasting way more
> than three bytes per char (and nobody complained so f
> "John" == John Levon <[EMAIL PROTECTED]> writes:
>> this can be really hard to debug. There is really little reason to
>> use UTF-8 except for staying as ASCII-transparent and as compatible
>> with 8-bit channels as possible.
John> what about storage ? I would hazard a guess that most of ou
Philipp Reichmuth <[EMAIL PROTECTED]> writes:
| LGB> One glyph that thakes 64 bits to encode...
|
| But not for any *technical* purpose. For all purposes of string
| processing, such as indexing, concatenation etc., this is *two*
| characters, not one.
Finding the length of the string...
| "Gl
On Thu, Dec 19, 2002 at 10:12:41PM +, John Levon wrote:
> what about storage ?
I think it does not matter too much. For small docs, LyX itself eats more
memory than the doc, if math is involved, we are already wasting way more
than three bytes per char (and nobody complained so far...)
Andre'
On Thu, Dec 19, 2002 at 12:31:18PM -0500, Kuba Ober wrote:
> No. It's just that faster code means less code in that situation, and
> don't we all like less code? As in: the best patch is the one which only
> removes code while preserving functionality ;-)
I am a big fan of that principle.
Andre'
JL> I don't think we do too much of that. Even user find/replace is slow
JL> because of our architecture and UTF8 will not significantly change that
JL> - fixing our algorithms will.
but then, a 16-bit-format is even better, because the special cases
for two-word characters are hit a lot less of
>>From 'man unicode':
LGB> For example, the German
LGB>character Umlaut-A ("Latin capital letter A with diaeresis") can either
LGB>be represented by the precomposed UCS code 0x00c4, or alternatively as
LGB>the combination of a normal "Latin capital letter A" fol
John Levon <[EMAIL PROTECTED]> writes:
| On Fri, Dec 20, 2002 at 12:11:24AM +0100, Lars Gullik Bj?nnes wrote:
|
| > That is only because they have nothing to say.
| > (or a hell of a compression algorithm)
|
| You mean you don't use one of the compression algorithms that can reduce
| the size of
Philipp Reichmuth <[EMAIL PROTECTED]> writes:
| KO> But it's probably very true that just using a 32-bit encoding with
| KO> *mostly* one-to-one mapping between characters and dwords is easy
| KO> to use. But not always easy to use.
|
| Do you have an counterexample of a Unicode character that c
On Fri, Dec 20, 2002 at 12:11:24AM +0100, Lars Gullik Bj?nnes wrote:
> That is only because they have nothing to say.
> (or a hell of a compression algorithm)
You mean you don't use one of the compression algorithms that can reduce
the size of every input ?
john
--
"ALL television is children's
On Fri, Dec 20, 2002 at 12:09:00AM +0100, Lars Gullik Bj?nnes wrote:
> | I think we want the core to use UTF8 too. But we have to deal with
> | variable-length character encodings of course.
>
> Why?
> (and where for that matter...)
Well, a character is no longer a fixed size, that's all. So eve
John Levon <[EMAIL PROTECTED]> writes:
| what about storage ? I would hazard a guess that most of our users can
| encode most of their document text in the first byte.
That is only because they have nothing to say.
(or a hell of a compression algorithm)
--
Lgb
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, Dec 19, 2002 at 04:50:06PM +, Duncan Simpson wrote:
|
| > time I ran into them. UTF8 is probably the right thing for storing the text in
| > a file IMHO but there are other choices.
|
| I think we want the core to use UTF8 too. But we have to
On Thu, Dec 19, 2002 at 10:33:17PM +0100, Philipp Reichmuth wrote:
> I'm not sure, the variable-length-ness leads to some bad performance
> hits on searching and string indexing, especially backwards; also,
I don't think we do too much of that. Even user find/replace is slow
because of our archi
>> time I ran into them. UTF8 is probably the right thing for storing the text in
>> a file IMHO but there are other choices.
JL> I think we want the core to use UTF8 too. But we have to deal with
JL> variable-length character encodings of course.
I'm not sure, the variable-length-ness leads to s
>> André Pönitz wrote:
>> > As far as I know there are already more than 2^16 chinese characters if
>> > all historic variants are taken into account. 2^16 gets tight if
>> > artificial scripts like Klingon are included. If one starts again with
>> > "code pages" and similar, all the old cruft is
On Thu, Dec 19, 2002 at 04:50:06PM +, Duncan Simpson wrote:
> time I ran into them. UTF8 is probably the right thing for storing the text in
> a file IMHO but there are other choices.
I think we want the core to use UTF8 too. But we have to deal with
variable-length character encodings of cou
In glibc wchar_t is 32 bits. Windows wide characters are UCS-2 or were last
time I ran into them. UTF8 is probably the right thing for storing the text in
a file IMHO but there are other choices.
But for GNU systems `wchar_t' is always 32 bits wide and,
therefore, capable of representi
On czwartek 19 grudzień 2002 12:31 pm, Kuba Ober wrote:
> On czwartek 19 grudzień 2002 02:34 am, you wrote:
> > On Wed, Dec 18, 2002 at 11:52:10AM -0500, Kuba Ober wrote:
> >
> > As far as I know there are already more than 2^16 chinese characters if
> > all historic variants are taken into account
-BEGIN PGP SIGNED MESSAGE-
On Donnerstag, 19. Dezember 2002 18:34, John Levon wrote:
> Whoo hoo. I'll apply these bits and then we'll look at the multiple
> encodings thing again.
>
> thanks a lot for your patient testing.
It is my desire to have working qt-lyx too. No need to thank.
(BTW
On Thu, Dec 19, 2002 at 02:28:36PM +0100, Kornel Benko wrote:
> Attached is what I had with the patched "QLyXKeySym::getSymbolName()".
Erf. I know what's going on. The fix should be easy. I'll just commit.
regards
john
--
"ALL television is children's television."
- Richard Adler
On Thu, Dec 19, 2002 at 12:22:34PM +0100, Kornel Benko wrote:
> IT WORKS!!
Whoo hoo. I'll apply these bits and then we'll look at the multiple
encodings thing again.
thanks a lot for your patient testing.
regards
john
--
"ALL television is children's television."
- Richard Adler
On czwartek 19 grudzień 2002 02:34 am, you wrote:
> On Wed, Dec 18, 2002 at 11:52:10AM -0500, Kuba Ober wrote:
> > Well, could anybody tell what doesn't fit into ucs2? Or, are there any
> > unicode pages that are outside of ucs2?
>
> As far as I know there are already more than 2^16 chinese charact
-BEGIN PGP SIGNED MESSAGE-
On Donnerstag, 19. Dezember 2002 12:22, Kornel Benko wrote:
> IT WORKS!!
John, you asked me about dialogs too ...
Attached is what I had with the patched "QLyXKeySym::getSymbolName()".
After removing this patch all dialogs seems to display ok again.
Displaying i
-BEGIN PGP SIGNED MESSAGE-
On Donnerstag, 19. Dezember 2002 00:42, John Levon wrote:
> On Wed, Dec 18, 2002 at 11:07:27AM +0100, Kornel Benko wrote:
> > action first set to [433]
> > action now set to [433]
>
> What bind file are you using ?
>
> OK, what is happening is that for me, the f
On Wed, Dec 18, 2002 at 11:52:10AM -0500, Kuba Ober wrote:
> Well, could anybody tell what doesn't fit into ucs2? Or, are there any
> unicode pages that are outside of ucs2?
As far as I know there are already more than 2^16 chinese characters if all
historic variants are taken into account. 2^16 g
On Wed, Dec 18, 2002 at 11:07:27AM +0100, Kornel Benko wrote:
> action first set to [433]
> action now set to [433]
What bind file are you using ?
OK, what is happening is that for me, the first binding with
Qt_Key_unknown happens to have an action of 88 (self insert) and it
works. For you howe
On Wed, Dec 18, 2002 at 04:01:02PM +, Angus Leeming wrote:
> As you're having so much difficulty with all this, why don't you cheat for
> the 1.3 release?
>
> QWorkArea.C has a lyxX11EventFilter that is currently used only for Selection
> events. Presumably it is passed KeyPress events also
On Wed, Dec 18, 2002 at 11:52:10AM -0500, Kuba Ober wrote:
> No doubt when we encounter some extraterrestrial civilization we may need many
> more characters than 64k (say 1/2 of that if we consider underutilized pages)
I hear peoplpe are already worried about this.
> then John would be happy
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Dec 18, 2002 at 10:26:09AM -0500, Kuba Ober wrote:
|
| > > If my LANG=en_GB, X will not let me compose these latin2 cahracters
| > > *anyway*, so I do not see how it is possible to ever insert them.
| >
| > I don't think that X's keyboard input an
On Wed, Dec 18, 2002 at 10:26:09AM -0500, Kuba Ober wrote:
> > If my LANG=en_GB, X will not let me compose these latin2 cahracters
> > *anyway*, so I do not see how it is possible to ever insert them.
>
> I don't think that X's keyboard input and X application's LANG have anything
> to do with e
On Wed, Dec 18, 2002 at 11:07:27AM +0100, Kornel Benko wrote:
> action first set to [433]
> action now set to [433]
> Key [action=433][@NONE@]
> Found the pseudoaction: [88|???]
> LyXFunc::dispatch: action[88] arg[???]
This is the problem. NONE of this should be hap
On Wed, Dec 18, 2002 at 07:35:55AM +0100, Philipp Reichmuth wrote:
> I thought that maybe your Qt LyX is running in a UTF-8 Unicode
> environment altogether, at least when you try pl_PL, and that there is
> some confusion with multibyte characters?
Well, that seems a bit vague ..
> What do you h
On środa 18 grudzień 2002 11:14 am, Angus Leeming wrote:
> On Wednesday 18 December 2002 3:52 pm, Andre Poenitz wrote:
> > On Wed, Dec 18, 2002 at 10:26:09AM -0500, Kuba Ober wrote:
> > > So, there are just a few simple steps that take place:
> > > 1. Keyboard scancodes result from physical keypres
On Åroda 18 grudzieÅ 2002 11:17 am, Andre Poenitz wrote:
> On Wed, Dec 18, 2002 at 05:07:58PM +0100, Lars Gullik Bjønnes wrote:
> > That its encoding is not standarized?
> > is it 16bit or 32 bit?
> >
> > problems like that...
>
> Ok, I thought it was safe to assuem 32 bits there. In anycase, I
On środa 18 grudzień 2002 11:12 am, Andre Poenitz wrote:
> On Wed, Dec 18, 2002 at 10:57:50AM -0500, Kuba Ober wrote:
> > Not only shot, but possibly too wide as well. I don't think we really
> > need 32 bits per character. Having 16 bits per character works fine in
> > QString, so I presume that's
On Wed, Dec 18, 2002 at 05:07:58PM +0100, Lars Gullik Bjønnes wrote:
> That its encoding is not standarized?
> is it 16bit or 32 bit?
>
> problems like that...
Ok, I thought it was safe to assuem 32 bits there. In anycase, I agree that
32 bit is the target. Would make mathed slimmer as most symbo
On Wed, Dec 18, 2002 at 10:57:50AM -0500, Kuba Ober wrote:
> Not only shot, but possibly too wide as well. I don't think we really need 32
> bits per character. Having 16 bits per character works fine in QString, so I
> presume that's all that's needed.
640k of RAM should be enough for everybody
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Dec 18, 2002 at 10:35:17AM -0500, Kuba Ober wrote:
>> > I would be surprised if char is something UTF-16 related on any common
>> > platform...
>>
>> Okay, not a good idea. What about wstring, then?
>
| That's probably 32 bit per char on IA32, a
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Dec 18, 2002 at 10:45:05AM -0500, Kuba Ober wrote:
>> Would it make any sense to use something like this:
>> typedef uint16_t lchar_t;
>> typedef std::basic_string lstring;
>
| What's wrong with std::wstring?
That its encoding is not standarized
Kuba Ober <[EMAIL PROTECTED]> writes:
| On ¶roda 18 grudzieñ 2002 10:55 am, Angus Leeming wrote:
>> On Wednesday 18 December 2002 3:45 pm, Kuba Ober wrote:
>> > Would it make any sense to use something like this:
>> > typedef uint16_t lchar_t;
>> > typedef std::basic_string lstring;
>> >
>> > "l"
On Wednesday 18 December 2002 3:52 pm, Andre Poenitz wrote:
> On Wed, Dec 18, 2002 at 10:26:09AM -0500, Kuba Ober wrote:
> > So, there are just a few simple steps that take place:
> > 1. Keyboard scancodes result from physical keypresses
> > 2. current modmap is used by the X server to map scancode
On środa 18 grudzień 2002 10:55 am, Angus Leeming wrote:
> On Wednesday 18 December 2002 3:45 pm, Kuba Ober wrote:
> > Would it make any sense to use something like this:
> > typedef uint16_t lchar_t;
> > typedef std::basic_string lstring;
> >
> > "l" stands for LyX (or low-overhead-in-conversion-t
On Wed, Dec 18, 2002 at 10:45:05AM -0500, Kuba Ober wrote:
> Would it make any sense to use something like this:
> typedef uint16_t lchar_t;
> typedef std::basic_string lstring;
What's wrong with std::wstring?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not hav
On Wed, Dec 18, 2002 at 10:35:17AM -0500, Kuba Ober wrote:
> > I would be surprised if char is something UTF-16 related on any common
> > platform...
>
> Okay, not a good idea. What about wstring, then?
That's probably 32 bit per char on IA32, and probably the way to go for
LyX.
Andre'
--
Thos
On Wed, Dec 18, 2002 at 10:26:09AM -0500, Kuba Ober wrote:
> So, there are just a few simple steps that take place:
> 1. Keyboard scancodes result from physical keypresses
> 2. current modmap is used by the X server to map scancode sequences to keysyms
> 3. keysyms are passed to the application via
On Wednesday 18 December 2002 3:35 pm, Kuba Ober wrote:
> On ¶roda 18 grudzieñ 2002 10:03 am, you wrote:
> > On Wed, Dec 18, 2002 at 10:01:17AM -0500, Kuba Ober wrote:
> > > AFAIR, std::string and QString have exactly same internal unicode
> > > representation (UTF-16 ???). I hope so, at least (/me
On Wednesday 18 December 2002 3:45 pm, Kuba Ober wrote:
> Would it make any sense to use something like this:
> typedef uint16_t lchar_t;
> typedef std::basic_string lstring;
>
> "l" stands for LyX (or low-overhead-in-conversion-to-QString) ;-)
SMiyata (sp?) suggested something similar to this som
On Åroda 18 grudzieÅ 2002 10:07 am, Lars Gullik Bjønnes wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> >> Unicodification is a big and dangerous job, and we will /still/ need
> >> from/toqstr unless we use QString in lyx itself, which we probably do
> >> not want to do.
> |
> | If the issue is
On środa 18 grudzień 2002 10:03 am, you wrote:
> On Wed, Dec 18, 2002 at 10:01:17AM -0500, Kuba Ober wrote:
> > AFAIR, std::string and QString have exactly same internal unicode
> > representation (UTF-16 ???). I hope so, at least (/me shrugs if they are
> > different).
>
> std::string is a typedef
> I believe this to be all that is needed for inserting
> keys with Qt frontend.
>
> If I do LANG=ro_RO ./lyx with this patch, I can insert t-cedilla etc.
> from latin2, just fine (assuming I've set document lang naturally).
>
> If my LANG=en_GB, X will not let me compose these latin2 cahracters
>
Kuba Ober <[EMAIL PROTECTED]> writes:
>> Unicodification is a big and dangerous job, and we will /still/ need
>> from/toqstr unless we use QString in lyx itself, which we probably do
>> not want to do.
>
| If the issue is to use std::string as the basic unicode-enabled string type,
| and easily us
On Wed, Dec 18, 2002 at 10:01:17AM -0500, Kuba Ober wrote:
> AFAIR, std::string and QString have exactly same internal unicode
> representation (UTF-16 ???). I hope so, at least (/me shrugs if they are
> different).
std::string is a typedef for std::basic_string.
I would be surprised if char is s
> Unicodification is a big and dangerous job, and we will /still/ need
> from/toqstr unless we use QString in lyx itself, which we probably do
> not want to do.
If the issue is to use std::string as the basic unicode-enabled string type,
and easily use such strings in Qt environment, then I presum
-BEGIN PGP SIGNED MESSAGE-
On Mittwoch, 18. Dezember 2002 07:35, Philipp Reichmuth wrote:
> BTW it would be nice to get at least ISO 8859-15 working, as it
> contains the Euro sign, which Polish or otherwise non-Latin-1 users
> might have a use for, too. :-)
You may achieve this in changi
-BEGIN PGP SIGNED MESSAGE-
On Mittwoch, 18. Dezember 2002 04:05, John Levon wrote:
> On Tue, Dec 17, 2002 at 11:38:06PM +0100, Kornel Benko wrote:
> > > 1. Update to current CVS and build. Do not patch lyx yourself at all
> > > please.
> >
> > done.
>
> Please try removing these lines alto
Hi John,
>> Red Hat 8 uses UTF-8 for a number of locales that employed one of the
>> various ISO 8859's in RH <= 7. I'm not sure which, as I'm a happy
>> FreeBSD user where console Unicode is a distant dream for the future.
>> But some of your LyX's encoding problems and/or your different
>> behav
On Tue, Dec 17, 2002 at 11:38:06PM +0100, Kornel Benko wrote:
> > 1. Update to current CVS and build. Do not patch lyx yourself at all
> > please.
>
> done.
Please try removing these lines altogether :
76 if (sym.empty()) {
77 lyxerr[Debug::KEY] << "sym empty i
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 17. Dezember 2002 22:08, John Levon wrote:
> On Tue, Dec 17, 2002 at 09:46:03PM +0100, Kornel Benko wrote:
> > It is worse.
> > I see "currency (¤)" instead, which has the same coding as Eurosign.
>
> If you could bear with me, I'm getting confused.
On Tue, Dec 17, 2002 at 09:46:03PM +0100, Kornel Benko wrote:
> It is worse.
> I see "currency (¤)" instead, which has the same coding as Eurosign.
If you could bear with me, I'm getting confused. I want to be a lot more
methodical now. So, could you please do the following :
1. Update to curren
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 17. Dezember 2002 21:18, John Levon wrote:
> On Tue, Dec 17, 2002 at 09:07:41PM +0100, Kornel Benko wrote:
> > > What is modifier ? Any ideas how I could try to enter this on my uk
> > > keyboard ?
> >
> > I am using us-keyboard. I can send you my ru
On Tue, Dec 17, 2002 at 09:07:41PM +0100, Kornel Benko wrote:
> > What is modifier ? Any ideas how I could try to enter this on my uk
> > keyboard ?
>
> I am using us-keyboard. I can send you my russian xmodmap mapping if you like.
Yes, please. It would be very helpful if I could test this mysel
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 17. Dezember 2002 20:50, John Levon wrote:
> On Tue, Dec 17, 2002 at 08:20:00PM +0100, Kornel Benko wrote:
> > But ... sorry ... unable to enter non-latin1 chars with this version.
>
> Can we work on the same page please. LANG=pl_PL ./lyx, change doc
On Tue, Dec 17, 2002 at 08:20:00PM +0100, Kornel Benko wrote:
> But ... sorry ... unable to enter non-latin1 chars with this version.
Can we work on the same page please. LANG=pl_PL ./lyx, change doc lang
to polish, try to enter t-cedilla (on my keyboard: compose - t -,).
What happens ?
> sete
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 17. Dezember 2002 19:36, Kornel Benko wrote:
> Rebuilding now.
Ok, ready. Display seems to be perfect now.
But ... sorry ... unable to enter non-latin1 chars with this version.
setenv LANG ru_RU
lyx
... try to insert Cyrillic_er (Modifyier + "r" on
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 17. Dezember 2002 19:15, John Levon wrote:
> On Tue, Dec 17, 2002 at 07:06:27PM +0100, Kornel Benko wrote:
> > It is independent of my LANG setting with this patch. It displays latin-2
> > only. To illustrate, see attached. It shows the displays with
On Tue, Dec 17, 2002 at 07:06:27PM +0100, Kornel Benko wrote:
> It is independent of my LANG setting with this patch. It displays latin-2 only.
> To illustrate, see attached. It shows the displays with the patched /non-patched QT
>versions
> of the same lyx-file.
Um, one of these screenshots is
On Tue, Dec 17, 2002 at 06:58:56PM +0100, Jean-Marc Lasgouttes wrote:
> John> Again, if somebody can tell me how to snoop the encoding to use
> John> in QLyXKeySym::getISOEncoded(), then we can get it to work.
>
> Can you get the encoding from the current language at cursor?
> (warning, I do not
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 17. Dezember 2002 18:13, John Levon wrote:
> On Tue, Dec 17, 2002 at 01:11:24PM +0100, Kornel Benko wrote:
> > But wait ..., now I am not able to display latin1-characters like
> > registered, copyright ...
>
> Using what LANG/encoding ? And is this
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Tue, Dec 17, 2002 at 06:44:57PM +0100, Philipp Reichmuth
John> wrote:
>> Well, does that mean that to enter Russian text I now need a
>> Russian version of Qt LyX or to open LyX from a separate,
>> Russian-encoding console, when I'm o
On Tue, Dec 17, 2002 at 06:44:57PM +0100, Philipp Reichmuth wrote:
> Well, does that mean that to enter Russian text I now need a Russian
> version of Qt LyX or to open LyX from a separate, Russian-encoding
> console, when I'm otherwise working in an all-Latin-1 or all-UTF-8
> environment?
I beli
Philipp Reichmuth <[EMAIL PROTECTED]> writes:
| Maybe it would be a good idea to now start delving into the
| Unicodification of LyX, in order to save the double work of first
| enabling all sorts of encodings in the document, and then converting
| the whole system to Unicode.
1.4.0 issue.
--
>> patch may be ok, if it is the last one then surely it is not ok.
JL> They're all latin1 so that's OK.
Well, does that mean that to enter Russian text I now need a Russian
version of Qt LyX or to open LyX from a separate, Russian-encoding
console, when I'm otherwise working in an all-Latin-1 or
John Levon <[EMAIL PROTECTED]> writes:
| On Tue, Dec 17, 2002 at 11:38:15AM +0100, Lars Gullik Bj?nnes wrote:
>
>> Unicode should fix these kind of problems... (I hope).
>
| Me too.
>
>> | X does not care about LANG. Try xev to see.
>>
>> I have no idea what qt does with this, but this is suppose
On Tue, Dec 17, 2002 at 01:55:22PM +0100, Kornel Benko wrote:
> > But wait ..., now I am not able to display latin1-characters like
> > registered, copyright ...
>
> Moreover, only latin-2 char are displayed correctly. For instance, all cyrillic
> char's are displayed as latin-2 too.
Just displa
On Tue, Dec 17, 2002 at 01:11:24PM +0100, Kornel Benko wrote:
> But wait ..., now I am not able to display latin1-characters like registered,
>copyright ...
Using what LANG/encoding ? And is this when you *enter* text, or can you
compose a document with these in xforms and show it correctly in q
On Tue, Dec 17, 2002 at 11:38:15AM +0100, Lars Gullik Bj?nnes wrote:
> Unicode should fix these kind of problems... (I hope).
Me too.
> | X does not care about LANG. Try xev to see.
>
> I have no idea what qt does with this, but this is supposed to work
> with xforms:
>
> M-x accent-cedilla G
On Tue, Dec 17, 2002 at 11:29:23AM +0100, Kornel Benko wrote:
> John Levon: If my LANG=en_GB, X will not let me compose these latin2 cahracters
> *anyway*, so I do not see how it is possible to ever insert
>them.
>
> X does not care about LANG. Try xev to see.
It certain
On Tue, Dec 17, 2002 at 09:18:29AM +0100, Juergen Vigna wrote:
> patch may be ok, if it is the last one then surely it is not ok. I WANT
> to have my menues and the rest in en_US (as that is my standard LANG
> environment althought I'm living in Italy and my mother tongue is german ;),
weirdo ! :
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 17. Dezember 2002 13:11, Kornel Benko wrote:
> But wait ..., now I am not able to display latin1-characters like
> registered, copyright ...
Moreover, only latin-2 char are displayed correctly. For instance, all cyrillic
char's are displayed as lati
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 17. Dezember 2002 07:53, John Levon wrote:
> On Tue, Dec 17, 2002 at 02:38:42AM +, John Levon wrote:
> > Here's a proof-of-concept. LANG=pl_PL menus are correct with the below
> > patch, wrong without.
>
> And here's the real patch. It's very big
John Levon <[EMAIL PROTECTED]> writes:
| On Tue, Dec 17, 2002 at 02:17:34AM +, John Levon wrote:
>
>> I reckon we can fix the menus etc. using the same thing, all we need is
>
| Here's a proof-of-concept. LANG=pl_PL menus are correct with the below
| patch, wrong without.
>
| Lars, comments ?
Kornel Benko <[EMAIL PROTECTED]> writes:
| On Dienstag, 17. Dezember 2002 09:18, Juergen Vigna wrote:
| > John Levon wrote:
| > > It would be great if people could give this a go. It Works For Me.
| >
| > I did not yet look at the patch, but I have a question. Are you talking
| > about having the
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 17. Dezember 2002 09:18, Juergen Vigna wrote:
> John Levon wrote:
> > It would be great if people could give this a go. It Works For Me.
>
> I did not yet look at the patch, but I have a question. Are you talking
> about having the menues and transla
John Levon wrote:
It would be great if people could give this a go. It Works For Me.
I did not yet look at the patch, but I have a question. Are you talking
about having the menues and translated strings displayed good or are
you talking about writing texts in other languages? If the first your
On Tue, Dec 17, 2002 at 02:38:42AM +, John Levon wrote:
> Here's a proof-of-concept. LANG=pl_PL menus are correct with the below
> patch, wrong without.
And here's the real patch. It's very big but conceptually simple : all
conversions to and from QString are wrapped. Not all are necessary,
On Tue, Dec 17, 2002 at 02:17:34AM +, John Levon wrote:
> I reckon we can fix the menus etc. using the same thing, all we need is
Here's a proof-of-concept. LANG=pl_PL menus are correct with the below
patch, wrong without.
Lars, comments ? Do people agree this is a sensible (albeit temporary
I believe this to be all that is needed for inserting
keys with Qt frontend.
If I do LANG=ro_RO ./lyx with this patch, I can insert t-cedilla etc.
from latin2, just fine (assuming I've set document lang naturally).
If my LANG=en_GB, X will not let me compose these latin2 cahracters
*anyway*, so
96 matches
Mail list logo
