French language with Speech Dispatcher, Speechd-el and DECtalk software 5.0

[Milan Zamazal]

>>>>> "GC" == Gilles Casse <address@hidden> writes:

    GC> Using the last CVS release of speechd-el, the c cedilla worked
    GC> but after a few tries, an e acute caused again the issue.

So you mean the problem is irregular and it sometimes occurs and
sometimes not?

    GC> The test gives this result here:

    GC>   (encode-coding-string "KEY ?\n" speechd--coding-system)

    GC> "KEY ???
 "

    GC> In hexa:

    GC> 22 4b 45 59 20 c3 c2 a1 0d 0a 22 0a
    GC> "  K  E  Y     ?  ?  ?  \r \n "  \n
                         ^^^
    GC> speechd--coding-system's value is utf-8-dos

The #c2 character is an extra character, it shouldn't be there.  Other
characters are correct.

But it doesn't mean the #c2 character is actually in the SSIP output --
it may just be added during conversions between different Emacs buffer
encodings.

Could you please do the following additional testing so that we are more
sure what happens?

- Enable protocol logging in Speech Dispatcher by uncommenting and
  setting the CustomLogFile option in speechd.conf, e.g.

    CustomLogFile "protocol" 
"/var/log/speech-dispatcher/speech-dispatcher-protocol.log"

- Load the following Elisp function:

  (defun test-utf8 (string)
    (let ((present (lambda (string)
                     (let ((i 0)
                           (len (length string))
                           (result (list ': (string-bytes string) string)))
                       (while (< i len)
                         (setq result (cons (aref string i) result))
                         (setq i (1+ i)))
                       (reverse result)))))
      (list (funcall present string)
            (funcall present (encode-coding-string string 'utf-8-dos)))))

- When the problem occurs, look into the protocol log in the file
  defined above and check whether the corresponding KEY command is
  encoded correctly there or not.  Please make sure that what you
  see/check is actually present in the log file, i.e. that you are not
  confused by a non-UTF buffer or terminal encoding.

- Eval the call

    (test-utf8 "KEY ?\n")

  Try to substite both the working and non-working keys for `?' and send
  the results.

Thanks for testing.

Regards,

Milan Zamazal

-- 
Wasting somebody else's time strikes me as the height of rudeness.
                                                      Bill Gates