GNU bug report logs - #79517
31.0.50; Screen artifacts problems when on Kitty terminal using Emacs and emojis

Previous Next

To reply to this bug, email your comments to 79517 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Screen artifacts problems when on Kitty terminal using
 Emacs and emojis
Date: Thu, 25 Sep 2025 19:22:48 -0300

[Message part 1 (text/plain, inline)]

Hello there!

This bug report is a follow up to the issue I first opened on Kitty
Terminal project (https://github.com/kovidgoyal/kitty/issues/9015).

**Bug Description**

When running Emacs in terminal mode (emacs -nw) inside Kitty, any user
action that causes a redraw over a line containing an emoji results in
visual corruption and artifacts. This includes selecting text, moving
the cursor, or scrolling. The selection highlight is often misaligned,
and parts of the line are not cleared or redrawn correctly.

More critically, this appears to be more than just a rendering
glitch. Emacs commands that calculate character positions, like
mark-sexp (C-M-SPC), fail to correctly identify matching delimiters if
an emoji is on the same line. This suggests that Emacs's internal cursor
position becomes desynchronized from the actual cursor position managed
by Kitty whenever a wide character is present.

I have performed several tests (detailed below) and I'm unable to
determine if this is a bug specific to Emacs's TUI mode, specific to
Kitty's handling of wide characters, or a subtle interaction between the
two.

Sometimes the background highlight stays even when text is no more
selected, chars disappear, emojis are rendered a bit bigger, a big
smaller.

The behavior is identical on both Linux and macOS. On iterm2(macOS),
gnome-terminal(linux) and xterm(linux) this won't happen.


**To Reproduce**
Steps to reproduce the behavior:

Call kitty -> emacs -> open my test_emojis_file.el with:

```
kitty --config NONE -e bash --norc -c "emacs -nw -Q ~/test_emojis_file.el"
```

This command should load kitty, bash and emacs without reading any user
side config.

The `test_emojis_file.el` is found attached.


I sometimes have to scroll, other times have to open another buffer and
come back, other times, just select things. I mean, minutes of usage on
emacs make this problem happen.

The one thing that is consistently making the error appear instantly is
using the C-M-SPC binding (Control, Meta (usually alt) and space) over
an opening parenthesis, this should highlight a selection between this
parenthesis and its correspondent matching closing one. It goes like
crazy, more below.

**Reproducing the Error**

**Screenshots**

1.) The file opened with the command above.

Attached 00.png or
https://github.com/user-attachments/assets/36ee7478-a78c-4071-b2d7-9b00cd4a08ee.

[00.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

2.) Cursor over the defvar starting parenthesis:

Attached 01.png or
https://github.com/user-attachments/assets/bebaefea-3564-4f5d-970b-4521261c4d14.

[01.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

3.) Issue the C-M-SPC binding:

Attached 02.png or
https://github.com/user-attachments/assets/a678de8f-5d4a-44fb-bef9-faf076071823.

[02.png (image/png, inline)]

[Message part 7 (text/plain, inline)]

4.) Even when no longer highlighted, artifacts stay on the screen:

Attached 03.png or:
https://github.com/user-attachments/assets/f2eee02a-5186-4e56-8292-180335f4d79a.

[03.png (image/png, inline)]

[Message part 9 (text/plain, inline)]

I do get some correction trying to force a redraw on Emacs with the
command `M-x redraw-display RET`, but this brings mixed results. If
nothing is highlighted it can fix, sometimes the entire screen,
sometimes part of the screen. If I have something rendering reactive to
the screen refresh though (like in a full setup, some sort of git
gutter) this triggers the problem again.


**Additional context**

I could not reproduce this problem by opening this file inside nano,
neovim or vim. I used the master branch Emacs for my initial tests, but
also tested on 30 (current version) and 29.


The Kitty author commented on why this would happen here:
https://github.com/kovidgoyal/kitty/issues/9015#issuecomment-3331445820.


Copying his response:

  This happens when the program running in the terminal and the terminal
  disagree on widths. kitty has the most correct, up-to-date and standards
  based approach to calculating widths and a robust solution to this
  problem. Read https://sw.kovidgoyal.net/kitty/text-sizing-protocol/
  Emacs needs to update its width calculation part at a minimum and
  ideally implement the width part of the above protocol.


Finally this is the reason I'm opening this bug report. Is there
anything that could be done to implement Kovidgoyal suggestion?


Thanks!

Message #8 received at 79517 <at> debbugs.gnu.org (full text, mbox):

From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
To: 79517 <at> debbugs.gnu.org
Subject: Re: 31.0.50; Screen artifacts problems when on Kitty terminal using
 Emacs and emojis)
Date: Thu, 25 Sep 2025 19:28:30 -0300

[Message part 1 (text/plain, inline)]

I forgot to add the annoing test file filled with emojis.

Please find it attached.

[test_emojis_file.el (application/emacs-lisp, inline)]

[Message part 3 (text/plain, inline)]

-- 

Rahul Martim Juliato
https://www.rahuljuliato.com

PGP Fingerprint: 6B68 4353 84E2 2C7E 5A26  B79A C666 FC94 BD7E A483
PGP Public Key : https://www.rahuljuliato.com/rahul_pub_key.asc

Message #11 received at 79517 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
Cc: 79517 <at> debbugs.gnu.org
Subject: Re: bug#79517: 31.0.50;
 Screen artifacts problems when on Kitty terminal using Emacs and
 emojis
Date: Fri, 26 Sep 2025 10:51:22 +0300

> From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
> Date: Thu, 25 Sep 2025 19:22:48 -0300
> 
> The Kitty author commented on why this would happen here:
> https://github.com/kovidgoyal/kitty/issues/9015#issuecomment-3331445820.
> 
> 
> Copying his response:
> 
>   This happens when the program running in the terminal and the terminal
>   disagree on widths. kitty has the most correct, up-to-date and standards
>   based approach to calculating widths and a robust solution to this
>   problem. Read https://sw.kovidgoyal.net/kitty/text-sizing-protocol/
>   Emacs needs to update its width calculation part at a minimum and
>   ideally implement the width part of the above protocol.
> 
> 
> Finally this is the reason I'm opening this bug report. Is there
> anything that could be done to implement Kovidgoyal suggestion?

This is the crux of the problem.  When Emacs displays on a text-mode
terminal (as opposed to a GUI frame on a windowing system), it uses
the Unicode width information, as presented in the Unicode data file
EastAsianWidth.txt.  If the terminal, in this case Kitty, uses a
different way of determining the widths, yielding different values,
there will be display problems.

AFAIU, the text-sizing protocol mentioned above provides an incomplete
solution, as far as Emacs is concerned.  This is because Emacs many
times performs internal layout calculations without actually
displaying anything.  As one example, when the user types C-n, Emacs
needs to determine the buffer position where this will place point,
and that requires to know the metrics of each character between the
current buffer position (where the cursor was shown before C-n) and
the buffer position where C-n will end.  Note that Emacs doesn't draw
anything on the screen for this purpose, it just runs internally its
display layout code, considering only the pixel coordinates.

Another example is a mouse click on some text on the screen: Emacs
needs a way to tell what was the buffer position corresponding to the
given screen coordinates.  Again, Emacs does that by consulting the
character widths, without displaying anything.

Now, AFAIU the proposed text-sizing protocol doesn't provide any
capability for Emacs to query the terminal about the width of a given
character, it only provides the control of the actual display width.
So, if Emacs should support this protocol, its algorithms need to be
changed so that (a) the width information comes from the Emacs
internal sources, assuming that the terminal can draw the characters
with the width specified by Unicode, and (b) the functions which
actually draw the characters to the screen enforce that width on the
terminal using the protocol control sequences.  The latter part needs
patches to how Emacs currently writes to text-mode terminals.  We also
need some code to determine whether the underlying terminal supports
this protocol, or (if that is not feasible) a user option to turn this
on and off.  Note that the modified code should be fast enough not to
slow down the display due to frequent look up of the width and
emission of the corresponding protocol sequences.  Such patches will
be welcome, but no one has yet submitted them.

All in all, Emacs and our users would be much happier if text-mode
terminal emulators would just have a knob to make them use the Unicode
width information, because then the current Emacs code would work
flawlessly for any complex character combinations.  Sadly, developers
of terminal emulators AFAIK decided that they don't need to provide
such an option, for reasons I cannot understand.

Message #14 received at 79517 <at> debbugs.gnu.org (full text, mbox):

From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Rahul Martim Juliato <rahuljuliato <at> gmail.com>, 79517 <at> debbugs.gnu.org
Subject: Re: bug#79517: 31.0.50; Screen artifacts problems when on Kitty
 terminal using Emacs and emojis
Date: Wed, 08 Oct 2025 17:33:06 -0300

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
>> Date: Thu, 25 Sep 2025 19:22:48 -0300
>> 
>> The Kitty author commented on why this would happen here:
>> https://github.com/kovidgoyal/kitty/issues/9015#issuecomment-3331445820.
>> 
>> 
>> Copying his response:
>> 
>>   This happens when the program running in the terminal and the terminal
>>   disagree on widths. kitty has the most correct, up-to-date and standards
>>   based approach to calculating widths and a robust solution to this
>>   problem. Read https://sw.kovidgoyal.net/kitty/text-sizing-protocol/
>>   Emacs needs to update its width calculation part at a minimum and
>>   ideally implement the width part of the above protocol.
>> 
>> 
>> Finally this is the reason I'm opening this bug report. Is there
>> anything that could be done to implement Kovidgoyal suggestion?
>
> This is the crux of the problem.  When Emacs displays on a text-mode
> terminal (as opposed to a GUI frame on a windowing system), it uses
> the Unicode width information, as presented in the Unicode data file
> EastAsianWidth.txt.  If the terminal, in this case Kitty, uses a
> different way of determining the widths, yielding different values,
> there will be display problems.
>
> AFAIU, the text-sizing protocol mentioned above provides an incomplete
> solution, as far as Emacs is concerned.  This is because Emacs many
> times performs internal layout calculations without actually
> displaying anything.  As one example, when the user types C-n, Emacs
> needs to determine the buffer position where this will place point,
> and that requires to know the metrics of each character between the
> current buffer position (where the cursor was shown before C-n) and
> the buffer position where C-n will end.  Note that Emacs doesn't draw
> anything on the screen for this purpose, it just runs internally its
> display layout code, considering only the pixel coordinates.
>
> Another example is a mouse click on some text on the screen: Emacs
> needs a way to tell what was the buffer position corresponding to the
> given screen coordinates.  Again, Emacs does that by consulting the
> character widths, without displaying anything.
>
> Now, AFAIU the proposed text-sizing protocol doesn't provide any
> capability for Emacs to query the terminal about the width of a given
> character, it only provides the control of the actual display width.
> So, if Emacs should support this protocol, its algorithms need to be
> changed so that (a) the width information comes from the Emacs
> internal sources, assuming that the terminal can draw the characters
> with the width specified by Unicode, and (b) the functions which
> actually draw the characters to the screen enforce that width on the
> terminal using the protocol control sequences.  The latter part needs
> patches to how Emacs currently writes to text-mode terminals.  We also
> need some code to determine whether the underlying terminal supports
> this protocol, or (if that is not feasible) a user option to turn this
> on and off.  Note that the modified code should be fast enough not to
> slow down the display due to frequent look up of the width and
> emission of the corresponding protocol sequences.  Such patches will
> be welcome, but no one has yet submitted them.
>
> All in all, Emacs and our users would be much happier if text-mode
> terminal emulators would just have a knob to make them use the Unicode
> width information, because then the current Emacs code would work
> flawlessly for any complex character combinations.  Sadly, developers
> of terminal emulators AFAIK decided that they don't need to provide
> such an option, for reasons I cannot understand.


Thanks for your quick response! 

I must say, in this subject I'm quite ignorant to be honest.

Please find below Kitty author's comment regarding the protocol.


    1. The text sizing protocol allows them to use whatever algorithm that
    floats their boat to determine character widths internally. The text sizing
    algorithms then allows them to force the terminal emulator to use those
    same widths that emacs determines internally to render the characters,
    thereby completely eliminating this issue. And there is some red herring
    about detecting support for this protocol, read: https://sw.kovidgoyal.net/kitty/text-sizing-protocol/#detecting-if-the-terminal-supports-this-protocol

    2. kitty does use the Unicode standard to determine character widths,
    and even specifies the exact algorithm to do so (EastAsianWidth.txt is
    insufficient for this). Read https://sw.kovidgoyal.net/kitty/text-sizing-protocol/#the-algorithm-for-splitting-text-into-cells


Just dropping this here in case someone more knowledgeable than me wants
to explore whether Emacs could take advantage of this protocol.

From other user comment: emojis on Emacs are also a problem on Ghostty
terminal emulator, and maybe this will also be a problem on WezTerm and
Alacritty once they also update their width mechanism.

Thanks again for the detailed explanation and for clarifying where the
main difficulties lie. I really appreciate your time and guidance.

-- 

Rahul Martim Juliato

Message #17 received at 79517 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
Cc: 79517 <at> debbugs.gnu.org
Subject: Re: bug#79517: 31.0.50; Screen artifacts problems when on Kitty
 terminal using Emacs and emojis
Date: Thu, 09 Oct 2025 09:57:24 +0300

> From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
> Cc: Rahul Martim Juliato <rahuljuliato <at> gmail.com>,  79517 <at> debbugs.gnu.org
> Date: Wed, 08 Oct 2025 17:33:06 -0300
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > All in all, Emacs and our users would be much happier if text-mode
> > terminal emulators would just have a knob to make them use the Unicode
> > width information, because then the current Emacs code would work
> > flawlessly for any complex character combinations.  Sadly, developers
> > of terminal emulators AFAIK decided that they don't need to provide
> > such an option, for reasons I cannot understand.
> 
> 
> Thanks for your quick response! 
> 
> I must say, in this subject I'm quite ignorant to be honest.
> 
> Please find below Kitty author's comment regarding the protocol.
> 
> 
>     1. The text sizing protocol allows them to use whatever algorithm that
>     floats their boat to determine character widths internally. The text sizing
>     algorithms then allows them to force the terminal emulator to use those
>     same widths that emacs determines internally to render the characters,
>     thereby completely eliminating this issue. And there is some red herring
>     about detecting support for this protocol, read: https://sw.kovidgoyal.net/kitty/text-sizing-protocol/#detecting-if-the-terminal-supports-this-protocol
> 
>     2. kitty does use the Unicode standard to determine character widths,
>     and even specifies the exact algorithm to do so (EastAsianWidth.txt is
>     insufficient for this). Read https://sw.kovidgoyal.net/kitty/text-sizing-protocol/#the-algorithm-for-splitting-text-into-cells

If kitty uses what is described there by default, then I don't see why
there would be any problems with Emacs, because it uses compatible
algorithms.

Are the problems only with Emoji sequences, or do you also see
problems with wide (a.k.a. "East-Asian") characters?  If the problem
is limited to Emoji, someone who is familiar with the kitty source
code and has enough time on their hands will need to analyze a couple
of cases with displaying Emoji, and describe the findings here, so we
could decide which changes and on what side (Emacs or kitty) are
needed to fix those problems.

If there are problems even with non-Emoji wide characters, then
there's probably something more fundamental here.  Again, specific
examples and analysis are needed.

Would someone like to take up this investigation?  TIA.

> Just dropping this here in case someone more knowledgeable than me wants
> to explore whether Emacs could take advantage of this protocol.

According to Item 2 of the Kitty author's response, there should be no
need for Emacs to use the special protocol, because this should
basically work OOTB, AFAIU.

Message #20 received at 79517 <at> debbugs.gnu.org (full text, mbox):

From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Rahul Martim Juliato <rahuljuliato <at> gmail.com>, 79517 <at> debbugs.gnu.org
Subject: Re: bug#79517: 31.0.50; Screen artifacts problems when on Kitty
 terminal using Emacs and emojis
Date: Sun, 02 Nov 2025 11:29:27 -0300

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
>> Cc: Rahul Martim Juliato <rahuljuliato <at> gmail.com>,  79517 <at> debbugs.gnu.org
>> Date: Wed, 08 Oct 2025 17:33:06 -0300
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > All in all, Emacs and our users would be much happier if text-mode
>> > terminal emulators would just have a knob to make them use the Unicode
>> > width information, because then the current Emacs code would work
>> > flawlessly for any complex character combinations.  Sadly, developers
>> > of terminal emulators AFAIK decided that they don't need to provide
>> > such an option, for reasons I cannot understand.
>> 
>> 
>> Thanks for your quick response! 
>> 
>> I must say, in this subject I'm quite ignorant to be honest.
>> 
>> Please find below Kitty author's comment regarding the protocol.
>> 
>> 
>>     1. The text sizing protocol allows them to use whatever algorithm that
>>     floats their boat to determine character widths internally. The text sizing
>>     algorithms then allows them to force the terminal emulator to use those
>>     same widths that emacs determines internally to render the characters,
>>     thereby completely eliminating this issue. And there is some red herring
>>     about detecting support for this protocol, read:
>> https://sw.kovidgoyal.net/kitty/text-sizing-protocol/#detecting-if-the-terminal-supports-this-protocol
>> 
>>     2. kitty does use the Unicode standard to determine character widths,
>>     and even specifies the exact algorithm to do so (EastAsianWidth.txt is
>>     insufficient for this). Read
>> https://sw.kovidgoyal.net/kitty/text-sizing-protocol/#the-algorithm-for-splitting-text-into-cells
>
> If kitty uses what is described there by default, then I don't see why
> there would be any problems with Emacs, because it uses compatible
> algorithms.
>
> Are the problems only with Emoji sequences, or do you also see
> problems with wide (a.k.a. "East-Asian") characters?  If the problem
> is limited to Emoji, someone who is familiar with the kitty source
> code and has enough time on their hands will need to analyze a couple
> of cases with displaying Emoji, and describe the findings here, so we
> could decide which changes and on what side (Emacs or kitty) are
> needed to fix those problems.
>
> If there are problems even with non-Emoji wide characters, then
> there's probably something more fundamental here.  Again, specific
> examples and analysis are needed.
>
> Would someone like to take up this investigation?  TIA.
>
>> Just dropping this here in case someone more knowledgeable than me wants
>> to explore whether Emacs could take advantage of this protocol.
>
> According to Item 2 of the Kitty author's response, there should be no
> need for Emacs to use the special protocol, because this should
> basically work OOTB, AFAIU.


As I mentioned earlier, I’m not very knowledgeable in this area.

However, someone
(https://github.com/kovidgoyal/kitty/issues/9015#issuecomment-3401961952)
has taken the initiative and drafted a rough patch that demonstrates
what might be required to support the Kitty text sizing protocol in
Emacs:

https://github.com/vkz/emacs-1/commit/fa141c4bfd2ca7caf05bb5196eda9c10c590c3ca

I’m sharing this here in case anyone with more expertise would like to
explore this further.

Message #23 received at 79517 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
Cc: 79517 <at> debbugs.gnu.org
Subject: Re: bug#79517: 31.0.50; Screen artifacts problems when on Kitty
 terminal using Emacs and emojis
Date: Sun, 02 Nov 2025 17:01:28 +0200

> From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
> Cc: Rahul Martim Juliato <rahuljuliato <at> gmail.com>,  79517 <at> debbugs.gnu.org
> Date: Sun, 02 Nov 2025 11:29:27 -0300
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
> >> Cc: Rahul Martim Juliato <rahuljuliato <at> gmail.com>,  79517 <at> debbugs.gnu.org
> >> Date: Wed, 08 Oct 2025 17:33:06 -0300
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > All in all, Emacs and our users would be much happier if text-mode
> >> > terminal emulators would just have a knob to make them use the Unicode
> >> > width information, because then the current Emacs code would work
> >> > flawlessly for any complex character combinations.  Sadly, developers
> >> > of terminal emulators AFAIK decided that they don't need to provide
> >> > such an option, for reasons I cannot understand.
> >> 
> >> 
> >> Thanks for your quick response! 
> >> 
> >> I must say, in this subject I'm quite ignorant to be honest.
> >> 
> >> Please find below Kitty author's comment regarding the protocol.
> >> 
> >> 
> >>     1. The text sizing protocol allows them to use whatever algorithm that
> >>     floats their boat to determine character widths internally. The text sizing
> >>     algorithms then allows them to force the terminal emulator to use those
> >>     same widths that emacs determines internally to render the characters,
> >>     thereby completely eliminating this issue. And there is some red herring
> >>     about detecting support for this protocol, read:
> >> https://sw.kovidgoyal.net/kitty/text-sizing-protocol/#detecting-if-the-terminal-supports-this-protocol
> >> 
> >>     2. kitty does use the Unicode standard to determine character widths,
> >>     and even specifies the exact algorithm to do so (EastAsianWidth.txt is
> >>     insufficient for this). Read
> >> https://sw.kovidgoyal.net/kitty/text-sizing-protocol/#the-algorithm-for-splitting-text-into-cells
> >
> > If kitty uses what is described there by default, then I don't see why
> > there would be any problems with Emacs, because it uses compatible
> > algorithms.
> >
> > Are the problems only with Emoji sequences, or do you also see
> > problems with wide (a.k.a. "East-Asian") characters?  If the problem
> > is limited to Emoji, someone who is familiar with the kitty source
> > code and has enough time on their hands will need to analyze a couple
> > of cases with displaying Emoji, and describe the findings here, so we
> > could decide which changes and on what side (Emacs or kitty) are
> > needed to fix those problems.
> >
> > If there are problems even with non-Emoji wide characters, then
> > there's probably something more fundamental here.  Again, specific
> > examples and analysis are needed.
> >
> > Would someone like to take up this investigation?  TIA.
> >
> >> Just dropping this here in case someone more knowledgeable than me wants
> >> to explore whether Emacs could take advantage of this protocol.
> >
> > According to Item 2 of the Kitty author's response, there should be no
> > need for Emacs to use the special protocol, because this should
> > basically work OOTB, AFAIU.
> 
> 
> As I mentioned earlier, I’m not very knowledgeable in this area.
> 
> However, someone
> (https://github.com/kovidgoyal/kitty/issues/9015#issuecomment-3401961952)
> has taken the initiative and drafted a rough patch that demonstrates
> what might be required to support the Kitty text sizing protocol in
> Emacs:
> 
> https://github.com/vkz/emacs-1/commit/fa141c4bfd2ca7caf05bb5196eda9c10c590c3ca

Thanks, but that's the opposite of what I meant.  This code tells
Kitty how many cells to use for characters, whereas Item 2 of the
Kitty author's response seems to indicate that there should be no need
for that, since both Kitty and Emacs use the same Unicode data to
determine the width of characters in cells.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.