[Fwd: Re: OpenDocument and Bidi Support?] (fwd)
Jonathan Ben Avraham <[email protected]> Wed, 26 Apr 2006 11:55:57 +0300 (IDT)
| Newsgroups | gmane.linux.region.israel.ivrix.discuss |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --------------070600070008050709030706 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-ID: <Pine.LNX.4.64.0604260905061.30388-SwPZZxgOB782zBO71LVbc/[email protected]> Hi Ivrix Discussions members, This might be of interest to some of you. I have already asked Matti Allouche to join the discussion as I believe that he is one of the most authoratative persons in the BIDI community. - yba -- EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il - ---------- Forwarded message ---------- Date: Wed, 26 Apr 2006 10:11:38 +0300 (IDT) From: Jonathan Ben Avraham <[email protected]> To: robert_weir-r/[email protected] Cc: patrick-Q/[email protected], [email protected], daniel.carrera-xEbBXpWRM6W/PLq7hoJVF4Po/[email protected], [email protected], [email protected] Subject: [Fwd: Re: OpenDocument and Bidi Support?] (fwd) Hi Robert, The short answer is that any document format specification that supports RTL languages must have at least two text formatting specifications; base direction (e.g. <div dir="rtl">) and alignment (e.g. <df align="right">). If you don't have these, then the document cannot be rendered correctly by any application. You cannot guess the base direction or alignment from the character encoding. Here are the reasons why this is so - 1. Mixed characters in one paragraph Both modern Hebrew an Arabic use Latin character words embedded in native text. An example is the sentence "IBM replaces CEO". When you translate this sentence into Hebrew or Arabic, especially for a technical audience, you leave "IBM" in Latin characters and you translate "replaces CEO" into native. This leaves you with a text string that starts with Latin characters but is in fact native. If you use a herustic that assumes that a paragraph starting with Latin should be displayed LTR, then the letters IBM will be displayed incorrectly - at the left side if the sentence instead of the right side. So this example breaks what is usually called the "bidi algoritm" heuristic for deciding base direction. Although some native authors do transliterate commonly known acronyms such as "IBM", this is rarely done for more technical terms that do not have commonly used translations in either Hebrew or Arabic, such as "TTL", "UDP", "TCP", "HTTP", "SSL", etc. These are almost never translated or even transliterated. 2. Mixed paragraphs in a structure A structure such as a table in a Hebrew document often has elements that are entirely in Latin characters. Since the document is Hebrew, you want the columns of the table to be displayed from right to left - that is, without respect to character encoding. To do this you need the equivalent of a dir="rtl" tag at some level, either in the table element, or more conveniently, in a more general element such as a div element. Note that this is the case even when the document has no Hebrew characters at all but is intended for a Hebrew reading audience that expects the row headers to be on the right side of the table. There is no heuristic that can correctly guess the readers expected direction, so you have to allow for it in the document format. For an example of this, see http://he.openoffice.org. Try removing the <div style="text-align: right" dir="rtl"> in the page and see just how badly the page gets messed up. There is no heurustic that an application can use to reconstitute the direction and alignment tags if they are missing from the document format. 3. Alignment Contrary to what most of us assume when we start working in BIDI, text alignment has nothing to do with character encoding. There are many instances when you want Hebrew text aligned left and English text aligned right. This is a page layout issue and cannot be guessed from the characters. Now there are many substitutes or workarounds that people have tried to suggest in the past that would allow reconstruction of base direction and even alignment, such as having the application stuff into the text extra RLO's or LRO's that the user does not explicitly type. Besides being an incorrect use of these characters, they corrupt the text. None of these substitutes is workable. Regards, - yba -- EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il - ---------- Forwarded message ---------- Date: Tue, 25 Apr 2006 21:25:14 +0300 From: Alan Yaniger <[email protected]> To: Jonathan Ben Avraham <[email protected]> Subject: [Fwd: Re: OpenDocument and Bidi Support?] Hi Yonatan, These came to me tonight. I don't know anything about ODF format, other than the facts that OOo uses it, and that I don't have any problems with Hebrew documents in ODF. On the other hand, do we have any interest in making ODF an ISO standard? Should we get involved in this matter at all? -- Alan Yaniger Tk Open Systems --------------070600070008050709030706 Content-Type: MESSAGE/RFC822; name="Re: OpenDocument and Bidi Support?" Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <Pine.LNX.4.64.0604260905062.30388-SwPZZxgOB782zBO71LVbc/[email protected]> Content-Description: Content-Disposition: inline; filename="Re: OpenDocument and Bidi Support?" Return-Path: <[email protected]> X-Original-To: [email protected] Delivered-To: [email protected] Received: from tango.tkos.co.il (tango.tkos.co.il [62.219.50.35]) by taragon.tkos.co.il (Postfix) with ESMTP id BE2D76DD38 for <[email protected]>; Tue, 25 Apr 2006 21:00:24 +0300 (IDT) Received: from openoffice.org (s002.sfo.collab.net [64.125.133.202]) by tango.tkos.co.il (8.12.11.20060308/8.12.11) with SMTP id k3PI0Mu2026596 for <[email protected]>; Tue, 25 Apr 2006 21:00:23 +0300 Received: (qmail 15018 invoked by uid 5302); 25 Apr 2006 18:00:16 -0000 Delivered-To: tigrisq-ayaniger-a7aO2kWzfBovaG5lAUEpRB2eb7JE58TQ@public.gmane.org Received: (qmail 15013 invoked from network); 25 Apr 2006 18:00:15 -0000 Received: from cylon1.sjc.collab.net (204.16.104.10) by s002.sfo.collab.net with SMTP; 25 Apr 2006 18:00:15 -0000 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by cylon1.sjc.collab.net with ESMTP; 25 Apr 2006 11:00:15 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AQAAAK7/TUSIbgsCDA0bVQ X-IronPort-AV: i="4.04,154,1144047600"; d="scan'208"; a="16116400:sNHT20964727" X-IRONPORT: SCANNED Received: from phys-mayi-2 ([129.157.128.84]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k3PI0D4h015657 for <[email protected]>; Tue, 25 Apr 2006 12:00:15 -0600 (MDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IYA00301HPWH5-E2w92h8IIZx/a0ihu1R/[email protected]> (original mail from Michael.Brauer-UdXhSnd/[email protected]) for [email protected]; Tue, 25 Apr 2006 20:00:13 +0200 (MEST) Received: from [129.157.136.31] (sr1-eham02-02.Germany.Sun.COM [129.157.136.31]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IYA000YLI0CPV-E2w92h8IIZx/a0ihu1R/[email protected]>; Tue, 25 Apr 2006 20:00:13 +0200 (MEST) Date: Tue, 25 Apr 2006 20:00:12 +0200 From: Michael Brauer - Sun Germany - ham02 - Hamburg <[email protected]> Subject: Re: OpenDocument and Bidi Support? In-reply-to: <OF73940AE2.41E043AD-ON8525715B.005FD62D-8525715B.0060D521-FAfgETck7NMAvxtiuMwx3w@public.gmane.org> To: robert_weir-r/[email protected] Cc: patrick-Q/[email protected], [email protected], daniel.carrera-xEbBXpWRM6W/PLq7hoJVF4Po/[email protected], [email protected] Message-id: <444E63AC.2050902-UdXhSnd/[email protected]> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 References: <OF73940AE2.41E043AD-ON8525715B.005FD62D-8525715B.0060D521-FAfgETck7NMAvxtiuMwx3w@public.gmane.org> X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on tango X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, UNPARSEABLE_RELAY autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tango.tkos.co.il Rob, Patrick, I'm not an expert regarding the details of bidi support, but OpenDocument has several writing-mode attributes that allow switching the writing direction: Section 15.2.19 describes a style:writing-mode attribute which specifies the default writing direction of a page. Section 15.5.36 describes a style:writing-mode attribute which specifies the default writing direction of a paragraph. Section 15.7.8 describes a style:writing-mode attribute which specifies the writing direction of a section. Section 15.8.13 describes a style:writing-mode attribute which specifies the writing direction of a table. To the best of my knowledge, these attribute interact with the bidi support of UNICODE. I will try to find out some more details from our BIDI experts. However, since I'm travelling, I cannot promise how long this will take. For that reason, help from others that are familiar with BIDI is very welcome. In general, I agree to Patrick that since OOo support BIDI, OpenDocument supports it as well. Michael robert_weir-r/[email protected] wrote On 04/25/06 19:37,: > > Hi Patrick, Part of the confusion in my mind is that XHTML does have > explicit bidi indications, in the form of dir="rtl" attribute. XHTML > supports Unicode as well. So why two ways of specifying Bidi in the > same standard? To a non-I18N expert, the immediate question is, "What > is ODF missing by not having a dir attribute?" "Nothing" is a fine > answer. But my working assumption is the SII director saw something he > didn't like. Perhaps some more complicated scenario involving tables, > mixed languages or something like that. I'll see if I can find out more. > > Thanks, > > -Rob > > > Patrick Durusau <patrick-Q/[email protected]> wrote on 04/25/2006 01:25:08 PM: > > > Rob, > > > > Err, but ODF is based upon XML which requires Unicode as the character > > set. Unicode specifies the direction of rendering for all the characters > > in Unicode. > > > > That is to say that Unicode and not ODF specifies rendering such as > > right to left. Whether an application supports that or not, is an > > entirely different question. But it is not an XML format question. > > > > For example, I could send you an XML file that contains Hebrew > > characters and unless your application supports bidi "display" (and you > > read Hebrew), it isn't going to look like much. But, if you run that > > file through an XML parser, it validates just fine. > > > > I am not unsympathetic (having studied Hebrew back in the days of almost > > non-existent support everywhere) to the notion that bidi representation > > should be required. However, I don't think ODF is the place to require > > it. We make few demands of applications based on ODF and I would like to > > see that continue. > > > > I have a close friend at the Westminster Hebrew Institute in > > Philadelphia who uses OpenOffice all the time for Hebrew texts. But, > > note that is an application and not ODF per se. > > > > Does that help? > > > > Hope you are having a great day! > > > > Patrick > > > > PS: I think we need to ask SII to clearly distinguish between formats, > > like ODF, and applications, like OpenOffice. If we were writing a > > specification for the latter, then requiring bidi support would be > > understandable. But we are not writing a specification for an > > application, only a format. > > > > robert_weir-r/[email protected] wrote: > > > > > I'm putting out these note to a couple quarters. As you know, ODF is > > > going through an ISO standardization vote. The ballot closes May 1st. > > > We just received a note from the Standardization Director of the > > > Standards Institution of Israel (SII), which said, in part: > > > > > > We, in Israel, have a problem with this standard as it does not > include > > > requirements/specifications for bi-directional writing (bidi). As you > > > know (I hope) the Hebrew and Arabic languages are written from > > > right-to-left. We are planning to vote no and I would appreciate it if > > > you could send this e-mail on to the relevant person, as we may not > have > > > enough votes regarding this issue but we believe it critical to the > > > success of this standard. > > > > > > Now, my impression was that ODF did have support for Complex Text > > > Layouts, including Bidi, vertical writing, Thai, Hindi, etc. Does > > > anyone know of any ODF issues in this area? I'd hate to get a > > > negative vote if Bidi support in fact was adequate, but not clear to > > > the reader of the specification. Does anyone have an example Hebrew > > > bidi document in ODF format, or better-yet something with mixed > > > content? If we can provide a detailed technical response to SII, we > > > may be able to turn this vote around. > > > > > > I'm cc'ing the manager of the Hebrew OpenOffice page > > > (http://he.openoffice.org/), since he may have the most direct > > > experience in this area. Certainly, any Israeli national with > > > expertise in this area who can write to IIS on this issue would be a > > > benefit. I can provide additional contact info. > > > > > > Finally, please treat this note with some sensitivity. If you recall, > > > we had a similar internationalization issue from Japan earlier in the > > > process and we were able to turn around their vote by explaining in > > > more detail how the specification accomplished what they were looking > > > for. The best approach was a tactful, technical and timely response. > > > The ISO ballot closes May 1st, so there isn't much time. > > > > > > Thank! > > > > > > -Rob > > > > > > > -- > > Patrick Durusau > > [email protected] > > Chair, V1 - Text Processing: Office and Publishing Systems Interface > > Co-Editor, ISO 13250, Topic Maps -- Reference Model > > Member, Text Encoding Initiative Board of Directors, 2003-2005 > > > > Topic Maps: Human, not artificial, intelligence at work! > > > > -- Michael Brauer Phone: +49 40 23646 500 Technical Architect Software Engineering Fax: +49 40 23646 550 StarOffice Development Sun Microsystems GmbH Sachsenfeld 4 D-20097 Hamburg, Germany e-mail: [email protected] --------------070600070008050709030706 Content-Type: MESSAGE/RFC822; name="Re: OpenDocument and Bidi Support?" Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <Pine.LNX.4.64.0604260905063.30388-SwPZZxgOB782zBO71LVbc/[email protected]> Content-Description: Content-Disposition: inline; filename="Re: OpenDocument and Bidi Support?" Return-Path: <robert_weir-r/[email protected]> X-Original-To: [email protected] Delivered-To: [email protected] Received: from tango.tkos.co.il (tango.tkos.co.il [62.219.50.35]) by taragon.tkos.co.il (Postfix) with ESMTP id 247F56DD38 for <[email protected]>; Tue, 25 Apr 2006 20:37:58 +0300 (IDT) Received: from openoffice.org (s002.sfo.collab.net [64.125.133.202]) by tango.tkos.co.il (8.12.11.20060308/8.12.11) with SMTP id k3PHbtKk025738 for <[email protected]>; Tue, 25 Apr 2006 20:37:56 +0300 Received: (qmail 1992 invoked by uid 5302); 25 Apr 2006 17:37:50 -0000 Delivered-To: tigrisq-ayaniger-a7aO2kWzfBovaG5lAUEpRB2eb7JE58TQ@public.gmane.org Received: (qmail 1987 invoked from network); 25 Apr 2006 17:37:49 -0000 Received: from cylon1.sjc.collab.net (204.16.104.10) by s002.sfo.collab.net with SMTP; 25 Apr 2006 17:37:49 -0000 Received: from e32.co.us.ibm.com ([32.97.110.150]) by cylon1.sjc.collab.net with ESMTP; 25 Apr 2006 10:37:49 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AQAAAOb4TUSCXTiEXXsBCgwPHQ X-IronPort-AV: i="4.04,154,1144047600"; d="scan'208"; a="16114454:sNHT27009696" X-IRONPORT: SCANNED Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k3PHbfDr016113 for <[email protected]>; Tue, 25 Apr 2006 13:37:41 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3PHXqs4193776 for <[email protected]>; Tue, 25 Apr 2006 11:33:53 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k3PHbc3l029648 for <[email protected]>; Tue, 25 Apr 2006 11:37:39 -0600 Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k3PHbcSG029627; Tue, 25 Apr 2006 11:37:38 -0600 Received: from wtfmail03.edc.lotus.com (wtfmail03.lotus.com [9.33.9.119]) by internet1.lotus.com (8.13.6/8.13.2) with ESMTP id k3PHbbnS002247; Tue, 25 Apr 2006 13:37:37 -0400 (EDT) In-Reply-To: <444E5B74.7000404-Q/[email protected]> To: patrick-Q/[email protected] Cc: [email protected], daniel.carrera-xEbBXpWRM6W/PLq7hoJVF4Po/[email protected], Lars.Oppermann-UdXhSnd/[email protected], Michael.Brauer-UdXhSnd/[email protected] Subject: Re: OpenDocument and Bidi Support? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: robert_weir-r/[email protected] Message-ID: <OF73940AE2.41E043AD-ON8525715B.005FD62D-8525715B.0060D521-FAfgETck7NMAvxtiuMwx3w@public.gmane.org> Date: Tue, 25 Apr 2006 13:37:36 -0400 X-MIMETrack: Serialize by Router on WTFMAIL03/WTF/M/Lotus(Release 6.5.5FP1|March 16, 2006) at 04/25/2006 01:37:38 PM, Serialize complete at 04/25/2006 01:37:38 PM Content-Type: multipart/alternative; boundary="=_alternative 0060D2108525715B_=" X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on tango X-Virus-Status: Clean X-Spam-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, HTML_MESSAGE,NO_REAL_NAME,SPF_HELO_SOFTFAIL,SPF_SOFTFAIL autolearn=no version=3.1.0 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tango.tkos.co.il This is a multipart message in MIME format. --=_alternative 0060D2108525715B_= Content-Type: text/plain; charset="US-ASCII" Hi Patrick, Part of the confusion in my mind is that XHTML does have explicit bidi indications, in the form of dir="rtl" attribute. XHTML supports Unicode as well. So why two ways of specifying Bidi in the same standard? To a non-I18N expert, the immediate question is, "What is ODF missing by not having a dir attribute?" "Nothing" is a fine answer. But my working assumption is the SII director saw something he didn't like. Perhaps some more complicated scenario involving tables, mixed languages or something like that. I'll see if I can find out more. Thanks, -Rob Patrick Durusau <patrick-Q/[email protected]> wrote on 04/25/2006 01:25:08 PM: > Rob, > > Err, but ODF is based upon XML which requires Unicode as the character > set. Unicode specifies the direction of rendering for all the characters > in Unicode. > > That is to say that Unicode and not ODF specifies rendering such as > right to left. Whether an application supports that or not, is an > entirely different question. But it is not an XML format question. > > For example, I could send you an XML file that contains Hebrew > characters and unless your application supports bidi "display" (and you > read Hebrew), it isn't going to look like much. But, if you run that > file through an XML parser, it validates just fine. > > I am not unsympathetic (having studied Hebrew back in the days of almost > non-existent support everywhere) to the notion that bidi representation > should be required. However, I don't think ODF is the place to require > it. We make few demands of applications based on ODF and I would like to > see that continue. > > I have a close friend at the Westminster Hebrew Institute in > Philadelphia who uses OpenOffice all the time for Hebrew texts. But, > note that is an application and not ODF per se. > > Does that help? > > Hope you are having a great day! > > Patrick > > PS: I think we need to ask SII to clearly distinguish between formats, > like ODF, and applications, like OpenOffice. If we were writing a > specification for the latter, then requiring bidi support would be > understandable. But we are not writing a specification for an > application, only a format. > > robert_weir-r/[email protected] wrote: > > > I'm putting out these note to a couple quarters. As you know, ODF is > > going through an ISO standardization vote. The ballot closes May 1st. > > We just received a note from the Standardization Director of the > > Standards Institution of Israel (SII), which said, in part: > > > > We, in Israel, have a problem with this standard as it does not include > > requirements/specifications for bi-directional writing (bidi). As you > > know (I hope) the Hebrew and Arabic languages are written from > > right-to-left. We are planning to vote no and I would appreciate it if > > you could send this e-mail on to the relevant person, as we may not have > > enough votes regarding this issue but we believe it critical to the > > success of this standard. > > > > Now, my impression was that ODF did have support for Complex Text > > Layouts, including Bidi, vertical writing, Thai, Hindi, etc. Does > > anyone know of any ODF issues in this area? I'd hate to get a > > negative vote if Bidi support in fact was adequate, but not clear to > > the reader of the specification. Does anyone have an example Hebrew > > bidi document in ODF format, or better-yet something with mixed > > content? If we can provide a detailed technical response to SII, we > > may be able to turn this vote around. > > > > I'm cc'ing the manager of the Hebrew OpenOffice page > > (http://he.openoffice.org/), since he may have the most direct > > experience in this area. Certainly, any Israeli national with > > expertise in this area who can write to IIS on this issue would be a > > benefit. I can provide additional contact info. > > > > Finally, please treat this note with some sensitivity. If you recall, > > we had a similar internationalization issue from Japan earlier in the > > process and we were able to turn around their vote by explaining in > > more detail how the specification accomplished what they were looking > > for. The best approach was a tactful, technical and timely response. > > The ISO ballot closes May 1st, so there isn't much time. > > > > Thank! > > > > -Rob > > > > -- > Patrick Durusau > [email protected] > Chair, V1 - Text Processing: Office and Publishing Systems Interface > Co-Editor, ISO 13250, Topic Maps -- Reference Model > Member, Text Encoding Initiative Board of Directors, 2003-2005 > > Topic Maps: Human, not artificial, intelligence at work! > > --=_alternative 0060D2108525715B_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Hi Patrick, Part of the confusion in my mind is that XHTML does have explicit bidi indications, in the form of dir="rtl" attribute. XHTML supports Unicode as well. So why two ways of specifying Bidi in the same standard? To a non-I18N expert, the immediate question is, "What is ODF missing by not having a dir attribute?" "Nothing" is a fine answer. But my working assumption is the SII director saw something he didn't like. Perhaps some more complicated scenario involving tables, mixed languages or something like that. I'll see if I can find out more.</font> <br> <br><font size=2 face="sans-serif">Thanks,</font> <br> <br><font size=2 face="sans-serif">-Rob</font> <br> <br> <br><tt><font size=2>Patrick Durusau <patrick-Q/[email protected]> wrote on 04/25/2006 01:25:08 PM:<br> <br> > Rob,<br> > <br> > Err, but ODF is based upon XML which requires Unicode as the character <br> > set. Unicode specifies the direction of rendering for all the characters <br> > in Unicode.<br> > <br> > That is to say that Unicode and not ODF specifies rendering such as <br> > right to left. Whether an application supports that or not, is an <br> > entirely different question. But it is not an XML format question.<br> > <br> > For example, I could send you an XML file that contains Hebrew <br> > characters and unless your application supports bidi "display" (and you <br> > read Hebrew), it isn't going to look like much. But, if you run that <br> > file through an XML parser, it validates just fine.<br> > <br> > I am not unsympathetic (having studied Hebrew back in the days of almost <br> > non-existent support everywhere) to the notion that bidi representation <br> > should be required. However, I don't think ODF is the place to require <br> > it. We make few demands of applications based on ODF and I would like to <br> > see that continue.<br> > <br> > I have a close friend at the Westminster Hebrew Institute in <br> > Philadelphia who uses OpenOffice all the time for Hebrew texts. But, <br> > note that is an application and not ODF per se.<br> > <br> > Does that help?<br> > <br> > Hope you are having a great day!<br> > <br> > Patrick<br> > <br> > PS: I think we need to ask SII to clearly distinguish between formats, <br> > like ODF, and applications, like OpenOffice. If we were writing a <br> > specification for the latter, then requiring bidi support would be <br> > understandable. But we are not writing a specification for an <br> > application, only a format.<br> > <br> > robert_weir-r/[email protected] wrote:<br> > <br> > > I'm putting out these note to a couple quarters. As you know, ODF is <br> > > going through an ISO standardization vote. The ballot closes May 1st. <br> > > We just received a note from the Standardization Director of the <br> > > Standards Institution of Israel (SII), which said, in part:<br> > ><br> > > We, in Israel, have a problem with this standard as it does not include<br> > > requirements/specifications for bi-directional writing (bidi). As you<br> > > know (I hope) the Hebrew and Arabic languages are written from<br> > > right-to-left. We are planning to vote no and I would appreciate it if<br> > > you could send this e-mail on to the relevant person, as we may not have<br> > > enough votes regarding this issue but we believe it critical to the<br> > > success of this standard.<br> > ><br> > > Now, my impression was that ODF did have support for Complex Text <br> > > Layouts, including Bidi, vertical writing, Thai, Hindi, etc. Does <br> > > anyone know of any ODF issues in this area? I'd hate to get a <br> > > negative vote if Bidi support in fact was adequate, but not clear to <br> > > the reader of the specification. Does anyone have an example Hebrew <br> > > bidi document in ODF format, or better-yet something with mixed <br> > > content? If we can provide a detailed technical response to SII, we <br> > > may be able to turn this vote around.<br> > ><br> > > I'm cc'ing the manager of the Hebrew OpenOffice page <br> > > (http://he.openoffice.org/), since he may have the most direct <br> > > experience in this area. Certainly, any Israeli national with <br> > > expertise in this area who can write to IIS on this issue would be a <br> > > benefit. I can provide additional contact info.<br> > ><br> > > Finally, please treat this note with some sensitivity. If you recall, <br> > > we had a similar internationalization issue from Japan earlier in the <br> > > process and we were able to turn around their vote by explaining in <br> > > more detail how the specification accomplished what they were looking <br> > > for. The best approach was a tactful, technical and timely response. <br> > > The ISO ballot closes May 1st, so there isn't much time.<br> > ><br> > > Thank!<br> > ><br> > > -Rob<br> > ><br> > <br> > -- <br> > Patrick Durusau<br> > [email protected]<br> > Chair, V1 - Text Processing: Office and Publishing Systems Interface<br> > Co-Editor, ISO 13250, Topic Maps -- Reference Model<br> > Member, Text Encoding Initiative Board of Directors, 2003-2005<br> > <br> > Topic Maps: Human, not artificial, intelligence at work! <br> > <br> > <br> </font></tt> --=_alternative 0060D2108525715B_=-- --------------070600070008050709030706 Content-Type: MESSAGE/RFC822; name="Re: OpenDocument and Bidi Support?" Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <Pine.LNX.4.64.0604260905064.30388-SwPZZxgOB782zBO71LVbc/[email protected]> Content-Description: Content-Disposition: inline; filename="Re: OpenDocument and Bidi Support?" Return-Path: <patrick-Q/[email protected]> X-Original-To: [email protected] Delivered-To: [email protected] Received: from tango.tkos.co.il (tango.tkos.co.il [62.219.50.35]) by taragon.tkos.co.il (Postfix) with ESMTP id BA1E26DD38 for <[email protected]>; Tue, 25 Apr 2006 20:25:25 +0300 (IDT) Received: from openoffice.org (s002.sfo.collab.net [64.125.133.202]) by tango.tkos.co.il (8.12.11.20060308/8.12.11) with SMTP id k3PHPOAd025271 for <[email protected]>; Tue, 25 Apr 2006 20:25:24 +0300 Received: (qmail 26922 invoked by uid 5302); 25 Apr 2006 17:25:18 -0000 Delivered-To: tigrisq-ayaniger-a7aO2kWzfBovaG5lAUEpRB2eb7JE58TQ@public.gmane.org Received: (qmail 26917 invoked from network); 25 Apr 2006 17:25:18 -0000 Received: from cylon2.sjc.collab.net (204.16.104.18) by s002.sfo.collab.net with SMTP; 25 Apr 2006 17:25:18 -0000 Received: from mail.insimail.com (HELO insimail.com) ([66.110.223.212]) by cylon2.sjc.collab.net with ESMTP; 25 Apr 2006 10:25:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AQAAAOD1TUSIbAEKDg0d X-IronPort-AV: i="4.04,154,1144047600"; d="scan'208"; a="11383511:sNHT17549938" X-IRONPORT: SCANNED X-ExtScanner: Niversoft's Find_Attachments X-Originating-IP: 66.110.223.212 Received: from [66.110.197.20] (HELO [127.0.0.1]) by insimail.com (CommuniGate Pro SMTP 4.2) with ESMTP id 16728185; Tue, 25 Apr 2006 13:25:15 -0400 Message-ID: <444E5B74.7000404-Q/[email protected]> Date: Tue, 25 Apr 2006 13:25:08 -0400 From: Patrick Durusau <patrick-Q/[email protected]> Reply-To: patrick-Q/[email protected] User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: robert_weir-r/[email protected] Cc: Michael.Brauer-UdXhSnd/[email protected], Lars.Oppermann-UdXhSnd/[email protected], daniel.carrera-xEbBXpWRM6W/PLq7hoJVF4Po/[email protected], [email protected] Subject: Re: OpenDocument and Bidi Support? References: <OF473740EA.85D9DF25-ON8525715B.005B4473-8525715B.005DF518-FAfgETck7NMAvxtiuMwx3w@public.gmane.org> In-Reply-To: <OF473740EA.85D9DF25-ON8525715B.005B4473-8525715B.005DF518-FAfgETck7NMAvxtiuMwx3w@public.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on tango X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tango.tkos.co.il Rob, Err, but ODF is based upon XML which requires Unicode as the character set. Unicode specifies the direction of rendering for all the characters in Unicode. That is to say that Unicode and not ODF specifies rendering such as right to left. Whether an application supports that or not, is an entirely different question. But it is not an XML format question. For example, I could send you an XML file that contains Hebrew characters and unless your application supports bidi "display" (and you read Hebrew), it isn't going to look like much. But, if you run that file through an XML parser, it validates just fine. I am not unsympathetic (having studied Hebrew back in the days of almost non-existent support everywhere) to the notion that bidi representation should be required. However, I don't think ODF is the place to require it. We make few demands of applications based on ODF and I would like to see that continue. I have a close friend at the Westminster Hebrew Institute in Philadelphia who uses OpenOffice all the time for Hebrew texts. But, note that is an application and not ODF per se. Does that help? Hope you are having a great day! Patrick PS: I think we need to ask SII to clearly distinguish between formats, like ODF, and applications, like OpenOffice. If we were writing a specification for the latter, then requiring bidi support would be understandable. But we are not writing a specification for an application, only a format. robert_weir-r/[email protected] wrote: > I'm putting out these note to a couple quarters. As you know, ODF is > going through an ISO standardization vote. The ballot closes May 1st. > We just received a note from the Standardization Director of the > Standards Institution of Israel (SII), which said, in part: > > We, in Israel, have a problem with this standard as it does not include > requirements/specifications for bi-directional writing (bidi). As you > know (I hope) the Hebrew and Arabic languages are written from > right-to-left. We are planning to vote no and I would appreciate it if > you could send this e-mail on to the relevant person, as we may not have > enough votes regarding this issue but we believe it critical to the > success of this standard. > > Now, my impression was that ODF did have support for Complex Text > Layouts, including Bidi, vertical writing, Thai, Hindi, etc. Does > anyone know of any ODF issues in this area? I'd hate to get a > negative vote if Bidi support in fact was adequate, but not clear to > the reader of the specification. Does anyone have an example Hebrew > bidi document in ODF format, or better-yet something with mixed > content? If we can provide a detailed technical response to SII, we > may be able to turn this vote around. > > I'm cc'ing the manager of the Hebrew OpenOffice page > (http://he.openoffice.org/), since he may have the most direct > experience in this area. Certainly, any Israeli national with > expertise in this area who can write to IIS on this issue would be a > benefit. I can provide additional contact info. > > Finally, please treat this note with some sensitivity. If you recall, > we had a similar internationalization issue from Japan earlier in the > process and we were able to turn around their vote by explaining in > more detail how the specification accomplished what they were looking > for. The best approach was a tactful, technical and timely response. > The ISO ballot closes May 1st, so there isn't much time. > > Thank! > > -Rob > -- Patrick Durusau [email protected] Chair, V1 - Text Processing: Office and Publishing Systems Interface Co-Editor, ISO 13250, Topic Maps -- Reference Model Member, Text Encoding Initiative Board of Directors, 2003-2005 Topic Maps: Human, not artificial, intelligence at work! --------------070600070008050709030706 Content-Type: MESSAGE/RFC822; name="OpenDocument and Bidi Support?" Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <Pine.LNX.4.64.0604260905065.30388-SwPZZxgOB782zBO71LVbc/[email protected]> Content-Description: Content-Disposition: inline; filename="OpenDocument and Bidi Support?" Return-Path: <robert_weir-r/[email protected]> X-Original-To: [email protected] Delivered-To: [email protected] Received: from tango.tkos.co.il (tango.tkos.co.il [62.219.50.35]) by taragon.tkos.co.il (Postfix) with ESMTP id C2F566DD38 for <[email protected]>; Tue, 25 Apr 2006 20:06:27 +0300 (IDT) Received: from openoffice.org (s002.sfo.collab.net [64.125.133.202]) by tango.tkos.co.il (8.12.11.20060308/8.12.11) with SMTP id k3PH6OJD023824 for <[email protected]>; Tue, 25 Apr 2006 20:06:26 +0300 Received: (qmail 5618 invoked by uid 5302); 25 Apr 2006 17:06:19 -0000 Delivered-To: tigrisq-ayaniger-a7aO2kWzfBovaG5lAUEpRB2eb7JE58TQ@public.gmane.org Received: (qmail 5576 invoked from network); 25 Apr 2006 17:06:19 -0000 Received: from cylon2.sjc.collab.net (204.16.104.18) by s002.sfo.collab.net with SMTP; 25 Apr 2006 17:06:19 -0000 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by cylon2.sjc.collab.net with ESMTP; 25 Apr 2006 10:06:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AQAAACPzTUSDFYRdeQEKDg0b X-IronPort-AV: i="4.04,154,1144047600"; d="scan'208"; a="11382192:sNHT20758486" X-IRONPORT: SCANNED Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k3PH6Hmj008231 for <[email protected]>; Tue, 25 Apr 2006 13:06:17 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3PH6Dpr145136 for <[email protected]>; Tue, 25 Apr 2006 13:06:17 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k3PH6DHV015814 for <[email protected]>; Tue, 25 Apr 2006 13:06:13 -0400 Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k3PH6DHM015796; Tue, 25 Apr 2006 13:06:13 -0400 Received: from wtfmail03.edc.lotus.com (wtfmail03.lotus.com [9.33.9.119]) by internet1.lotus.com (8.13.6/8.13.2) with ESMTP id k3PH6CG0000919; Tue, 25 Apr 2006 13:06:12 -0400 (EDT) To: Michael.Brauer-UdXhSnd/[email protected], Lars.Oppermann-UdXhSnd/[email protected], patrick-Q/[email protected], daniel.carrera-xEbBXpWRM6W/PLq7hoJVF4Po/[email protected] Cc: [email protected] Subject: OpenDocument and Bidi Support? MIME-Version: 1.0 Importance: High X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: robert_weir-r/[email protected] Message-ID: <OF473740EA.85D9DF25-ON8525715B.005B4473-8525715B.005DF518-FAfgETck7NMAvxtiuMwx3w@public.gmane.org> Date: Tue, 25 Apr 2006 13:06:12 -0400 X-MIMETrack: Serialize by Router on WTFMAIL03/WTF/M/Lotus(Release 6.5.5FP1|March 16, 2006) at 04/25/2006 01:06:12 PM, Serialize complete at 04/25/2006 01:06:12 PM Content-Type: multipart/alternative; boundary="=_alternative 005DEF308525715B_=" X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on tango X-Virus-Status: Clean X-Spam-Status: No, score=3.7 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, HTML_30_40,HTML_FONT_FACE_BAD,HTML_MESSAGE,NO_REAL_NAME, SPF_HELO_SOFTFAIL,SPF_SOFTFAIL autolearn=no version=3.1.0 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tango.tkos.co.il This is a multipart message in MIME format. --=_alternative 005DEF308525715B_= Content-Type: text/plain; charset="US-ASCII" I'm putting out these note to a couple quarters. As you know, ODF is going through an ISO standardization vote. The ballot closes May 1st. We just received a note from the Standardization Director of the Standards Institution of Israel (SII), which said, in part: We, in Israel, have a problem with this standard as it does not include requirements/specifications for bi-directional writing (bidi). As you know (I hope) the Hebrew and Arabic languages are written from right-to-left. We are planning to vote no and I would appreciate it if you could send this e-mail on to the relevant person, as we may not have enough votes regarding this issue but we believe it critical to the success of this standard. Now, my impression was that ODF did have support for Complex Text Layouts, including Bidi, vertical writing, Thai, Hindi, etc. Does anyone know of any ODF issues in this area? I'd hate to get a negative vote if Bidi support in fact was adequate, but not clear to the reader of the specification. Does anyone have an example Hebrew bidi document in ODF format, or better-yet something with mixed content? If we can provide a detailed technical response to SII, we may be able to turn this vote around. I'm cc'ing the manager of the Hebrew OpenOffice page (http://he.openoffice.org/), since he may have the most direct experience in this area. Certainly, any Israeli national with expertise in this area who can write to IIS on this issue would be a benefit. I can provide additional contact info. Finally, please treat this note with some sensitivity. If you recall, we had a similar internationalization issue from Japan earlier in the process and we were able to turn around their vote by explaining in more detail how the specification accomplished what they were looking for. The best approach was a tactful, technical and timely response. The ISO ballot closes May 1st, so there isn't much time. Thank! -Rob --=_alternative 005DEF308525715B_= Content-Type: text/html; charset="US-ASCII" <p><font size=2 face=" Arial">I'm putting out these note to a couple quarters. As you know, ODF is going through an ISO standardization vote. The ballot closes May 1st. We just received a note from the Standardization Director of the Standards Institution of Israel (SII), which said, in part:</font> <p><font size=2 face=" Arial">We, in</font><font size=3 face=" Arial"> </font><font size=2 face=" Arial"> Israel, have a problem with this standard as it does not include</font><font size=3 face=" Arial"> </font><font size=2 face=" Arial"><br> requirements/specifications for bi-directional writing (bidi). As you</font><font size=3 face=" Arial"> </font><font size=2 face=" Arial"><br> know (I hope) the Hebrew and Arabic languages are written from</font><font size=3 face=" Arial"> </font><font size=2 face=" Arial"><br> right-to-left. We are planning to vote no and I would appreciate it if</font><font size=3 face=" Arial"> </font><font size=2 face=" Arial"><br> you could send this e-mail on to the relevant person, as we may not have</font><font size=3 face=" Arial"> </font><font size=2 face=" Arial"><br> enough votes regarding this issue but we believe it critical to the</font><font size=3 face=" Arial"> </font><font size=2 face=" Arial"><br> success of this standard. </font> <p><font size=2 face=" Arial">Now, my impression was that ODF did have support for Complex Text Layouts, including Bidi, vertical writing, Thai, Hindi, etc. Does anyone know of any ODF issues in this area? I'd hate to get a negative vote if Bidi support in fact was adequate, but not clear to the reader of the specification. Does anyone have an example Hebrew bidi document in ODF format, or better-yet something with mixed content? If we can provide a detailed technical response to SII, we may be able to turn this vote around. </font> <p><font size=2 face=" Arial">I'm cc'ing the manager of the Hebrew OpenOffice page (http://he.openoffice.org/), since he may have the most direct experience in this area. Certainly, any Israeli national with expertise in this area who can write to IIS on this issue would be a benefit. I can provide additional contact info.</font> <p><font size=2 face=" Arial">Finally, please treat this note with some sensitivity. If you recall, we had a similar internationalization issue from Japan earlier in the process and we were able to turn around their vote by explaining in more detail how the specification accomplished what they were looking for. The best approach was a tactful, technical and timely response. The ISO ballot closes May 1st, so there isn't much time.</font> <p><font size=2 face=" Arial">Thank!</font> <p><font size=2 face=" Arial">-Rob</font> <p> --=_alternative 005DEF308525715B_=-- --------------070600070008050709030706 Content-Type: TEXT/X-VCARD; charset=utf-8; name=alan.vcf Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <Pine.LNX.4.64.0604260905066.30388-SwPZZxgOB782zBO71LVbc/[email protected]> Content-Description: Content-Disposition: attachment; filename=alan.vcf begin:vcard=0D fn:Alan Yaniger=0D n:Yaniger;Alan=0D email;internet:[email protected]=0D version:2.1=0D end:vcard=0D =0D =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00 --------------070600070008050709030706 Content-Type: text/plain Content-Disposition: inline MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ---- Ivrix-discuss list. See http://ivrix.org.il. To unsubscribe, please send mail to [email protected] wi= th only the following line in the message body (NOT SUBJECT!): unsubscribe --------------070600070008050709030706--