Subject: Re: [idn] An ignorant question about TC<-> SC

From: liana Ye <[email-masked]>
Date: Thu, 25 Oct 2001 02:37:37 -0700

On Thu, 25 Oct 2001 16:27:10 +0900 Martin Duerst <[email-masked]> writes:
> At 13:02 01/10/23 -0700, liana Ye wrote:
> 
> >  From screen display point view, TC/SC are different glyph
> >  sets(who defines the sets? How is it used by 1/5 of the world
> >population? Is Uicode group the only authoritive one? In
> >China there are over 600 recorded views on this).
> 
> The Han ideographs in Unicode/ISO 10646 are defined by the
> IRG (Ideographic Raporteur Group). This group reports to
> ISO/IEC SC2 WG2, the ISO WG responsible for ISO 10646.
> It is composed of representatives from all the countries
> or similar entities interested in Han ideographs. That
> includes China, Japan, Korea (both South and North), Taiwan,
> Hong Kong, Singapore, and the US (I hope I didn't forget
> anybody, and please excuse the maybe politically uncorrect
> shortcuts). The US is the only country represented without
> a tradition of using Han ideographs, but usually only
> sends a small delegation and mainly helps with wording.
> Many other countries may send rather large delegations
> (given the number of characters, which means a lot of
> work, this is no surprise). The Unicode consortium
> participates in the IRG with an observer status only.
> 
> The IRG has published guidelines for deciding when to
> unify two occurences and when not. Because of the very
> huge number of characters, there is in some cases indeed
> a thin line as to whether something should be unified or
> not. And in these cases, the IRG just has to make a decision.
> 
> Overall, the guidelines are somewhat difficult to understand
> at first, but they are designed mainly with a 'least surprise
> to the average user' in mind, and I think they have achieved
> this goal very well. The guidelines are based on earlier
> ones used for the Japanese standard.
> 
> The core of the guidelines says that if two characters look
> significantly different, then they are encoded with two codes
> even if they e.g. are one-to-one SC/TC equivalents. This is
> to avoid suddenly changing the appearance of letters for a
> user who may not be familiar with the significantly differently
> looking shape. On the other hand, cases where there is only
> a small difference in shape are unified (i.e. only one code)
> unless this small difference in shape makes an actual
> difference in meaning.
> 
> Overall, the results are so that if you present a text
> where you change the glyph shapes within the range that
> is unified, people who have done basic education but don't
> know about different shapes (e.g. people in Taiwan or
> Hong Kong who only know about TC, or people in China or
> Singapore who only know about SC, or people in Japan who
> only know about the forms used in Japan) will read over
> these changes without problems, and might at some points
> say 'this looks a bit strange', but will still identify
> the character.
> 
> There are some exceptions to these rule related to backwards-
> compatible roundtripping (source separation rule).
> 
> 
> Hope this helps,      Martin.

In another word, the fundimental work from UCS is the to table 
glyphs based on their visual distinction.  Then why this group 
get into the guide line work in normalization of characters? Why
they give advice such as "not put TC/SC into" another table 
for a different purpose?

Liana

---

From: Martin Duerst <[email-masked]>
Date: Fri, 26 Oct 2001 16:31:31 +0900

At 02:37 01/10/25 -0700, liana Ye wrote:

>glyphs based on their visual distinction.

That is simply not true. The fundamental work is to make
sure that the result is best usable by average users for
their average purpose (writing electronic texts).

There have been a lot of requests to use finer distinctions,
e.g. from researchers or from people who publish dictionaries.
They were rejected, because they would confuse the average
user and the average use more than they would help.

There have also been requests for more unification, e.g. to
simplify searching/lookup in some situations, but they
have again been rejected because they would confuse the
average user and the average use more than they would help.
[In addition, such unifications would have to deal with the
many-to-one and many-to-many mappings, which just wouldn't
work.]

>Then why this group
>get into the guide line work in normalization of characters?

Because they are experts on characters, they use normalization
in their implementations, and so on.

>Why

Because many of them have been studying Han characters extensively,
and many others have worked with people who have done so, for
actual implementations and products, and they all have learned,
in one way or another, that TC/SC conversion is a very hard
problem that cannot be solved by a simple mapping table.

Do you really think that people from companies such as Microsoft,
IBM, Apple, and many others (see the list of members of the
Unicode Consortium at
http://www.unicode.org/unicode/consortium/memblogo.html),
and in particular the specialists for internationalization
in these companies, would want to tell you that TC/SC
mapping is difficult if they knew how to do it? Do you
think that any of these companies would not want to
sell products that did the conversion if it were easy
enough to make such a product? How much time do you think
engineers in each of these companies have spent studying
the problem and trying to come up with a simple but
satisfactory solution, without a satisfactory result?

I very much think that all of the people at the Unicode
Consortium would be very glad if there were a simple
mapping solution to the TC/SC problem, and would not
at all object to it being added to IDN, because they
understand that the TC/SC is an important one. But they
know from years, if not decades, of experience, that
it's all but an easy job, depeding a lot on context
(as James has said) which is not available in IDN,
and where a machine never gets perfect.

Hope this helps.    Regards,    Martin.

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Oct 2001 06:37:54 -0400

Martin,

For better or worse, your explanation and history is somewhat
revisionist.   While I believe the UTC has done an outstanding
job in more recent years to try to clean things up and
generalize them --in the directions you suggest-- my strong
recollection of the battles over "UCS" and what became 10646
follows.   NOTE: most of the WG may not want (or need) to read
this.  It goes over ground that we've been over before, and I am
writing this primarily in the hope that we can avoid cycling
through it again, in pieces.  The conclusion is that
Unicode/10646 is what we have today, and what we are stuck with,
and that arguments about history and design criteria are largely
pointless.

For those who want the history, at least as I remember it, read
on...

The original UCS effort, leading to what was known as 10646 
DIS-1, was focused on an effort whose criteria included a strong
focus on comparability and generalized applications use.  That
effort included a rather extensive liaison/ requirements
statement from the then-ISO TC97 subcommittee on programming
languages to the then TC97 SC2 that was accepted by SC2.  That
statement of requirements asked for a UCS that contained many of
the properties that we've discovered in the last few years would
be really helpful if they were present in Unicode, but aren't
there.  For example, there was to be no mixing of precomposed
characters and those that were built up as a sequence of code
points, using either non-spacing or overstrike ideas.   And
there was to be no overlaying of characters that looked alike
but were different.   

This is obviously the dream of someone doing string comparisons
and report-writing (which programming language people do, or
did, very often), since every character image seen on a page
would represent exactly the same string length in a computer,
i.e., 
  length-in-visual-units (string) =
      length-in-character-units (string)
always.

And, e.g., what I see as the hardest part of the TC <-> SC
problem would not have existed, aince there would have been no
confusion between, e.g., a Chinese character and a
similar-looking Korean or Japanese one.

The result, coming into the DIS-1 vote, did not completely meet
those critera (for example, it did contain provision for
overlaying glyphs), although it was arguably close to it.  It
was also large (requiring four octets) and, in some ways, fairly
unwieldy.  And, of course, by virtue of not having overlaying,
transposition from written text in an unknown language into a
coded character set representation was a far worse problem than
the one we struggle with today.  And, if I recall, the draft
hadn't preserved contingency and ordering of important and
frequently used existing character sets as block subsets.

In the ISO ballot resolution process, supposedly to handle some
negative votes against DIS-1, the then-complete proposal was
replaced, as an editorial substitution, with the then-current
version of Unicode.  Doing it as an editorial substitution
prevented any further review by interests within most (or any?)
of the ISO Member Bodies, nor was it possible for the other
subcommittees who had stated requirement to SC2 to comment on
the new version.  

The Unicode standard of that time had come out of a consortium
of, essentially, printer manufacturers.  Their primary design
criteria apparently included preservation of existing and
heavily-used character sets as proper block subsets (to avoid
having to change ROMs); keeping to a minimum number of octets
per character, especially [then] frequently-used characters
(memory was expensive and printer memory (and "board real
estate") was even more expensive than computer memory); and, to
the extent that they didn't conflict with the above, "if they
look alike, they are alike" and "if it is possible to think of
it as a font difference, it is" rules.  And, using those rules,
they assumed that 16 bits would be enough, forever.

At this late date, the most reaaonable thing that can be said
about the different between the approaches represented by
Unicode and 10646 DIS-1 is that they started from different
criteria and made the tradeoffs differently.  Which approach is
"better" depends on where one starts and what one considers most
important.   And both represent compromises with their original
criteria, due to conflicts among their requirements, so neither
was (or would have been) completely consistent internally.

Any complex, international, character set effort that started
more or less from scratch would face similar tradeoffs, e.g.:

	* preservation of the properties and locality of
	existing, heavily-used character sets versus optimality
	for, e.g., collation (for example, in a mixed case
	language in which both cases are expected to be used
	regularly, it would be much more convenient to have the
	characters arranged as 
          {Upper1, Lower1, Upper2,	Lower2, ... }
	rather than
	  {Upper1, Upper2, ..., Lower1, Lower2, ... }

	* Accurate transcription from a printed form, especially
	in an unknown language, into the coded character set
	versus keeping languages distinct or scripts together.
	
	* String comparisons versus the compactness of a
	character set
	
	* Overall size versus avoiding "unification".

and so on.  

And, in my personal opinion (then and now) the Unicode designers
were a little naive about the number of characters which a UCS
would ulimately need to accomodate and were a little too biased
in their thinking by their then-existing market.  That market
was mostly North American and Western European, their deployed
products were primarily deployed in those markets, and backward
compatibility with existing devices and thinking probably
impacted optimization decisions about the character set's
organization.   But, as I said at the beginning, times have
changed -- the current UTC is clearly trying to work around the
design limitations imposed by that starting point.

The bottom line is that Unicode is what we have.  It is lots
better for our purposes than its 1.0 version.  ISO 10646 DIS-1
is an historical footnote (as is this entire note).  We _need_
to figure out how to make what we have work.  That implies
either abandoning other sorts of ideas, or ideas that would
depend on an entirely different coding structure.  Or we need to
move other sorts of ideas into additional layers where we can
create more flexibility than the DNS gives us.  Or, of course,
we can get used to the idea that reaching a conclusion on
internationalized domain names, or even internationalized access
to them, will take a _very_ long time.   

After all, it has taken us thousands of years to create the
large variety of languages and writing systems (some might say
"the total mess") we have in the world today.  Perhaps it is
hubris to believe that we can reconcile all of the differences
as part of a DNS effort.  But, since the alternative is giving
up, and the requirements are important, I think we need to focus
in on the important and solvable problems and try to move
forward, rather than getting stuck on the historical sequences
that got us here, or on interesting research ideas, or on
unsolvable problems.

     john

--On Friday, 26 October, 2001 16:31 +0900 Martin Duerst
<[email-masked]> wrote:

>...

---

From: "ben" <[email-masked]>
Date: Fri, 26 Oct 2001 10:03:39 -0400

Hi Martin,

> But they

If that is the case, then why is it not a good idea to explicitly
label what type of script an IDN is in using 2LDs or TLDs?  (Other
then the fact that it is not interoperability and therefore should not
be a standard... )  This can be applied to all other language scripts
and not just <idn>.<traditional> and <idn>.<simplified> for Chinese
domain name users.  Users of IDNs are alot smarter and more
resourceful then we give them credit for, *as long as* we make it 100%
clear what script the IDN is in and not make it some kind of a
guessing game for them.

Thanks
Ben

---

From: "ben" <[email-masked]>
Date: Fri, 26 Oct 2001 10:20:00 -0400

Hi John,

> For those who want the history, at least as I remember it, read

Thanks for the history lesson and I now have a much better
understanding of all the efforts that have gone into this.  So I have
the same question for you as I do for Martin.  Why can't we simply
label an IDN with the what language script it is in.  In my opinion,
it is much more important for an IDN user to know "what script the IDN
is in" and far less important to know "if the IDN will take them to a
company or goverment or military or organization website".

Thanks
Ben

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Oct 2001 10:56:55 -0400

--On Friday, 26 October, 2001 10:20 -0400 ben <[email-masked]>
wrote:

> Hi John,
> 
>> 
>> For those who want the history, at least as I remember it,
>> read on...
>> 
> 
> understanding of all the efforts that have gone into this.  So
> I have the same question for you as I do for Martin.  Why
> can't we simply label an IDN with the what language script it
> is in.  In my opinion, it is much more important for an IDN
> user to know "what script the IDN is in" and far less
> important to know "if the IDN will take them to a company or
> goverment or military or organization website".

I'm not sure I understand your question, but I think you are
asking a basic question about the organization of the DNS.
I.e., if we decide languages are really important, why don't we
reorganize things into a language-based hierarchy, rather than a
country-and-function-based one?

The only _technical_ answers are that it would be hard to get
there from here, and that, given the administrative nature of
the DNS delegation structure, finding a single, agreed-upon,
authority for each language would be extremely hard.  There are
also a number of administrative obstacles, not the least of
which is that many people would not agree with your opinion.

I hate to keep saying this, but your question takes me back to
what I think is the basic problem here.  The DNS was designed to
provide identifiers for computer resources, using an
administrative structure that was fairly convenient for those
computer resources.  If we need to find names, or understand
strings, along other dimensions, we are either going to need to
remove the problem from the DNS or we are going to be faced with
tradeoffs among a range of undesirable solutions.

    john

---

From: "ben" <[email-masked]>
Date: Sun, 28 Oct 2001 10:26:28 -0500

Hi John,

I understand and respect your knowledge/opinion (as I recall reading
something you wrote on the history of gTLD and ccTLD) on the
difficulties of setting up another type of script hierarchy for the
<idn>.<idn>.

However, if one day it is indeed brought to the table, I most
certainly would like your vote of confidence (assuming that I have not
missed other technical difficulties that you see with it.)

Thanks
Ben

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 31 Oct 2001 12:00:35 -0800

The history of the Unicode/10646 merger is really irrelevant to TC<->SC, but
there are some inaccuracies that should not be left hanging.

> This is obviously the dream of someone ...

Your dream of having every character image seen on a page representing
exactly the same string length in a computer basically only works for ASCII.
Most of the properties that you find unhelpful in Unicode are a property of
human scripts, and many were already in DIS-1 (the 10646 DIS that failed its
ballot). Scripts such as Arabic, Hebrew, and most South and Southeast Asian
languages require combining marks; so for them your equation is broken. For
compatibility with the ISO bibliographic standards, combining marks are also
required for Latin, Cyrillic and Greek.

What the Unicode standard did put into place is a programmatic mechanism for
*identifying* sequences that should always be visually indistinguishable and
should always be considered equivalent -- the equivalency issue happens even
if there are no precomposed characters simply because of the possibility of
different orderings of combining characters. So there is a well-defined,
standard mechanism, rather than leaving the identification up to each
individual implementer, and having thousands of different implementations
have different rules.

DIS-1 suffered from a number of severe flaws:

* Since no code points were permitted where any byte was a C0 or C1 control,
there were only 35,271 possible code points on the BMP, instead of 64K.
Moreover, there were compatibility issues with C wide characters, since
zero-extended ASCII was not a valid DIS 10646 wide char.

* The 2-byte form in DIS-1 was variable -- one would use announcer sequences
to pick subsets in the 2-byte form. This is ISO 2022 all over again, and
horrible to process. The adoption rate by industry would have been
*severely* compromised at the unpalatable choice of either quadrupling text
memory (and it was hard enough to get them to move to 16 bits per character)
or having a 2022-like mess to deal with. There would still be no getting
around the multiple representations for what would otherwise be
indistinguishable characters shared by the CJK languages.

* There was no UTF-8: the first UTF (UTF-1) was developed by Unicode to
encapsulate the merged Unicode/10646 in a sequence of compatible bytes. That
UTF was superceded by the superior UTF-8, but the principles were the same.

For these and other reasons, the DIS-1 failed its ballot. The result of the
merger between Unicode and 10646 is far better, has been widely implemented
and meets the requirements of many organizations: software vendors, W3C,
ECMA, and the many national standards organizations such as Japan, China,
Republic of Korea, Denmark, Sweden and many other countries that have
adopted and translated the ISO standard.

> Doing it as an editorial substitution

There was a rather long ballot period for the DIS, with ample time for
comment by both member bodies and other ISO subcommittees.

> of, essentially, printer manufacturers.

We have heard the "printer company" urban legend before. Some of the
companies originally involved might be thought of as "printer companies",
but most were not. For example, Microsoft and IBM are not usually thought of
as "printer companies"! From the beginning, the focus was on Unicode as an
encoding that would work as an internal process code in implemenations, as
well as an encoding for interchange. Items that *look* like printer-ROM
hacks, like the addition of the Zapf dingbats, were pushed by software
companies like WordPerfect, and not by HP, Apple, or Xerox.

We are very curious as to the origin of this "printer company" story; where
did you hear this?

> Their primary design
> criteria apparently included

The design criteria were not at all as you state:

> preservation of existing and

Both the DIS-1 and Unicode segmented scripts into blocks, and generally
ordered characters in a script to match existing ordering in standards in
use if there were not reasons to change it, and both preserved Latin-1, but
that was just the sensible thing to do. There was no notion of having
unchanged printer ROMs.

> keeping to a minimum number of octets per character, especially [then]
frequently-used characters
> estate") was even more expensive than computer memory);

Unicode was designed as a 16 bit standard. Before the merger, there was no
UTF-8. The design was precisely 2 octets per character, independent of
frequency.

>  and, to
> it as a font difference, it is" rules.

The design criteria was to encode characters, not glyphs. For more on the
difference, see http://www.unicode.org/unicode/reports/tr17/

> And, using those rules,

Yes, under the original design principles of Unicode -- although not
matching your list -- 16 bits would have been enough for the commercially
significant characters of the world. (That depended on the use of IDS-like
mechanisms for uncommon CJK characters, using jamo sequences instead of
composed Hangul syllables, etc.) One of the changes brought about by the
merger was the recognition that in the new merged architecture -- and with
the increased number of presentation forms – this was insufficient. This led
to the development of UTF-16.

>   {Upper1, Upper2, ..., Lower1, Lower2, ... }

This actually does *not* solve the collation problem for any language that I
know of. Case (and usually accent) differences are at a different level than
base letter differences. They *cannot* be solved by a rearrangement of
codes.  See UCA (or the synchronized, equivalent ISO standard ISO/IEC 14651)
for more details (http://www.unicode.org/unicode/reports/tr10/).

However, you are right in terms of implemenation that if upper/lowercase
differences had always been at a fixed offset, it would be somewhat easier
to build more compact mapping tables for upper/lower/titlecasing operations.
And there are other cases where in hindsight a rearrangement of codes would
have lead to simpler implementations.

> versus keeping languages distinct or scripts together.

I see what you are trying to get at, but *no* character standard attempts to
preserve printed forms (see the discussion of characters vs glyphs).

This is perhaps better stated as:

* Determining the set of underlying abstract characters -- and the
interactions among them -- that are to represent the wide variety of glyphs
used to write different languages.

> * Overall size versus avoiding "unification".

As in the last point -- *every* character standard "unifies" glyphs into
abstract characters. GB is unified. JIS is unified. The rules for
unification used by the IRG was developed from the original rules used in
unifying JIS. Even Latin-1 is unified: after all, we could also have encoded
different Ö, Ü, á, etc. for French, German, Polish, etc, since there are
different typographic standards in those countries for the placement and
shape of accents.

> design limitations imposed by that starting point.

This is absolutely untrue. The developers of Unicode had worked
*extensively* with non-Roman markets. Although many of the developers were
Americans, many were not. And the companies forming Unicode had active
subsidiaries in a wide range of non-Roman markets -- including CJK, and
those subsidiaries certainly made their issues known.

Joe Becker was up front in 1989 that the number of "things" that people
would eventually want to represent was somewhere in the vicinity of 250,000:
that estimate has held up remarkably well, 12 years later. The naivite  was
not regarding the number of characters, but rather regarding the prospects
for being able to constrain the architecture of the UCS (as discussed
above), and use Private Use for archaic scripts, special-use symbols, etc.

> depend on an entirely different coding structure.

Yes, Unicode/10646 is what we have now. It is not perfect -- those of us who

worked on it from the beginning know the warts the best! But most of the
complexities are simply due to the complexities of human scripts, and the
Unicode consortium continually works to enhance the standard, data tables,
properties, technical reports, technical standards, guidelines, and other
information. This information is absolutely vital for producing
interoperable implementations.

Unicode/10646 is in widespread use, has a large body of implementations and
is the foundation for any system that is to deal with text around the world.

> Or we need to

Your bottom line is core, and absolutely correct: "I think we need to focus
in on the important and solvable problems and try to move forward".

I only take the time to correct some of the items above because a mistaken
impression of the process of development of Unicode and ISO 10646 might lead
people to have a mistaken impression of the quality of Unicode and 10646, or
the organizations behind them.

>      john

Mark

—————

Δός μοι ποῦ στῶ, καὶ κινῶ τὴν γῆν — Ἀρχιμήδης
[http://www.macchiato.com]

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 31 Oct 2001 20:59:18 -0500

Mark,

As you're feeling your oats.

>                                                                  ... but

I wish the UTC felt that way about a) making any recommendation as a
body concerning any any attempt by another body to utilize the work
product of the UTC, and b) specifically making an operational suggestion
that does not appear to be accompanied by operational data, or a non-naive
understanding of the dns.

...

> We are very curious as to the origin of this "printer company" story; where

That's "printer consortia". Private, with $$ to sit at the table. Like W3C
now, but worse.

It was my impression in 1991, at UTR#4-time, at 2.0-time, and at UTR#8-time.

It [Unicode] didn't spring out of the operating system industry. So which
peripheral device consortia is left? Disks? Modems?

It is still my impression today. Having writ XPG/1, and XPG/4.2, and knowing
most of the P1003.x particpants of the 90's, and the business and technical
managements of Bull, ICL, Siemens, Olivetti, Nixdorf, IBM, Sun, SGI, and HP
during the 90's -- I really don't care how much you'd prefer to believe that
the non-printer lines of business considered Unicode as strategic. I watched
them staff-up for the iso2022 period, and down-staff, and staff-up for the
File-System-Safe period, and down-staff. "Them" means Unix vendor business
core unit, not printer unit.

Just because we (first Apple, then MicroSoft, then us Unix vendors) all got
within a transform format of Unicode by 1996 doesn't mean that Unicode was
a core value proposition. At HP HP-15 was vastly more important, and at SMI
the multi-byte code-path for sort(1) was simply abominable, HP-UX 10.0 and
Solaris 2.4 and 2.5 -- when we multi-byted (UTF-8'd the tty, the file system,
and all the user libs and apps).

> the organizations behind them.

Jeez. I made mistakes in XPG/1. I let Nixdorff shave bits off a pid for an
early SMP-which-processor identifier. I made mistakes in Spec1170 also.
You guys act as if you never goofed -- and you guys actually put Klingon,
Esperanto and Pharonic Egyptian in your runqueue -- ahead of living languages.

We could replace Unicode as the basis for work on internationalizing the dns.
It wouldn't be a lark, but at least we already know what _not_ to do when
creating encoding for identifiers, and in terms of incongruity, it couldn't
be worse than ACE-for-labels, something-else-for-everything-else.

To quote from the report of the 1996 invitational workshop (not one was a
Unix implementor)

   E: The IAB should encourage the IRTF to create a research group to
   explore the open issues of character sets on the Internet. This group
   should set its sights much higher than this workshop did.

That was a sound recommendation. It hasn't been acted on. It should have
been, and it still should be in the present.

Just to keep things honest, from rfc2044:

   UTF-8 was originally a project of the X/Open Joint
   Internationalization Group XOJIG with the objective to specify a File
   System Safe UCS Transformation Format [FSS-UTF] that is compatible
   with UNIX systems, supporting multilingual text in a single encoding.
   The original authors were Gary Miller, Greger Leijonhufvud and John
   Entenmann.

I replaced John Entenmann (SMI) on XOJIG in 1995, and Gary Miller (IBM)
and I came out with our code-set independent architectures for our two
repsective operating systems (AIX and Solaris) in 1995/6.

We have bigger fish to fry than the ruffled feathers of Unicadettes, or
anyone else for that matter.

Anyone who wants to say they heard it from me is free to so state.

Some days I look at national standards and think, is that really any worse
than this mess?

Eric

---

From: "Jonathan Rosenne" <[email-masked]>
Date: Thu, 1 Nov 2001 06:37:54 +0200

For the record: 

1. ISO-10646 DIS 1 was unacceptable from our point of view, i.e. Hebrew,
and Israel voted against it without any other consideration.

2. There was a proposal that ISO should consider printer codes, as a
follow on to ISO 6429, but it did not get very far.

Jony