Why --enable-qt5 isn't default?

[Guy Rutenberg]

Hi,

I just compiled LyX from source on a new machine and I found out the
default is still Qt4 and one has to specify --enable-qt5 to compile against
Qt5. With Qt4 being past end-of-life for more than 4 years, and Qt5 being
stable for more than 6 years, is there still a reason not switching the
default for ./configure?

Thanks,
Guy
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Hebrew document template

[Guy Rutenberg]

Hi,

On Wed, 29 Apr 2020 at 10:34, Pavel Sanda  wrote:

>
>
> Would you like to include the example into LyX examples we distribute with
> the
> sourcecodes?
>
>
Sure, I think it might be useful.

Thanks,
Guy
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Translating string affected by the document language

[Guy Rutenberg]

Hi,

How can one get a list of all translatable strings that get translated
accoring to the current document's language?

This is a continuation of the discussion in
https://www.lyx.org/trac/ticket/11607. I think that basically nobody uses
the Hebrew translation for the GUI (most people prefer English UI) but
people do use it for writing documents in Hebrew. I want to concentrate the
translation effort where it matters and not simply translate everything.

Thanks,
Guy

Re: Hebrew on LyX

[Guy Rutenberg]

Hi,

Sorry, for the long delays. family commitments make it hard for me in the
last few days to be on top of my email (but that's good :-))

On Sun, 28 Apr 2019 at 22:52, Scott Kostyshak  wrote:

>
> > I would suggest shipping LyX with a template file configured with XeTeX
> > (and sensible and common fonts).
>
> Can you suggest a specific font?
>
>
Most fonts that ship as defaults with most operating systems are not very
good when it comes to Hebrew typography. After some consulting, sane
defaults based on free-licensed fonts are:
- Serif: David/Frank Ruhl. The culmus fonts are high quality, but there are
also free licensed versions of those in Google Fonts directory.
- Sans-serif: DejaVu Sans Serif, has good hebrew support, depending on the
combination/usage Alef can go as well.
- Monospace: Miriam Libre (from Google Fonts)

Thanks,
Guy

Re: Hebrew on LyX

[Guy Rutenberg]

Hi,

I think for 99% of the users writing in Hebrew, XeTeX is the (only)
reasonable choice for writing in Hebrew. There are many broken things
pdfTeX when it comes to Hebrew (and RTL languages), and fonts are only one
of them (another example is hyperref).

If you are forced to use pdfTex (or non-XeTeX) you should prefer using
culmus-latex over ivritex. Ivritex has been deprecated for +10 years.

I would suggest shipping LyX with a template file configured with XeTeX
(and sensible and common fonts).

Thats my two cents.

Thanks,
Guy

On Wed, 24 Apr 2019 at 17:16, Guenter Milde  wrote:

> Dear LyX developers,
>
> currently, typesetting Hebrew with LyX's default settings (i.e. TeX fonts)
> requires installation of font packages not in TeXLive.
> Installation instructions (partially somewhat outdated) are on the LyX
> wiki.
>
> The alternatives are:
>
> ivritex fonts
>   bitmap,
>   font encoding LHE (7bit, non-standard missing small latin letters)
>   no vocalisation (nikud) characters
>
> culmus fonts
>   Type 1,
>   font encoding HE8,
>   compiling with dvipdfm works only after converting some fonts
>   with `t1binary` and custom install.
>
>
> The current default is LHE (ivritex fonts).
>
> For selecting the HE8 fonts, there are two options:
>
> a) use custom fontencoding setting [HE8,T1] and preamble code
>(as in unicodesymbols/012-hebrew_he_HE8.lyx)
>
>-1 "expert" setup required for each document
>
>+1 no "hidden" change of the default setup (LHE fonts from ifritex)
>
> b) patch lib/languages
>
> diff --git a/lib/languages b/lib/languages
> index 3f8733787d..097a2f85ac 100644
> --- a/lib/languages
> +++ b/lib/languages
> @@ -780,10 +780,14 @@ Language hebrew
> QuoteStyle   english
> InternalEncoding true
> # babel-hebrew expects the encoding for *other* languages
> last:
> -   # FontEncodingHE8
> -   # Define the font encoding the babel-hebrew way and
> +   # FontEncodingHE8|LHE
> +   # Use font encoding HE8 if the Culmus fonts are installed
> and
> # work around too simple test for article-like classes in
> rlbabel.def.
> PreBabelPreamble
> + \IfFileExists{he8david.fd}{%
> +   \def\HeblatexEncoding{HE8}
> +   \def\HeblatexEncodingFile{he8enc}%
> + }{}
>   \providecommand{\l@chapter}{\relax}
> EndPreBabelPreamble
> DateFormats  "d  |d MMM |dd/MM/"
>
> +1 selects Type1 (vector) fonts (Culmus) as default, if available
>and falls back to LHE if not.
>(This can be overridden in documents with preamble code
> similar to option a).)
> -0 clumsy
> -1 if a user has both, LHE and HE8 fonts installed, documents
>that worked with dvipdfm may now fail.
>
>
> What should we use in LyX 2.4?
>
> Günter
>
>

Alignment of section titles in KOMA classes

[Guy Rutenberg]

Hi,

In the regular document classes, if a document's main language is Hebrew,
than alignment in LyX's display of section titles is context-dependent
(right if Hebrew, left otherwise). In the Koma classes (for example
KOMA-Script article) it does not work that way.

I suspect the relevant code is the style in the layout file:

> Style Section
> Align Left
> Font
>   Family  Sans
> EndFont
> End
>

Is there a way to instruct LyX to treat the Left Alignment as
direction-dependent automatically? Alternatively, can we change the
alignment to be "Block" as in the standard classes?

Thanks,
Guy

Re: [LyX/master] Fix parentheses with Hebrew

[Guy Rutenberg]

Hi,

On Thu, 1 Nov 2018 at 18:43, Richard Kimberly Heck  wrote:

>
> My second suggestion in the last email is along these lines, too. I
> should have added that it is only when the language is Hebrew that we do
> any of the other tests. (We have to go through the whole file, of
> course, to find out whether Hebrew is ever used.)
>
> I've followed the suggestion and now it runs much faster. See my attached
patch.

Thanks,
Guy
From d6fe68cfbbb3e9cbd0fd9748ebb9b392dfc4bb96 Mon Sep 17 00:00:00 2001
From: Guy Rutenberg 
Date: Thu, 1 Nov 2018 19:23:17 +0200
Subject: [PATCH] Fix performance when fixing parentheses in Hebrew.

---
 lib/lyx2lyx/lyx2lyx_tools.py | 15 ---
 lib/lyx2lyx/lyx_2_4.py   | 10 ++
 2 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/lib/lyx2lyx/lyx2lyx_tools.py b/lib/lyx2lyx/lyx2lyx_tools.py
index 51412e5b31..73f7d78c10 100644
--- a/lib/lyx2lyx/lyx2lyx_tools.py
+++ b/lib/lyx2lyx/lyx2lyx_tools.py
@@ -83,9 +83,6 @@ insert_document_option(document, option):
 
 remove_document_option(document, option):
   Remove _option_ as a document option.
-
-get_language_for_line(document, i):
-  Return the language setting for line number i.
 '''
 
 import re
@@ -607,15 +604,3 @@ def is_document_option(document, option):
 return False
 
 return True
-
-
-def get_language_for_line(document, i):
-" Return the language for line number i"
-layout = get_containing_layout(document.body, i)
-if not layout:
-return document.language
-start_of_par = layout[3]
-for line in document.body[i:start_of_par:-1]:
-if line.startswith('\\lang '):
-return line[len('\\lang '):]
-return document.language
diff --git a/lib/lyx2lyx/lyx_2_4.py b/lib/lyx2lyx/lyx_2_4.py
index b6b626c316..670e31abfc 100644
--- a/lib/lyx2lyx/lyx_2_4.py
+++ b/lib/lyx2lyx/lyx_2_4.py
@@ -1383,11 +1383,13 @@ def revert_lformatinfo(document):
 
 def convert_hebrew_parentheses(document):
 " Don't reverse parentheses in Hebrew text"
+current_language = document.language
 for i, line in enumerate(document.body):
-if line.startswith(''):
-# not a text line, skip
-continue
-if get_language_for_line(document, i) == 'hebrew':
+if line.startswith('\\lang '):
+current_language = line[len('\\lang '):]
+elif line.startswith('\\end_layout'):
+current_language = document.language
+if current_language == 'hebrew' and not line.startswith('\\'):
 document.body[i] = line.replace('(','\x00').replace(')','(').replace('\x00',')')
 
 
-- 
2.11.0

Re: [LyX/master] Fix parentheses with Hebrew

[Guy Rutenberg]

On Thu, 1 Nov 2018 at 17:44, Jürgen Spitzmüller  wrote:

> Am Donnerstag, den 01.11.2018, 16:26 +0100 schrieb Kornel Benko:
> > This would not be better.
>
> I was not saying it is good. I was just saying it's not a loop.
>
>
After some profiling the main culprit is the call to get_containing_layout,
which is apparently some kind of O(n^2). For example for de/Tutorial.lyx
there are about ~5000 lines, and we indeed call during the conversion we
call get_containing_layout 5285 times. However, it calls find_end_of_layout
a whopping 80936 times.

Another small issue, if the usage of range under Python2 which also
contributes quite a bit to the performance hit.

Jürg
>

Re: [LyX/master] Fix parentheses with Hebrew

[Guy Rutenberg]

Hi,

It seems not to be an endless loop, but to simply take a *very* long time.
I'll look at what keeping it busy, and submit a patch.

Thanks,
Guy

On Thu, 1 Nov 2018 at 16:48, Kornel Benko  wrote:

> Am Dienstag, 30. Oktober 2018 12:34:47 CET schrieb Juergen Spitzmueller <
> sp...@lyx.org>:
> > commit 0ec295d63ef1ae59ab016214d4934585d351ccc4
> > Author: Juergen Spitzmueller 
> > Date:   Tue Oct 30 12:33:35 2018 +0100
> >
> > Fix parentheses with Hebrew
> >
> > Patch by Guy Rutenberg, with some changes of mine.
> >
> > Fixes: #11191
> > ---
> >  development/FORMAT   |6 
> >  lib/lyx2lyx/lyx2lyx_tools.py |   17 +++-
> >  lib/lyx2lyx/lyx_2_4.py   |   20 +-
> >  src/Paragraph.cpp|   61
> --
> >  src/TextMetrics.cpp  |   11 +---
> >  src/version.h|4 +-
> >  6 files changed, 73 insertions(+), 46 deletions(-)
>
> Not able to read doc/de/Additional.lyx after this commit.
> Endless loop in lyx2lyx.
>
> Kornel

LyX Trac forbids search engines?

[Guy Rutenberg]

Hi,

https://www.lyx.org/robots.txt disallows search engines from the trac. Is
this intentional? It makes finding tickets in the trac much harder.

Thanks,
Guy

Re: Parentheses keys are reversed in Hebrew

[Guy Rutenberg]

Hi,

I've created a patch to fix the handling of parentheses in Hebrew. It also
bumps up the format number and updates lyx2lyx accordingly.

The patch is attached. I've also added it to the #11191 ticket.

Thanks,
Guy

On Sat, 27 Oct 2018 at 13:03, José Abílio Matos  wrote:

> On Friday, 26 October 2018 20.58.11 WEST Richard Kimberly Heck wrote:
> > I suspect that a "get_language_for_line" routine could be useful
> > elsewhere, so feel free to add it to lyx2lyx_tools.py.
>
> True.
>
> It is needed also to revert the info insets. I have an half finished
> solution
> for that but I do not (honestly) expect to have time for that before Xmas.
>
> --
> José Abílio
>
>
>
From ba8b24887f870697369c171456f3bf234bc602e1 Mon Sep 17 00:00:00 2001
From: Guy Rutenberg 
Date: Sat, 27 Oct 2018 19:10:10 +0300
Subject: [PATCH] Fix parentheses handling for Hebrew.

Also updated lyx2lyx to seamlessly handle LyX 2.3 documents.
---
 lib/lyx2lyx/lyx2lyx_tools.py | 17 -
 lib/lyx2lyx/lyx_2_4.py   | 20 +++-
 src/Paragraph.cpp| 15 +++
 src/TextMetrics.cpp  |  6 --
 src/version.h|  4 ++--
 5 files changed, 40 insertions(+), 22 deletions(-)

diff --git a/lib/lyx2lyx/lyx2lyx_tools.py b/lib/lyx2lyx/lyx2lyx_tools.py
index cb1996ecb5..51412e5b31 100644
--- a/lib/lyx2lyx/lyx2lyx_tools.py
+++ b/lib/lyx2lyx/lyx2lyx_tools.py
@@ -83,10 +83,13 @@ insert_document_option(document, option):
 
 remove_document_option(document, option):
   Remove _option_ as a document option.
+
+get_language_for_line(document, i):
+  Return the language setting for line number i.
 '''
 
 import re
-from parser_tools import find_token, find_end_of_inset
+from parser_tools import find_token, find_end_of_inset, get_containing_layout
 from unicode_symbols import unicode_reps
 
 # This will accept either a list of lines or a single line.
@@ -604,3 +607,15 @@ def is_document_option(document, option):
 return False
 
 return True
+
+
+def get_language_for_line(document, i):
+" Return the language for line number i"
+layout = get_containing_layout(document.body, i)
+if not layout:
+return document.language
+start_of_par = layout[3]
+for line in document.body[i:start_of_par:-1]:
+if line.startswith('\\lang '):
+return line[len('\\lang '):]
+return document.language
diff --git a/lib/lyx2lyx/lyx_2_4.py b/lib/lyx2lyx/lyx_2_4.py
index 365ba6fc02..b6b626c316 100644
--- a/lib/lyx2lyx/lyx_2_4.py
+++ b/lib/lyx2lyx/lyx_2_4.py
@@ -36,7 +36,7 @@ from parser_tools import (count_pars_in_inset, find_end_of_inset, find_end_of_la
 #is_in_inset, set_bool_value
 #find_tokens, find_token_exact, check_token
 
-from lyx2lyx_tools import (put_cmd_in_ert, add_to_preamble)
+from lyx2lyx_tools import (put_cmd_in_ert, add_to_preamble, get_language_for_line)
 #  revert_font_attrs, insert_to_preamble, latex_length
 #  get_ert, lyx2latex, lyx2verbatim, length_in_bp, convert_info_insets
 #  revert_flex_inset, hex2ratio, str2bool
@@ -1381,6 +1381,22 @@ def revert_lformatinfo(document):
 i = i + 1
 
 
+def convert_hebrew_parentheses(document):
+" Don't reverse parentheses in Hebrew text"
+for i, line in enumerate(document.body):
+if line.startswith(''):
+# not a text line, skip
+continue
+if get_language_for_line(document, i) == 'hebrew':
+document.body[i] = line.replace('(','\x00').replace(')','(').replace('\x00',')')
+
+
+def revert_hebrew_parentheses(document):
+" Store parentheses in Hebrew text reversed"
+# This only exists to keep the convert/revert nameing convention
+convert_hebrew_parentheses(document)
+
+
 ##
 # Conversion hub
 #
@@ -1408,9 +1424,11 @@ convert = [
[563, []],
[564, []],
[565, [convert_AdobeFonts]], # Handle adobe fonts in GUI
+   [566, [convert_hebrew_parentheses]],
   ]
 
 revert =  [
+   [565, [revert_hebrew_parentheses]],
[564, [revert_AdobeFonts]],
[563, [revert_lformatinfo]],
[562, [revert_listpargs]],
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 96f95d721c..00aa6c0d05 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -2017,19 +2017,10 @@ char_type Paragraph::getUChar(BufferParams const & bparams,
 	// FIXME: The special casing for Hebrew parens is due to the special
 	// handling on input (for Hebrew in e5f42f67d/lyxgit); see #8251.
 	char_type uc = c;
-	if (rp.use_polyglossia) {
-		switch (c) {
-		case '(':
-			if (lang == "hebrew")
-uc = ')';
-			break;
-		case ')':
-			if (lang == "hebrew")
-uc = '(';
-			break;
-		}
+
+

Re: Parentheses keys are reversed in Hebrew

[Guy Rutenberg]

Hi,

I've started working on a patch. I removed the parentheses reversing code
in TextMetrics.cpp and in Paragraph.cpp. Now what remains to do is to
update the lyx2lyx script.

Just a quick question before I write the code:
1. Is there a simple way to iterate over all the text lines in
document.body?
2. Is there a simple way to get the current language for a line in
document.body?
I just want to avoid writing the same code twice if such logic already
exists.

Overall, it doesn't see to complicated to solve.
Thanks,
Guy

On Fri, 26 Oct 2018 at 10:37, Jürgen Spitzmüller  wrote:

> Am Montag, den 22.10.2018, 10:21 +0200 schrieb Jean-Marc Lasgouttes:
> >
> > Finally (this might be a question for Jürgen), is the handling of
> > Hebrew
> > still different from the handling of other RtL languages in this
> > respect?
>
> Yes.
>
> > It should not IMO.
>
> Definitely not. That's the point of the ticket I linked to earlier.
>
> Jürgen
>
> >
> > JMarc
>

Re: Parentheses keys are reversed in Hebrew

[Guy Rutenberg]

Hi,


On Mon, 22 Oct 2018 at 11:21, Jean-Marc Lasgouttes 
wrote:

>
> So is the conclusion that the LyX' hebrew keymap needs fixing?
>

Probably yes (because the handling of () and [] differ). However, my guess
is that there is some code that reversed Hebrew brackets upon insertion.
After that code is fixed to be consistent we would be able to know in if
and what the fix for the hebrew keymap is needed.

Regards,
Guy

Re: Parentheses keys are reversed in Hebrew

[Guy Rutenberg]

Hi,

I've made some more experiments (this time on the git version) and it seems
the behavior changes based on how hebrew is typed:
* If you are using the system's keyboard layout then () get reversed, and
[] {} <> are correct.
* If you are using lyx's hebrew keymap (and system's keyboard layout as
english) then () are correct and [],{} and <> are reversed.

In both cases, the display in lyx matches xelatex output (which is good).

Thanks,
Guy

On Mon, 22 Oct 2018 at 09:52, Guy Rutenberg  wrote:

> Hi,
> I'm re-sending my last message as it appears I accidentally didn't send it
> to the list. I've also added the lyx-devel, as it seems to be more
> appropriate.
>
> On Fri, 19 Oct 2018 at 17:22, Guy Rutenberg 
> wrote:
>
>> On Fri, 19 Oct 2018 at 11:05, Daniel  wrote:
>>
>>>
>>> However, this is with an English, German, etc. keyboard layout. This
>>> changes if I switch to the Hebrew keyboard layout. But then the Hebrew
>>> keyboard layout seems to have parenthesis switched relative to the
>>> English:
>>>
>>
>> I'm referring to the case of using Hebrew keyboard layout.
>>
>>>
>>>
>>> https://en.wikipedia.org/wiki/Hebrew_keyboard#/media/File:Hebrew_keyboard_layout.png
>>>
>>>
>> I don't know how made that diagram, but I'm pretty sure that he didn't
>> use an actual Hebrew keyboard. I have around seven different keyboards
>> around me right now from different manufacturers, non have this weird
>> things with reversed parenthesis. Even the actual keyboard photo in the
>> Wiki article shows the parenthesis to be normal and not reversed as in the
>> diagram.
>>
>>
>>> So, if you are using a Hebrew keyboard layout, then LyX seems to behave
>>> correctly. But in that case I am wondering why other applications don't
>>> behave that way for you.
>>
>>
>> Because LyX behavior is unexpected to the normal user.
>>
>> On Fri, 19 Oct 2018 at 13:11, Jürgen Spitzmüller  wrote:
>>
>>>
>>>
>>> Please comment here:
>>> https://www.lyx.org/trac/ticket/11191
>>>
>>> We generally need to audit LyX's behavior with bracket/parens input in
>>> RTL, but we urgently need input from experienced users.
>>>
>>>
>> I've added a new comment there as well. I'll gladly help to fix this
>> issue if someone can point me in the right direction.
>>
>
>
> I've looked again at the bug and the patch linked there. It seems that the
> code handling parenthesis had been moved to somewhere else. Where does it
> resides now? I want to try and patch it so it won't reverse parenthesis in
> hebrew.
>
> Thanks,
> Guy
>

Re: Parentheses keys are reversed in Hebrew

[Guy Rutenberg]

Hi,
I'm re-sending my last message as it appears I accidentally didn't send it
to the list. I've also added the lyx-devel, as it seems to be more
appropriate.

On Fri, 19 Oct 2018 at 17:22, Guy Rutenberg  wrote:

> On Fri, 19 Oct 2018 at 11:05, Daniel  wrote:
>
>>
>> However, this is with an English, German, etc. keyboard layout. This
>> changes if I switch to the Hebrew keyboard layout. But then the Hebrew
>> keyboard layout seems to have parenthesis switched relative to the
>> English:
>>
>
> I'm referring to the case of using Hebrew keyboard layout.
>
>>
>>
>> https://en.wikipedia.org/wiki/Hebrew_keyboard#/media/File:Hebrew_keyboard_layout.png
>>
>>
> I don't know how made that diagram, but I'm pretty sure that he didn't use
> an actual Hebrew keyboard. I have around seven different keyboards around
> me right now from different manufacturers, non have this weird things with
> reversed parenthesis. Even the actual keyboard photo in the Wiki article
> shows the parenthesis to be normal and not reversed as in the diagram.
>
>
>> So, if you are using a Hebrew keyboard layout, then LyX seems to behave
>> correctly. But in that case I am wondering why other applications don't
>> behave that way for you.
>
>
> Because LyX behavior is unexpected to the normal user.
>
> On Fri, 19 Oct 2018 at 13:11, Jürgen Spitzmüller  wrote:
>
>>
>>
>> Please comment here:
>> https://www.lyx.org/trac/ticket/11191
>>
>> We generally need to audit LyX's behavior with bracket/parens input in
>> RTL, but we urgently need input from experienced users.
>>
>>
> I've added a new comment there as well. I'll gladly help to fix this issue
> if someone can point me in the right direction.
>


I've looked again at the bug and the patch linked there. It seems that the
code handling parenthesis had been moved to somewhere else. Where does it
resides now? I want to try and patch it so it won't reverse parenthesis in
hebrew.

Thanks,
Guy

Re: LyX and (ancient) Hebrew

[Guy Rutenberg]

Hi,

On 3 December 2016 at 23:51, Scott Kostyshak  wrote:

> >
> > If I may offer some suggestions... I am not a programmer who can
> implement
> > this, but I use Hebrew in LyX quite often, including ancient Hebrew with
> > everything on it. Xetex is the only one, in my experience, that is really
> > working.
>
> Good to know. I wonder if we should set our Hebrew manuals to XeTeX by
> default.


XeTeX is by far the best option today to typeset Hebrew and LyX should
default to it. Culmus-latex and ivritex (the old ways to get Hebrew
working) are no longer actively maintained as they are inferior in almost
any sense.

A while a go I wrote a simple tutorial to get an Hebrew document working
using LyX and XeTeX.

https://www.guyrutenberg.com/2015/03/21/creating-a-hebrew-document-in-lyx-2-1-with-xetex/

Regards,
Guy

Re: Our \LyX{} inset breaks compilation in Hebrew (but \LaTeX{} does not)

[Guy Rutenberg]

On 2 September 2016 at 14:04, Jürgen Spitzmüller  wrote:

> Am Freitag, den 02.09.2016, 10:32 + schrieb Guenter Milde:
> > Like LaTeX, LyX is an English name. Wrapping in "language English"
> > seems the correct way to handle it.
>
> No. Brand names such as "LyX", "LaTeX" or "Pepsi" are not English (as
> less as they are German, French etc.). These are internationally used
> names (sometimes called "econyms" in linguistics) that happen to use
> latin script, but are language-abstract.
>

I believe that most people writing in Hebrew will consider LyX and LaTeX as
English, even if technically that's incorrect. If there is a simple way to
mark a given text as latin script and language-agnositc, it's probably the
best, otherwise, English is as far as I can see a safe bet. I can't think
of any real side effects it will cause.


>
>
> >
> > There is more than just the direction:
> >
> > - It uses the Latin script.
>
> Doesn't \L assure that?
>

The \L macro as defined in babel also changes the language.

Regards,
Guy

Re: Our \LyX{} inset breaks compilation in Hebrew (but \LaTeX{} does not)

[Guy Rutenberg]

Hi,

Both \lyx and \latex macros should be marked as English insets when part of
Hebrew text. Otherwise they will be rendered reversed, just as Scott
mentioned.

Regards,
Guy

On 29 Aug 2016 23:22, "Guenter Milde"  wrote:

> On 2016-08-29, Jean-Marc Lasgouttes wrote:
> > Le 29/08/2016 à 01:39, Scott Kostyshak a écrit :
> >> Our compilation of the Hebrew splash file fails with "Missing glyphs!"
> >> errors. Indeed, if you look at the output, the LyX inset outputs are
> >> missing. Interestingly, the \LaTeX{} commands work fine (i.e. do not
> >> cause an error), and result in R-to-L output (XeTaL).
>
> > I cannot double check that since the (your?) instructions for installing
> > Hebrew support in  Ubuntu are so scary. I am not going to overwrite my
> > texlive installation juste for that.
>
> >> Are our \LyX{} commands supposed to work in this context?
>
> > We never wondered about that. What are the packages used in hebrew? Do
> > they contain a special definition for \LaTeX? If so, we should do the
> same.
>
> For Greek with 8-bit fonts, such macros must be wrapped in \textlatin (or
> set to a Latin-using language) due to the Greek fonts missing latin
> letters.
> (\textlatin is defined by Babel.)
>
> This may be similar for hebrew.
>
> Günter
>
>

Bug in math macro preview

[Guy Rutenberg]

Hi,

I've encounter a minor bug in the previewing of math macro: That is, after
you create a math macro it would normally exapand the macro in normal math
mode to the LyX representation of the macro. However, if the macro name is
a single digit (e.g. \1) LyX wouldn't preview the macro. Apart form that,
the document will compile fine.

My guess this bug originates from TeX allowing letter-strings for macro
names, however it also allows single non-letter characters.

The command must begin with an escape character (category code
> 
>  0)
> and be composed of a series of letters (category code
> 
>  11)
> or one single non-letter, following the escape character.
>
(https://en.wikibooks.org/wiki/TeX/def).

If someone could point me in the right direction in the source, I'll
happily attempt to fix it myself.

Thanks.

Guy

Re: [PATCH] lyxpak.py: Use `subprocess` for spawning scripts.

[Guy Rutenberg]

Hi,

On Thu, Jul 16, 2015 at 12:16 AM, Guy Rutenberg 
wrote:

> Hi,
>
> On Mon, Jul 13, 2015 at 1:43 PM, Enrico Forestieri  wrote:
>
>> So, Guy, you can drop support for python 2.6. I also see that there would
>> be another enhancement, if you would like to have a stab at it. When
>> calling
>> lyx2lyx, the script uses "python" to invoke the interpreter, such that the
>> first python found in the PATH would be used. As it could be a wrong
>> version,
>> we can replace "python" with the path to the current interpreter, which
>> surely is the right version. This may seem superfluous when the scripts
>> will
>> work with either python 2.7 or 3.x, but in the mean time it would help.
>>
>
> Sure, I'll submit a new patch being compatible with Python 2.7 and above.
> I'll also fix the python PATH issue. The new patches will probably take me
> a few days as I'm away from my computer.
>
>
>
I've attached an updated patch. It is compatible with python >= 2.7, and
also includes invokes the correct python interpreter for lyx2lyx as
suggested.

Thanks,

Guy
From 726071892f1a960a149399ec79bd7e61b1ce83e1 Mon Sep 17 00:00:00 2001
From: Guy Rutenberg 
Date: Sat, 11 Jul 2015 18:52:14 +0300
Subject: [PATCH] lyxpak.py: Use `subprocess` for spawning scripts.

`os.popen` is deprecated since Python-2.6. Also, this fixes the handling
of files with quotes in their names. The patch requires Python >= 2.7.

Furthermore, the patch executes the lyx2lyx script with the same
interpreter used for it, to maintain compatibility.

I also removed some lines related to Python-2.4, as it is no longer
supported anyway.
---
 lib/scripts/lyxpak.py |   34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/lib/scripts/lyxpak.py b/lib/scripts/lyxpak.py
index 9a56bf0..bf66c70 100755
--- a/lib/scripts/lyxpak.py
+++ b/lib/scripts/lyxpak.py
@@ -16,10 +16,13 @@
 # line options, however.
 
 import gzip, os, re, string, sys
-if sys.version_info < (2, 4, 0):
-from sets import Set as set
 from getopt import getopt
 from cStringIO import StringIO
+import subprocess
+
+# The path to the current python executable. sys.executable may fail, so in
+# this case we revert to simply calling "python" from the path.
+PYTHON_BIN = sys.executable if sys.executable else "python"
 
 running_on_windows = (os.name == 'nt')
 
@@ -69,13 +72,6 @@ def gzopen(file, mode):
 return open(unicode(file, 'utf-8'), mode)
 
 
-def run_cmd(cmd):
-handle = os.popen(cmd, 'r')
-cmd_stdout = handle.read()
-cmd_status = handle.close()
-return cmd_status, cmd_stdout
-
-
 def find_exe(candidates, extlist, path):
 for prog in candidates:
 for directory in path:
@@ -98,6 +94,7 @@ def gather_files(curfile, incfiles, lyx2lyx):
 " Recursively gather files."
 curdir = os.path.dirname(abspath(curfile))
 is_lyxfile = re_lyxfile.search(curfile)
+
 if is_lyxfile:
 if running_on_windows:
 # os.popen cannot cope with unicode arguments and we cannot be
@@ -106,14 +103,16 @@ def gather_files(curfile, incfiles, lyx2lyx):
 tmp = NamedTemporaryFile(delete=False)
 tmp.close()
 copyfile(unicode(curfile, 'utf-8'), tmp.name)
-lyx2lyx_cmd = 'python "%s" "%s"' % (lyx2lyx, tmp.name)
-l2l_status, l2l_stdout = run_cmd(lyx2lyx_cmd)
+try:
+l2l_stdout = subprocess.check_output([PYTHON_BIN, lyx2lyx, tmp.name])
+except subprocess.CalledProcessError:
+error('%s failed to convert "%s"' % (lyx2lyx, curfile))
 os.unlink(tmp.name)
 else:
-lyx2lyx_cmd = 'python "%s" "%s"' % (lyx2lyx, curfile)
-l2l_status, l2l_stdout = run_cmd(lyx2lyx_cmd)
-if l2l_status != None:
-error('%s failed to convert "%s"' % (lyx2lyx, curfile))
+try:
+l2l_stdout = subprocess.check_output([PYTHON_BIN, lyx2lyx, curfile])
+except subprocess.CalledProcessError:
+error('%s failed to convert "%s"' % (lyx2lyx, curfile))
 if l2l_stdout.startswith("\x1f\x8b"):
 l2l_stdout = gzip.GzipFile("", "r", 0, StringIO(l2l_stdout)).read()
 lines = l2l_stdout.splitlines()
@@ -222,8 +221,9 @@ def find_lyx2lyx(progloc, path):
 lyx_exe, full_path = find_exe(["lyxc", "lyx"], extlist, path)
 if lyx_exe == None:
 error('Cannot find the LyX executable in the path.')
-cmd_status, cmd_stdout = run_cmd("%s -version 2>&1" % lyx_exe)
-if cmd_status != None:
+try:
+cmd_stdout = subprocess.check_output([lyx_exe, '-version'], stderr=subprocess.STDOUT)
+except subprocess.CalledProcessError:
 error('Cannot query LyX about the lyx2lyx script.')
 re_msvc = re.compile(r'^(\s*)(Host type:)(\s+)(win32)$')
 re_sysdir = re.compile(r'^(\s*)(LyX files dir:)(\s+)(\S+)$')
-- 
1.7.9.5

Re: [PATCH] lyxpak.py: Use `subprocess` for spawning scripts.

[Guy Rutenberg]

Hi,

On Mon, Jul 13, 2015 at 1:43 PM, Enrico Forestieri  wrote:

> So, Guy, you can drop support for python 2.6. I also see that there would
> be another enhancement, if you would like to have a stab at it. When
> calling
> lyx2lyx, the script uses "python" to invoke the interpreter, such that the
> first python found in the PATH would be used. As it could be a wrong
> version,
> we can replace "python" with the path to the current interpreter, which
> surely is the right version. This may seem superfluous when the scripts
> will
> work with either python 2.7 or 3.x, but in the mean time it would help.
>

Sure, I'll submit a new patch being compatible with Python 2.7 and above.
I'll also fix the python PATH issue. The new patches will probably take me
a few days as I'm away from my computer.

Thanks,

Guy

[PATCH] lyxpak.py: Use `subprocess` for spawning scripts.

[Guy Rutenberg]

Hi,

The lyxpak.py uses `os.popen`, which is deprecated since Python-2.6.
Furthermore, it causes the script to fail for files with quotes in their
name, e.g., quote"quote.lyx. The attached patch fixes this issue by
switching to use the module subprocess.

I made sure that it is compatible with Python-2.6, as the "Additional
Software" page on the LyX site lists this as the minimal supported version.
If support for 2.6 is not really needed, the patch could be simpler.

Thanks,

Guy
From 77525e65d15419b06abe4299f601250a6b5965a8 Mon Sep 17 00:00:00 2001
From: Guy Rutenberg 
Date: Sat, 11 Jul 2015 18:52:14 +0300
Subject: [PATCH] lyxpak.py: Use `subprocess` for spawning scripts.

`os.popen` is deprecated since Python-2.6. Also, this fixes the handling
of files with quotes in their names. The patch maintains compatability
with Python-2.6 by including its own version of `check_output` if it
isn't available from `subprocess`.
---
 lib/scripts/lyxpak.py |   65 ++---
 1 file changed, 51 insertions(+), 14 deletions(-)

diff --git a/lib/scripts/lyxpak.py b/lib/scripts/lyxpak.py
index 9a56bf0..76875d3 100755
--- a/lib/scripts/lyxpak.py
+++ b/lib/scripts/lyxpak.py
@@ -20,6 +20,46 @@ if sys.version_info < (2, 4, 0):
 from sets import Set as set
 from getopt import getopt
 from cStringIO import StringIO
+import subprocess
+
+
+
+# Copied almost verbatim from Python 2.7 sources, the `output` keyword argument
+# for CalledPRocessError was removed because it doesn't exists in Python 2.6
+def check_output_backport(*popenargs, **kwargs):
+r"""Run command with arguments and return its output as a byte string.
+
+If the exit code was non-zero it raises a CalledProcessError.  The
+CalledProcessError object will have the return code in the returncode
+attribute and output in the output attribute.
+
+The arguments are the same as for the Popen constructor.  Example:
+
+>>> check_output(["ls", "-l", "/dev/null"])
+'crw-rw-rw- 1 root root 1, 3 Oct 18  2007 /dev/null\n'
+
+The stdout argument is not allowed as it is used internally.
+To capture standard error in the result, use stderr=STDOUT.
+
+>>> check_output(["/bin/sh", "-c",
+...   "ls -l non_existent_file ; exit 0"],
+...  stderr=STDOUT)
+'ls: non_existent_file: No such file or directory\n'
+"""
+if 'stdout' in kwargs:
+raise ValueError('stdout argument not allowed, it will be overridden.')
+process = subprocess.Popen(stdout=subprocess.PIPE, *popenargs, **kwargs)
+output, unused_err = process.communicate()
+retcode = process.poll()
+if retcode:
+cmd = kwargs.get("args")
+if cmd is None:
+cmd = popenargs[0]
+raise subprocess.CalledProcessError(retcode, cmd)
+return output
+# If we use a recent version of Python (>=2.7) use the library's check_output,
+# otherwise use the backported one
+check_output = getattr(subprocess, 'check_output', check_output_backport)
 
 running_on_windows = (os.name == 'nt')
 
@@ -69,13 +109,6 @@ def gzopen(file, mode):
 return open(unicode(file, 'utf-8'), mode)
 
 
-def run_cmd(cmd):
-handle = os.popen(cmd, 'r')
-cmd_stdout = handle.read()
-cmd_status = handle.close()
-return cmd_status, cmd_stdout
-
-
 def find_exe(candidates, extlist, path):
 for prog in candidates:
 for directory in path:
@@ -107,13 +140,16 @@ def gather_files(curfile, incfiles, lyx2lyx):
 tmp.close()
 copyfile(unicode(curfile, 'utf-8'), tmp.name)
 lyx2lyx_cmd = 'python "%s" "%s"' % (lyx2lyx, tmp.name)
-l2l_status, l2l_stdout = run_cmd(lyx2lyx_cmd)
+try:
+l2l_stdout = check_output(['python', lyx2lyx, tmp.name])
+except subprocess.CalledProcessError:
+error('%s failed to convert "%s"' % (lyx2lyx, curfile))
 os.unlink(tmp.name)
 else:
-lyx2lyx_cmd = 'python "%s" "%s"' % (lyx2lyx, curfile)
-l2l_status, l2l_stdout = run_cmd(lyx2lyx_cmd)
-if l2l_status != None:
-error('%s failed to convert "%s"' % (lyx2lyx, curfile))
+try:
+l2l_stdout = check_output(['python', lyx2lyx, curfile])
+except subprocess.CalledProcessError:
+error('%s failed to convert "%s"' % (lyx2lyx, curfile))
 if l2l_stdout.startswith("\x1f\x8b"):
 l2l_stdout = gzip.GzipFile("", "r", 0, StringIO(l2l_stdout)).read()
 lines = l2l_stdout.splitli

Re: Need RtL user wisdom (was: Re: logical cursor movement)

[Guy Rutenberg]

Hi,


On Sun, Jul 5, 2015 at 9:57 PM, Lior Silberman  wrote:

> Tested with LyX 2.1.3 (so with my own file, not the attachment) and
> got the expected result.  "Visual" cursor movement means left and
> right arrow keys always move the cursor left and right.  The "logical"
> behaviour is as follows:
> ...
>
>
What Lior describes is indeed "expected" behaviour for "logical" cursor
movement.


On Sun, Jul 5, 2015 at 7:35 PM, Jean-Marc Lasgouttes 
wrote:

>
> I agree with you, but the code in Text3.cpp has always been like that (see
> 11a6b3c4c). Does it mean that logical cursor movement is not supposed to be
> logical or nobody uses it?
>
>
While it may be confusing, logical cursor movement is the common behaviour
most people expect (at least Hebrew speaking, I'm not sure about Arabic but
we it was discussed in the mailing-list before). I guess it may require
sometime to get used to if you are not familiar with the
directionality-hell that comes along with using a RTL language in a LTR
environment :-)


Regards,

Guy

Re: [Patch] Two lyxpak bugs

[Guy Rutenberg]

Hi,

On Fri, Jul 3, 2015 at 3:53 PM, Enrico Forestieri  wrote:

> Your patch still does not work on Windows. It may work when files have
> names encodable in the current code page, otherwise it fails.
> Note that NTFS uses UTF-16 even if python returns "msbc" as the filesystem
> encoding. Instead, the attached patch works for me on any platform I have
> access to. I think it also solves your problem even if in a different way.
>

This works great on Linux.

Thanks,

Guy

Re: [Patch] Two lyxpak bugs

[Guy Rutenberg]

Hi Enrico,

Thanks for your feed back.

Sorry, but I cannot reproduce this problem. The file names are already
> utf-8 encoded as they are extracted form the LyX file and the created
> zip file seems to be OK. I attach here an example zip file created with
> lyxpak.py (it is inside a tar archive to avoid problems with mail agents).
> Although when listed the file names in the zip file may appear as mangled,
> they are actually extracted just fine:
>

I indeed found bugs in the patch I submitted, but for some reason the mail
I sent to the mailing list seems like it wasn't delivered (I hope this one
gets through).

There was a problem in the old patch with handling filesystems where  the
filesystem's encoding is not UTF-8.The problem occurs because in the .lyx
file, the filenames are stored as UTF-8, while the filesystem may use a
different one. For example, Windows uses "mbsc". The attached modified
patch addresses these issues. Also by using the "arcname" argument, the zip
file it produces list the files correctly.

For example, file listing without the patch

Path = בדיקה.zip
Type = zip
Physical Size = 966

   Date  TimeAttr Size   Compressed  Name
--- -  

2015-07-01 21:59:40 . 1634  738  §×.lyx
2015-07-01 21:59:04 .02  ק×××¥.tex
--- -  

  1634  740  2 files, 0 folders

And with the patch

Path = בדיקה.zip
Type = zip
Physical Size = 966

   Date  TimeAttr Size   Compressed  Name
--- -  

2015-07-01 21:59:40 . 1634  738  בדיקה.lyx
2015-07-01 21:59:04 .02  קובץ.tex
--- -  

  1634  740  2 files, 0 folders


The proposed patch should also work with non UTF-8 filesystems (I did
limited testing on a windows 7 machine).

Regarding the first patch.

In your patch you unconditionally strip the last path component, which is
> wrong. Although the case you describe is rare, it may nonetheless happen,
> but the attached 01 patch should suffice. Please, report back whether it
> works for you.
>

The proposed change still fails when the last prefix bit is a valid
directory.

For example consider the following layout

lyx_file.lyx
lyx_included.tex
lyx_/

Where lyx_file.lyx includes lyx_included.tex. The common prefix will be
"lyx_", which is a valid directory, hence the proposed check in your patch
pass, but afterwords, it won't be able to locate the files.

My patch indeed strips the last path component, but I'm pretty sure that
the part that gets removed in never the common parent directory. For
example consider the following cases

some_dir/lyx_file.lyx
some_dir/lyx_included.lyx

The common prefix will be "some_dir/lyx_". The "lyx_" part will indeed be
removed, and the result will be "some_dir/", like it should.

some_dir/lyx_file.lyx
some_dir/tex_file.lyx

The common prefix will be "some_dir/" and because the "/" is part of the
common prefix, "some_dir/" will also be the result of the truncation and
the appending of os.path.sep.

Furthermore, consider the following edge case where the common prefix is
"/". We have
In [6]: os.path.dirname('/') + os.path.sep
Out[6]: '//'

In [7]: "/".rpartition(os.path.sep)[0] + os.path.sep
Out[7]: '/'

This shows that the original lyxpak.py (and I believe your patch as well)
will get topdir to be "//" instead of "/", which means that the string
replacement in

while i < len(incfiles):
incfiles[i] = string.replace(incfiles[i], topdir, '', 1)
i += 1

will fail.

Enrico, did you find a use case where my patch results in the wrong
behaviour? I might be missing some edge-case myself which I be happy to fix.

Thanks a lot for your guidance and remarks.

Regards,

Guy
From 249d30e46b24b92b8e5823e72f8322539620c780 Mon Sep 17 00:00:00 2001
From: Guy Rutenberg 
Date: Fri, 26 Jun 2015 19:54:34 +0300
Subject: [PATCH] lyxpak: Fix filename encoding in zip export.

By default Python's zipfile module stores files in the CP437 encoding.
This can create unreadable filenames on some systems. However, if one
passes `arcname` as a unicode object, a utf-8 representation of the
filename is kept.

Moreover, LyX's internal filename representation is UTF-8, which may
differ from the filesystem's encoding. This may lead to problems
including files which have foreign characters in their names. The patch
fixes this issue.
---
 lib/scripts/lyxpak.py |   17 ++

Re: [Patch] Two lyxpak bugs

[Guy Rutenberg]

The second patch doesn't work in windows properly. I'll submit a fixed one.
On Jun 26, 2015 11:57 PM, "Enrico Forestieri"  wrote:

> On Fri, Jun 26, 2015 at 08:13:05PM +0300, Guy Rutenberg wrote:
>
> > Hi,
> >
> > I've attached patches for two bugs I've encountered in the lyxpak script:
> >
> > The first bug is related to how the common path prefix for the included
> > files is calculated. If the common string prefix (the byte-by-byte
> prefix)
> > of the included files is also a file, the script would get the wrong
> > path-prefix and fail. The first patch fixes this issue.
> >
> > The second bug is related to handling non-ascii filenames when exporting
> to
> > zip file. Zip files created by Python's zipfile module by default store
> > filenames as 8-bit cp-437 encoding. This is problematic when filenames
> use
> > characters from any other encdoing. To solve this issue I explicitly
> pass a
> > unicode object as 'arcname' which causes the zipfile module to store the
> > file as utf-8 and set the approperiate flag bits for the file in the
> > archive.
> >
> > I've tested both patches in Linux, but I guess some testing on Windows is
> > needed as well. There is one point which I expect trouble with is in the
> > conversion to the unicode object. The lyx file itself is utf-8 so the
> > conversion to unicode is straight-forward for any filename extracted from
> > it. But the filename of the lyxfile is in the file-system encoding, which
> > might differ, hence causing problems.
>
> Thanks, I'll have a look.
>
> --
> Enrico
>

[Patch] Two lyxpak bugs

[Guy Rutenberg]

Hi,

I've attached patches for two bugs I've encountered in the lyxpak script:

The first bug is related to how the common path prefix for the included
files is calculated. If the common string prefix (the byte-by-byte prefix)
of the included files is also a file, the script would get the wrong
path-prefix and fail. The first patch fixes this issue.

The second bug is related to handling non-ascii filenames when exporting to
zip file. Zip files created by Python's zipfile module by default store
filenames as 8-bit cp-437 encoding. This is problematic when filenames use
characters from any other encdoing. To solve this issue I explicitly pass a
unicode object as 'arcname' which causes the zipfile module to store the
file as utf-8 and set the approperiate flag bits for the file in the
archive.

I've tested both patches in Linux, but I guess some testing on Windows is
needed as well. There is one point which I expect trouble with is in the
conversion to the unicode object. The lyx file itself is utf-8 so the
conversion to unicode is straight-forward for any filename extracted from
it. But the filename of the lyxfile is in the file-system encoding, which
might differ, hence causing problems.

Thanks,

Guy
From c55fc9512a06bd107dfe21ec465235c891b49429 Mon Sep 17 00:00:00 2001
From: Guy Rutenberg 
Date: Fri, 26 Jun 2015 18:35:52 +0300
Subject: [PATCH 1/2] lyxpak: Fix the common path prefix calculation.

The old implementation could fail in some rare cases.
---
 lib/scripts/lyxpak.py |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/lib/scripts/lyxpak.py b/lib/scripts/lyxpak.py
index 9d5add1..cc1bdfd 100755
--- a/lib/scripts/lyxpak.py
+++ b/lib/scripts/lyxpak.py
@@ -298,10 +298,9 @@ def main(args):
 # Find the topmost dir common to all files
 if len(incfiles) > 1:
 topdir = os.path.commonprefix(incfiles)
-# Check whether topdir is valid, as os.path.commonprefix() works on
-# a character by character basis, rather than on path elements.
-if not os.path.exists(topdir):
-topdir = os.path.dirname(topdir) + os.path.sep
+# As os.path.commonprefix() works on a character by character basis,
+# rather than on path elements, we need to remove any trailing bytes.
+topdir = topdir.rpartition(os.path.sep)[0] + os.path.sep
 else:
 topdir = os.path.dirname(incfiles[0]) + os.path.sep
 
-- 
1.7.9.5

From 7662f1263350edd894dc3cedfd3358cefda2ee92 Mon Sep 17 00:00:00 2001
From: Guy Rutenberg 
Date: Fri, 26 Jun 2015 19:54:34 +0300
Subject: [PATCH 2/2] lyxpak: Fix filename encoding in zip export.

By default Python's zipfile module stores files in the CP437 encoding.
This can create unreadable filenames on some systems. However, if one
passes `arcname` as a unicode object, a utf-8 representation of the
filename is kept.
---
 lib/scripts/lyxpak.py |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/scripts/lyxpak.py b/lib/scripts/lyxpak.py
index cc1bdfd..8227ba1 100755
--- a/lib/scripts/lyxpak.py
+++ b/lib/scripts/lyxpak.py
@@ -322,7 +322,10 @@ def main(args):
 if makezip:
 zip = zipfile.ZipFile(ar_name, "w", zipfile.ZIP_DEFLATED)
 for file in incfiles:
-zip.write(file)
+# Passing unicode object as `arcname` ensures that the files
+# are stored as utf-8 in the zip, preserving non-ascii
+# characters properly
+zip.write(file, unicode(file, 'utf-8'))
 zip.close()
 else:
 tar = tarfile.open(ar_name, "w:gz")
-- 
1.7.9.5

Hebrew Translation

[Guy Rutenberg]

Hi All,

I've made some update to the Hebrew translation of LyX (in the 2.2dev
branch) and translated ~500 strings.

Whats the preferable way to submit the changes (patch? whole .po file?) and
to whom?

Thanks,

Guy

Adding new builtin math macros

[Guy Rutenberg]

Hi,

Suppose I want to add to LyX new built-in math macros, like \pmod. Which
files do I need to modify?

(To clarify, I want to change the sources not my specific document).

Thanks,

Guy

Re: Call for testers: the features/str-metrics branch

[Guy Rutenberg]

Hi,


On 12 May 2014 00:31, Guy Rutenberg  wrote:

> I did some initial testing and came up with the following wrong behavior:
>

I actually found a more serious bug. When in RTL mode (`language hebrew`)
if one types a single continuous line without any spaces, LyX simply hangs
when it reaches the end-of-line. If there are spaces it breaks the line
correctly. I've checked it on Linux, can others reproduce the bug as well?

Regards,

Guy

Re: Call for testers: the features/str-metrics branch

[Guy Rutenberg]

Hi,

On 30 April 2014 19:36, Jean-Marc Lasgouttes  wrote:

> One new feature of the branch is that all the hand-made handling of Hebrew
> and Arabic characters is now unused. This is good news for Urdu or other
> scripts.
>
> If you do not try it out now, the risk is that you'll discover issues when
> it lands on master :)
>

I did some initial testing and came up with the following wrong behavior:
When in RTL mode (i.e. settng the document language to hebrew) and typing
some narrow characters such as ו (vav) or even the English `i` slightly
moves the right margin to the left. By typing consecutive "narrow"
characters this movement is significant.

Typing wide characters has the opposite effect: The margin moves to the
right.

I've attached a screenshot. All the lines should be aligned the same,
however different character width shift the margin differently (there
should be no shift at all).

Regards,

Guy

Re: Systemcall::startscript() Arguments

[Guy Rutenberg]

Hi,

On 18 July 2013 02:17, Pavel Sanda  wrote:
>
> The usual way is that you send patches to the list and if there is agreement
> they are fine someone commits for you.


I trying to describe my proposed changes before actually writing them,
as that would take much longer. If there is an agreement on the kind
of changes needed, aproving the patches is easier and it's less likely
that I'll work on patches which will not be accepted.

> I also suggest that you CC Enrico (doing it right now), his is mastering
> this QProcess area and I'm not sure how much he is around the list nowadays.

Great, I'll wait for his opinion before starting to actually work on it.

Thanks,

Guy

Re: Systemcall::startscript() Arguments

[Guy Rutenberg]

Hi,

On 6 July 2013 15:04, Stephan Witt  wrote:

> IMHO, the current state is a result of using system() call at first
> because of platform independency and it is never moved to the execv()
> style later because using QProcess is an option only.
>

Now that I'm more familiar with that code, I think I can tackle it and
convert all calls to execv style with explicit stdin/stdout/stderr. To
support compilation without QProcess, I suggest taking the execv style
parameters (together with file names) and constructing a system() call with
proper quotation. Such refactoring should result in a cleaner code, and be
better security-wise as the task of proper quotation would be handled in a
single location.

What do you think about the suggest change?

BTW why can't we deprecate building without QProcess?

Also, being kind of new to lyx-devel, what's the preferred way to submit
such changes? As I'll probably have a local branch with a couple commits
for it, I can submit a series of patches, or I can put a copy of my git rep
online and submit a pull-request.

Regards,

Guy

Re: [PATCH] Strange Behaivor: xdg-open left as zombie

[Guy Rutenberg]

Hi Richard,

On 12 July 2013 17:52, Richard Heck  wrote:

> I'm not sure we absolutely need it, Guy, but can you send a note to devel
> saying something like: I hereby license my contributions to LyX under the
> General Public License, version 2 or any later version? Then I'll commit.


No problem.

I hereby license my contributions to LyX under the General Public License,
version 2 or any later version.

Regards,

Guy

Re: [PATCH] Strange Behaivor: xdg-open left as zombie

[Guy Rutenberg]

Hi,

On 5 July 2013 10:54, Scott Kostyshak  wrote:

>
> I think that the part that actually runs system commands is in:
> src/support/Systemcall.cpp


I've created a patch to fix it. Stats:

 src/support/Systemcall.cpp  |   26 --
 src/support/SystemcallPrivate.h |2 +-
 2 files changed, 17 insertions(+), 11 deletions(-)

Basically, what I did was to add a new parameter to
SystemcallPrivate::startProcess() to tell if we should detach. If so, I'm
calling QProcess::startDetached instead of QProcess::start().

Regards,

Guy


fix_zombies.patch
Description: Binary data

Systemcall::startscript() Arguments

[Guy Rutenberg]

Hi,

I'm going over the code of Systemcall::startscript() and I wonder why the
developers opted out to pass spaces separated arguments instead of a list
of arguments (e.g. system() vs execv() argument passing)?

QProcess seems to support both ways to pass arguments, but passing
arguments explicitly (instead of as part of the command itself) seems to me
more reasonable and safe (less prune to bugs when doing improper quotation
of spaces etc.)

I would be glad if someone could spare sometime and explain to me why
things work as they do.


Thanks,

Guy

Re: Strange Behaivor: xdg-open left as zombie

[Guy Rutenberg]

Hi,

I'm bringing up this topic from the past :-). I've rechecked the issue,
with the latest sources from the git, and I can see that it leaves out
zombie process after each time one compiles the document (Ctrl+R). The git
version leaves out "evince" zombie process, so this isn't caused by an
Ubuntu/Debian related patch (I've also went over their patches to make sure
they don't have anything that might cause this).

Can someone point me to the relevant code for executing the different
viewers? I want to try to patch myself, but being pointed at the right
direction can be helpful.

(As this is an old topic, I'm linking to the original thread:
http://thread.gmane.org/gmane.editors.lyx.general/77664)

Thanks,

Guy


On 6 January 2013 21:39, Guy Rutenberg  wrote:

> Hi,
>
> On 5 January 2013 22:02, Richard Heck  wrote:
>
>> This should be reported to the Ubuntu people. They include a patch that
>> uses xdg-open for this kind of purpose. The LyX sources do not include that
>> patch, for other reasons.
>>
>>
> I've reported the bug in
> https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/109
>
> Ubuntu users: If you're using Ubuntu and can confirm it affects you,
> please indicate it that bug report.
>
> Thanks,
>
> Guy
>

Re: Strange Behaivor: xdg-open left as zombie

[Guy Rutenberg]

Hi,

On 5 January 2013 22:02, Richard Heck  wrote:

> This should be reported to the Ubuntu people. They include a patch that
> uses xdg-open for this kind of purpose. The LyX sources do not include that
> patch, for other reasons.
>
>
I've reported the bug in
https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/109

Ubuntu users: If you're using Ubuntu and can confirm it affects you, please
indicate it that bug report.

Thanks,

Guy

Re: [PATCH] lyxpak.py undefined variable 'path'

[Guy Rutenberg]

Hi,

Did anybody had time to review this patch? It's quite simple: 3 added lines.

Would it be more helpful if I file a bug report in the trac? I've sent the
patch directly to the mailing list per the instructions in the development
FAQ.

Thanks,

Guy



http://www.guyrutenberg.com


On Fri, Nov 23, 2012 at 7:43 PM, Guy Rutenberg wrote:

> Hi,
>
> In case lyxpak.py is executed outside of the lyx tree, it attempts to
> search the $PATH for the lyx2lyx executable. However, this fails due to an
> undefined variable 'path'. I've attached a straight forward patch fixing
> the issue.
>
> The patch is against the latest revision from the git tree.
>
> Thanks,
>
> Guy
>

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

[Guy Rutenberg]

Hi,

On Mon, Jan 12, 2009 at 12:16 PM, Abdelrazak Younes  wrote:

> Jean-Marc Lasgouttes wrote:
>
>>
>> For stuff like this, LyX uses the language of the document, not of the
>> interface. Actually, LyX uses (at least) two localizations in parallel.
>>
>>
>
> Or even three if this is a bidi document (eg: Hebrew/English with a French
> UI). In general for stuff like this LyX uses the language of current
> paragraph... I hope this is also true for numbering.
>
> Abdel.
>
>
Thanks for your insight. I didn't know that LyX uses different po files
depending on the paragraph's language.
I've altered the he.po file and it worked. I've attached a patch of the
changes.

Thanks,

Guy


he.po.patch
Description: Binary data

Re: [Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

[Guy Rutenberg]

Hi Martin,

On Mon, Jan 12, 2009 at 10:37 AM, Martin Vermeer wrote:

>
> Is this the right place to do it in? I'm honestly asking. Isn't this
> something that can be done by localization in he.po and should not be
> in the C++ code base? What is the reason for doing it like this?
>

There are two reasons that I think are worth putting it in the C++ code:

1. Many users who write documents in Hebrew are using the English interface
of LyX, so that changes in he.po will not affect them.
2. If one translates "\\arabic{enumi}." to ".\\arabic{enumi}" it will just
create another problem, because now the numbering in the English text will
show the dot before the symbol.

I haven't verified it, but I think this is an issue with all RTL languages,
and I believe it shouldn't be tied to any specific language translation.



Regards,

Guy

[Patch] Fix for Numbering Symbol Direction in RTL Paragraphs

[Guy Rutenberg]

Hi,

When writing a paragraph with an RTL language (I checked with Hebrew, but it
should also happen with Arabic), and adding numbered list, the symbols are
shown in the wrong order. I mean by that, that the dot comes before the
numbering symbol instead of after it.

The patch checks whether we are in a RTL paragraph and if so reverses it.

I've attached the patch and a LyX document that shows the problem.

The patch is against the trunk, but if it's needed for the fix to enter the
1.6 development, I'll be glad to provide one against this branch.


Regards,

Guy



http://www.guyrutenberg.com


test.lyx
Description: application/lyx


fix.patch
Description: Binary data

Where in the Code List Numbering Happens?

[Guy Rutenberg]

Hi,

I've decided to tackle an old bidi bug where list numbering in RTL text are
reversed (e.g. the dot appears before the number instead of after it).

I've tried going through the code and find where the list numberings are printed
to screen, but I couldn't find it.

I've understood there is an instance of the Layout class that represents the
Enumerate environment, but I didn't find where it's created and where its
content is printed to the screen.

I would really appreciate is someone could help out.


Thanks,

Guy Rutenberg


---
http://www.guyrutenberg.com

Assertion in TextMetrics.cpp - LyX-1.6.0_rc

[Guy Rutenberg]

Hi,

I've encountered a strange assertion error when clicking the left boundary
of a formula contained in a long line of Hebrew text.


I've attached a minimal file (test.lyx) that reproduces the bug.

The following output was generated when running lyx -dbg workarea test.lyx
(There are more lines before this but I don't think they are relevant).


TextMetrics.cpp(1400): TextMetrics::editXY(cur, 975, 35)
CoordCache.cpp(53): InsetCache contains:
CoordCache.cpp(58): Inset 0xf05cd0(unknown) has point 974,43
CoordCache.cpp(58): Inset 0xf4f200(unknown) has point 977,43
CoordCache.cpp(58): Inset 0x10fb8b0(unknown) has point 1029,43
CoordCache.cpp(58): Inset 0x11e26a0(unknown) has point 1003,43
CoordCache.cpp(58): Inset 0x11e27f0(unknown) has point 997,43
CoordCache.cpp(58): Inset 0x11e7c10(unknown) has point 987,43
CoordCache.cpp(58): Inset 0x11e86c0(unknown) has point 1039,43
CoordCache.cpp(58): Inset 0x11eca10(unknown) has point 1057,43
CoordCache.cpp(58): Inset 0x11ecb80(unknown) has point 1013,43
CoordCache.cpp(58): Inset 0x11f25c0(unknown) has point 1047,43
CoordCache.cpp(58): Inset 0x1209f80(unknown) has point 1023,43
lassert.cpp(21): ASSERTION (pos != 0 && inset == insetBefore) || inset ==
pars[pit].getInset(pos) VIOLATED IN TextMetrics.cpp:1436
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check "false" in file lassert.cpp:23
Aborted




Thanks,

Guy


N.B. This bug is also reproducible in LyX 1.6.0_rc4. This bug doesn't exist
in previous versions (LyX 1.5.*).


test.lyx
Description: application/lyx

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Guy Rutenberg]

Hi,

Dov Feldstern <[EMAIL PROTECTED]> writes:



Hi Ran (and any other would-be Bidi testers),

Please try out the patches from
http://permalink.gmane.org/gmane.editors.lyx.devel/86921 and let us know
(preferably in a reply to that thread, but I reply to here is also fine)
how you feel about the proposed behavior.



I've applied the four patches in that post. It looks good and doesn't cause
problems.
I found still a small bug in functionality
if I type
אבג  abc דהו

I get

אבג [ abc]דהו

when I move back (to the space) with the cursor the extra space is
eliminated (I've attached a screenshot to show how it looks on screen). If I
do the same thing in Lyx 1.4 (I guess it's the same as lyx1.5 without the
patches) it results in

אבג [abc] דהו

which is bettter in my opinion. The important thing is that Lyx 1.4 only
moves the space after I type "דהו" in hebrew so that the space doesn't
change location wrongly  as it would if the English text would also be typed
in RTL.

The first image(screenshot11.png) shows the result of the input in lyx
1.5with the patches, and the second one in lyx
1.4. I prefer the result in lyx 1.4 as it's more intuitive I think for the
user.

Regards,

Guy
<><>

Re: [1.5.0svn] msguniq: found 4 fatal errors

[Guy Rutenberg]

Timothy Reaves <[EMAIL PROTECTED]> writes:



Any idea's as to why I'm getting the following?

cat qt4_l10n.pot layouts_l10n.pot languages_l10n.pot ui_l10n.pot | \
msguniq -o LyX-1.5.po && rm -f  qt4_l10n.pot layouts_l10n.pot

languages_l10n.pot

ui_l10n.pot



msguniq: found 4 fatal errors
make[3]: *** [l10n_pots] Error 1
make[2]: *** [LyX-1.5.pot-update] Error 2
make[1]: *** [LyX-1.5.pot] Error 2
make: *** [all-recursive] Error 1
Dusty >





Hi,
I've found the following workaround for the problem (worked for me). I know
it
isn't the best one and there should be a better solution but this one works
for
now..

echo "" > languages_l10n.pot

It will empty the file and as a result the compilation should go fine (at
least
it did so for me).

Regards,
Guy

Re: [1.5.0svn] msguniq: found 4 fatal errors

[Guy Rutenberg]

Timothy Reaves <[EMAIL PROTECTED]> writes:

> 
> Any idea's as to why I'm getting the following?
> 
> 
> Dusty >
> 
> 


Hi, I had the same problem and I found the following workaround:

echo "" > po/language_i18n.pot

emptying the above file seems to fix the compilation problem, I guess it will
have some side effects on the *.po files, but if you use the English UI you
shouldn't have any problem.

Regrads,
Guy

Re: [patch] Bidi / RTL / Hebrew, r17354, and bug 3040

[Guy Rutenberg]

Dov Feldstern <[EMAIL PROTECTED]> writes:

> 
> Hi!
> 
> I think that I've finally tracked down the cause for a problem we've 
> been having for a long time with RTL / Hebrew in LyX 1.5. Specifically, 
> this is the problem described in bug 3040 (see links below), where in 
> the frontend, Hebrew words are placed in the correct position on the 
> screen, but the letters within each word are reversed. There were also 
> some weird interactions between this and the locale settings (for 
> certain *illegal* locale settings, the problems suddenly disappeared); 
> conversely, a change made in r17354-17355 made the problem reappear, 
> even for the illegal locale settings. (Incidentally, also prior to 
> r15893, the bug existed always --- regardless of the locale --- and I 
> was never able to understand how the changes made there had any effect 
> on the Bidi code.) I think the following will explain all these phenomena:
> 

Hi,

Thanks Dov! it works very good and puts an end to the need of illegal locale
settings. Hebrew support was restored. Now I hope it won't break again :).

When this patch will be committed to the svn?

Regards,
Guy

[BUG]Lyx can't create output file when the file name contains certain characters

[Guy Rutenberg]

Hi all,

Lyx-1.5svn introduced the longed waited support to handling hebrew
filenames. but apparently it can't handle some of the characters. I can't
figure yet why it doesn't handle them as they are part of the regular hebrew
alphabet which the rest of it works.

The characther that can't appear in the file name is ע (Ein in hebrew, the
16th letter in the alphabet). For example ע.lyx as a filename will cause lyx
not to funtion.

This is a major bug in hebrew support.

I've attached an example document with the "bad" filename.

When trying to view the output in pdf/dvi/ps you get the following error:

! Unbalanced quotes in argument W".tex
W".dvi: W".dvi: No such file or directory
Error: Cannot view file

File does not exist: /tmp/lyx_tmpdir11468bmjiD3/lyx_tmpbuf2/W".dvi


Regards,
Guy Rutenberg


ע.lyx
Description: application/lyx

[Bug] Hebrew headers are displayed as gibbrish

[Guy Rutenberg]

In the lyx1.5svn, if using the language's default encoding (default option
in the setting dialog) hebrew text inserted into headers (such as title,
author and date) is displayed as gibbrish.
The other text in the document is displayed correctly. One possible solution
is changing the encoding manually to cp1255.

By the way if you let Lyx insert the date for you (by not specifying any
date) the date (in hebrew) is displayed correctly.

I opened a bug report in the bugzilla with an example document for
reproducing the problem, bug #3235.

My guess is that lyx doesn't really set the encoding for the headers unless
an encoding is chosen manually.

Regards,
Guy

Re: Bidi support in Lyx 1.5 svn

[Guy Rutenberg]

Hi,
Dov mentioned that LyX bidi algorithm did a good job at previous versions,
and I agree with it. If Lyx bidi algroithm is indeed spread all over the
place, I think we will be better off disabling Qt bidi algorithm (if it's
possible). I think it won't require much additional code as disabling the
Lyx Bidi algorithm.

Abdel: In previous versions of Lyx, did it handle Arabic right, or messed
the directions?

Guy


Abdelrazak Younes <[EMAIL PROTECTED]> writes:



Dov Feldstern wrote:

> Abdel, I know that you agree with Guy on this one, so maybe you guys are



> right... And it's true that for Arabic, letting Qt deal with everything
> will probably simplify things a lot... However, it sounds like a really
> big job to me, and I think that the alternative would work, and would be



> much much simpler, even if it is a little backwards.

Perhaps we can reuse part of LyX bidi algorithm. I am thinking about
keeping the reordering of words but not the reordering of letters. This
must be done by Qt because it is the one who knows how to paint them on
screen at the end.
This won't be a big change because we already pass the strings word by
word to the painter.

Abdel.

Re: Bidi support in Lyx 1.5 svn

[Guy Rutenberg]

Hi,

I did further testing on the issue and found out that the problem occurs
only when the locale that is set in LC_CTYPE (directly or via LANG) is a
valid locale.
For example the display of Hebrew will be wrong if LC_CTYPE is set to en_US
but it will be correct when set to he, en, he_US or any other unrecognized
locale.
Further more when typing hebrew when LC_CTYPE is configured to a valid
value, and not setting the text as "language hebrew" in LyX (that causes lyx
to treat the Hebrew as English or the default language) the hebrew text is
displayed right, but when marking it as hebrew in Lyx it displays wrong (as
described in bug #3040). If you set the LC_CTPE to invalid value the Hebrew
text marked as hebrew is displayed correctly but the one that isn't marked
in Lyx as hebrew is displayed wrong (As should be excepted as it isn't
marked as hebrew).

My guess is that when LC_CTYPE is set to a valid locale and you type hebrew
(and don't mark it as hebrew in Lyx) Qt sorts the hebrew text when printed
to the screen so it will be displayed correcty. But when the text is marked
as Hebrew within Lyx, Lyx already sorts the text so it should displayed
correcty, but when it prints it Qt recognizes it as hebrew and reverse the
order of the letter (so in it's point of view the letter will be displayed
correctly).

To sum it up when the LC_CTYPE is set correcty Qt recognizes the hebrew text
and when it's the hebrew text is marked as hebrew also Lyx recognizes it and
both of them reverse the order of the letters.

The solution in my point of view is to leave the correct display for Qt and
remove the reversing of letters from Lyx.
If someone will point me where the reversing of hebrew letters is done in
the Lyx code I will try do it my self.

I hope we shall solve this bug soon.

Best Regargs,
Guy

Guy Rutenberg <[EMAIL PROTECTED]> writes:



Hi,

The faulty environment variable is LC_CTYPE. when setting this
variable (either directly or by setting the LANG) LyX doesn't handle
hebrew text  correctly.
Do someone now when lyx looks at the LC_CTYPE and what effect it has
when it's set in LyX?

Regards,
Guy

On 1/4/07, Guy Rutenberg <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I can confirm that the bug is related to the environment variable, and
> especially the ones that relate to the locale settings.
> I couldn't solve the problem with only unsetting the LANG but I solved

it

> when I unset all the locale related variables. As this is not a nice
> solution I will try to find out exactly which enviroment variable is

faulty,

> and report back.
>
> Thanks for helping,
> Guy
>
> Dov Feldstern wrote:
>
> >  What had been strange was that I (dov) was not seeing this problem,
> > while Guy
> >  was, and we couldn't figure out why. I've finally been able to
> > reconstruct this
> >  problem with:
> >
> >  setenv LANG he_IL
> >
> >  In other words, when LANG is *not* set, then the words are not
> > reversed, but
> >  when it is set, then the words are reversed. So Guy --- try to unset
> > this
> >  variable (and maybe also LANGAUGE, if it's set?) and see if that

helps.

> >
> >  Note, however, that it is important that we be able to have the
> > variable set --
> >  when it's not set, the menus do not display hebrew correctly... So

the

> > solution
> >  should be local to the painting, not just getting rid of this
> > environment variable.
> >
> >
>

Re: Bidi support in Lyx 1.5 svn

[Guy Rutenberg]

Hi,

The faulty environment variable is LC_CTYPE. when setting this
variable (either directly or by setting the LANG) LyX doesn't handle
hebrew text  correctly.
Do someone now when lyx looks at the LC_CTYPE and what effect it has
when it's set in LyX?

Regards,
Guy



On 1/4/07, Guy Rutenberg <[EMAIL PROTECTED]> wrote:


Hi,
I can confirm that the bug is related to the environment variable, and
especially the ones that relate to the locale settings.
I couldn't solve the problem with only unsetting the LANG but I solved it
when I unset all the locale related variables. As this is not a nice
solution I will try to find out exactly which enviroment variable is faulty,
and report back.

Thanks for helping,
Guy

Dov Feldstern wrote:

>  What had been strange was that I (dov) was not seeing this problem,
> while Guy
>  was, and we couldn't figure out why. I've finally been able to
> reconstruct this
>  problem with:
>
>  setenv LANG he_IL
>
>  In other words, when LANG is *not* set, then the words are not
> reversed, but
>  when it is set, then the words are reversed. So Guy --- try to unset
> this
>  variable (and maybe also LANGAUGE, if it's set?) and see if that helps.
>
>  Note, however, that it is important that we be able to have the
> variable set --
>  when it's not set, the menus do not display hebrew correctly... So the
> solution
>  should be local to the painting, not just getting rid of this
> environment variable.
>
>

Re: Bidi support in Lyx 1.5 svn

[Guy Rutenberg]

Hi,
I can confirm that the bug is related to the environment variable, and
especially the ones that relate to the locale settings.
I couldn't solve the problem with only unsetting the LANG but I solved it
when I unset all the locale related variables. As this is not a nice
solution I will try to find out exactly which enviroment variable is faulty,
and report back.

Thanks for helping,
Guy

Dov Feldstern wrote:


 What had been strange was that I (dov) was not seeing this problem, while
Guy
 was, and we couldn't figure out why. I've finally been able to
reconstruct this
 problem with:

 setenv LANG he_IL

 In other words, when LANG is *not* set, then the words are not reversed,
but
 when it is set, then the words are reversed. So Guy --- try to unset this
 variable (and maybe also LANGAUGE, if it's set?) and see if that helps.

 Note, however, that it is important that we be able to have the variable
set --
 when it's not set, the menus do not display hebrew correctly... So the
solution
 should be local to the painting, not just getting rid of this environment
variable.

Re: Bidi support in Lyx 1.5 svn

[Guy Rutenberg]

Hi,
1) I'm using Gentoo Linux
2) yes, I do svn update every time I begin testing lyx. I also did svn
update couple of minutes before creating the example file.
3) tried that, didn't effect anything. I'm starting lyx with the -userdir
flag set to ~/.lyx-1.5 so it won't mess with the older lyx installation.

I have attached a small LyX file the shows the bug that I'm talking about.
By the way, I noticed when creating the example that the punctuation marks
are in the right place. So the ony problem is with the letters themselves.

Thanks for your help,
Guy

Dov Feldstern wrote:

Hi!


This is strange, because I don't see the problems you're describing (in
bug #3040).

1) What OS are you working in? (I'm in Linux)
2) Have you recompiled the latest version from svn?
3) You might want to try removing the .lyx directory (or whatever the
equivalent on Windows is) --- I've found in the past that sometimes the
old configuration made all kinds of weird things happened which turned
out to work just fine when I started with a clean configuration.

Perhaps if none of this helps, you could either send to the list or else
attach to the bug report a small LyX file with some Hebrew, and I'll try
opening it at my end and see if it looks okay here?

Good luck!
Dov

Bidi support in Lyx 1.5 svn

[Guy Rutenberg]

Hi,

I tried Dov's fix for the problem, but unfortunately it doesn't work for me.
The output is still correct (as it used to) but the display in the UI is
still wrong. I opened yesterday a bug report with detailed explanation with
what is wrong in the hebrew display in the UI.
I Hope it will get fixed soon,  because lyx1.5 has otherwise much better
handling of hebrew (importing from latex works, hebrew labels works and also
hebrew filenames).

Regards,
Guy

Dov Feldstern wrote:


Hi!

I've been following this issue and playing around with it for a while
now, and I think the problem may not be as bad as we think --- I don't
think any major rewriting is necessary.

Here's how I'm able to get bidi (Hebrew) at least basically working (I
just tried it now on r16375):

(Note that at stage 3 you have to re-compile, so you should really start
there...)

  1) Make sure that "Right-to-left language support" in Tools ->
Preferences... -> Language (not Language settings!) is enabled (I just
discovered that somehow mine wasn't, even though I thought it was, which
of course made things not work ;) )
  2) In order to type in Hebrew, you need to do *two* things:
 a) change the language (F12, if you're using Dekel's bindings for
Hebrew)
 b) change the keyboard input to Hebrew. On Linux, I do it using the
command: setxkbmap -compat "group_led" -symbols
"us(pc104)+il+group(menu_toggle)", and then the Windows Menu key
toggles between Hebrew and English.
 Again, it's important to do *both* of these!
  3) The document encoding has to be set correctly. The only way I was
able to get this to work is as follows:
a) You have to add the "cp1255" encoding to a hard-coded list of
possible encodings. Georg has explained multiple times how to do this,
I'm attaching a patch which does it.
b) after applying the patch, in Document -> Settings... -> Language,
uncheck "Use language's default encoding", and choose "cp1255" in
Encoding.

This should work, it looks okay in the GUI, the generated output is
correct.

So:

1) Can you please confirm that this does in fact work for you too?
2) We should fix it so that F12 (change language) also changes the
keyboard. Actually, I think it's better if it doesn't really change the
keyboard (that then affects all keyboard input, not only in lyx), but
rather that it would translate the input accordingly. I don;t really
know how all of this works, any input on these issues would be
appreciated.
3) There's probably a better way than having to manually change the
encoding to cp1255. There's probably some way to automatically associate
the language with the encoding (I thought that's what "use language's
default encoding" is supposed to do, but obviously something's a little
off). Georg, can you help with this?

Hope this helps, and that we can finally get Bidi working in 1.5!

Dov

Re: Bidi support in Lyx 1.5 svn

[Guy Rutenberg]

It doesn't work well with unicode, my guess is that it will have to be
rewritten.

Guy

On 12/21/06, Martin Vermeer <[EMAIL PROTECTED]> wrote:


On Thu, 2006-12-21 at 11:45 +0200, Guy Rutenberg wrote:
> Hi,
>
> I'm testing Lyx 1.5 svn, and specifically interested in the bidi
support.
> Lyx 1.5 has a regression in the bidi support compared to lyx 1.4. I
would
> like to help fix this problem, but I can't understand how Lyx determines
> when a paragraph should be RTL and when it should be LTR. If someone
would
> point me to where I can find documentation on this issue (and preferably
> other things regarding how bidi is handled in the code) I would
appreciate
> it very much.
>
> Regards,
> Guy

I suspect it isn't really properly documented anywhere, not even in the
code. I believe you need to look at LyXText::isRTL() and probably how
this is being used in rowpainter.C. But there is more stuff all over the
place. I wonder how this homegrown stuff interacts with Unicode.

HTH Martin

Bidi support in Lyx 1.5 svn

[Guy Rutenberg]

Hi,

I'm testing Lyx 1.5 svn, and specifically interested in the bidi support.
Lyx 1.5 has a regression in the bidi support compared to lyx 1.4. I would
like to help fix this problem, but I can't understand how Lyx determines
when a paragraph should be RTL and when it should be LTR. If someone would
point me to where I can find documentation on this issue (and preferably
other things regarding how bidi is handled in the code) I would appreciate
it very much.

Regards,
Guy

Re: Hebrew Translation

[Guy Rutenberg]

hi,

1) LyX works for pretty good in hebrew in version 1.4.1 (i haven't tested it
yet on 1.4.3 and 1.5) but many hebrew users complain that it's pretty hard
configuring LyX for use with hebrew (especialy keyboards as LyX doesn't use
for some reason the keyboard layouts of the Xserver). There some more
problems with hebrew (mostly gui stuff where hebrew is display as gibrrish)
which I guess will be fixed when lyx moves to Unicode (as i understood it
should happen in lyx 1.5).

2) I didn't talk about the localization of the gui (but i think i will take
a look it to see if i can help). I want to help translating the LyX
documantation which comes with every lyx installation such as the user-guide
and etc.

Guy Rutenberg

On 9/8/06, Martin Vermeer <[EMAIL PROTECTED]> wrote:


On Fri, Sep 08, 2006 at 08:44:08AM +0300, Guy Rutenberg wrote:
> hi,
>
> I would like to help with the hebrew translation of the LyX
documentation. I
> contacted Tzafrir Cohen (which is listed as the contact for hebrew) but
he
> told me that he doesn't activly maintain the hebrew translation. As
there is
> no active contact for hebrew translation i don't know how can i help
with
> the translation. I would thank you if you could explain to me how can i
send
> new translation for the documentation and if I can be the hebrew
tranlation
> contact man.
>
> Best Regards,
> Guy Rutenberg

First of all, does LyX work properly in Hebrew? Separate questions for
1.4.3 and 1.5svn...

Localization is done using the Gnu gettext system, which has its own
documentation.

- Martin

Hebrew Translation

[Guy Rutenberg]

hi,

I would like to help with the hebrew translation of the LyX documentation. I
contacted Tzafrir Cohen (which is listed as the contact for hebrew) but he
told me that he doesn't activly maintain the hebrew translation. As there is
no active contact for hebrew translation i don't know how can i help with
the translation. I would thank you if you could explain to me how can i send
new translation for the documentation and if I can be the hebrew tranlation
contact man.

Best Regards,
Guy Rutenberg