Can someone on Windows help this person?
https://www.lyx.org/trac/ticket/11173
Riki
bug 9418 is about a crash which happens during mathml generation after
copying a math macro to the clipboard. The bug report shows several
problems, which I'll address eventually, but the actual crash happens
because Buffer::updateMacroInstances() iterates through the insets from
begin to end.
LyX 2.1 will support to set a math font fo the document. If one uses non-TeX fonts, one can choose
for the math font between Computer modern or its non-TeX variant. This is by default the font
"latinmodern-math.otf".
As LyX requires this font, we should check for it in chkconfig.ltx. This is cu
On jeu. 16 juin 2011 18:48:53 CEST, Julien Rioux wrote:
I too am experiencing slowness and sometimes complete unresponsiveness
since maybe a couple days, so don't feel alone.
I looked at it on tuesday and 'top' did not reveal any process that
used too much
memory or cpu. This is a mistery to
On 15/06/2011 11:22 AM, David Hopkins wrote:
Did the website just go offline? I can't access www.lyx.org or the wiki.
Sincerely,
Dave Hopkins
I too am experiencing slowness and sometimes complete unresponsiveness
since maybe a couple days, so don't feel alone.
--
Julien
Am 15.06.2011 17:22, schrieb David Hopkins:
Did the website just go offline? I can't access www.lyx.org or the wiki.
Works for me.
regards Uwe
Did the website just go offline? I can't access www.lyx.org or the wiki.
Sincerely,
Dave Hopkins
On Wed, Jun 15, 2011 at 10:38 AM, Uwe Stöhr wrote:
> Dear LyXers,
>
> we are updating the LyX manuals, templates and example files for LyX 2.0.x.
> In this respect we need your help: Can anybody who
On mer. 15 juin 2011 16:38:09 CEST, Uwe Stöhr wrote:
Dear LyXers,
we are updating the LyX manuals, templates and example files for LyX
2.0.x. In this respect we need your help: Can anybody who uses noweb
please check if our example files "noweb2lyx.lyx", "listerrors.lyx" and
"Literate.lyx" an
Am Montag, 2. Mai 2011 schrieb Jürgen Spitzmüller:
> Kornel wrote:
> > Somehow I lost the ability to access ssh-svn.
> > I mean, I am not able to
> >
> > "svn co
> >
> > svn+ssh://kor...@svn.lyx.org/lyx/lyx-devel/branches/BRANCH_2_0_X" my
> > password will be rejected.
>
> Just try
>
>
Kornel wrote:
> Somehow I lost the ability to access ssh-svn.
> I mean, I am not able to
> "svn co
> svn+ssh://kor...@svn.lyx.org/lyx/lyx-devel/branches/BRANCH_2_0_X" my
> password will be rejected.
Just try
svn co svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_2_0_X
Jürgen
On 05/02/2011 10:08 AM, Kornel wrote:
> Somehow I lost the ability to access ssh-svn.
> I mean, I am not able to
> "svn co
> svn+ssh://kor...@svn.lyx.org/lyx/lyx-devel/branches/BRANCH_2_0_X"
> my password will be rejected.
>
This hasn't worked for a while, I don't think. Try removing the "sv
Somehow I lost the ability to access ssh-svn.
I mean, I am not able to
"svn co
svn+ssh://kor...@svn.lyx.org/lyx/lyx-devel/branches/BRANCH_2_0_X"
my password will be rejected.
The already checked-out data (trunk, BRANCH_1_6_X) are still full functional
though.
Kornel
signature
Since 2 years my installer supports SVG images. This is done by using Inkscape as converter for the
svg images and worked fine until LyX 1.6.3.
Since LyX 1.6.4 this doesn't work and I cannot figure out why. Can you please do me the favor and
apply the attached patch to branch and test out if yo
Helge Hafting wrote:
> Or it might be a translation mistake that fails to preserve
> some special character.
maybe this?
README.localization:
Note also that there are already used global shortcuts (such as p k x c m s a)
and you should avoid to use these characters for first-level menu shortcuts
When using LyX with LANG=C, I can set the "section*" type with
ALT+P * 2
and set "section" using ALT+P 2
When I use LyX with LANG=nb_NO.UTF-8, the latter still works but the
former breaks. When I type the asterisk, I get an asterisk in the
document instead of selecting the starred paragraph typ
> A completely different idea would be to make it the bibbliography way, i.e.,
> let LyX compute the longest label.
Thanks for the tip, I will follow this.
regards Uwe
Uwe Stöhr wrote:
> I thought fixing bug 5909 would be easy:
>
> I modify InsertprintNomencl so that a when inserting the nomenclature list
> or left-clicking on it opens a dialog where the nomenclature label width is
> specified.
A completely different idea would be to make it the bibbliography wa
I thought fixing bug 5909 would be easy:
I modify InsertprintNomencl so that a when inserting the nomenclature list or left-clicking on it
opens a dialog where the nomenclature label width is specified.
So far the theory, but I failed to do so and don't know what I do wrong. Attached is a roug
Today I cleaned up and simplified the fraction in mathed.
This way I also added support for the optional argument of \cfrac. The LaTeX part and the
metrics/drawing works so, but I am unable to set the cursor correctly. Therefore it is currently not
possible to set the cursor to the cell of the o
Jean-Marc Lasgouttes schrieb:
What does not work now? One problem was that you insisted in calling
explicitly InsetText::foo, whereas InsetCollapsable::foo was the right
one.
Yes this was the problem. I missed that you fixed this in the meantime when I
wrote my post.
Sorry for the confusion
Uwe Stöhr wrote:
> I'm a bit confused. What color is being ignored? I do get grey text
in a phantom inset, and I get > red if I put "latex" instead of
"phantomtext".
Sorry for the confusion. That this didn't work was ma fault because I
used InsetText and not InsetCollabsible. JMarc kindly fix
> I'm a bit confused. What color is being ignored? I do get grey text in a phantom inset, and I get
> red if I put "latex" instead of "phantomtext".
Sorry for the confusion. That this didn't work was ma fault because I used InsetText and not
InsetCollabsible. JMarc kindly fixed this yesterday.
Uwe Stöhr writes:
>> See my other mail. Either this needs to be implemented in the standard insets
>> as well, or you need to set the color in InsetPhantom.cpp. See InsetERT for a
>> model.
>
> That was my point. This needs to be implemented to standard insets as
> well. The current implementatio
> See my other mail. Either this needs to be implemented in the standard insets
> as well, or you need to set the color in InsetPhantom.cpp. See InsetERT for a
> model.
That was my point. This needs to be implemented to standard insets as well. The current
implementation is unintuitive and not w
Richard Heck wrote:
> I'm a bit confused. What color is being ignored? I do get grey text in a
> phantom inset, and I get red if I put "latex" instead of "phantomtext".
Jean-Marc's recent cleanup of InsetPhantom fixed this apparently.
Jürgen
Jürgen Spitzmüller wrote:
Uwe Stöhr wrote:
There's still the problem that the color definition for the phantom inset
is ignored in stdinsets.inc. The other definitions work fine as far as I
tested now again.
See my other mail. Either this needs to be implemented in the standard insets
Jean-Marc Lasgouttes wrote:
Jürgen Spitzmüller writes:
rgheck wrote:
If it seems worth it, this could be done for branch, too. There's no
format change---and, as you say, the manual describes the way it works NOW.
Yes, the fix looks simple enough. Is something similar needed fo
Uwe Stöhr wrote:
> There's still the problem that the color definition for the phantom inset
> is ignored in stdinsets.inc. The other definitions work fine as far as I
> tested now again.
See my other mail. Either this needs to be implemented in the standard insets
as well, or you need to set the
rgheck schrieb:
as you say, the manual describes the way it works NOW.
There's still the problem that the color definition for the phantom inset is ignored in
stdinsets.inc. The other definitions work fine as far as I tested now again.
regards Uwe
Jürgen Spitzmüller writes:
> rgheck wrote:
>> If it seems worth it, this could be done for branch, too. There's no
>> format change---and, as you say, the manual describes the way it works NOW.
>
> Yes, the fix looks simple enough. Is something similar needed for other
> elements (font attribute
rgheck wrote:
> If it seems worth it, this could be done for branch, too. There's no
> format change---and, as you say, the manual describes the way it works NOW.
Yes, the fix looks simple enough. Is something similar needed for other
elements (font attributes)?
Jürgen
Uwe Stöhr wrote:
> I think I wrote that FIXME. The issue wasn't so much that I thought
there would be serious
> problems as that, whenever I did this---just before 1.6.0?---it
seemed not to be the right time to
> be messing with such things. The fix now is probably fairly simple.
Many thanks f
> I think I wrote that FIXME. The issue wasn't so much that I thought there
would be serious
> problems as that, whenever I did this---just before 1.6.0?---it seemed not to
be the right time to
> be messing with such things. The fix now is probably fairly simple.
Many thanks for your fix; stdin
Jean-Marc Lasgouttes wrote:
Jürgen Spitzmüller writes:
Jean-Marc Lasgouttes wrote:
You need to set this in the header file. I did that for paragraph
customization and plain layout at rev. 28336.
But how come it does not work in the layout file?
AFAICS it is only imple
Jürgen Spitzmüller writes:
> Jean-Marc Lasgouttes wrote:
>> > You need to set this in the header file. I did that for paragraph
>> > customization and plain layout at rev. 28336.
>>
>> But how come it does not work in the layout file?
>
> AFAICS it is only implemented in InsetFlex so far See this
Jean-Marc Lasgouttes wrote:
> > You need to set this in the header file. I did that for paragraph
> > customization and plain layout at rev. 28336.
>
> But how come it does not work in the layout file?
AFAICS it is only implemented in InsetFlex so far See this FIXME in
InsetFlex.h:
// FI
Jürgen Spitzmüller writes:
> Uwe Stöhr wrote:
>> But I can write what I want, everything is ignored. The color is always
>> black, MultiPar is always false, CustomPars is always true.
>
> You need to set this in the header file. I did that for paragraph
> customization and plain layout at rev. 28
Uwe Stöhr wrote:
> But I can write what I want, everything is ignored. The color is always
> black, MultiPar is always false, CustomPars is always true.
You need to set this in the header file. I did that for paragraph
customization and plain layout at rev. 28336.
BTW since this is a real inset,
Uwe Stöhr wrote:
For the new phantom inset, the paragraph dialog must not be called by
the user, because paragraph settings would lead to LaTeX errors. This
is the same as with the ERT and the Index inset.
I have now this code in stdinsets.inc:
InsetLayout Phantom:Phantom
LatexType
For the new phantom inset, the paragraph dialog must not be called by the user, because paragraph
settings would lead to LaTeX errors. This is the same as with the ERT and the Index inset.
I have now this code in stdinsets.inc:
InsetLayout Phantom:Phantom
LatexType command
> I can do it, but not immediately (and not for 1.6.1).
It is not urgent.
Thanks in advance for taking over and regards
Uwe
Uwe Stöhr wrote:
> > Hm, I'd guess that you'll need two separate macros \lyxarrow and
>
> > \lyxarrowright. After all, in a multilingual document LTR and RTL can be
> > mixed, so both variants might occur in parallel.
>
> You are right. Could you please take over and implement this. I'm currently
> Hm, I'd guess that you'll need two separate macros \lyxarrow and
> \lyxarrowright. After all, in a multilingual document LTR and RTL can be
> mixed, so both variants might occur in parallel.
You are right. Could you please take over and implement this. I'm currently very limited with my
spare
On Sat, Dec 06, 2008 at 03:29:49PM +0100, Uwe Stöhr wrote:
> @@ -726,7 +731,11 @@
> macros << noun_def << '\n';
>
> if (mustProvide("lyxarrow"))
> + {
> + Language const * lang;
> + useLanguage(lang);
> macros << lyxarrow_def << '\n';
Uwe Stöhr wrote:
> Bug http://bugzilla.lyx.org/show_bug.cgi?id=3560 is about that we define
> the menu separator always as \trangleright, while it needs to be
> \triangleleft for RTL languages. This should be easy to fix, but I'm too
> stupid to get it right, see the attached attempt. Any help?
Hm
Bug http://bugzilla.lyx.org/show_bug.cgi?id=3560 is about that we define the menu separator always
as \trangleright, while it needs to be \triangleleft for RTL languages.
This should be easy to fix, but I'm too stupid to get it right, see the
attached attempt. Any help?
Is there something like
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> needsUpdate returns true when the status of the selection has changed
>> (turned on or turned off).
>
> you meant selHandle?
Indeed.
JMarc
Jean-Marc Lasgouttes wrote:
> "Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> > Removing the first solves the problem and it works
> > perfectly.
> >
> > Can anyone tell me why this term is needed or did I just solve the bug ?
> > (Or I might to have to look somewhere else?)
> >
> needsUpdate returns true when the status of the selection has
> changed (turned on or turned off). While your patch is indeed
> the right solution for table movement,
Well, actually it wasn't the right solution as I realized later that the
expected behaviour is that after the first keystrok
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> Removing the first solves the problem and it works
> perfectly.
>
> Can anyone tell me why this term is needed or did I just solve the bug ?
> (Or I might to have to look somewhere else?)
>
> PS. The description of cur.selHandle(..
Hi all,
When your cursor is in an empty cell of a table and you hit
Shift+Right-Arrow, nothing happens. Hitting it again selects both cells,
which you would expect after the first keystroke. The same happens when
you are in the last position of a cell and you've not selected anything
yet.
This
rgheck wrote:
> See if r25508 works for you.
It does. Thanks indeed.
Jürgen
Juergen Spitzmueller wrote:
rgheck wrote:
I finally got around to doing this. I've also re-written the latex2lyx
conversion routine so that it uses the unicodesymbols file.
I'm not sure exactly what you had in mind for convert_subfig, as I don't
know anything about figures, but perhaps this
rgheck wrote:
> I finally got around to doing this. I've also re-written the latex2lyx
> conversion routine so that it uses the unicodesymbols file.
>
> I'm not sure exactly what you had in mind for convert_subfig, as I don't
> know anything about figures, but perhaps this will let you do it now?
Jürgen Spitzmüller wrote:
In order to fully fix bug 4927, we need to do some LaTeX->LyX conversion,
because subfigure captions can contain LaTeX constructs such as \label.
Currently, subcaptions with such constructs are simply eaten (i.e.,
dataloss).
I think we should factor out the routines of
José Matos wrote:
> > I'm happy to do this, but it'll be a bit, as I "have" to go to St
> > Andrews next week and will be busy.
>
> I am more or less on the same situation. Really busy here with several
> deadlines and at the same time glad to help you after the next week. :-)
Thank you both. I'll
On Friday 06 June 2008 17:13:17 rgheck wrote:
> I'm happy to do this, but it'll be a bit, as I "have" to go to St
> Andrews next week and will be busy.
I am more or less on the same situation. Really busy here with several
deadlines and at the same time glad to help you after the next week. :-)
Juergen Spitzmueller wrote:
In order to fully fix bug 4927, we need to do some LaTeX->LyX conversion,
because subfigure captions can contain LaTeX constructs such as \label.
Currently, subcaptions with such constructs are simply eaten (i.e.,
dataloss).
I think we should factor out the routines o
In order to fully fix bug 4927, we need to do some LaTeX->LyX conversion,
because subfigure captions can contain LaTeX constructs such as \label.
Currently, subcaptions with such constructs are simply eaten (i.e.,
dataloss).
I think we should factor out the routines of convert_latexcommand_index t
On Fri, Nov 02, 2007 at 02:33:03PM +0100, Edwin Leuven wrote:
> Uwe Stöhr wrote:
>> Then my comments are not good enough. \href requires some characters to be
>> escaped or changed. The for loop parse the string for a certain character
>> and do something with it when found. Every loop run checks
Edwin Leuven wrote:
Uwe Stöhr wrote:
Then my comments are not good enough. \href requires some characters
to be escaped or changed. The for loop parse the string for a certain
character and do something with it when found. Every loop run checks
for another character of the list.
maybe qurl c
Uwe Stöhr wrote:
Then my comments are not good enough. \href requires some characters to
be escaped or changed. The for loop parse the string for a certain
character and do something with it when found. Every loop run checks for
another character of the list.
maybe qurl can help here?
http:/
Uwe Stöhr wrote:
> There are other things to clean up in there, it is not clear what the
different 'for' loop are
> doing with the strings.
Then my comments are not good enough. \href requires some characters to
be escaped or changed. The for loop parse the string for a certain
character an
Thanks for looking at this!
> That's because you used strings instead of characters.
Yes this was really my problem - sometimes things can be so simple.
> There are other things to clean up in there, it is not clear what the
different 'for' loop are
> doing with the strings.
Then my comments
Hans Meine wrote:
On Freitag 02 November 2007, Abdelrazak Younes wrote:
@@ -77,10 +77,10 @@
OutputParams const & runparams) const
{
//FIXME: all strings in this routine should be docstrings
- string url = to_utf8(getParam("target"));
+ docstring url = ge
On Freitag 02 November 2007, Abdelrazak Younes wrote:
> @@ -77,10 +77,10 @@
> OutputParams const & runparams) const
> {
> //FIXME: all strings in this routine should be docstrings
> - string url = to_utf8(getParam("target"));
> + docstring url = getParam("target");
Uwe Stöhr wrote:
Enrico wrote today:
> Now waiting for the next bug associated
> to unsigned chars and docstreams.
There's a potential problem in Hyperlink.cpp I'm not able to fix:
http://www.lyx.org/trac/changeset/21352
Could anybody please help me here? I can't get it to work when I change
Enrico wrote today:
> Now waiting for the next bug associated
> to unsigned chars and docstreams.
There's a potential problem in Hyperlink.cpp I'm not able to fix:
http://www.lyx.org/trac/changeset/21352
Could anybody please help me here? I can't get it to work when I change to char_type, I get
Uwe Stöhr schrieb:
There is a serious problem for all current dialogs:
You can set dialog elements to disables state, but whenever you press
the apply button, this is overwritten and all elements are set bach to
enabled state.
I found the reason for this now. It's in ButtonController:
void
There is a serious problem for all current dialogs:
You can set dialog elements to disables state, but whenever you press the apply button, this is
overwritten and all elements are set bach to enabled state.
This one prevents to make the optional parameters really optional using
checkboxes. To
> Note that reference to an inset is a very fragile thing. I guess that
> an undo-redo cycle will reallocate the inset.
Stored insets are used in two ways:
1. navigation. Because I compare a stored inset pointer with currently
available ones. If the stored pointer does not exist, navigation of
th
"Bo Peng" <[EMAIL PROTECTED]> writes:
> My question is: is there any reliable way to store the reference to an
> inset? Basically, I need to save something about an inset, and look up
> that inset with it easily later.
Note that reference to an inset is a very fragile thing. I guess that
an undo-
On Sat, Sep 08, 2007 at 11:06:04PM -0500, Bo Peng wrote:
> Currently, EmbeddedFiles stores a list of ParConstIterator that can be
> used to locate the inset's paragraph. This has a number of problems:
>
> 1. I can only move the cursor to the beginning of the paragraph, not
> where the inset is.
>
> I spent a few hours on this idea, and everything seems to be fine
> until I use inset_iterator_begin(inset_ptr) to locate the inset. Lyx
> instantly crashes. It turns out the the stored inset pointer is
> obsolete without any buffer edition.
It turns out that I can not use 'inset_iterator_begin(
Currently, EmbeddedFiles stores a list of ParConstIterator that can be
used to locate the inset's paragraph. This has a number of problems:
1. I can only move the cursor to the beginning of the paragraph, not
where the inset is.
2. Such ParConstIterator need to be updated along with
structureChan
I was completely busy today. Well, I tried to follow the emails related to this
subject. Abdel mentioned the main points:
For Arabic we have planned to have both ArabTeX and ARABI,
but for Farsi we (at least me as a Farsi User) have decided to use only ARABI.
Currently it is possible to
Uwe Stöhr schrieb:
Attached a correct patch from Georg. As
> Bug 3878 http://bugzilla.lyx.org/show_bug.cgi?id=3878 prevents the
Userguide from beeing compiled
this should go in before RC2.
It's in now as it fixes a release stopper:
http://www.lyx.org/trac/changeset/18819
The patch is from
> Can ArabTeX run on Windows, or does that not work?
ArabTeX can in general be run on Windows but to be able to typeset Arabic with LyX on Windows, I
also need the arabi-package.
regards Uwe
Uwe Stöhr wrote:
> You are probably right but AFAIK, the distinction between \AR and \FR
is only useful when you
> specifically use ARABI.
>
> I am only repeating here...
Me too ;-): Arabi provides the input encoding cp1256 so without arabi,
no Arabic, especially on Windows.
So to come t
> You are probably right but AFAIK, the distinction between \AR and \FR is only
useful when you
> specifically use ARABI.
>
> I am only repeating here...
Me too ;-): Arabi provides the input encoding cp1256 so without arabi, no
Arabic, especially on Windows.
So to come to an end, let's change
Uwe Stöhr wrote:
>>>Regarding the \R vs. \AR --- I believe that is Arabi-specific.
>>
>> Yes but without arabi you can't typeset Arabic and Farsi.
>
> I think that's not true. There are plans to add ARABI support for
Arabic but AFAIU (Mostafa knows > better) the situation is as
Uwe Stöhr wrote:
> The problem is computer access. The internet (and computer in
general) penetration in those
> countries is *much* lower than Nederland.
But aren't Saudi-Arabia, Kuweit, Katar, and Bahrain very rich Arabic
speaking countries?
Very rich country doesn't mean that all people
>>>Regarding the \R vs. \AR --- I believe that is Arabi-specific.
>>
>> Yes but without arabi you can't typeset Arabic and Farsi.
>
> I think that's not true. There are plans to add ARABI support for Arabic but AFAIU (Mostafa knows
> better) the situation is as follows:
>
> Now:
> Ar
> The problem is computer access. The internet (and computer in general)
penetration in those
> countries is *much* lower than Nederland.
But aren't Saudi-Arabia, Kuweit, Katar, and Bahrain very rich Arabic speaking
countries?
Uwe
Uwe Stöhr wrote:
Dov Feldstern schrieb:
> I really wish we had people who really use Arabic and latex, who
could tell us which packages are > usually used, whether they ever mix
languages, etc.
The problem is that people start using a feature after it has been
implemented and they see tha
Uwe Stöhr wrote:
Dov Feldstern schrieb:
Regarding the \R vs. \AR --- I believe that is Arabi-specific.
Yes but without arabi you can't typeset Arabic and Farsi.
I think that's not true. There are plans to add ARABI support for Arabic
but AFAIU (Mostafa knows better) the situation is as fo
Dov Feldstern schrieb:
Test out the small TeX-file in
http://bugzilla.lyx.org/show_bug.cgi?id=2928#c9
When you use Hebrew additionally it works.
The file as it is doesn't compile. I believe the babel line should read:
\usepackage[english,arabic]{babel}
It doesn't matter where you define the
Okay, I finally got arabic sort of working in latex, but the debian
packages don't seem to be in such great shape yet. First of all, it was
looking for Arabicore.sty, when in fact I have arabicore.sty (a legacy
from non-case-sensitive OSes...?); and I'm getting a conflict between
arabi and arab
Dov Feldstern schrieb:
Uwe, what are you basing this claim on?
> And how do you know that it
> doesn't really work?
Test out the small TeX-file in
http://bugzilla.lyx.org/show_bug.cgi?id=2928#c9
When you use Hebrew additionally it works.
I also looked at the source code of babel and the comma
Uwe Stöhr wrote:
Mostafa Vahedi schrieb:
It doesn't seem to be a bug.
> Because when some words in ARABIC are written inside a LATIN paragraph
> the command "\R{arabic phrase}" is used to indicate that. The command
> "\R{arabic phrase}" is supposed to change the language to ARABIC too.
It
Dov Feldstern schrieb:
Mostafa, you're able to generate Farsi dvi documents, right?
The problem occurs when you use another language or latin characters in your document, see the
LyX-testfile I attached to the bug report.
regards Uwe
Mostafa Vahedi schrieb:
It doesn't seem to be a bug.
> Because when some words in ARABIC are written inside a LATIN paragraph
> the command "\R{arabic phrase}" is used to indicate that. The command
> "\R{arabic phrase}" is supposed to change the language to ARABIC too.
It is a bug because the
Mostafa, you're able to generate Farsi dvi documents, right?
Mostafa Vahedi wrote:
It doesn't seem to be a bug. Because when some words in ARABIC are
written inside a LATIN paragraph the command "\R{arabic phrase}" is used
to indicate that. The command "\R{arabic phrase}" is supposed to change
It doesn't seem to be a bug. Because when some words in ARABIC are written
inside a LATIN paragraph the command "\R{arabic phrase}" is used to indicate
that. The command "\R{arabic phrase}" is supposed to change the language to
ARABIC too. But when a new paragraph begins such that the previous p
This bug prevents LyX from beeing used to typeset Arabic and Farsi:
http://bugzilla.lyx.org/show_bug.cgi?id=2928
The reason for this is that LyX currently use \R{} instaed of \AR{} for Arabic
and \FR{} for Farsi.
I'm not familiar with the Bidi/language code and assume that there are special BiDi
Attached a correct patch from Georg. As
> Bug 3878 http://bugzilla.lyx.org/show_bug.cgi?id=3878 prevents the Userguide
from beeing compiled
this should go in before RC2.
Bug 1942 is still not fixed, but this can be done later as this is a cosmetic
bug.
Seeking for another OK to commit.
regard
Bug 3878 http://bugzilla.lyx.org/show_bug.cgi?id=3878 prevents the Userguide from beeing compiled,
so I tried to fix this quickly.
The attahed patch fixes this bug but reintroduce bug 1942
http://bugzilla.lyx.org/show_bug.cgi?id=1942 because the patch for bug 1942 is incorrect. The
correct fix
Georg Baum wrote:
> > Georg, where is this function supposed to be called?
>
> in validate() (therefore the hack with init() const and the mutable
> members). The comment says it:
>
> + // validate() should have been called before
> + BOOST_ASSERT(complete_);
> +
But Encoding does not
Jürgen Spitzmüller wrote:
> The source for all those problems (including the assert, which is correct
> and should be reenabled) is that Encoding::init() is _never_ called. I
> guess Georg just overlooked that.
It was called originally, but for some reason I don't know the call did not
appear in
Uwe Stöhr wrote:
> > 1. open the file "armenian-article.lyx" from the examples
> > 2. change the document layout from "article (armenian)" to "article" and
> > save the file under a new name.
> > 3. change the document language from Armenian to Korean
> >
> > -> Crash:
>
> This problem is more gene
1 - 100 of 409 matches
Mail list logo
