José Matos wrote:
On Wednesday 18 July 2007 01:21:52 Dov Feldstern wrote:
Also, this has only convinced me even more that it's wrong to apply a
lyx2lyx fix for this patch: this is a bug fix, there were previously
.lyx files which were ok, but which lyx was generating incorrect latex
for, and patch 1820 fixes that. If there are lyx documents out there
which patch 1820 affects, it can only do them good. All this lyx2lyx
patch does is to explicitly set the language to the wrong values in all
kinds of situations.
OK you convinced me. I will accept the fix to bug 1820 if you add a comment in
release notes. Do we have a deal?
Deal. What exactly should the comment say --- just explain where the
problems were, and that they are now hopefully fixed?
I actually like Martin's idea of just having a placeholder format change
to go along with this --- just in case we do ever decide that some kind
of format change is needed, so we can identify what is before and what
is after the fix was applied. Does this sound right?
BTW in terms of final output what could it be the difference with and without
this patch applied? Was the previous output always wrong to RTL users and so
people learned to avoid it?
This type of answer would justify our response to this bug.
As far as I can determine, there are two main changes:
1. In certain specific cases, the text inside a footnote is displayed in
the wrong language (i.e., in the GUI it shows that it's in Hebrew, but
is printed in latex in English characters and in LTR, or vice-versa).
2. A footnote breaks the RTL sequence, so instead of logical
{A...M[1]N...Z} being displayed as {Z...N[1]M...A}, it's displayed as
{M...A}[1]{Z...N}.
Regarding case 1, I doubt that many users were actually creating
documents which included these situations. If there are such documents,
then I would guess that it's for one of the following reasons:
(a) the user did not notice that the latex was generated incorrectly (in
the GUI it displays correctly, and maybe the user didn't go over the
latex output carefully --- after all, it's only a footnote...);
(b) the user knew about this, but assumed that someday the bug would be
corrected;
(c) the user was generating the document for a non-latex backend, which
generates correct output in these situations (I don't really know how
the other backends deal with these situations; plaintext output is
correct, as far as I can tell).
In all these cases, I think that including the lyx2lyx patch would only
be detrimental.
Regarding case 2, a user could conceivably realize what was happening,
and therefore decide to write the text in the wrong logical order:
{N...Z[1]A...M}, so that it would be displayed correctly as
{Z...N}[1]{M...A}. In this case, they *would* want a lyx2lyx fix.
However, creating documents that are logically wrong is bad practice,
and could lead to other problems. For example, if such text is broken by
a line-break, it gets totally mangled... So it's not a good situation to
have gotten into in the first place, and I would argue that we should
not perpetuate it by providing a "fix" for it.
Regarding non-RTL users, (2) doesn't affect them so much, but (1) does.
However, if the languages being mixed are same-alphabet languages (e.g.,
European languages), then they may not even notice something is wrong,
because it would display more-or-less correctly. So in this case, I
don't think that the fix would make much of a difference, nor would the
lyx2lyx patch. But I'm not sure about this.
So, what's the upshot?
1. Can I commit the patch for 1820 (the patch itself, the cleaned-up
version at http://permalink.gmane.org/gmane.editors.lyx.devel/90016)?
2. I provide a comment explaining this (I'll try to make it as shrt as
possible) for the release notes.
3. Preferably, also add a placeholder format change to go along with it,
but no lyx2lyx for the moment?
Thanks!
Dov
