Re: Why does lyx use it's own keyboard instead of the systems?
Micha Feigin wrote:
On Tue, 10 Mar 2009 11:44:46 +0200
Ronen Abravanel wrote:
Before you rush into this change - Consider the following usecase:
Switching to math - When I'm in math-mode, I always want my keyboard layout
to be English. While In windows, The current keyboard layout override the
global one (If you put the cursor in an Hebrew context, the language will
switch to Hebrew, If you put your cursor in English context - you'll write
in English).
When I'm writing document, I want the Ctrl+m will be the only thing I need
to do in order to start typing math. "Ctrl-m Alt-Shift" Is match to
expensive..
good point, but you also have two input senarios in math.
1. Entering parameters (regular typing). AFAIK it should always be in english
because I don't think that latex can handle anything else
2. in text mode inside math mode, where you want to be able to type both
(although at the moment it requires explicitly entering the \R{} macro to get
hebrew in there
Does everyone agree on the first point and are you willing to manually change
in the second case or do you want some other behviour?
So - If LyX will use the native-system-keyboard-layout - It will have to be
able to change it depending the current context (Math\Regular) - And in
every OS.
On Tue, Mar 10, 2009 at 9:59 AM, Abdelrazak Younes wrote:
Micha Feigin wrote:
Sorry, sent off list by mistake
On Mon, 9 Mar 2009 22:05:51 +0100
Jean-Marc Lasgouttes wrote:
There are two issues. For running the dictionary you need to know the
language.
For hebrew and arabic it's another issue, you need to know the system
language
so that you know directionality. Hebrew is right to left. For hebrew
characters
it may be easy to decide, for what about spaces and numbers? For these
we need
to know the system keyboard language and not guess it from the
character.
Under windows I know it's possible since for example word does it.
Question is
whether this is possible to know under linux (I guess so since there
are panel
applets that show the language). Which again comes down to the question
whether
there is a technical issue why to work this way or not.
So you want to change language when the keyboard layout is changed at
system level, right?
I never thought of these layouts as indicators of the actual language.
If Qt gives us
this information, we should be able to do it.
JMarc
For every other program the system language is used for input (alt-shift
in my
case). So for example when writing mail or using oowriter I change the
system
language to change input. Lyx is the only exeption where I __have__ to
keep the
system language for english and bind (f12 in this case) to language
hebrew. It
makes things incosistent and non-intuitive, esspecially for new users.
I agree. For RTL languages, it makes a lot of sense to change the current
language together with the system. Advanced users wishing to change the
language independently should be able to disable this feature though.
Now, you have to find someone willing to implement this feature ;-)
FYI, a year or two ago I advocated that the text direction should be based
uniquely on the encoding, independently of the language settings, like Qt
does. But I failed to convince other developers.
Dov, are you reading this? ;-)
Abdel.
A little late, but yes, I am still lurking on the mailing lists... ;)
I think the main reason (to answer the title question) is that we don't know how
to get/set the system-wide keyboard language in a cross-platform way. If it's
possible to do that, then I think it should be fairly simple to implement a
solution along the following lines:
Ideally, if it *were* possible to detect the system-wide keyboard language
setting, then LyX should (optionally! for users that *want* this feature) set
it's internal language to the system-wide setting, plain and simple. The only
thing to make sure, though, is that in the same manner, whenever LyX chooses to
change it's internal language, it should also *set* the system-wide keyboard
setting to that language. I think that that would solve the issue raised by
Ronen: when entering a math inset, LyX would set the internal, as well as the
system-wide, language to english (or latex, technically? I forget the exact
details), which would mean that the math text would be set correctly; and when
exiting that inset, LyX automatically sets the language back to whatever it was
before entering the inset. Similarly, when moving the cursor over existing text,
LyX changes the language to match the underlying text. I'm almost certain that
LyX already does all of this language setting --- except that not at the
system-wide level, that's what would have to be added.
Note, however, that even if this is implemented, I think I would *still* choose
to use LyX's keymaps, for reasons that I've explained elsewhere (last time
around was at http://article.gmane.org/gmane.editors.lyx.general/48426). And
while some of the reasons menti
Re: Hebrew and Nikud on Linux (Ubuntu)
Nigel Pegram wrote:
Hi everyone,
I've been using Lyx for a while but have not been able to get nikud to
work correctly. I can enter unicode, even to the point of consonantal
Hebrew, but as soon as I add a vowel, I get errors.
I have attached a sample file with one point added. If I delete the
vowel, the document is generated correctly. The relevant part of the log
seems to be:
! Package ucs Error: Please activate option 'combine'.
See the ucs package documentation for explanation.
Type H for immediate help.
...
l.32 שדגשֻ
\selectlanguage{polutonikogreek}
Composed characters can only be rendered correctly, when the option
'combine' i
s activated
! Undefined control sequence.
\u-default-1467 #1->\...@cmb \qubuts
{#1}
l.32 שדגשֻ
\selectlanguage{polutonikogreek}
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., `\hobx'), type `I' and the correct
spelling (e.g., `I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.
The full log is also attached.
Lyx 1.6.1, Ubuntu 8.10
Any suggestions appreciated.
TIA
Nigel
I have had some success with this in the past, though I haven't tried it
recently. It mostly has to do with whether latex itself has nikud support. So I
would first focus on getting it working with latex itself.
There's culmus-latex (http://www.guyrutenberg.com/culmus-latex/), the latest
version of which at least partially supports nikud; I'm not sure if it's
packaged for ubuntu or if you have to install from source.
You might also want to ask about this on the ivritex mailing list
(http://listserv.tau.ac.il/archives/ivritex.html) --- that's more
latex-oriented, but again --- I think that's the real problem, not LyX.
I don't have time to look into this right now, but if you do follow this up and
come up with anything interesting, please report it back here and/or update the
bugzilla issue for nikud (http://bugzilla.lyx.org/show_bug.cgi?id=3366).
Good luck!
Dov
Re: Key bindings
Peleg Michaeli wrote:
On Sat, 2008-11-22 at 17:34 +, Peleg Michaeli wrote:
When you say "so I have configured my keyboard to have all of the
greek letters,
including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀ ∃ and many more" --- did
you do
anything to actually configure the keyboard, or just paste stickers
on or
something? I mean, when you press a key, will LyX be getting a "g"
or some
unicode character?
Very simple: I have reconfigured GNOME, so now when I press "Alt Gr +
s", for example, I get σ. If I press the same key combination with
Caps-Lock on, or with Shift key pressed as well, I get Σ. Pressing the
key that is just near the "z" key on its left produces ∀, and doing
that
with Shift produces ∃, and many more options.
I haven't put any stickers. I know the keys (at least most of them) by
heart − it's very simple. I do it like that since even though I know
TeX
quite good, it is much shorter to write emails to friends like this:
"Let x∈P and y∈Q. Since P and Q are normal, xyx^-1y^-1∈P∩Q={e}... ⇒
something..." or compare "...hence P\subseteq Q" to "...hence P⊆Q".
So, in LyX, when I press "Alt Gr + a" I get α, but I don't want to get
α
− I want to get "\alpha", and I believed that LyX might have a
solution
to this need (and, apparently, it has − but only in 1.6). Vim, for
example, knows really well how to deal with that.
It is important to say also that the configuration is very basic, and
it
works in ANY software on my computer, including LyX. It's not a "hack"
in the risky aspect of it.
Depending on your answers to these questions, I *may* be able to
help a little...
Hi Dov -
Can you think of any solution to this without switching to LyX 1.6 ?
Thanks,
Peleg.
No. However, perhaps you can try installing 1.6 in a virtualized environment
(Qemu, VirtualBox are relatively easy to set up, I think), so that it won't
affect your production system until you've got it configured correctly...
Re: Key bindings
Peleg Michaeli wrote:
On Sat, 2008-11-22 at 20:28 +0200, Dov Feldstern wrote:
They shouldn't all be bothering you, only the ones you include are
activated.
Probably it's cua -- that's the default.
what exactly does your bind file look like?
I'm attaching cua and hebrew here.
The cua.bind is in usr/share/... and the hebrew.bind is in
~/.lyx1.5.1/bind/
The first line of hebrew.bind ("\bind_file cua") is including cua.bind. I don't
remember the rules in terms of whether you can override bindings, and they may
also have changes since 1.5. The easiest thing to do may be to just copy
cua.bind from /usr to your local lyx bind directory, rename it to mycua or
something, get rid of the "C-g y" in there, and include that in hebrew instead
of cua. See if that helps.
Thanks,
Peleg.
Re: Key bindings
Peleg Michaeli wrote: On Fri, 2008-11-21 at 13:27 +, Guenter Milde wrote: You could try to grep for C-g in all bind files that are read directly or indirectly. I have found these: ./bind/xemacs.bind:\bind "C-g" "cancel" ./bind/xemacs.bind:\bind "C-x C-g""buffer-view ps" ./bind/mac.bind:\bind "C-g" "error-next" ./bind/emacs.bind:\bind "C-g" "cancel" ./bind/emacs.bind:\bind "C-x C-g""buffer-view ps" ./bind/cua.bind:\bind "C-g" "error-next" Do you think it is safe to delete these? They shouldn't all be bothering you, only the ones you include are activated. Probably it's cua -- that's the default. what exactly does your bind file look like? And: how can I know if these files are really readed? (the above is the result of grep in /usr/share/lyx1.5.1/) Thanks, Peleg.
Re: Key bindings
Peleg Michaeli wrote: On Fri, 2008-11-21 at 23:18 +, Guenter Milde wrote: So you really have a Psi-key? Well, yes. I type a lot of math, so I have configured my keyboard to have all of the greek letters, including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀ ∃ and many more. I thought that it might really shorten my LyX experience (though, I still mostly use vim for LaTeX, but LyX is much better with Hebrew), but... In 1.6, you will get a text-psi in text and (with the above fix) a kursive math \psi in the LaTeX output. ...but I guess I'll need 1.6 for that. Well, I'm quite scared of this, since I only have ubuntu 7.04 and I don't know how it'll react, and since it took me a while to configure Hebrew properly in that LyX (I've been through hell, actually... but maybe this hell is related to configuring the Hebrew fonts in pdflatex, actually, and not in LyX? I'm not so sure...) I'll have to think about it a bit (add information if you like to!) Thanks a lot, Peleg. Hi, Peleg! I'm not totally clear as to how your keyboard is set up, and I think that that may be the problem (for what it's worth, I'm able to create the "C-g y" binding without any trouble, with Hebrew; this is in 2.0svn, but I don't think this should have changed appreciably even from 1.5). Do you use a keyboard map (Tools->Preferences->Keyboard-> "use keyboard math"; the exact menus may be a little different in 1.5)? Does your keyboard output english or hebrew (i.e., do you switch languages at the keyboard level, or *only* using F12 in LyX)? When you say "so I have configured my keyboard to have all of the greek letters, including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀ ∃ and many more" --- did you do anything to actually configure the keyboard, or just paste stickers on or something? I mean, when you press a key, will LyX be getting a "g" or some unicode character? Depending on your answers to these questions, I *may* be able to help a little... Dov
Re: getting a document with no page numbers
Micha wrote:
I trying to get a document with no page numbers and for some reason it's just
not working.
both
\pagestyle{empty}
\thispagestyle{empty}
seem to be ignored.
Any idea on where to look for the culprit?
the document style is article, bibtex and amstex are in use. The document is
both hebrew and english
thanks
\thispagestyle{empty} works for me (1.7svn, article, hebrew and english, but no
bibtex or amstex). Note that the command has to be in ERT on the specific page,
not in the preamble (which is obvious, given that it's for a specific page ---
but I think I once had trouble because of that ;) ). Besides the ERT, I also set
the Document->Settings...->Page Layout->Heading style to "empty" --- I'm not
sure if both are necessary or not...
HTH!
Dov
Re: Still no composing, and a crash...
I'm continuing this discussion on the lyx-devel list, anyone on this list who's interested can continue following it there (http://permalink.gmane.org/gmane.editors.lyx.devel/108759) Dov Feldstern wrote: John Coppens wrote: Hello people. I'm not a very frequent user of LyX, but irregularly I do use it, and seem to run into recurrent problems. I reported the accented character composing problem a while ago (it just doesn't work - I can't type Compose-e-', and get é, as I _can_ with other programs, like sylpheed). If it works in other programs, that probably means that your os is setup to handle this, so there should be no need for LyX's built-in keymaps. Try disabling the "use keyboard map" option, and see if that helps. To be sure, I compiled and installed 1.5.5, and still have the same problem. But, worse, I tried to change the keyboard map, and LyX just crashed. This message appeared on the terminal: lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help->Introduction and send us a bug report, if necessary. Thanks ! Bye. Aborted To reproduce: LyX -> Tools -> Preferences -> Select Keyboard -> Enable 'Use keyboard map' -> Press 'Browse' (Crash). This shouldn't happen. Are you able to produce a backtrace of this? What version of LyX are you using? Am I doing something wrong here? John
Re: Still no composing, and a crash...
Dov Feldstern wrote: What version of LyX are you using? Sorry, you already mentioned it's 1.5.5 ;)
Re: Still no composing, and a crash...
John Coppens wrote: Hello people. I'm not a very frequent user of LyX, but irregularly I do use it, and seem to run into recurrent problems. I reported the accented character composing problem a while ago (it just doesn't work - I can't type Compose-e-', and get é, as I _can_ with other programs, like sylpheed). If it works in other programs, that probably means that your os is setup to handle this, so there should be no need for LyX's built-in keymaps. Try disabling the "use keyboard map" option, and see if that helps. To be sure, I compiled and installed 1.5.5, and still have the same problem. But, worse, I tried to change the keyboard map, and LyX just crashed. This message appeared on the terminal: lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help->Introduction and send us a bug report, if necessary. Thanks ! Bye. Aborted To reproduce: LyX -> Tools -> Preferences -> Select Keyboard -> Enable 'Use keyboard map' -> Press 'Browse' (Crash). This shouldn't happen. Are you able to produce a backtrace of this? What version of LyX are you using? Am I doing something wrong here? John
Re: keyboard question
Pavel Sanda wrote: On Wed, Jul 02, 2008 at 09:13:27PM +0200, Pavel Sanda wrote: Should we get rid of our own keyboard mapping soonish then? Does anybody still use it and could not use alternatives provided by his environment? yes it is still used, i remember some screem last time we discussed this. The main argument I remember was "It works, so why remove it". Now we seem to have cases where "it works (as expected)" is not necessarily true... no, one relevant case was to be able to use the same scheme for different platforms; another argument came from Dov, probably something with hebrew things... Pavel is correct, there are certain features which the keymap offers which I think would be very hard to offer, especially in a system-independent manner, without keymaps (details below). I haven't followed this thread very closely, and I do not use dead keys --- I'm not sure how they're supposed to work at all --- so I don't feel qualified to provide suggestions with regard to the original problem. It isn't clear to me whether keymaps were or were not being used in this case. But perhaps if they were, then the user should just try to shut them off. In any case, I don't think that keymaps should ever interfere with anything, if they are shut off (if they do, it's a bug, not a problem with keymaps per se). Specifically, these are some of the features which I think would be hard to implement without keymaps: *) when moving the cursor across text in different languages, it's nice if the language is automatically changed to match the text under the cursor (similar to when placing the cursor on \emph text, the input automatically becomes \emph. I don't know how this could be done without keymaps. *) at least on my setup, which I switch the language at the keyboard level, it is switched for all applications. I find it much nicer if the language is switched only for the single application (in our case, LyX) in which I asked to switch it. An extreme example of why the alternative is annoying: if I switch the keyboard to hebrew in LyX, and then ctrl-d to view the dvi, xdvik pops up, but then doesn't recognize 'q' to close (because my keyboard is now set to Hebrew). *) At least for hebrew, we need to perform two actions when switching languages: (1) change the input to hebrew; and (2): switch the text language to hebrew. It's nice if we can perform both actions with one keypress. This is not possible, though, if the keyboard input switching happens independently of LyX. If all of the above issues can be solved without LyX's keymaps, then I don't mind having keymaps removed. But until that time, I do use keymaps. And again, I don't think it should interfere with anything for anyone who doesn't want to use them. Dov P.S. here's a link to my arguments in favor of keymaps from a previous round of discussions: http://permalink.gmane.org/gmane.editors.lyx.devel/88939 (Pavel --- thanks for remembering that this issue is important to me!)
Re: [OT] templating latex
Rich Shepard wrote:
On Fri, 4 Apr 2008, Dov Feldstern wrote:
Based on your example, I would strongly recommend that you look into
http://www.cheetahtemplate.org/ --- it's a wonderful tool, and it
looks to me like it may be just what you're looking for.
Dov,
Thank you for the recommendation. But, I don't see why I want to put html
code in my python application in order to produce .tex files. Or write xml.
I see the value of the templater for web applications and unstructured
reports. However, that's not what I need.
Hmmm, I thought that perhaps I had misunderstood what you're trying to do, but
on reading the thread again, it still seems to me like cheetah may be what you
want ;) . I'll explain:
Cheetah is actually orthogonal to html --- it's just that html is what it is
usually used for, and I guess the manual is geared towards that. But in fact, it
can be used for anything --- code generation, for example; as well as typesetting.
So basically, what you would do is this: start out with a latex file that
outputs something that you want. Then, just replace the instances of the data in
the latex file with the variables in cheetah's format. The result is a template
which is basically a .tex file, but which has variables in place of the actual
data. When you instantiate the template with actual data, you get a .tex file.
No html/xml whatsoever involved in this.
Attached is an example which is similar to the example you posted. Here's one
way of how you can use it, but since this is python, there are many other ways,
depending on which is most convenient for your workflow.
0) you'll obviously have to install cheetah if you actually want to try this out
1) We'll create a file with the actual data that we want to fill the template
with. In this case, we're going to use pickle to dump it into a file
"cheetah.data". Note that what we dump into this file should be a dictionary,
whose keys are strings of the names of the variable that we reference in the
template (title and pairData, in our case), and whose values are the values we
want to give these variables.
Python 2.3.4 (#2, Jan 5 2005, 08:24:51)
[GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Executing Local Startup... Done.
>>> pairData = [("Jobs","Tax base"),
... ("Jobs","Infrastructure"),
... ("Jobs","Schools"),
... ("Jobs","Housing"),
... ("Jobs","Medical care"),
... ("Jobs","Sustainability"),
... ("Jobs","Traffic volume"),
... ("Tax base","Infrastructure"),
... ("Tax base","Schools"),
... ("Tax base","Housing"),
... ("Tax base","Medical care"),
... ("Tax base","Sustainability"),
... ("Tax base","Traffic volume"),
... ("Infrastructure","Schools"),
... ("Infrastructure","Housing"),
... ("Infrastructure","Medical care"),
... ("Infrastructure","Sustainability"),
... ("Infrastructure","Traffic volume"),
... ("Schools","Housing"),
... ("Schools","Medical care"),
... ("Schools","Sustainability"),
... ("Schools","Traffic volume"),
... ("Housing","Medical care"),
... ("Housing","Sustainability"),
... ("Housing","Traffic volume"),
... ("Medical care","Sustainability"),
... ("Medical care","Traffic volume"),
... ("Sustainability","Traffic volume")]
>>> title="Cheetah Example"
>>> from pickle import dump
>>> dump({'pairData':pairData, 'title':title}, open("cheetah.data", "w"))
>>> (Ctrl-D)
2) We now have the template (cheetah.tmpl) and the data (cheetah.data). We now
want to create the actual tex file:
[EMAIL PROTECTED]> cheetah fill --oext tex --pickle cheetah.data cheetah.tmpl
the result is a file called cheetah.tex.
This is just a normal tex file. run latex on it, view the dvi, etc.
Now you discover that the output is not exactly what you want. But the beauty is
this: this is purely a late
[OT] templating latex (was: Re: Creating a Document Programmatically)
Rich Shepard wrote: On Tue, 25 Mar 2008, Rich Shepard wrote: Has anyone done this? Our model is written in Python, so we can use the open() and write() methods to squirt strings to a disk file. After learning PyX (Python wrapper for TeX/LaTeX primarily for graphics), and trying to use it to write the reports, I'm back to embedding LaTeX markup in Python comments. Risking public humiliation (Hey! I'm used to that since I testify at all sorts of government hearings.), I'm posting my first abortive attempt to learn how to do the job. Small file attached; as long as you have python installed on your system, it will run. Based on your example, I would strongly recommend that you look into http://www.cheetahtemplate.org/ --- it's a wonderful tool, and it looks to me like it may be just what you're looking for. Enjoy! Dov
Re: Fuzzy fonts (Hebrew)
Peleg Michaeli wrote: Thank you all for your replies! I will try ivritex's mailing list; it's quite weird, because I do have culmus fonts installed - the problem is with ivritex, still? Probably. My understanding is that most of the functionality of ivritex has already been incorporated into babel (3.8, I believe). However, that does *not* include usage of the culmus fonts --- so the fact that they're installed in the system doesn't mean that latex knows how to use them yet. That is still under development under the auspices of ivritex, and can be downloaded here https://sourceforge.net/project/showfiles.php?group_id=33341. But I think that it's not complete yet, though I'm not sure. So here's what I would do: 1) try installing culmus-latex from the above link, and see how it is. You might want to try the subversion repository, which is slightly more up-to-date. 2) If it's not good enough, get in touch with the ivritex mailing list and see if anyone knows what the current status is: is this still being developed? Will this work ever be incorporated into babel, too? 3) It would be interesting to understand how the culmus fonts *do* already work in latex on Windows --- maybe that can point in a direction for getting it working on Linux, too... Agai, the ivritex list is where I would pursue this... Anyway, it is comfoting that you can see both in a good quality. Yes, I am not using adobe reader (since it is not free software); I am using just simple PDF viewer (actually, Evince 0.8.1) - for the experiment, I have tried a different PDF viewer - KGhostView 0.2.0 - and it looks much better - but this software is awfully slow and have problems with zoomings. Hmmm, I guess you're more idealistic than me... I have found that the quality in Acrobat Reader (which is at least free as in beer) is often significantly better than the open source alternatives that I have tried --- though I haven't tried these in a couple of years, so things may be better today. I'm sorry to hear the evince isn't better, I was hoping that perhaps it would be. You might want to try okular --- it's the new KDE viewer, still under development, I believe. Haven't tried it myself, though... Dov
Re: Fuzzy fonts (Hebrew)
Peleg Michaeli wrote: Hey... First of all - thanks for your reply. Before I do all of your suggested tests (which I will do) I just have to say: it seems like the pdf you've sent me has fuzzy Hebrew as well! Perhaps the problem is with the pdf *viewer* that you're using? Some files I use look horrible in gv, but they're fine using acroread... Well - as I understand, PDF should embed the fonts inside it, so it's not impossible that we see the documents in two computers in two different ways; so for the example, I will add here links to two documents that I have generated using LyX, one while I had Windows, and one in my ubuntu. The two documents are generated from the same source file, so you'll probably see the huge differences. The link to the "windows" generated PDF is here: - http://www.freeall.org/peleg/math/TOP_MMN16-C-windows.pdf And the link the the "ubuntu" generated PDF is here: - http://www.freeall.org/peleg/math/TOP_MMN16-C-ubuntu.pdf See the difference? Hmmm, not really :( ... both files look OK to me. Of course they use different fonts --- on Windows you're probably using the culmus fonts, and on ubuntu the fonts that come with ivritex (which are not yet culmus fonts, and not as nice) --- but in terms of "quality" I don't see a difference... Regarding the use of culmus fonts on linux, there has been some work in that direction going on in ivritex, I strongly urge you to ping the mailing list there to see if there's any progress with this (and I don't really know the details, they may be able to confirm whether or not what I'm saying is correct). Here is the source for BOTH of the PDFs: - http://www.freeall.org/peleg/math/TOP_MMN16.lyx Thanks again, hopefully I will do the rest of the tests some other time. Peleg.
Re: Fuzzy fonts (Hebrew)
Peleg Michaeli wrote: Hello. Since I have moved to Linux (ubuntu 7.04) and installed LyX (1.5.1) (before that I had Windows XP and LyX 1.5.something), my PDF documents are generated with low quality, both in Hebrew and English; though, DVI/PS documents are fine. I believe that it is somehow related to fonts; and I guess that this is a problem with pdflatex and not directly with LyX; but when I tried to generate PDFs from pure .tex files (with Hebrew) using pdflatex, it seems like it wasn't fuzzy, so maybe LyX DOES have something to do with that. For sure, I will add here two files that I have tested. The first test is in Hebrew and is very simple; I have tried it with pdftex command, and it worked fine. here is the code: Hi! I'm afraid I can't help too much, but it does sound like the problem is with fonts or with the tex setup, and not with LyX per se. I tried generating from the LyX file you attached and it looks fine to me (see attached; BTW, your binary attachments don't seem to have made it through...). Here are a few things you can try: *) try going the ps2pdf or dvipdfm path, instead of pdflatex. Does that make any difference? *) try exporting from LyX to .tex (both plain tex and pdflatex), and then generating the pdf from those files as if they were pure .tex. Does that work? *) If none of these things help, I would also try asking on the ivritex mailing list --- chances are someone there will be able to provide more help. Also, try providing more information abut your setup: what tex distribution are you using (TeXLive, tetex, ...)? Once you provide the answers to the above issues, perhaps we'll be able to figure out what's going wrong... Good luck! Dov a1.pdf Description: Adobe PDF document
visual cursor mode (Bidi)
Hi! I've just committed to 1.6.0svn a series of patches which add the option of "visual mode" for bidi cursor movement. This patch series is *not* going to be ported back to 1.5.x, that would be too complicated at this point. And as 1.6.0 is nearing (?) an alpha release, I hope this won't be too troublesome. I'd be happy to get some feedback about this from anyone who is capable of compiling from svn and is interested in testing this out. I'm sure that there are some tweaks that will be necessary. Also, there were a few issues which were discussed some months ago, and which I felt could be better addressed once visual mode was implemented (e.g., behavior of spaces at RTL/LTR boundaries, etc.). Finally, there are some specific issues which are directly related to visual mode, which have not been implemented yet, and which I hope to complete: *) ctrl-LEFT and ctrl-RIGHT (word-at-a-time movement), HOME and END keys *) switching between RTL and LTR languages at an RTL/LTR border sometimes causes the cursor to jump; I consider that behavior acceptable for logical mode, but not in visual mode *) tables and matrices (and multiline math in general) have not been tested, and I'm also not sure what the correct behavior should be in all these cases So, again, I'd be happy to get any feedback, and if there are problems, it would be great if a minimal LyX document which shows the anomalous behavior could be attached. Dov
Re: Compare Changes/Differences between LyX Documents
Juergen Spitzmueller wrote: Bo Peng wrote: http://www.cs.bgu.ac.il/~dekelts/ldiff/ Quite interesting, do you see any hope of integrating this to lyx? ldiff basically just compares tex files (LyX files are converted to tex via lyx -e by the script). I think we should build in some native comparing feature instead (which will mark differences with our change tracking markup). IIRC we have an enhancement request about this. Jürgen Once we move to the xml format, we may be able to leverage some generic xml-diff tools. One that seems quite good (though not very active): http://www.logilab.org/859/ Dov
Re: Hebrew on Mac OS X
Alexander Maryanovsky wrote: On Dec 19, 2007 8:14 PM, Dov Feldstern <[EMAIL PROTECTED]> wrote: Hi! Abdel, thanks for the heads up. I just haven't been able to keep up with the mailing list / development in the past few weeks... :( I don't really understand much at all about the packaging. My understanding is that these are LaTeX issues, over which LyX has no control, and which are also very platform specific. So I'm afraid I can't be of much help here... Dov, I'm not an expert, but my understanding is also that my issue is a LaTeX issue. I think, however, that you're missing my point. On platforms where a package manager is the standard way to obtain software, LyX installs great, and I have no complaints. On platforms where the standard way to obtain software is by downloading a file from a website (Windows, Mac OS X), however, an application should, whenever possible, include all of its dependencies in the installation file. Basically, my point is that It is not user-friendly if an application does not work properly out-of-the box. I am not disputing that. As I said, I just don't know anything about the packaging, so I can't help out here. And as Abdel said, any contributions are, of course, welcome... Dov
Re: Hebrew on Mac OS X
Abdelrazak Younes wrote: Alexander Maryanovsky wrote: On 12/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: It means that the jesus font (an hebraic font) is unavailable on your system. I guess that you have to install the hebrew package on your latex distribution to get a set of hebrew fonts. I just installed ivritex-dist (http://downloads.sourceforge.net/ivritex/ivritex-1.2.1-dist.tar.gz by copying its contents into ~/Library/texmf) and now the error isn't displayed, but all Hebrew text appears blank in the output file, be it DVI or PDF (English text appears fine). I know this isn't a LyX issue, but could you help me anyway, or at least point me somewhere where I could get help? On a related note, don't you guys think that an application should work out of the box, without having to go hunt around the internet for packages and such? Sure and you are welcome to help us toward this goal ;-) If LyX claims to support Hebrew, why not go all the way and include all the required stuff in its installation? Are the licenses incompatible or something? Any investigation is welcome. We only have one Hebrew developer (Dov, are you reading this?) and he will gladly accept your help. Abdel. Hi! Abdel, thanks for the heads up. I just haven't been able to keep up with the mailing list / development in the past few weeks... :( I don't really understand much at all about the packaging. My understanding is that these are LaTeX issues, over which LyX has no control, and which are also very platform specific. So I'm afraid I can't be of much help here... And I second Charles suggestion: the ivritex mailing list could be helpful regarding hebrew-specific latex issues. I seem to recall that there was someone else asking about Mac OS X a few months ago, so you might also want to search the ivritex archives. Sorry I couldn't be of much help... Dov
Re: long inlined math inside right-to-left article
Yitzhak Zangi wrote:
I write Hebrew article, and when an inlined formula exceeds the length of
the line, it breaks and it is starting from the (left) end of the line till
where the text ends, and resuming in the middle of the next line to the
(right) begginning, so the text resumes in the middle of the line. (I think
everyone who writes in both languages know this problem)
I tried to fix it by using \{..} command to keep it together, but then all
the fomula is displayed in the first line as too long line.
Using Ctrl-Enter won't help either, because the first line look then short,
and because LyX isn't WYSIWYG, I need to see the output to know if the
formula is broken or not.
Is there any elegant way to fix the problem??
(N.B. I don't know LaTeX yet)
Thanks.
Hi!
I don't exactly understand the issue --- could you perhaps provide a
minimal LyX file in which this problem is apparent? Also, what version
of LyX are you using?
Dov
Re: Configuring LyX for Arabic or Persian
amp3030 wrote: Hi all, I am trying to configure LyX to write in Persian (Farsi) or Arabic, but I cannot do that. I have installed lyx on my ubuntu 7.10 system using Synaptic. I have also installed texlive-lang-arab, texlive-extra-utils and texlive-xetex packages. I followed instructions of the official LyX wiki page carefully, but nothing is gonna working. When I use Farsi/Arabic (Arabi) as the language, an error message says: You haven't defined the languafe farsi/arabic yet. Can anyone help to resolve this? Thanks in advance, Masoud. Hi! Could you please provide a more information: specifically, what version of LyX are you using? What is your default language set to, what is the language of the current document? And what exactly are you trying to do: write the entire document in Farsi/Arabic, just insert a word here or there in an otherwise english document, or what? Dov
Re: LyX1.5.2: Keyboard problem
Nicolás wrote: Hi! In previous versions of LyX I could use (in Windows) (Alt gr + "´") + "o" in order to get an accented o: "ó". In LyX 1.5.2 (and I think also in 1.5.1) this does not work. Is this a bug or do I have to configure something? Thanks! Cheers, Nicolás I have no idea how the mechanism you describe used to work, but here's a long shot: try turning off the "Right-to-left language support" option in the preferences, and see if that makes a difference. If it does, please let us know! Dov
Re: Miximg scripts.
Ernesto Posse wrote:
Thanks. Your suggestion worked, after changing the primary keyboard
map to null. It works with both the mini-buffer command and through
the Text style -> Customize dialog box.
Great! I'm glad I was able to help.
One more question, is the issue of the options for fontenc and babel
addressed in version 1.5.2?
Uwe, do you remember what the story is with this issue, regarding farsi?
(see below for more details)
Ernesto Posse wrote:
But apparently the solution is to modify the options for fontenc and
babel as follows:
\usepackage[LFE,LAE,OT1]{fontenc}
\usepackage[farsi,english]{babel}
So LyX should generate these instead of the default
\usepackage[T1]{fontenc}
\usepackage{babel}
Uwe, I believe you worked on this at some point? I may have thwarted
your efforts then...? Do you know what the current situation is?
Nevertheless, LaTeX does give some warnings:
"LaTeX Font Warning: Encoding `LFE' has changed to `OT1' for symbol font.
Re: Miximg scripts.
Ernesto Posse wrote:
On 9/29/07, Dov Feldstern
wrote:
Ernesto Posse wrote:
I think the arabi package was installed correctly, since MiKTeX didn't
give me any errors. I don't know how else to check if it is correctly
installed (it has about 207 files.) I tried reinstalling it, but I
obtain the same results.
One way to check would be to see if you can "compile" a regular latex
(non-LyX) file with Farsi, maybe arabi includes some Farsi examples you
could test with. If you are able to do that, then it means that
arabi/latex are set up correctly, and the problem is getting LyX to work
with it. Otherwise, it means the problem is with your latex/arabi setup,
and there's not too much point in trying to get LyX to work before you
fix that.
I didn't find any examples in the arabi package, but I wrote my own.
Apparently the error occurs when using the babel package:
This compiles fine:
\documentclass[farsi,english]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8,latin9]{inputenc}
\begin{document}
hello
\end{document}
But if I try to use a command from farsi, such as \alefhamza, I get a
babel error: (even if I don't use babel, which is odd:)
Package babel Error: You haven't loaded the option english yet.
If I add
\usepackage{babel}
I get
LaTeX Error: Encoding scheme `LAE' unknown.
But apparently the solution is to modify the options for fontenc and
babel as follows:
\usepackage[LFE,LAE,OT1]{fontenc}
\usepackage[farsi,english]{babel}
So LyX should generate these instead of the default
\usepackage[T1]{fontenc}
\usepackage{babel}
Uwe, I believe you worked on this at some point? I may have thwarted
your efforts then...? Do you know what the current situation is?
Nevertheless, LaTeX does give some warnings:
"LaTeX Font Warning: Encoding `LFE' has changed to `OT1' for symbol font.
Furthermore, I spoke too soon when I said that just typing worked
fine. When I switch languages, it does seem to correctly switch the
script, except for punctuation symbols. Only latin letters and digits
seem to be correctly rendered, but the rest of the keyboard seems
"stuck" with the other keyboard map. Only when I switch off keybord
maps do I get the correct symbols.
Hmm, this is strange. What have you set your primary and secondary
keymaps to? What is your default language (Tools -> Preferences ->
Language settings -> Language) and what is the document language
(Document -> Settings... -> Language)? Which language seems to be
working correctly, and which does not? Can you give an exact recipe for
reproducing (e.g.: open a new document, set language to , type
"abc"...)?
It's working for me (with a few slight variations on your setup and
recipe -- see below --- perhaps those will help).
Primary: american
Try switching this (primary) to "null" --- I think that means that your
default language will be used.
Secondary: farsi
Default language: English
Things seem to go awry when the language is switched, regardless of
whether keyboard maps are on or off.
(this seems to indicate that the problem is not with the keymaps, but
elsewhere in your system. Could it be that by accident you also switched
the language at the OS-keyboard-level?)
Here's the recipe:
1. Open new document
2. type some text, including punctuation symbols
3. Set language to Farsi (Edit->Test Style->Customize->Language set to Farsi)
Try switching languages by typing "language farsi" in the minibuffer
(Alt-x).
4. Type some text.
5. Set language to English or American (Edit->Test
Style->Customize->Language set to English)
Again, try the same command as above (still with "farsi"! this will
toggle farsi off).
6. Type text. Punctuation symbols are now wrong.
Does this help?
If it does, you can bind the "language farsi" command to a key, see,
e.g., the suggestions here:
http://permalink.gmane.org/gmane.editors.lyx.devel/88941 .
Dov
Re: Miximg scripts.
Ernesto Posse wrote: I think the arabi package was installed correctly, since MiKTeX didn't give me any errors. I don't know how else to check if it is correctly installed (it has about 207 files.) I tried reinstalling it, but I obtain the same results. One way to check would be to see if you can "compile" a regular latex (non-LyX) file with Farsi, maybe arabi includes some Farsi examples you could test with. If you are able to do that, then it means that arabi/latex are set up correctly, and the problem is getting LyX to work with it. Otherwise, it means the problem is with your latex/arabi setup, and there's not too much point in trying to get LyX to work before you fix that. Furthermore, I spoke too soon when I said that just typing worked fine. When I switch languages, it does seem to correctly switch the script, except for punctuation symbols. Only latin letters and digits seem to be correctly rendered, but the rest of the keyboard seems "stuck" with the other keyboard map. Only when I switch off keybord maps do I get the correct symbols. Hmm, this is strange. What have you set your primary and secondary keymaps to? What is your default language (Tools -> Preferences -> Language settings -> Language) and what is the document language (Document -> Settings... -> Language)? Which language seems to be working correctly, and which does not? Can you give an exact recipe for reproducing (e.g.: open a new document, set language to , type "abc"...)? Dov
Re: Language Change
snvv wrote: Hello I use sid debian with LyX 1.5-1 and I have a rather strange problem. When I change language (alt+shift) the LyX menu is activated. Thus, in order to write I have to press once the mouse (cursor) in the text to continue. I thought might be a LyX config but I can't find anything about it. Any suggestion please? sn Hi! It doesn't sound like a LyX config issue, sounds more like a bad interaction between LyX and the Desktop Environment. Here are a few suggestions, though they are probably not what you were hoping for, it's more workarounds than solutions: 1) Pressing Alt a second time may be enough to release the menu, so you don't have to go to the mouse every time you switch languages. 2) You might want to consider changing the key combination you use for switching languages (at the OS- / Window Manager- / Desktop Environment- level). I changed the combination I use, because there are some LyX bindings which I used a lot that contained Alt-Shift (e.g., Alt-Shift-right and Alt-Shift-left to increase/decrease the nesting level, for example in a listing). You can probably do this through the Gnome/KDE configuration if you're using one of those, or directly using setxkbmap. 3) I like using keymaps for switching languages in LyX, rather than switching at the keyboard level. To do that, you go to Tools -> Preferences... -> Look and feel -> Keyboard, and check the "use keyboard map" option. Then select the primary and secondary keymaps that you want (I have 'null' as my primary, which I guess means no keymap). To switch between the keymaps, you have two options: if you're using an RTL language, then just switching to that language should automatically activate the keymap. Otherwise, you have to first make sure that the RTL option is turned off (Tools -> Preferences... -> Language settings -> Language, and *un*check "Right-to-left language support"), and then you can use the Alt-k-1 and Alt-k-2 keybindings to select the primary or secondary keyboard, Alt-k-t to toggle between them (I myself use Hebrew, which is an RTL language, so I don't use these bindings). Note, however, that regardless of how you switch the keyboard, you should also set the language correctly (Edit -> Text style -> Customized... -> Language, or using the "language " lfun), in order to let latex know what language the text is in, so that it can output it correctly. For this reason, using a keymap is an advantage, because then you can create a key binding which will both switch the keyboard and set the language with one keypress. I don't know how to achieve this if you're switching languages at the OS-level. Dov
Re: Miximg scripts.
Ernesto Posse wrote: Great, thanks. I wasn't setting "Edit -> Text style ->Customized... -> Language" properly. Is there a key binding for this option? There is an lfun called "language" which does exactly this, and which you can bind to any key you want. In Hebrew, we use F12 for the binding. I suggest adapting one of the files attached here, just use the language "farsi": http://permalink.gmane.org/gmane.editors.lyx.devel/88941 . Just place the file to your .lyx/bind directory (I'm not sure what the Windows equivalent is, the truth is you could probably place the file anywhere), and select it as your bind file (Tools -> Preferences... -> Look and feel -> User interface). Note that since you're using an RTL language, then you shouldn't even have to use the bindings for explicitly setting the keymap (M-k 1, etc.) --- it should happen automatically when you switch the language. When I am typing, it seems to work, but when I try to view it (for example in DVI) I get latex errors such as: LaTeX Error: Encoding scheme `LAE' unknown. Command \alefhamza unavailable in encoding T1. Package inputenc Error: Unicode char \u8:0' not set up for use with LaTeX. I am trying to mix English and Farsi. I followed the instructions from the Wiki (http://wiki.lyx.org/Windows/Farsi). I am running LyX 1.5.1 on Windows Vista, with MiKTeX 2.6. What could be the problem? I don't know the Farsi stuff, Mostafa is our Farsi expert. But some things I would check: are you sure that the "arabi" latex package is installed and set up correctly? What's bothering me is that the LAE encoding scheme seems to be unknown, I believe that's what should be used for Farsi. Uwe, Mostafa --- any ideas? By the way, I found that in menus.bind, both options for "M-k o" and "M-k x" are set to "keymap-off". If I change one of them to 'keymap-on', it seems to be ignored. I'm not even sure what the keymap-off and keymap-on lfuns are supposed to do... But as I said above, for an RTL language, you shouldn't need any of the keymap lfuns, switching the language should take care of this as long as you've setup the keymaps to be used. On 9/27/07, Dov Feldstern <[EMAIL PROTECTED]> wrote: Ernesto Posse wrote: Is it possible to write a document in LyX (1.5.1) that mixes two (or more) scripts? If so, how? I have been able to install and use an alternative keyboard map for a non-latin script, but, even though one can specify two keyboard maps, I have not been able to find anywhere in the documentation how to select the second map. Thanks. Hi! Yes, it is possible, there are actually a few different ways to do it. However, your success may also depend on which scripts specifically you are talking about. The easiest way is perhaps to just switch the keyboard at the OS-level. Depending on your OS / Desktop Environment, you can probably change the "keyboard's language", and then whatever you type will be in that script. Another option is to use LyX's built-in keymaps. It sounds like you have already discovered this option. In order to use it, you can use the following keybindings: "M-k 1" "M-k 2" to choose the primary / secondary keymap; "M-k t" to toggle between them. Two caveats, though: Firstly, Keymaps currently support only two scripts simultaneously. Secondly, if both scripts you want to use are non-RTL, you have to turn off the RTL option (see the RELEASE-NOTES, or http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_5_X/RELEASE-NOTES#L31?rev=20486). Personally, I prefer keymaps. I have pointed out some of the reasons why in a previous post (http://permalink.gmane.org/gmane.editors.lyx.devel/88939), you can see there if those reasons make sense to you or not, and that may help you decide which method is better for you. Note, however, that regardless of which method you use, you should also make sure that the language of the text (Edit -> Text style -> Customized... -> Language) is set correctly. Otherwise, chances are that latex will choke on the non-latin characters. This is where using a LyX keymap has an advantage: since you can change the keymap from within LyX, you can create a keybinding which will both switch the keymap and set the language using only a single keystroke. I don't know of any way to do this if you use OS-level keyboard support. If you provide a little more specific information (which scripts? what OS are your working on? ...) we may be able to provide further assistance. Dov
Re: Miximg scripts.
Ernesto Posse wrote: Is it possible to write a document in LyX (1.5.1) that mixes two (or more) scripts? If so, how? I have been able to install and use an alternative keyboard map for a non-latin script, but, even though one can specify two keyboard maps, I have not been able to find anywhere in the documentation how to select the second map. Thanks. Hi! Yes, it is possible, there are actually a few different ways to do it. However, your success may also depend on which scripts specifically you are talking about. The easiest way is perhaps to just switch the keyboard at the OS-level. Depending on your OS / Desktop Environment, you can probably change the "keyboard's language", and then whatever you type will be in that script. Another option is to use LyX's built-in keymaps. It sounds like you have already discovered this option. In order to use it, you can use the following keybindings: "M-k 1" "M-k 2" to choose the primary / secondary keymap; "M-k t" to toggle between them. Two caveats, though: Firstly, Keymaps currently support only two scripts simultaneously. Secondly, if both scripts you want to use are non-RTL, you have to turn off the RTL option (see the RELEASE-NOTES, or http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_5_X/RELEASE-NOTES#L31?rev=20486). Personally, I prefer keymaps. I have pointed out some of the reasons why in a previous post (http://permalink.gmane.org/gmane.editors.lyx.devel/88939), you can see there if those reasons make sense to you or not, and that may help you decide which method is better for you. Note, however, that regardless of which method you use, you should also make sure that the language of the text (Edit -> Text style -> Customized... -> Language) is set correctly. Otherwise, chances are that latex will choke on the non-latin characters. This is where using a LyX keymap has an advantage: since you can change the keymap from within LyX, you can create a keybinding which will both switch the keymap and set the language using only a single keystroke. I don't know of any way to do this if you use OS-level keyboard support. If you provide a little more specific information (which scripts? what OS are your working on? ...) we may be able to provide further assistance. Dov
Re: [OT] keymaps
Charles de Miramon wrote: Dov Feldstern wrote: If we're talking about keymaps, then yes, I find them very useful. I posted my reasons on the developers list a while back, and I hope to eventually do some work on improving them, too. See http://permalink.gmane.org/gmane.editors.lyx.devel/88939 . If LyX was capable of communicating with the window manager through dbus, it could send a message "switch the keyboard to Hebrew" when you enter the cursor in a Hebrew text. I don't *want* to switch the keyboard at the system level. As I explained in item (4), I only want to switch the keyboard in my specific application (LyX), not for the entire OS. KWin is capable of launching a window in a specific locale, so you can get an Hebrew LyX in an English desktop. I don't need KWin for that --- I can just set the locale in my shell before starting lyx (or wrapping it in a script, if I want to do that all the time). But anyhow, I'm not sure what the relevance of this is to keymaps: I use a Hebrew keymap in an English-UI LyX, the two issue are totally independent of each other, and they should remain that way. It is not cross-platform, This is a major consideration. but on one platform with a little scripting you can get much more configurability than you can ever code into LyX. For example, you could script then when you enter an Hebrew text a virtual Hebrew keyboard appears on screen. I don't see why keymaps are in the way of this kind of configurability. Keymaps have a very specific use, and for my needs at least, they do what they're supposed to do better than any of the alternatives. If you also want to add dbus support --- for this or for any other purpose, then by all means, do (though the cross-platform issue would have to be considered). As I've mentioned already, I don't see why anyone should *object* to keymaps. If you prefer the alternatives, the keymaps don't interfere with them in any way. But for those of us who *do* like keymaps, they are very useful, and can be made even more so with a little more work (which I still hope to get to eventually). Cheers, Charles Dov
[OT] keymaps (was: Re: dead keys)
Charles de Miramon wrote: By the way, is there anybody who uses this lyx-specific keyboard configuration ? In my opinion, it looks like a relic of the past and a useless layer of complexity. Keyboards should be configured OS-wide. If we're talking about keymaps, then yes, I find them very useful. I posted my reasons on the developers list a while back, and I hope to eventually do some work on improving them, too. See http://permalink.gmane.org/gmane.editors.lyx.devel/88939 . However, I don't really know anything about dead-keys (I don't use them), so I'm not sure if it's the same keymap mechanism or not... Cheers, Charles Dov
Re: Problem with Hebrew Lyx - Reply
Gideon Livshits wrote: Hello! Firstly, I would like to thank you for your quick response to my problem. It means a lot! You're welcome. In general, you'll find people on the lyx mailing lists to be very responsive and helpful :) . (BTW, I'm CC-ing the mailing lists, so that this gets into the mailing lists archives, and may prove useful to other users. For those other users: this is correspondence regarding http://bugzilla.lyx.org/show_bug.cgi?id=4228) I sent an example file to the following address: [EMAIL PROTECTED] I attach it again here. The file you sent works for me --- so my guess is that it's a latex configuration issue. See below... Soon after posting the bug, I realized that I should have kept the encoding default, which I did (as you mentioned). This changed the list of errors - from about 8 to only one, in which it complained it was lacking the jerus10 font, and therefore would produce neither dvi nor postscript. To clarify, I am giving you all the relevant details: Under Document Settings I have made the following changes (to accommodate Hebrew): Document Class: article (Hebrew) Postscript driver: Dvips (tried this because I saw the others weren't working - it too doesn't work) Fonts: Changed nothing (kept defaults) The same goes for everything else, I only changed the language to Hebrew. I *kept* the original tick under "Use language's default encoding". Under Preferences the only change I made was to select Hebrew as the default language instead of Hebrew (which I think is wrong anyway, since it apparently applies to the language of interface, which I want to stay in English). (Hmm..., I think the user interface also has to do with locale settings --- you should be able to change the default document language without changing the UI, maybe by playing around with those. If you're compiling from source, you can use the --disable-nls option when configuring, and then the UI will certainly not change... But this has nothing to do with the main problem we're discussing.) So here it is: User interface file: default Bind file: mac Default Language: Hebrew. (also as an aside: some additional LyX setup which you might want to perform is to use keymaps --- these allow you to use Hebrew without having to switch languages at the keyboard level; and then also to have some keybindings for switching languages. See Dekel's instructions at http://www.cs.bgu.ac.il/~dekelts/lyx/instructions2.html, though you'll have to play around with it to see which parts you want and which you don't, they may not be up to date; and see http://permalink.gmane.org/gmane.editors.lyx.devel/88941 for key bindings files --- I would use these instead of the ones Dekel mentions.) My Latex distribution is LiveTex 2007. You mention ivritex - I don't know what this is, and I don't have it installed (at least I think I don't). Would this fix everything? Do you know where I could get it? ivritex (http://ivritex.sf.net) is the name of the project for adding Hebrew support to babel. It used to be a standalone package, but has been incorporated into the latest versions of babel, so if you have babel 3.8 then it already includes hebrew support built-in. However, you may still need other support packages (fonts, etc.). I'm using TeXLive 2007 (I assume this is the same as LiveTeX?), though I'm on Linux/debian. This already uses babel 3.8, so there's no need for installing ivritex separately. There's a debian package called texlive-lang-hebrew, which provides a latex package called cjhebrew which provides the additional support needed. Try and see if you have some similar package that you could install. Another option is to use the culmus fonts. For that, I think that you'll have to download the culmus fonts (http://culmus.sourceforge.net/, chances are it's also bundled for your OS), as well as install (from source) culmus-latex, which is an in-development part of ivritex for supporting the culmus fonts (http://sourceforge.net/project/showfiles.php?group_id=33341). Just installing that package may be enough. In either case, I think one or both of the two options mentioned above is what will solve your issue (again, let us know either way). If you still need more help with correctly setting up Hebrew with LaTeX, you should also check out the ivritex mailing list. Thanks a lot for all your help, Gideon P. S. Please tell me if I missed something or if you need more information. Good luck, Gmar Hatima Tova! Dov
Re: LyX cannot entirely change the document language - now bug 4062
Helge Hafting wrote: Dov Feldstern wrote: Helge Hafting wrote: Paul Smith wrote: Thanks, Steve. If it is not a bug, then many users like me -- I guess -- would be very happy if they were given the option of choosing as global the change of language, i.e., affecting all paragraphs and not only the the new ones. Such an option already exists: select whatever you want to change --- the entire document, if that's what you want --- and then set the language from "Edit->Text Style->Customized", Exactly what users don't want. First - this can be lots of work if you have many pages to change with lots of little foreign snippets inbetween that you don't want to change. (quoutes, tech terms and so on in a different language.) Second, starting to write a document with the wrong language is common for people who work with several languages. You don't notice the wrong language at all if both languages uses the same writing system, which is the case for the many european languages that work with latin1. You don't see it until you run the final spellcheck, or notice weird hyphenation when doing view->dvi. or using the "language xxx" lfun from the minibuffer. Switching the language of a document may have other effects, such as determining language-dependent document-wide settings, as well as determine the "default" language when you start typing, but it would seem very strange to me if it also change the language of already typed in text. Not strange at all. Document text that isn't explicitly set to some language, is in the "document language" and changes if that language is ever changed. This is very convenient. I can see that this will be different with languages that uses different writing systems, such as english and hebrew. Changing one to another might be meaningless with no common letters. But then, anyone wanting to type hebrew will notice right away that their new document is set to english. I guess this is the crux of our disagreement... As you yourself said, it'll never happen that one types anything in Hebrew and only later realizes that he's been typing in English, it's just not possible. But what does often happen is that you start typing a mixture of English and Hebrew, and then at some point realize that this should really be a Hebrew document, so you switch the language of the document, but you certainly don't expect all existing English paragraphs to become Hebrew... In that case, I don't dispute the validity of this bug report. But I do want to clarify that when it is fixed, care should be taken not to change the behavior regarding RTL languages. I'll add a note to this effect to the bug report. Ideally, I guess the determination of whether or not to preserve the language of "default" text when switching the document language from A to B should be something like this: if A and B have the same alphabet (which I don't think we can check --- but what about if we would use the encoding as a surrogate --- would that work for you?) then all "default language" text should remain "default", i.e., it is now considered to be in language B. However, if B has a different alphabet (encoding) than A, then all text marked as "default" should now be explicitly marked as A. Does that sound right? Note, however, that this could be very confusing, because sometimes the language will change, and other times it won't, and the user may not understand why it is or isn't in any specific case... Dov
Re: LyX cannot entirely change the document language - now bug 4062
Helge Hafting wrote: Paul Smith wrote: Thanks, Steve. If it is not a bug, then many users like me -- I guess -- would be very happy if they were given the option of choosing as global the change of language, i.e., affecting all paragraphs and not only the the new ones. Such an option already exists: select whatever you want to change --- the entire document, if that's what you want --- and then set the language from "Edit->Text Style->Customized", or using the "language xxx" lfun from the minibuffer. Switching the language of a document may have other effects, such as determining language-dependent document-wide settings, as well as determine the "default" language when you start typing, but it would seem very strange to me if it also change the language of already typed in text. I think this is a bug, in the "paste" mechanism. You can change the language of all paragraphs (except those with an exlicit foreign language) by changing the document language. But this only works if you _wrote_ the document that way. If you _pasted_ as little as a single word from a document with another language, then this screws up. (_Writing_ that foreign word and using edit->text style to mark it foreign will work - you can still change the document language and have everything else change with it.) This is very strange --- I see the behavior you're describing with regard to, say, English and French, but not (thank goodness) with regard to English and Hebrew: In other words, when I have typed (or pasted) in something in English, and the switch the document language to Hebrew, then what's already been typed or pasted in remains in English, as I would expect. The behavior that's occurring with English and French seems very strange to me, what I would expect is for all text that's already been typed in to remain in its original language. If the user explicitly wants to switch the language of text that's already been typed in, it can be done as explained above. I tested and reported this as bug 4062 Helge Hafting
Re: LyX cannot entirely change the document language
Richard Heck wrote: Paul Smith wrote: On 7/24/07, Steve Litt <[EMAIL PROTECTED]> wrote: > After having written a piece of a document, there is apparently no way > of changing the overall language of the document, in the sense that > the part already written remains as written with the previous > language, i.e., looking in the LyX file with a text editor, one sees > > \lang "previous language" > > before of each paragraph previously written with the old language. > > I am using LyX 1.5.0rc2 on Fedora Linux 7. > > Do you confirm this as a bug? This sounds like a bug to me. You can see what LyX is doing: It's changing the global language but keeping the language of each extant paragraph. But that's probably not what the user expects. Richard I don't think this is a bug. It seems perfectly logical to me that changing the language of a document doesn't change the language of anything that's already been typed in. Changing the language of a document may affect overall things, like where page numbers appear, or other such language-specific conventions. But it shouldn't change text that's already been typed in. That would seem very strange to me... If I want to change the language of already typed in text, I can select it, and then change its language. Dov
Re: using rc1
Sven Schreiber wrote: Abdelrazak Younes schrieb: I think these bugs will not show up in RC1 if you disable the "RTL support" option in the Preference->Language Settings->Language option. Very interesting, thank you for the hint! I don't mean to be disrespectful for RTL language users, but maybe disabling that option by default would be safer? (Assuming that the majority of lyx users don't use RTL.) thanks, sven :) . Actually, we are now experimenting with going in the other direction --- i.e., enabling this option by default --- and we may in the future get rid of the option entirely (i.e., have it always on). So it would be better if (as soon as you're using a version in which the above bugs are fixed) you would switch the RTL option back on, and then let us know if you see anything bad resulting from this: more bugs, slowness (which is solved by turning RTL off), etc. If we see that it really affects non-RTL users adversely, then we will go back to having it off by default. But if it doesn't hurt, we'd rather have it on. Dov
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: Hi, I already replied Stefan off list, but I will post this again so anyone can comment. The brain (at least mine) does not like movement to the opposite side. When you press the left arrow, you expect the cursor to move to the left. Try riding a bike with the hands crossed, wear a helmet!!! So I think the visual movement is the most convenient and intuitive. Microsoft Word is an example of how NOT to do it. It does not change the RTL or LTR mode except by an explicit request by the user (ALT-SHIFT), and even as you cruise into a RTL part, and you want to add a letter, if you were writing English before, the added letter will be English. And the cursor movement is to the opposite side (it jumps to the end of the RTL, and goes backwards in opposite of the arrow key). As far as getting used to logical movement, you can get used to anything, but it is easier to get used to good things. Nobody complains about Word since the Israeli market is small and big companies always do us (the Hebrew users) a "favor" by thinking about us at all, so we accept whatever is given us. I would like lyx to be a little smarter, and to change its RTL or LTR mode by itself as you move across already written text. When you point at a word, the most COMMON intention is to add letter or fix spelling or continue writing, so lyx should already put you in the right language (it doesn't do so now). If you want the opposite language, I think you should ask for it explicitly once you are in place. Thanks for the interest. Miki "Stefan Schimanski" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hi all! Instead of replying individually to all the messages on this subject, I'll try to sum up my responses here. First of all, just for the record --- as Miki pointed out, I *am* an RTL user ;) . I also have a lot of experience with Bidi editing in LyX. It's just that this issue is particularly thorny --- because what I consider to be the correct solution (the one that does not impose limits on the user) is 99.9% of the time *not* what the user meant (I'll explain below). - But first: a side issue which has been raised in this thread is that of "visual movement". A feature request for this already appears in bugzilla (http://bugzilla.lyx.org/show_bug.cgi?id=3577). Note, however, that this should *not* replace logical mode, but rather be an option for the user to choose which she prefers. Regarding implementation of visual mode: *) I agree 100% with Miki above about how it should work: the current language should be determined by the current font, *not* by remembering what the last font was. *) The basic idea for implementing visual mode is dead simple: pressing RIGHT in LTR paragraphs (LEFT in RTL) should move to position vis2log(log2vis(pos)+1), and the opposite is with -1. (vis2log and log2vis are in Bidi.cpp. In this case, Stefan, I think you're going to *have* to use them, I don't see any way around it). But there are a lot of details to work out: there may still be issues of boundary, I'm not sure; there also may be some logic needed in order to make the transitions between paragraphs behave correctly (e.g., I'm in an LTR paragraph moving RIGHT. When I reach the end of the paragraph, pressing RIGHT again should move me to the *end* of the first line in the next paragraph if it's RTL. I'm not sure if this is already covered by vis2log or not.); math insets would have to be adjusted separately, I think. But basically that's it. But I think it'll take a little work to work out the kinks. I'm attaching a patch which just demonstrates the feasibility of this approach. It crashes all over (or shall I say: left and right?) --- I don't deal with any edge (no pun intended) case whatever. But if you type in some mixed English--Hebrew text on a single line, with the mouse move the cursor somewhere that's not at an edge, then you can move around visually as long as you stay away from the edge. But the problem, of course, is working out all the details... In the meantime, we have tried to make cursor movement in bidi documents behave a little more predictably: In an LTR paragraph, RIGHT moves forward (logically) --- both in RTL and in LTR texts (so in RTL it's moving opposite to the arrow, yes) --- and LEFT backwards. And the reverse for RTL paragraphs. Insets (e.g., footnote) within a paragraph also follow this rule: in an RTL inset inside an LTR paragraph, arrow direction will be "backwards". This was implemented in order to avoid the cursor getting "stuck" between RTL and LTR insets, as it used to up until now. Two other differences which provide the user with some visual feedback which make typing bidi a little easier: 1) The language of spaces is now marked; so if something funny is happening with spaces in bidi, it's a little easier to figure out why. 2) As in previous versions of LyX, the cursor will now c
Re: Linus on GIT and SCM
Dov Feldstern wrote: http://developers.slashdot.org/article.pl?sid=07/06/03/004214 Sorry about this --- sent to the wrong address. ;) Some of you may still find it interesting, though --- it sounds like he trashes SVN...
Linus on GIT and SCM
http://developers.slashdot.org/article.pl?sid=07/06/03/004214
Re: Physical units
Miki Dovrat wrote:
Hi,
Do you know how to make a protected half space, so the units don't come out
on a different line than the number?
Miki
Well, if you put it inside an equation, then the thin space itself *is*
protected. BTW, inside an equation you can also type in the thin space
as \, .
I created a math macro for myself called units which does the following:
#1\,\mathrm{#2}
Then, to type in units you just have to Ctrl-m (enter math mode) \units
space (enter the value) RIGHT (or LEFT in an RTL paragraph) (enter the
units) space space. The result has a protected thin space, with the
units in roman letters, as they should be.
Dov
"Uwe Stöhr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Steed, Robert J schrieb:
I'm starting to write my thesis in Lyx and it so happens that I need to
use microns(?) in my physical units alot. But I can't get a non-italic ?
in math mode. Unicode doesn't seem to work either I get error messages:
Package inputenc Error: Unicode char \u8:μ not set up for use with
LaTeX.
As you are using LyX 1.5 you can enter it directly via the keyboard. The
only thing you have to do
is to use the default encoding for English in your case. Attached is a
LyX-file showing this.
You can alternatively use the ERT-command
\textmu
when you add this to your document preamble:
\usepackage{textcomp}
Concerning units, don't forget that there is only a hlaf space between
number and units. A half
space is produced in LyX with the shortcut "Ctrl-Shift Space" (menu
Insert-> Formatting -> Thin
space), see also the attached example.
regards Uwe
Re: Physical units
You could probably create a macro for it, which would make the input
much easier --- you would only need to use the ERT once, when creating
the macro. (I haven't use the SIunits package, maybe it's simple enough
to use that macros are not even necessary; but if you find yourself
typing a lot of ERT over and over again, it may be helpful).
To learn about how to create and use macros in math, see the User Guide,
Section 5.6. I think there's been quite a bit of development regarding
math macros going on lately, I'm not sure though how much of it is
already in the beta versions.
Good luck!
Dov
Steed, Robert J wrote:
I think that its working. I have to use ERT to do it, right?
Thanks for the speedy reply.
Rob
-Original Message-
From: Brian Larsen [mailto:[EMAIL PROTECTED]
Sent: Wed 30/05/2007 15:40
To: Steed, Robert J
Cc: lyx-users@lists.lyx.org
Subject: Re: Physical units
I use the SIunits package for latex to do all my units. It is a bit
cumbersome until you get the hang of it but then works great. I just
include it in the LyX preamble, here is what I use in the preamble for
siunits:
% new commands using SIunits.sty %%%
\usepackage[thickqspace,thickspace,amssymb]{SIunits}
\usepackage{amssymb,amsmath,amsbsy,amsfonts}
\newcommand{\ev}{\electronvolt}
\newcommand{\kg}{\kilogram}
\newcommand{\cm}{\centi\meter}
\newcommand{\npcmcubed}{\cm\rpcubed}
\newcommand{\npcmsquared}{\cm\rpsquared}
\newcommand{\npsecond}{\reciprocal\second}
\newcommand{\nm}{\nano\meter}
\newcommand{\mps}{\meter\per\second}
\newcommand{\npmps}{\meter\usk\npsecond}
Cheers,
Brian
On 5/30/07, Steed, Robert J <[EMAIL PROTECTED]> wrote:
I'm starting to write my thesis in Lyx and it so happens that I need to
use microns(?) in my physical units alot. But I can't get a non-italic ? in
math mode. Unicode doesn't seem to work either I get error messages:
Package inputenc Error: Unicode char \u8:? not set up for use with LaTeX.
Does anyone know what I should do?
I'm using lyx-1.5.0beta3 and miktex on winxp.
Thanks
Rob
Re: lyx-1.5 beta3 bug
Rodrigo Fresneda wrote: Hi, everyone. I have been using lyx-1.5 beta 3 for some time now, and so far everything works very nicely, except, perhaps, that the cursor movement is very slow. Regarding the slowness, please try to turn off the RTL option (Tools -> Preferences... -> Language settings -> Language -> Right-to-left language support) and see if that makes any difference. Please let us know either way! Thanks! Dov
Re: LyX 1.5(beta3) bugs/opinions/suggestions
Michal Ramsza wrote: Hello, 1. Try to write $x \leq y$ - the \leq part is displayed as an empty box instead of the right symbol. This likely has to do with the particular screen font that you're using. I know that I sometimes see those empty boxes instead of characters which do not appear in the particular font I'm using (I think, though I'm not certain, that math is affected by this as well). You can change the screen fonts through Tools -> Preferences... -> Look and feel -> Screen fonts.
Re: [bug - lyx 1.5.0beta1] changing keyboard in lyx 1.5.0beta1
Hi! Georg just fixed the keyboard issue today in svn1.5.0. So now both of these issues should be solved. Let us know if this is not the case... Dov Miki Dovrat wrote: Yes, I already filed bugs on these issues prior to the beta release. Miki "Micha Feigin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I tried lyx 1.5.0beta1 on my linux system and I ran into two problems: changing the keyboard doesn't work (it continues to write in english on screen despite doing something else in the output). right to left text apears left to right Anyone else notice that also?
Re: [bug - lyx 1.5.0beta1] changing keyboard in lyx 1.5.0beta1
Micha Feigin wrote: I tried lyx 1.5.0beta1 on my linux system and I ran into two problems: changing the keyboard doesn't work (it continues to write in english on screen despite doing something else in the output). right to left text apears left to right Anyone else notice that also? Hi! (1) Regarding the second problem you describe, I just sent in a patch fixing the bug, see http://thread.gmane.org/gmane.editors.lyx.devel/79740 (or the lyx-devel mailing list) for details. (2) Regarding keyboard input, you need to do two things together: also change the keyboard input, and also switch the language (F12 with dekel's bindings). See http://thread.gmane.org/gmane.editors.lyx.devel/74576/focus=74622 for details. Note that it's no longer necessary to recompile in order to get the correct encodings, but you may still want to play around with cp1255/auto/default. HTH! Dov
Re: Culmus Hebrew fonts
Hi!
You should also check out this package: http://nikud.berlios.de/ . It is
mainly for using nikud, but as a side effect it also uses the culmus
fonts. It's also really simple to use --- after the initial setup
(explained on the site), all you need to do is use the culmus package
instead of babel. I've used it a little bit here and there, but not very
much --- I'd be happy to hear how this compares to the solution
described below. Please keep us posted!
It seems to me that perhaps LyX should use this package (or something
similar) by default, since the default ivritex fonts are not great ---
especially when it comes to bold or italics... How would one go about
doing something like that? (not that I have time to do that at the
moment, but maybe someone else could...?)
Dov
Miki Dovrat wrote:
I actually got it working
I feel I am stating the obvious to the Hebrew users who already KNOW the
answer and didn't have time to respond.
There is a package called "hebfont.sty", written by Boris Lavva, which has
created macros to use all the hebrew fonts (culmus, and the old default
ones) as
\DeclareTextFontCommand{\text..}{\fontfamily{somefontname}\selectfont}
The package was apparently installed in Windows by the culmus.exe pointed to
by the lyx wiki page on setting up Hebrew. I have seen that this package is
a part of ivritex as well.
He lists there all of the following culmus fonts by their names: david,
frank, aharoni, drugulin, yad, ellinia, miriam, nachlieli, as well as the
old fonts which came with previous latex distributions.
These \selectfont commands get cancelled every time a language change is
made from Hebrew to English or math, so they are good for a few words, a
paragraph or so, but I found an explanation how to change the default font
of the entire document and other font related commands here:
http://www.cl.cam.ac.uk/~rf10/pstex/latexcommands.htm
so
\renewcommand{\rmdefault}{ellinia} will change all Hebrew in the document to
the culmus font Ellinia (for example).
It isn't exactly what I want since it also changes back the English font to
its default cmr (It was lmodren), so I will actually have to look how to
change only the left to right parts.
There is much more variety in the culmus fonts, and they look better.
Thanks for everyone who replied on and off the group.
Miki
Re: Descriptions: more than one word in item header?
Urtzi Jauregi wrote: Hi everybody, I am writing a list of items using the LyX Description environment. In LaTeX, I can put as many words as I want in the header of each item (the part that appears highlighted in bold); however, in LyX only the firs word gets highlighted. I've exmined the LyX source code of my file, but I haven't found a clear way of solving this problem. Any suggestions? Thank you in advance, - Urtzi - Hi! Just use a protected-blank (C-Space or C-S-Space, with cua bindings) to separate the words that you want to appear in the item heading. Good luck! Dov
Re: Update to: [announce] LyX150svn builds for Windows
Hi! Try Document -> Settings... -> Language, uncheck "use language's default encoding", and then see if utf8 appears in the list of Encodings. I must warn you that (a) I'm not using the Windows version, (b) I have no idea about Japanese, and (c) I'm not sure that switching to utf8 is really the correct thing to do --- with Hebrew, I find that utf8 doesn't help, rather I need to set the encoding to cp1255, so you may have to switch it to whatever encoding is correct for Japanese. Hope this helps! Dov Stacia Hartleben wrote: Hi, I just installed the LyX1.5.0 beta and I can't figure out how to get the encoding working. I'm trying to do a document which has Japanese text in it but it keeps telling me "change the encoding to "utf8" but I don't know where to do that - help? On 12/21/06, Niklas Huldén <[EMAIL PROTECTED]> wrote: Uwe Stöhr wrote: > [EMAIL PROTECTED] schrieb: > >>> I fixed some bugs and changed a lot in the installer, here's the >>> changelog: >>> https://developer.berlios.de/project/shownotes.php?release_id=11890 >> have other people been successful with this installer ? >> >> I tried the previous version, and the current one. But >> - lyx.bat just opens a dos-box, immediately closes it again and dies. >> - lyx.exe returns the spartanic error message: >> "This application has failed to start, because the applicatioon >>configuration is incorrect. Reinstalling the application may fix >> this problem." > > Hmm strange. Are you on Win2000? It seems that there are two extra > libraries needed that I didn't ship with the installer. The next > version will have them included, so please test out the next version. > I'll release it tomorrow or on Friday. > > regards Uwe > I can confirm this. Same symptoms on a new WinXPhome machine with the installer from 19.12. configure.py says this: >configure.py Traceback (most recent call last): File "C:\Program Files\LyX 1.4.3-5\Resources\configure.py", line 34, in ? def writeToFile(filename, lines, append = False): NameError: name 'False' is not defined Niklas H.
Re: Itemised list spacing
Paul JH Drake wrote:
There are no non-floated items in the immediate vicinity of the list, but
there are some "Here Definitely" floats elsewhere in the chapter - I need to
do this as the float placement is critical and the default placement isn't
adequate.
It sounds to me like the problem has to do at least partly with the
floats, though I may be totally on the wrong track. But if that is the
problem, then what I try to do is first of all figure out what I think
tex *should* be doing: could whatever appears immediately after the list
just as easily have appeared on the same page as the list (i.e., is
there enough room for it there)? Chances are that you'll discover that
it couldn't have, because it's something which shouldn't be broken up,
but there's not enough room for it in its entirety on the same page as
the list.
If it still seems like there shouldn't be a problem, it may help to see
--- just to try and diagnose the problem --- what happens when you try
the following:
*) If you replace one of the lists with a paragraph of plain text which
takes up about the same space which the list should take up --- does the
spacing look any better, or is it still problematic? If it's not any
better, then probably the problem is not with the lists per-se.
*) Alternatively, if you add more items to the list, are the additional
items "squeezed in" on the same page, or do they get added on only on
the next page? If they just get squeezed in onto the same page, with the
spacing looking slightly better, then again --- the problem is not
really the list itself.
*) Thirdly, try adding another paragraph immediately after one of the
problematic lists, between the list and any floats. Does that paragraph
get displayed on the same page as the list?
I haven't really suggested any solutions, though if I'm correct this may
be enough to help you understand what's causing the problem, and then
maybe also to solve it. Otherwise, I'm at a loss...
I don't know about the enumitem package, but you might try inserting the
following as ERT (Insert -> TeX) in the first item of the list
\addtolength{\itemsep}{-0.6\baselineskip}
Thanks, I'll try that.
I'm not sure that I understood exactly what the problem
is --- if the above suggestions don't help, perhaps you could attach an
example LyX file in which the problem you're describing occurs? Also,
what version of LyX are you using?
I'm using lyx-1.4.3-2 with SuSE 10.1 (guru package)
The lyx file is quite big at present - I might attach it if the above doesn't
work.
Perhaps you could copy only a problematic section into a new file. If
that "solves" the problem (i.e., the new file is spaced correctly) that
only strengthens my feeling that the problem is not with the lists
per-se. Either way, make sure not to attach anything you wouldn't want
the whole world to be able to see (like a not-yet-published thesis... ;) )!
Good luck!
Re: Itemised list spacing
Paul JH Drake wrote:
Hi
I'm currently writing my thesis with Lyx and having some problems with the
spacing of itemised lists. At the moment, lists appear to be automatically
spaced to fill the empty space on a page, so I get some lists that look fine
and others with only 3 items spanning an entire A4 page.
I don't know why the lists should be spaced the way you're describing
--- could it be that they are surrounded by something which must fit on
an entire page by itself (e.g., non-floated graphs or tables)?
I've had a look around for solutions, but haven't found any yet. Does the
enumitem package allow correction of this and if so, how do you install it
for use with Lyx?
I don't know about the enumitem package, but you might try inserting the
following as ERT (Insert -> TeX) in the first item of the list
\addtolength{\itemsep}{-0.6\baselineskip}
Of course, you can change the amount (-0.6) according to your needs.
This allows you to change the spacing between items on a per-list basis,
if you have to do it for the entire document then there's probably a
better way.
Many thanks for your time
Hope this helps. I'm not sure that I understood exactly what the problem
is --- if the above suggestions don't help, perhaps you could attach an
example LyX file in which the problem you're describing occurs? Also,
what version of LyX are you using?
Paul
Dov
