>> Are there any quirks in the support for Armenian? If there are please
>> document that somewhere so that we can point people to the right place.
> Uwe, why did you not answer this question? I am doing that now, because I
> think that the quirks should be known.
I explained the quirks I saw.
> Yes, there are some quirks. Here is what I don't like:
>
> - If you mark one single character in armenian language all ASCII
> characters in your document will appear as pseudo-armenian nonsense in the
> output. This is by far the most serious problem.
I don't understand: I can set the document language to Armenian, then all characters will be
translated to Armenian ones. To exclude some characters from this translation you have to use the
\aroff command in ERT or the environment I defined in the new layout file. Armenian users will learn
from the example file how to handle this.
We have to accept this behaviour - we cannot rewrite the armtex-package. And I think we can live
with this. You always have to learn as user how your language has to be used in a program, look at
the Hebrew and Arabic support.
> - The same happens if you change the document encoding to the new armenian
> encoding. In both cases the user has no clue why that happens.
What's the problem here? When I set the encoding manually I know what I am doing. Using an Armenian
encoding for english of course gives senseless output. That's the same as if I write an Hebrew text
but choose latin2 as encoding.
> - useless loading of babel
That's what I explained in my reply to José.
> - The lyx2lyx part is useless, since the armenian language tags are not
> removed from the body, and because of the encoding problem Uwe got. A
> working lyx2lyx conversion would need to translate all armenian unicode
> characters into the pseudo ascii coding used by armtex.
I don't think so. Converting an Armenian ocument to LyX 1.4.x is not posible as Armenian is only
supported by LyX 1.5. That's something the user can accept. Furthermore translating the characters
to the nasty armtex transliteration is not a good solution as this leads only to confusions. So the
lyx2lyx code is only useless for reverting to another LyX 1.5svn version.
I mean we cannot be compatible backward to every old LyX-version. Some features are new in a certain
LyX version without backward compatibility. I mean we currently can also not export all non latin1
documents to LyX 1.4.x-format. To test this, create an English document and insert there a
latin2-only character. Then try to convert the document to LyX 1.4.x - lyx2lyx fails. I discussed
this two days ago with José.
Btw. I think we currently don't have an Armenian user, so why would somebody have it working in LyX
1.4.x?
> - The test for the \usepackage{armtex} output is not correct (inputenc
> == "default" is not handled correctly,
I don't understand. When you choose Armenian as document language with default encoding, armscii8
will be used as input encoding and armtex is loaded. Armtex is also loaded when you chose the
armscii8 encoding manually.
> and neither the case when armenian is one of several used languages)
This isn't true. Take my example file I committed and mark some characters as e.g. Afrikaans. Then
your get
\usepackage[latin9,armscii8]{inputenc}
This is correct but armtex can't handle this case, so not our problem or bug.
> - The FORMAT entry is useless
Feel free to make it better.
> - future implementation of proper armenian support is now much more
> difficult, because existing documents with the ERT quirks need to be
> handled.
I disagree. As long as the armtex-package is not rewritten, it will stay like this. In the meantime
the users can now use it with LyX. And later eventualy converting an ERT command via lyx2lyx
shouldn't be difficult as there is only one, the \aroff command.
> For example, one could introduce a new language flag "document only
> language". Languages with this flag set would not appear in the character
> language dialog, and if a document has that language it would not be
> possible to set a different one with the character dialog.
This is a nice idea but there's currently nobody else than you taking care about such stuff, and
more important, have such brilliant ideas! I'm unfortunately to untalented to implement these
things. It costs me several hours of testing, reading, implementing the current solution and without
your help, I would never get this to work. I'm for example even not able to fully implement your
patch for bug 3043 as you could see from my questions I sent you in private mails.
But as you are retired from LyX I don't want to wait two years or so until someone implements such a
solution you proposed.
To say it again, I think the current solution is useful also for average users and doesn't interfere
with existing LyX documents. It furthermore can be adopted to any future solution, for example the
adoption for the babel call is just to remove the antry in the languages file, the \aroff command
can easily be handled as it is only one command.
regards Uwe
