Loading ...
Sorry, an error occurred while loading the content.

Re: [jasspa] Accented vowels

Expand Messages
  • Thomas Hundt
    I ll be happy to test whatever binaries you care to send. My box is a Thinkpad which is a normal i386 box. IMO the dead keys should be ignored by software
    Message 1 of 10 , Apr 10, 2006
    • 0 Attachment
      I'll be happy to test whatever binaries you care to send. My box is a
      Thinkpad which is a normal i386 box.

      IMO the "dead keys" should be ignored by software -- especially if
      grabbing them prevents some other processor from using them. (Not sure
      how this works in X: if one program accepts the keystroke, does that
      tell some other piece of software not to use it to modify the next
      keystroke?) The way they work is, you push them, then release them,
      then push the next one, then release it, and that one comes up accented.
      (Example: I shift to German mode, hit the '=' key, nothing happens,
      let it go, then hit the 'o' key and get an 'o' with an accent on top of it.)


      -Th


      Jon Green wrote, On 4/10/2006 1:36 AM:
      > saberquiero wrote:
      >> Hi, I have using ME for years in Windows, but now I've just install it
      >> in Ubuntu Linux, using the Patrick Das Gupta's package. All alright,
      >> but an important (for me) detail: I don't may write accented spanish
      >> vowels: when I press the acute accent key, an Q appears on screen. The
      >> correct behaviour is waiting for the next key andt hen write the
      >> proper character. Thus happens in other programs, as gedit, or the
      >> command shell. It this problem solvable?
      >>
      >> Regards,
      >>
      >> Rodolfo Valeiras.
      >
      > I looked at this over the weekend. I think the code handling for
      > XK_dead_xxxxxxxx needs to be changed in unixterm.c. I got the impression
      > that these should be treated as prefix keys. I do not fully understand
      > what is being delivered to ME yet for a given set of key strokes. This
      > information would be useful to have with the expected key.
      >
      > There are some printfs in unixterm.c that are useful to enable, this
      > will list out what X is delivering.
      >
      > Yes it is solvable - just need to understand what is being delivered and
      > what is expected to be output. Any further information would be useful.
      >
      > Jon.
      >
    • saberquiero
      ... key ... On my Spanish keyboard, to the right of the L is the Ñ (N tilde, ; and ... accent and acute accent, double and single quotes in US, I think). This
      Message 2 of 10 , Apr 10, 2006
      • 0 Attachment
        > Anyway: On mine, and I believe this is what Rodolfo is seeing, in
        > Spanish layout mode, the '/" key (next to Enter) produces a 'Q'. I
        > believe this is supposed to be an accent key (hit that, then hit the
        key
        > you want to accent).

        On my Spanish keyboard, to the right of the L is the Ñ (N tilde, ; and
        : in an US Keyboard), and to the right of Ñ, the " and ' (two points
        accent and acute accent, double and single quotes in US, I think).
        This is the key which outputs Q in ME. On top of this, to the right of
        the P, the ^ and ` key (cincunflex and grave accent, used in Frech; {
        and [ in US) outputs a P.

        I can tell I'm in Spanish because, for example,
        > the ;/: key outputs an 'n~' (tilde on top of an 'n'). (In German, this
        > key outputs an umlauted character, and the accent key is the =/+ key,
        > which also outputs a 'Q', and if I hit Shift first, which would
        normally
        > get me a different kind of accent, a 'P'. Aha!)
        >
        > None of which gets us any closer to a solution, but at least we know
        > there's an issue.
      • Rodolfo Valeiras Reina
        I also would like to help, if I m able. Only consider I m not an experienced Linux user. Rodolfo.
        Message 3 of 10 , Apr 10, 2006
        • 0 Attachment
          I also would like to help, if I'm able. Only consider I'm not an
          experienced Linux user.

          Rodolfo.

          Thomas Hundt escribió:
          > I'll be happy to test whatever binaries you care to send. My box is a
          > Thinkpad which is a normal i386 box.
          >
          > IMO the "dead keys" should be ignored by software -- especially if
          > grabbing them prevents some other processor from using them. (Not sure
          > how this works in X: if one program accepts the keystroke, does that
          > tell some other piece of software not to use it to modify the next
          > keystroke?) The way they work is, you push them, then release them,
          > then push the next one, then release it, and that one comes up accented.
          > (Example: I shift to German mode, hit the '=' key, nothing happens,
          > let it go, then hit the 'o' key and get an 'o' with an accent on top of it.)
          >
          >
          > -Th
          >
          >
          > Jon Green wrote, On 4/10/2006 1:36 AM:
          >> saberquiero wrote:
          >>> Hi, I have using ME for years in Windows, but now I've just install it
          >>> in Ubuntu Linux, using the Patrick Das Gupta's package. All alright,
          >>> but an important (for me) detail: I don't may write accented spanish
          >>> vowels: when I press the acute accent key, an Q appears on screen. The
          >>> correct behaviour is waiting for the next key andt hen write the
          >>> proper character. Thus happens in other programs, as gedit, or the
          >>> command shell. It this problem solvable?
          >>>
          >>> Regards,
          >>>
          >>> Rodolfo Valeiras.
          >> I looked at this over the weekend. I think the code handling for
          >> XK_dead_xxxxxxxx needs to be changed in unixterm.c. I got the impression
          >> that these should be treated as prefix keys. I do not fully understand
          >> what is being delivered to ME yet for a given set of key strokes. This
          >> information would be useful to have with the expected key.
          >>
          >> There are some printfs in unixterm.c that are useful to enable, this
          >> will list out what X is delivering.
          >>
          >> Yes it is solvable - just need to understand what is being delivered and
          >> what is expected to be output. Any further information would be useful.
          >>
          >> Jon.
          >>
          >
          >
          > __________________________________________________________________________
          >
          > This is an unmoderated list. JASSPA is not responsible for the content of
          > any material posted to this list.
          >
          > To unsubscribe, send a mail message to
          >
          > mailto:jasspa-unsubscribe@yahoogroups.com
          >
          > or visit http://groups.yahoo.com/group/jasspa and
          > modify your account settings manually.
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
        • Jon Green
          OK after digging into this a bit more then it is the compose that is causing a problem. I m running on Sun and just switched into French, so on the Sun
          Message 4 of 10 , Apr 10, 2006
          • 0 Attachment
            OK after digging into this a bit more then it is the compose that is
            causing a problem. I'm running on Sun and just switched into French, so
            on the Sun keyboard there is a special compose key (not sure what Linux
            does?) so I receive a XK_Multi_key event (xff20) which generates a
            space, then I can enter i' or 'i and get the appropriate accent.

            Tracing the input and using the compose status in the
            XLookupString(&event.xkey,keyStr,20,&keySym,&comp) I get:

            #1 got key ff20, ss=0 comp=0
            Adding ff key to buffer 32(0x0020)
            #1 got key ff20, ss=0 comp=1
            Adding ff key to buffer 32(0x0020)
            #1 got key 69, ss=0 comp=2
            Adding 00 key to buffer 105(0x0069)
            #1 got key ec, ss=0 comp=3
            Adding 00 key to buffer 236(0x00ec)

            So the compose does eventually produce the correct character and comp=0
            when we drop out of compose mode. Digging around the web I found the
            following which is probably what we need to add to process the strings.
            I'll have another play around with this tomorrow night.

            Jon.

            ++

            Some international lang conversion code example:

            case KeyPress:
            {
            Keysym keysym;
            Status status;
            int buflength;
            static int bufsize = 16;
            static char *buf = NULL;
            if (buf == NULL) {
            buf = malloc(bufsize);
            if (buf < 0) StopSequence();
            }
            buflength = XmbLookupString(ic, &event, buf, bufsize,
            &keysym, &status);
            /* first, check to see if that worked */
            if (status == XBufferOverflow) {
            buf = realloc(buf, (bufsize = buflength));
            buflength = XmbLookupString(ic, &event, buf, bufsize,
            &keysym, &status);
            }
            /* We have a valid status. Check that */
            switch(status) {
            case XLookupKeysym:
            DealWithKeysym(keysym);
            break;
            case XLookupBoth:
            DealWithKeysym(keysym);
            /* **FALL INTO** charcter case */
            case XLookupChars:
            DealWithString(buf, buflength);
            case XLookupNone:
            break;
            } /* end switch(status) */
            } /* end case KeyPress segment */
            break; /* we are in a switch(event.type) statement */
          Your message has been successfully submitted and would be delivered to recipients shortly.