2) Due to the current bugs or limitations of the ARABI package
whenever we want to use Farsi we should use Arabic too (because
some of the
shared definitions are defined in Arabic definitions files only).
Moreover Farsi should be called before Arabic. Again there are two
ways:
2-a) It
Bennett Helm wrote:
X Default
o Justified
o Left
o Center
o Right
maybe giving the choice between default or environment default and
custom or force makes it more explicit?
o Default
o Custom
o Justified
o Left
o Center
o Right
it would of course be nicer if we could tell
Bo Peng wrote:
Waiting for two OKs.
Please use this version.
I wonder if there is any side-effect of using something like the attached
instead.
A/
Index: InsetMathHull.cpp
===
--- InsetMathHull.cpp (revision 18837)
+++
May I point you to http://bugzilla.lyx.org/show_bug.cgi?id=3561 again?
This is a critical bug for quite some time in bugzilla without a
clear explanation what the problem is. I added this now as a comment.
It has not much to do with the source view, but with encoding changes
in general,
6) (One other bug!). We should add the command
\selectlanguage{farsi} as an ERT as the first line of the
document.
No need for this. When the document language is Farsi, no switch is
needed. For later switches, this
is currently correctly done by LyX.
Again as I said this bug is
Alfredo wrote:
Edwin Leuven wrote:
unless someone shouts out i am gonna put this in by noon tomorrow (thu 21)
(shouting) You have my ok :-)
enjoy:
http://www.lyx.org/trac/changeset/18842
Mostafa Vahedi schrieb:
I can not give any guarantee about the fix. The author is extermely busy
sometimes. I prefer the manual one for the time being. Then if it stays
more we can do something about it. I have submitted many bug fixes to
the author and I am waiting for his reply.
OK, but
Mostafa Vahedi schrieb:
I can not give any guarantee about the fix. The author
is extermely busy sometimes. I prefer the manual one for
the time being. Then if it stays more we can do something
about it. I have submitted many bug fixes to the author
and I am waiting for his reply.
Neal Becker wrote:
Actually, it's not table. If I put the cursor anywhere in the document, I
have the same result. All the options for alignment are greyed out, and
default is checked.
Uncheck default then.
Default sets the alignment to whatever is preferred for
the paragraph type in
Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's not an
option in the way that the others are.
Sorry, but I consider that a bad argument. Sure, default is a bit
different. That does NOT imply it can't be a radio button like the rest.
To me, default means
6)(One other bug!). We should add the command
\selectlanguage{farsi} as an ERT as the first
line of the
document.
I can see no difference. With and without the
ERT command, the result is identical.
I checked this issue after applying the patches.
Still I have problem if I don't put
I discovered another bug while trying to get nomencl.sty to work for me.
(The latter may be a latex problem - I get no glossary whatsoever,
but no error message either.)
The rater annoying error is that I get latex compile errors whenever
I change the document language!
I.e. view-dvi once,
Mostafa Vahedi schrieb:
OK. So which way are we going to follow? The manual one or
the other one?
The automatic one if possible.
I tested, but it doesn't work for me,
no matter where I call \TOCLanguage.
We should load the babel package this way:
Georg Baum wrote:
Helge Hafting wrote:
I noticed the glossary stuff while translating.
Inserting a few entries as well as a glossary don't
do anything though. No errors - and no glossary.
This should not happen. Glossaries are supposed to work.
I exported the file to tex, and
Helge Hafting wrote:
I discovered another bug while trying to get nomencl.sty to work for me.
(The latter may be a latex problem - I get no glossary whatsoever,
but no error message either.)
The glossary problem is now solved (bad local makeindex)
but the .aux problem remains.
The rater
On 20.06.2007, at 23:30, Bernhard Roider wrote:
Bo Peng schrieb:
On 6/20/07, Neal Becker [EMAIL PROTECTED] wrote:
1.50rc1
When I edit math, previews don't update until I fiddle around a bit.
1. Edit math
2. Click outside math - no update
3. Click inside math again
4. Click outside math
Stefan Schimanski wrote:
This is a critical bug for quite some time in bugzilla without a
clear explanation what the problem is. I added this now as a comment.
It has not much to do with the source view, but with encoding changes
in general, also during TeX export. You basically cannot export
Same problem here:
When editing a nested element in an math inset and clicking outside
the complete formula the preview never (not slowly, never) gets
updated. But this is so far the only case where I can really
reproduce it.
Please file a bugzilla report about it since Jose dictated that
I wonder if there is any side-effect of using something like the attached
instead.
Your patch is better, so you have my OK.
My original thought was to remove outside addPreview so that all
MathHull (and other previewable insets) get their preview in this way
(if preview empty, add snippet). I
Helge Hafting wrote:
The problem is solved. I had a custom makeindex script in order to
support index styles and still use indexes from within lyx-1.3
This script did not work with glossaries though. Removing it
fixed everything.
You know that you can customize the makeindex call now in
On Thursday 21 June 2007 14:36:33 Bo Peng wrote:
Anyway, your patch fixes this specific problem with less code, so it can go
in.
Cheers,
Bo
OK.
--
José Abílio
New doc1 | New doc2 | | Close |
My close button is huge here, please correct it. This is qt422, linux.
Maybe I am lacking an icon?
Cheers,
Bo
Am 21.06.2007 um 16:16 schrieb Bo Peng:
New doc1 | New doc2 | | Close |
My close button is huge here, please correct it. This is qt422, linux.
Maybe I am lacking an icon?
Cheers,
Bo
There should be an icon. And then Qt renders it small AFAIK. Have you
updated your resource
Bob Alvarez wrote:
I hope this is the right place to send this.
You can post such things at bugzilla.lyx.org, but I've added a note to
2714 about it, so no need now.
I usually do not want to start a new paragraph after a display
equation, so I have been setting the next paragraph to
Maybe I am lacking an icon?
There should be an icon. And then Qt renders it small AFAIK. Have you
updated your resource folder?
I have added closetab.xmp to scons_manifest.py.
Cheers,
Bo
On 21 jun 2007, at 13.12, Helge Hafting wrote:
Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's
not an option in the way that the others are.
Sorry, but I consider that a bad argument. Sure, default is a bit
different. That does NOT imply it can't be a
Anders Ekberg wrote:
On 21 jun 2007, at 13.12, Helge Hafting wrote:
Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's not
an option in the way that the others are.
Sorry, but I consider that a bad argument. Sure, default is a bit
different. That does NOT
When editing a nested element in an math inset and clicking outside
the complete formula the preview never (not slowly, never) gets
updated. But this is so far the only case where I can really
reproduce it.
This is now bug 3903.
Bo
and this one doesn't make sense:
if we could tell beforehand what the default was because then we could
show something like:
o Justified (default)
o Left
o Center
o Right
?
On Jun 21, 2007, at 11:38 AM, Edwin Leuven wrote:
and this one doesn't make sense:
if we could tell beforehand what the default was because then we
could show something like:
o Justified (default)
o Left
o Center
o Right
?
Of the options I've seen, I agree that this is the best.
The problem with bug 3903
(http://bugzilla.lyx.org/show_bug.cgi?id=3903) is clear, there is no
notifyCursorLeave when you are not in an InsetMathHull (the outer
level of the inset). Therefore, after you edit in, for example, super
or subscript, math preview is not updated.
There is another
Bennett Helm wrote:
On Jun 21, 2007, at 11:38 AM, Edwin Leuven wrote:
and this one doesn't make sense:
if we could tell beforehand what the default was because then we
could show something like:
o Justified (default)
o Left
o Center
o Right
?
Of the options I've seen, I agree that this is
This patch addresses the usability bugs discussed in this thread:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have
good ideas on these things.) The main change is that the Default
button is now a radio
Bennett Helm wrote:
On Jun 21, 2007, at 11:38 AM, Edwin Leuven wrote:
and this one doesn't make sense:
if we could tell beforehand what the default was because then we
could show something like:
o Justified (default)
o Left
o Center
o Right
?
Of the options I've seen, I agree
Bo Peng wrote:
This is the unfinished part. Numerous LFUNC can contaminate an
inset, what is the best way to know if an inset is modified? I am
thinking of doing an markDiry after each recordUndo, but there are too
many recordUndo's. Is there any way to know if recordUndo() is called?
Why
Bo Peng wrote:
The problem with bug 3903
(http://bugzilla.lyx.org/show_bug.cgi?id=3903) is clear, there is no
notifyCursorLeave when you are not in an InsetMathHull (the outer
level of the inset). Therefore, after you edit in, for example, super
or subscript, math preview is not updated.
On Jun 21, 2007, at 17:28 , Richard Heck wrote:
Anders Ekberg wrote:
On 21 jun 2007, at 13.12, Helge Hafting wrote:
Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's
not an option in the way that the others are.
Sorry, but I consider that a bad argument.
i think frac can go (as in attached) since there are only 2 entries
which are already on the main math toolbar
gonna commit unless someone objects
...
something else entirely:
the panels can be easily added to the toolbar list by putting the
following in default.ui:
latex_deco
The following fix (based on your nice explanation) seems to cure the problem
without major rearrangements, but I didn't tested it well.
Have you fixed 1486 yet. Jose has Oked it so you can commit now,
please remember to close the bug as well.
It is amazing that you can always find better fixes
Bo Peng wrote:
The following fix (based on your nice explanation) seems to cure the
problem without major rearrangements, but I didn't tested it well.
Have you fixed 1486 yet. Jose has Oked it so you can commit now,
please remember to close the bug as well.
I don't have commit rights yet.
You patch seems to work but I do not really understand what is
going on. Could you explain a bit?
I found this notifyCursorLeaves(old, new) function and see what is
going on. If Abdel does not see any side effect of calling too many
notifyCursorLeaves, your patch has my OK.
I, starting from
Have you fixed 1486 yet. Jose has Oked it so you can commit now,
please remember to close the bug as well.
I don't have commit rights yet. Could you do that for me?
I will do that.
Sure, the standalone notifyCursorLeaves calls Inset::notifyCursorLeaves of
all insets in the cursor stack; so
Richard Heck wrote:
This patch addresses the usability bugs discussed in this thread:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have
good ideas on these things.) The main change is that the Default
Bo Peng wrote:
You patch seems to work but I do not really understand what is
going on. Could you explain a bit?
I found this notifyCursorLeaves(old, new) function and see what is
going on. If Abdel does not see any side effect of calling too many
notifyCursorLeaves, your patch has my OK.
That's a great usability improvement!
+1
Bo
I don't know Bo, I think that latex_code() is a reasonably efficient way of
having a signature of the math inset (to check if it has changed). I would
be surprised if this had a real performance impact (typically O(1)
operations per user interaction, we do much worse elsewhere in the code)
OK.
On Tue, Jun 19, 2007 at 06:15:24PM +0200, Jean-Marc Lasgouttes wrote:
christian == christian ridderstrom [EMAIL PROTECTED] writes:
christian On Mon, 18 Jun 2007, Andre Poenitz wrote:
Now that I was too stupid to get my booking right the first time, I
again have a choice of dates.
Bo Peng wrote:
I don't know Bo, I think that latex_code() is a reasonably efficient way
of having a signature of the math inset (to check if it has changed). I
would be surprised if this had a real performance impact (typically O(1)
operations per user interaction, we do much worse elsewhere
Alfredo Braunstein wrote:
This is bad. What if the user changes layout (or worse document class) and
the new layout has different default alignment? You are losing information
here.
ah, i see the problem now.
there seem to be 2 problem cases:
1 x is set and we change the default to x:
2 x
Uwe Stöhr wrote:
Mostafa Vahedi schrieb:
See the attached patch. I implemented this but disabled it because
\TOCLanguage gives me the error
unknown command. Therefore your example-lyxified doesn't compile.
The command \TOCLanguage{} is defined after the call to BABEL in
Latex Preamble.
Richard Heck wrote:
This patch addresses the usability bugs discussed in this thread:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have
good ideas on these things.) The main change is that the Default
if i creat a selection that spans more than one line and then type
something (so that the selection gets replace with my new text), the
selection before the line where cursor is isn't crossed out. there is a
missing screen update here.
second thing is when i delete a collapsed footnote. the
:-) You patch seems to work but I do not really understand what is
going on. Could you explain a bit?
Sure, the standalone notifyCursorLeaves calls
Inset::notifyCursorLeaves of
all insets in the cursor stack; so this catches the parent
MathHullInset.
I was about to write such a function,
Edwin Leuven wrote:
case 2 is in my opinion not so relevant because i don't see why (in the
current solution) one would have default unchecked and then choose the
explicit alignment that matches default behavior
One such cases: I'm in Standard Layout and I want my par centered so I set
it
Uwe Stöhr wrote:
Actually, Mostafa has fixed the last *two* issues for Farsi, but not
for Arabic, so as not to interfere with ArabTex. But at least the
know-how is already in the sources. We only need to figure out how to
allow the option of either Arabi or ArabTeX, so that one doesn't break
Alfredo Braunstein wrote:
Edwin Leuven wrote:
case 2 is in my opinion not so relevant because i don't see why (in the
current solution) one would have default unchecked and then choose the
explicit alignment that matches default behavior
One such cases: I'm in Standard Layout and I want my
Mostafa Vahedi wrote:
Currently (only) Unicode is used for Farsi as the input encoding. Moreover in Unicode the openning parenthesis is always the left one (independent of the language) I have modified the code to reverse the direction of the character-pairs when it wants to display the
Edwin Leuven wrote:
Alfredo Braunstein wrote:
Edwin Leuven wrote:
case 2 is in my opinion not so relevant because i don't see why (in the
current solution) one would have default unchecked and then choose the
explicit alignment that matches default behavior
One such cases: I'm in
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Looking at the timetables, only Finnair gives me an arrival date
of 11h40 on Thursday (which is OK to catch the bus),
Andre I'll be there at 11:55.
OK.
but the return would have to be on monday (12h15) or wednesday.
Last week there were
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Andre Have you checked less direct flights? There still seems to be
Andre Helsinki-Berlin for available ~100 EUR on Tuesday.
Jean-Marc I may not understand their site, but they do not tell me on
Attached is a better patch where everything is implemented:
- correct encoding for the fontenc package. Mostafa tested this and gave his OK
for this issue.
- special quotation mark definitions for Farsi. Mostafa tested this and gave
his OK for this issue.
- fix for bug 2929 - use \textAR and
Mostafa Vahedi schrieb:
But if you put the command \TOCLanguage{farsi} then
if you do not put \selectlanguage{farsi} as the first
command after the \begin{document} or in other words
as an ERT at the first line of the document then you
will receive several complains from LyX about some
Dov Feldstern schrieb:
I haven't read this entire thread thoroughly yet, but you might want to
see if this specific issue is related to
http://bugzilla.lyx.org/show_bug.cgi?id=3555 (only relevant in mixed
language documents, I think, but I'm not sure...)
We don't have this problem here
I will test this now. But even if it all works, this is *not* OK as it
is --- it breaks ArabTeX Arabic. Please see the email I sent earlier
tonight for a patch which separates between arabi and arabtex. This
patch should be implemented over the arabic_arabi language.
I'll get back to you
Attached is a patch from Georg that fixes the regression bug 1942:
Inconsistent look of integral symbols.
I tested it thoroughly will all combinations of the packages esint, wasysym,
and amsmath.
A Mac user has reported a perhaps related problem that I and Georg couldn't reproduce as
Dov Feldstern schrieb:
I will test this now. But even if it all works, this is *not* OK as it
is --- it breaks ArabTeX Arabic.
I don't understand. Currently ArabTeX is never loaded by LyX for Arabic documents so it is also not
used. My patch requires arabi for both languages.
To repeat
Uwe Stöhr wrote:
Dov Feldstern schrieb:
I will test this now. But even if it all works, this is *not* OK as it
is --- it breaks ArabTeX Arabic.
I don't understand. Currently ArabTeX is never loaded by LyX for Arabic
documents so it is also not used. My patch requires arabi for both
Uwe Stöhr schrieb:
I don't understand. Currently ArabTeX is never loaded by LyX for Arabic
documents so it is also not used.
Bug 2928 is the prove for my statement. Bug 2928 occurs because the \R command is not defined. But
when ArabTeX was loaded \R would have been defined. When you load
Uwe Stöhr wrote:
Uwe Stöhr schrieb:
I don't understand. Currently ArabTeX is never loaded by LyX for
Arabic documents so it is also not used.
Bug 2928 is the prove for my statement. Bug 2928 occurs because the \R
command is not defined. But when ArabTeX was loaded \R would have been
I have attached the Farsi keyboard based on Linux Farsi keymap which can be
added to directory LYX_DEVEL/lib/kbd/. The only problem I have is the last
line in which I tried to assign a letter to the double quote, i.e. \, and it
did not work.
couldn't be mapped because it's reserved for
Dov Feldstern schrieb:
So my patch can't break arabTeX as it is already not used.
Correct me when I'm wrong.
see http://permalink.gmane.org/gmane.editors.lyx.devel/88100. If you
follow the instructions there, ArabTeX works perfectly alright in LyX.
You procedure requires a lot of manual
I'm resending this message, as only about half my emails seem to be
getting through tonight. My apologies if you're receiving it twice...
Uwe Stöhr wrote:
Dov Feldstern schrieb:
I will test this now. But even if it all works, this is *not* OK as it
is --- it breaks ArabTeX Arabic.
I don't
Uwe Stöhr wrote:
Dov Feldstern schrieb:
So my patch can't break arabTeX as it is already not used.
Correct me when I'm wrong.
see http://permalink.gmane.org/gmane.editors.lyx.devel/88100. If you
follow the instructions there, ArabTeX works perfectly alright in LyX.
You procedure requires
Dov Feldstern schrieb:
To repeat myself: ArabTeX without arabi can't be used due to the
missing babel interface and
ArabTeX is not babel-based, and therefore doesn't require a babel
interface.
But LyX currenly uses babel to handle the different languages. Therefore arabi will be used when
Uwe Stöhr wrote:
Dov Feldstern schrieb:
To repeat myself: ArabTeX without arabi can't be used due to the
missing babel interface and
ArabTeX is not babel-based, and therefore doesn't require a babel
interface.
But LyX currenly uses babel to handle the different languages. Therefore
arabi
I don't think that bug 3902 should stop you committing your valuable
solution to bug 1942 as, in the Mac case, it provides a considerable
improvement.
I'm not sure that the bug 1942 solution has introduced the problem
of bug 3902 but, rather, has provided visibility to bug 1942.
The
In testing lyx1.5.0rc1 math block problems on a Mac under OSX 10.4, I
have found that starting lyx using src/lyx results in math blocks not
displaying symbols, instead, for example Greek letters display as
English letters with the Greek character mu displaying as English m.
However, if I
Dov Feldstern schrieb:
and one of them has been supported for
a long time, so suddenly switching to the other and breaking
compatibility with the traditionally supported one doesn't seem right.
As I said we never supported arabTeX directly. So we don't switch to something.
Mostafa, what is
Am 22.06.2007 um 02:22 schrieb Roger Mc Murtrie:
In testing lyx1.5.0rc1 math block problems on a Mac under OSX 10.4,
I have found that starting lyx using src/lyx results in math blocks
not displaying symbols, instead, for example Greek letters display
as English letters with the Greek
Pretty trivial patch attached.
Ok?
Andre'
Index: Text3.cpp
===
--- Text3.cpp (revision 18813)
+++ Text3.cpp (working copy)
@@ -973,7 +973,7 @@
docstring hexstring = cmd.argument();
if
2) Due to the current bugs or limitations of the ARABI package
whenever we want to use Farsi we should use Arabic too (because
some of the
shared definitions are defined in Arabic definitions files only).
Moreover Farsi should be called before Arabic. Again there are
Bennett Helm wrote:
X Default
o Justified
o Left
o Center
o Right
maybe giving the choice between "default" or "environment default" and
"custom" or "force" makes it more explicit?
o Default
o Custom
o Justified
o Left
o Center
o Right
it would of course be nicer if we
Bo Peng wrote:
>> Waiting for two OKs.
>
> Please use this version.
I wonder if there is any side-effect of using something like the attached
instead.
A/
Index: InsetMathHull.cpp
===
--- InsetMathHull.cpp (revision 18837)
+++
May I point you to http://bugzilla.lyx.org/show_bug.cgi?id=3561 again?
This is a critical bug for quite some time in bugzilla without a
clear explanation what the problem is. I added this now as a comment.
It has not much to do with the source view, but with encoding changes
in general,
6) (One other bug!). We should add the command
"\selectlanguage{farsi}" as an ERT as the first line of the
document.
>>> No need for this. When the document language is Farsi, no switch is
>>> needed. For later switches, this
>>> is currently correctly done by LyX.
>>
Alfredo wrote:
>> Edwin Leuven wrote:
>> unless someone shouts out i am gonna put this in by noon tomorrow (thu 21)
>
> (shouting) You have my ok :-)
enjoy:
http://www.lyx.org/trac/changeset/18842
Mostafa Vahedi schrieb:
I can not give any guarantee about the fix. The author is extermely busy
sometimes. I prefer the manual one for the time being. Then if it stays
more we can do something about it. I have submitted many bug fixes to
the author and I am waiting for his reply.
OK, but
>> Mostafa Vahedi schrieb:
>> I can not give any guarantee about the fix. The author
>> is extermely busy sometimes. I prefer the manual one for
>> the time being. Then if it stays more we can do something
>> about it. I have submitted many bug fixes to the author
>> and I am waiting for his
Neal Becker wrote:
Actually, it's not table. If I put the cursor anywhere in the document, I
have the same result. All the options for alignment are greyed out, and
default is checked.
Uncheck default then.
Default sets the alignment to whatever is preferred for
the paragraph type in
Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's not an
option in the way that the others are.
Sorry, but I consider that a bad argument. Sure, "default" is a bit
different. That does NOT imply it can't be a radio button like the rest.
To me, "default"
6)(One other bug!). We should add the command
"\selectlanguage{farsi}" as an ERT as the first
line of the
document.
>>> I can see no difference. With and without the
>>> ERT command, the result is identical.
>> I checked this issue after applying the patches.
>> Still I
I discovered another bug while trying to get nomencl.sty to work for me.
(The latter may be a latex problem - I get no glossary whatsoever,
but no error message either.)
The rater annoying error is that I get latex compile errors whenever
I change the document language!
I.e. view->dvi once,
Mostafa Vahedi schrieb:
OK. So which way are we going to follow? The manual one or
the other one?
The automatic one if possible.
I tested, but it doesn't work for me,
no matter where I call \TOCLanguage.
We should load the babel package this way:
Georg Baum wrote:
Helge Hafting wrote:
I noticed the glossary stuff while translating.
Inserting a few entries as well as a glossary don't
do anything though. No errors - and no glossary.
This should not happen. Glossaries are supposed to work.
I exported the file to tex, and
Helge Hafting wrote:
I discovered another bug while trying to get nomencl.sty to work for me.
(The latter may be a latex problem - I get no glossary whatsoever,
but no error message either.)
The glossary problem is now solved (bad local makeindex)
but the .aux problem remains.
The rater
On 20.06.2007, at 23:30, Bernhard Roider wrote:
Bo Peng schrieb:
On 6/20/07, Neal Becker <[EMAIL PROTECTED]> wrote:
1.50rc1
When I edit math, previews don't update until I fiddle around a bit.
1. Edit math
2. Click outside math - no update
3. Click inside math again
4. Click outside math
Stefan Schimanski wrote:
> This is a critical bug for quite some time in bugzilla without a
> clear explanation what the problem is. I added this now as a comment.
> It has not much to do with the source view, but with encoding changes
> in general, also during TeX export. You basically cannot
Same problem here:
When editing a nested element in an math inset and clicking outside
the complete formula the preview never (not slowly, never) gets
updated. But this is so far the only case where I can really
reproduce it.
Please file a bugzilla report about it since Jose dictated that
I wonder if there is any side-effect of using something like the attached
instead.
Your patch is better, so you have my OK.
My original thought was to remove outside addPreview so that all
MathHull (and other previewable insets) get their preview in this way
(if preview empty, add snippet). I
Helge Hafting wrote:
> The problem is solved. I had a custom makeindex script in order to
> support index styles and still use indexes from within lyx-1.3
> This script did not work with glossaries though. Removing it
> fixed everything.
You know that you can customize the makeindex call now in
1 - 100 of 160 matches
Mail list logo
