Re: [OOo-Hebrew] [YBA] Proposal for MoF 2008/2009
Henner Drewes <[email protected]> Sat, 17 May 2008 18:20:11 +0300
| Newsgroups | gmane.comp.openoffice.hebrew |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============54376117726381112== Content-Type: multipart/alternative; boundary="------------040702010803020501020004" This is a multi-part message in MIME format. --------------040702010803020501020004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I did not mean to downgrade the importance of export / import issues.=20 Please consider my remarks as and add-on. They did not mean to negate=20 anything of the existing proposal. But for completeness, the issues=20 mentioned should be included. I consider it highly impossible or at least ineffective to improve=20 certain capabilities, if problems in an underlying engine persist and=20 are not solved. In this case for example, writer's own problems with paragraph numbering = need to defined and described. Only then a reasonable strategy for=20 solving import and export can be developed, as import and export relies=20 on writer. I assume an evaluation of this kind has been already done=20 within TKOS, but I would recommend to provide more details, both for the = community and for the soundness of the proposal. Sure you need to be able to import and export MSO documents. I tried=20 many times to import Hebrew word docs, and found out that writer cannot=20 handle the justified Hebrew text. But this was not an import issue, it=20 was a general issue of RTL text output. Without solid RTL capabilities=20 in OOo, all the import and export features will be useless, because=20 people will simply get stuck at another point. (OK, now the .doc gets=20 imported, but it does not get displayed properly) Luckily we already=20 have a good base for all this in OOo (at least I think so), but here and = there we encounter some annoying bugs. Probably in a lot of cases, it=20 will be not to hard to eliminate them. I have been working on that=20 during the past months, and I will continue doing so. But my resources=20 are limited, and e.g. I haven't done any programming for other platforms = than Windows so far. So I think, this is the point where other people=20 should fill in. And in my opinion these issues should get a high=20 priority on TKOS' agenda. Nadav Kavalerchik wrote: > i must emphasize the importants of importing / exporting abilitys and=20 > quality of the OOo that has to be as good as possible for people to be = > able to migrate and use OO along side MSO. > > we have MANY students and teachers in MANY schools that have issues=20 > with documents they make at home and bring to class and the other way=20 > around. leave aside the interface issues (people that use MSO UI are=20 > used to a little bit different UI) we must not give them excuses not=20 > to use OO based on document's import/export compatabilities. > > sure OO needs to have the base of rtl sorted out. but expecting the=20 > majority of users to use or switch to OO and be isolated (unable to=20 > exchange documents with MSO) is not somthing we can have right now :-) = > at leaset not for people how have no idealogy of the OpenSource movemen= t. > > please consider this. > > :-) > > 2008/5/17 Henner Drewes <[email protected] <mailto:[email protected]>= >: > > Dear Jonathan, > > > I have some comments on your proposal to the MoF. > > - In section =D7=911 the limitation of OOo's capabilities to displa= y > RTL and Hebrew paragraph numbering is mentioned. However, details > on the current limitations are not given. Looking at the > referenced issues in the OOo issue tracker, I noticed that all > mentioned issues are dealing with MS Word import and export only. > No issue exists that describes the current limitations when > working with OOo native files. > > I think it would be wise to clearly describe the status quo - > maybe not in the proposal itself, but file an issue in issue > tracker, and give a reference in the proposal. > > - There are still a lot of details to be worked on concerning > general bidi issues and typographic details in RTL text output. > I have provided patches for issues 77976 > <http://qa.openoffice.org/issues/show_bug.cgi?id=3D77976> and 85715= > <http://qa.openoffice.org/issues/show_bug.cgi?id=3D85715>, which > have been integrated recently. While issue 77976 dealt only with > Windows, I recently noticed that there is a similar problem > present on Linux. I haven't filed an issue on that yet, since as a > Windows user I am not affected personally. But I think you should > address this type of problems in your proposal and check all > platforms. > There is also issue 85089 > <http://qa.openoffice.org/issues/show_bug.cgi?id=3D85089>, which > affects not only Arabic, but Hebrew as well. Issue 89286 > <http://qa.openoffice.org/issues/show_bug.cgi?id=3D89286> was added= > recently. And there is issue 55927 > <http://qa.openoffice.org/issues/show_bug.cgi?id=3D55927>, which of= > course will become obsolete if edit engine will be replaced by > writer ( which sounds really exciting ... ), but in the mean time > it keeps annoying a lot of users. > > To summarize, proper RTL text output is a vital prerequisite for > achieving all other goals mentioned in the proposal. It should be > addressed and integrated into the proposal. > > Thank you for efforts. > > Henner > > > > Jonathan Ben Avraham wrote: >> Hi list members, >> In preparation for resumption of the Hebrew OOo project with the >> Ministry of Finance I have prepared a proposed work plan (in >> Hebrew) that you can find here: >> http://openoffice.org.il/Tk_plan_for_MoF_OOo_2008.pdf. >> >> The plan has passed one round of comment from Lior Kaplan and >> Nadine Cohen. Now it's your turn to comment. >> >> I expect that TkOS will be concluding an agreement with the MoF >> on the basis of this plan in the coming weeks, so if you have >> strong feelings about what should be in the plan, now is the time >> to make those feelings known. >> >> Happy independence day, >> >> - yba >> >> > > --=20 > -------------------------------------------------------------------= ----- > > *Henner Drewes* > > /Tel./ +49 =E2=80=93 201 =E2=80=93 426 38 960 > /Mobile Germany:/ +49 163 157 27 14 > /Mobile Israel/: +972 54 212 48 53 > /Home Israel: +972 77 212 48 53/ > /Sip:/[email protected] <mailto:[email protected]> > /Skype: /hennerd > > > /Email/ [email protected] > <mailto:[email protected]> > www.movement-notation.de <http://www.movement-notation.de/> > -------------------------------------------------------------------= ----- > > > -- > Hebrew OpenOffice Mailing List [email protected] > <mailto:[email protected]> > To unsubscribe see: http://openoffice.org.il/mailman/listinfo/hebre= w > ------------------------------------------------------------------------ --------------040702010803020501020004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"= > <title></title> </head> <body bgcolor=3D"#ffffff" text=3D"#000000"> I did not mean to downgrade the importance of export / import issues. Please consider my remarks as and add-on. They did not mean to negate anything of the existing proposal. But for completeness, the issues mentioned should be included.<br> <br> I consider it highly impossible or at least ineffective to improve certain capabilities, if problems in an underlying engine persist and are not solved.<br> In this case for example, writer's own problems with paragraph numbering need to defined and described. Only then a reasonable strategy for solving import and export can be developed, as import and export relies on writer. I assume an evaluation of this kind has been already done within TKOS, but I would recommend to provide more details, both for the community and for the soundness of the proposal.<br= > <br> Sure you need to be able to import and export MSO documents. I tried many times to import Hebrew word docs, and found out that writer cannot handle the justified Hebrew text. But this was not an import issue, it was a general issue of RTL text output. Without solid RTL capabilities in OOo, all the import and export features will be useless, because people will simply get stuck at another point. (OK, now the .doc gets imported, but it does not get displayed properly) Luckily we already have a good base for all this in OOo (at least I think so), but here and there we encounter some annoying bugs. Probably in a lot of cases, it will be not to hard to eliminate them. I have been working on that during the past months, and I will continue doing so. But my resources are limited, and e.g. I haven't done any programming for other platforms than Windows so far. So I think, this is the point where other people should fill in. And in my opinion these issues should get a high priority on TKOS' agenda.<br> <br> Nadav Kavalerchik wrote: <blockquote cite=3D"mid:[email protected]"= type=3D"cite">i must emphasize the importants of importing / exporting abilitys and quality of the OOo that has to be as good as possible for people to be able to migrate and use OO along side MSO.<br> <br> we have MANY students and teachers in MANY schools that have issues with documents they make at home and bring to class and the other way around. leave aside the interface issues (people that use MSO UI are used to a little bit different UI) we must not give them excuses not to use OO based on document's import/export compatabilities.<br> <br> sure OO needs to have the base of rtl sorted out. but expecting the majority of users to use or switch to OO and be isolated (unable to exchange documents with MSO) is not somthing we can have right now :-) at leaset not for people how have no idealogy of the OpenSource movement.<br> <br> please consider this.<br> <br> :-)<br> <br> <div class=3D"gmail_quote">2008/5/17 Henner Drewes <<a moz-do-not-send=3D"true" href=3D"mailto:[email protected]">hennerd@free= net.de</a>>:<br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt = 0.8ex; padding-left: 1ex;"> <div style=3D"direction: ltr;" bgcolor=3D"#ffffff" text=3D"#000000"> <p style=3D"margin-bottom: 0cm; margin-top: 0pt;">Dear Jonathan,</p> <br> I have some comments on your proposal to the MoF.<br> <br> - In section =D7=911 the limitation of OOo's capabilities to display RTL = and Hebrew paragraph numbering is mentioned. However, details on the current limitations are not given. Looking at the referenced issues in the OOo issue tracker, I noticed that all mentioned issues are dealing with MS Word import and export only. No issue exists that describes the current limitations when working with OOo native files. <br> <br> I think it would be wise to clearly describe the status quo - maybe not in the proposal itself, but file an issue in issue tracker, and give a reference in the proposal. <br> <br> - There are still a lot of details to be worked on concerning general bidi issues and typographic details in RTL text output. <br> I have provided patches for issues <a moz-do-not-send=3D"true" href=3D"http://qa.openoffice.org/issues/show_bug.cgi?id=3D77976" target=3D"_blank">77976</a> and <a moz-do-not-send=3D"true" href=3D"http://qa.openoffice.org/issues/show_bug.cgi?id=3D85715" target=3D"_blank">85715</a>, which have been integrated recently. While issue 77976 dealt only with Windows, I recently noticed that there is a similar problem present on Linux. I haven't filed an issue on that yet, since as a Windows user I am not affected personally. But I think you should address this type of problems in your proposal and check all platforms. <br> There is also issue <a moz-do-not-send=3D"true" href=3D"http://qa.openoffice.org/issues/show_bug.cgi?id=3D85089" target=3D"_blank">85089</a>, which affects not only Arabic, but Hebrew as well. Issue <a moz-do-not-send=3D"true" href=3D"http://qa.openoffice.org/issues/show_bug.cgi?id=3D89286" target=3D"_blank">89286</a> was added recently. And there is issue <a moz-do-not-send=3D"true" href=3D"http://qa.openoffice.org/issues/show_bug.cgi?id=3D55927" target=3D"_blank">55927</a>, which of course will become obsolete if edit engine will be replaced by writer ( which sounds really exciting ... ), but in the mean time it keeps annoying a lot of users.<br> <br> To summarize, proper RTL text output is a vital prerequisite for achieving all other goals mentioned in the proposal. It should be addressed and integrated into the proposal.<br> <br> Thank you for efforts.<br> <br> Henner <div class=3D"Ih2E3d"><br> <br> <br> Jonathan Ben Avraham wrote: <blockquote type=3D"cite">Hi list members, <br> In preparation for resumption of the Hebrew OOo project with the Ministry of Finance I have prepared a proposed work plan (in Hebrew) that you can find here: <br> <a moz-do-not-send=3D"true" href=3D"http://openoffice.org.il/Tk_plan_for_MoF_OOo_2008.pdf" target=3D"_blank">http://openoffice.org.il/Tk_plan_for_MoF_OOo_2008.pdf<= /a>. <br> <br> The plan has passed one round of comment from Lior Kaplan and Nadine Cohen. Now it's your turn to comment. <br> <br> I expect that TkOS will be concluding an agreement with the MoF on the basis of this plan in the coming weeks, so if you have strong feelings about what should be in the plan, now is the time to make those feelings known. <br> <br> Happy independence day, <br> <br> =C2=A0- yba <br> <br> <br> </blockquote> <br> </div> <div>-- <br> <hr> <p><b><font size=3D"4"><font face=3D"Arial, sans-serif"><font color=3D"#666666">Henner Drewes</font></font></font></b></p> <dl> <dt><font face=3D"Arial, sans-serif"><font size=3D"2"><i>Tel.</i> += 49 =E2=80=93 201 =E2=80=93 426 38 960</font></font></dt> <dt> <font face=3D"Arial, sans-serif"><font size=3D"2"><i>Mobile Germany:</i> +49 163 157 27 14</font></font></dt> <dt> <font face=3D"Arial, sans-serif"><font size=3D"2"><i>Mobile Israel</i>: +972 54 212 48 53</font></font></dt> <dt><font face=3D"Arial, sans-serif"><font size=3D"2"><i>Home Israe= l: +972 77 212 48 53</i></font></font></dt> <dt> <font face=3D"Arial, sans-serif"><font size=3D"2"><i>Sip:</i><= a moz-do-not-send=3D"true" href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a></font></font></dt> <dt> <font size=3D"2"><font face=3D"Arial, sans-serif"><i>Skype: </= i><a moz-do-not-send=3D"true">hennerd<br> </a></font><font face=3D"Arial, sans-serif"><br> <br> <i>Email</i> <a moz-do-not-send=3D"true" href=3D"mailto:[email protected]" target=3D"_blank">he= [email protected]</a></font></font></dt> <dt> <a moz-do-not-send=3D"true" href=3D"http://www.movement-notation.de/" target=3D"_blank"><font size=3D= "2"><font face=3D"Arial, sans-serif">www.movement-notation.de</font></font></a></d= t> <hr> </dl> </div> </div> <br> --<br> Hebrew OpenOffice Mailing List <a moz-do-not-send=3D"true" href=3D"mailto:[email protected]">[email protected]</a><br= > To unsubscribe see: <a moz-do-not-send=3D"true" href=3D"http://openoffice.org.il/mailman/listinfo/hebrew" target=3D"_bla= nk">http://openoffice.org.il/mailman/listinfo/hebrew</a><br> <br> </blockquote> </div> </blockquote> <div class=3D"moz-signature"> <dl> <hr> </dl> </div> </body> </html> --------------040702010803020501020004-- --===============54376117726381112== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Hebrew OpenOffice Mailing List [email protected] To unsubscribe see: http://openoffice.org.il/mailman/listinfo/hebrew --===============54376117726381112==--