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.
I consider it highly impossible or at least ineffective to improve
certain capabilities, if problems in an underlying engine persist and
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
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.
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.
Post by Nadav Kavalerchiki 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.
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.
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.
please consider this.
:-)
Dear Jonathan,
I have some comments on your proposal to the MoF.
- In section ×1 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.
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=77976> and 85715
<http://qa.openoffice.org/issues/show_bug.cgi?id=85715>, 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=85089>, which
affects not only Arabic, but Hebrew as well. Issue 89286
<http://qa.openoffice.org/issues/show_bug.cgi?id=89286> was added
recently. And there is issue 55927
<http://qa.openoffice.org/issues/show_bug.cgi?id=55927>, 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
Post by Jonathan Ben AvrahamHi list members,
In preparation for resumption of the Hebrew OOo project with the
Ministry of Finance I have prepared a proposed work plan (in
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
--
------------------------------------------------------------------------
*Henner Drewes*
/Tel./ +49 â 201 â 426 38 960
/Mobile Germany:/ +49 163 157 27 14
/Mobile Israel/: +972 54 212 48 53
/Home Israel: +972 77 212 48 53/
/Skype: /hennerd
www.movement-notation.de <http://www.movement-notation.de/>
------------------------------------------------------------------------
--
To unsubscribe see: http://openoffice.org.il/mailman/listinfo/hebrew
------------------------------------------------------------------------