Kornel Benko wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> On Thursday 16 May 2002 18:53, Herbert Voss wrote:
>
>>can someone confirm?
>>
>
> No, working here.
ok, I see,
thanks
Herbert
--
http://www.lyx.org/help/
-BEGIN PGP SIGNED MESSAGE-
On Thursday 16 May 2002 18:53, Herbert Voss wrote:
> can someone confirm?
No, working here.
Kornel
- --
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8
iQCVAwUBPOQRZbewfbDGmeqhAQGD0AQAiWs0Vcrb+9Z2qSkkFirMDidcToKfnNyt
A
can someone confirm?
- open new doc
- choose document->class->book(koma class)
- choose document->language->spanish
- write a word
-> dvi-view gives an error
the command
\addto\extrasspanish{\bbl@deactivate{~}}
is unknown
Herbert
--
http://www.lyx.org/help/
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
Juergen> Is it possible to add a search path as a LaTeX command to the
Juergen> single LaTeX file? So that for example all external filenames
Juergen> inside the LaTeX file are withou
On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
> Juergen> Is it possible to add a search path as a LaTeX command to the
> Juergen> single LaTeX file? So that for example all external filenames
> Juergen> inside the LaTeX file are without path.
>
> This is what the \input@path macro does, if I under
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
>>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
>>
Juergen> I think we should generate files always in the tmp dir. We
Juergen> never should generate temporary files in
On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
>
> Juergen> I think we should generate files always in the tmp dir. We
> Juergen> never should generate temporary files in another dir (also if
> Juergen> use_tempdir is false). I understand
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> I think we should generate files always in the tmp dir. We
Juergen> never should generate temporary files in another dir (also if
Juergen> use_tempdir is false). I understand that someone could wish
Juergen> to have all it's La
On 09-Apr-2002 Jean-Marc Lasgouttes wrote:
> Would having prepareFile return RemoveExtension(filename_) fix this?
>
> Of course the converted files should be generated in /tmp in this
> case. However this gives rise to the same complications as in
> insetinclude. So this is more work.
I think
Jean-Marc Lasgouttes wrote:
>
> Herbert> open a new doc and insert a graphic which is two dirs deeper
> Herbert> than the doc dir.
>
> Would having prepareFile return RemoveExtension(filename_) fix this?
sure, but only for files which are in deeper dirs.
It's no problem for me to change it t
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> Jean-Marc Lasgouttes wrote:
>>> "Herbert" == Herbert Voss <[EMAIL PROTECTED]>
>>> writes:
>>>
>>
But why does latex search in the tmp dir? We give it a nice
\input@path to tell that it should also look in
Jean-Marc Lasgouttes wrote:
>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
>
> Herbert> open a new doc and insert a graphic which is two dirs deeper
> Herbert> than the doc dir.
> [...]
> Herbert> hope, this helps
>
> I guess it does, but I do not know when I will have time
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> open a new doc and insert a graphic which is two dirs deeper
Herbert> than the doc dir.
[...]
Herbert> hope, this helps
I guess it does, but I do not know when I will have time to
investigate this.
JMarc
Jean-Marc Lasgouttes wrote:
>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
>
>>>But why does latex search in the tmp dir? We give it a nice
>>>\input@path to tell that it should also look in the doc dir.
>>>
>
>
> Herbert> this belongs to non-(e)ps-files which were converte
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>> But why does latex search in the tmp dir? We give it a nice
>> \input@path to tell that it should also look in the doc dir.
Herbert> this belongs to non-(e)ps-files which were converted.
Could you explain a bit more?
JMarc
Jean-Marc Lasgouttes wrote:
>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
>
> Herbert> the patch
> Herbert> http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
>
> Herbert> is buggy when you insert a graphic file which is in a deeper
> Herbert> dir than the
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> the patch
Herbert> http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
Herbert> is buggy when you insert a graphic file which is in a deeper
Herbert> dir than the one from the doc. In this case the absolut path
the patch
http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
is buggy when you insert a graphic file which is in a deeper dir
than the one from the doc. In this case the absolut path is missing,
the converted image is written into the doc dir and latex fails,
because it searchs
John Levon wrote:
> On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:
>
>
>>- insert float
>>- insert into the float a graphic
>>- and insert a caption
>>- save and close
>>- reopen
>>---> the caption is outside the float
>>
>
> no, I can't spot any problems like this ...
thanks,
On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:
> - insert float
> - insert into the float a graphic
> - and insert a caption
> - save and close
> - reopen
> ---> the caption is outside the float
no, I can't spot any problems like this ...
john
--
"Way back at the beginning of t
can anybody confirm?
- insert float
- insert into the float a graphic
- and insert a caption
- save and close
- reopen
---> the caption is outside the float
this happens only for graphic insets.
Herbert
--
http://www.lyx.org/help/
On Wed, 13 Feb 2002, R. Lahaye wrote:
> R. Lahaye wrote:
> >
> > the references themselves appear as question-marks in the text [?]
>
> Sorry, my mistake. I had a look at the LaTeX log file and two equations
> were labeled with exactly the same label. For some reason that skrewed
> up the referen
R. Lahaye wrote:
>
> the references themselves appear as question-marks in the text [?]
Sorry, my mistake. I had a look at the LaTeX log file and two equations
were labeled with exactly the same label. For some reason that skrewed
up the referencing table (why?).
Removing one of the equation lab
It would seem that another latex run may be needed to fill in the
labels. Check the latex log file to see if there are any error
messages in the log. Also check to see if a warning line exists that
says something like "need another latex run" as this is also used to
trigger additional latex run
0/CsSA.blg
29 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.dvi
9 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.log
3144 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.ps
21 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex
3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex.dep
Is this problem
> (if I understands this correctly)... yes why not.
>
> ...but to avoid rewriting anything in the parser, output it into a
> ostringstream and pass that to the parser just as usual.
That would be the simple solution. Indeed.
Andre'
--
André Pönitz .
> | reading this formula with 1.2.0 gives always the message
> | that the file may be corrupted (truncated).
> | so far so good, but lyx ignores all the text behind
> | this formula.
>
> so the formula parser does not read (and remove) the \end_inset...
It ignores after its own end everything
> sure! but it was lyx which allowed the user to do that!
> and btw: it's no problem to run this with latex! means
> it's allowed latex stuff ...
Ok. I did not know that, so this has to be fixed indeed.
> > It would be pretty difficult to parse bad input, given that it's already a
> > pain to p
Andre Poenitz wrote:
>
> > 1.1.6fix3:
> > in an equnarray you can delete the lower right cell.
> > the formula than looks like
> >
> > \begin_inset Formula \begin{eqnarray*}
> > 11 & 21 & 31\\
> > 21 & 22 & 23\\
> > 31 & 32 <- missing cell!
> > \end{eqnarray*}
> >
> > \end_inset
> >
>
> 1.1.6fix3:
> in an equnarray you can delete the lower right cell.
> the formula than looks like
>
> \begin_inset Formula \begin{eqnarray*}
> 11 & 21 & 31\\
> 21 & 22 & 23\\
> 31 & 32 <- missing cell!
> \end{eqnarray*}
>
> \end_inset
>
> in 1.1.6 this doesn't matter, the lyxfile i
1.1.6fix3:
in an equnarray you can delete the lower right cell.
the formula than looks like
\begin_inset Formula \begin{eqnarray*}
11 & 21 & 31\\
21 & 22 & 23\\
31 & 32 <- missing cell!
\end{eqnarray*}
\end_inset
in 1.1.6 this doesn't matter, the lyxfile is always
read well.
readi
On Thu, Sep 28, 2000 at 11:40:22PM +0300, Dekel Tsur wrote:
> The problem is in Intl::InitKeyMapper: Since the "default" language is
> removed, n should be initialized to 0.
This reminds me that I plan to add automatic keymap switching according to
the current language (this is currently done wit
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> But why sel is 0 ? The problem is in Intl::InitKeyMapper: Since
Dekel> the "default" language is removed, n should be initialized to
Dekel> 0. I've attached a patch that does both fixes.
Applied.
JMarc
On Thu, Sep 28, 2000 at 05:49:02PM +0200, Lars Gullik Bj&resh;nnes wrote:
> | The actual problem is here:
> |
> | > #5 0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224
> |
> | This line should read:
> |
> | return browser ? fl_get_browser_line(browser, sel) : string();
> |
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > #3 0x815ec58 in lyx::abort () at abort.C:9
| > #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
| > ^ This causes
| >
> #3 0x815ec58 in lyx::abort () at abort.C:9
> #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
> ^ This causes
> the crash
If lyxstring really
When \kbmap is true, LyX crashes on startup. This bug is very recent (last day
or two).
The backtrace:
#0 0x401e1a01 in kill ()
#1 0x401e1863 in gsignal ()
#2 0x401e28c5 in abort ()
#3 0x815ec58 in lyx::abort () at abort.C:9
#4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LA
Michael Schmitt <[EMAIL PROTECTED]> writes:
| I got another warning when clicking at the end of the loaded document:
|
| UMR: Uninitialized memory read
| This is occurring while in:
| int
| WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*)
| [WorkArea.C:299]
Hm
Michael Schmitt <[EMAIL PROTECTED]> writes:
| UMR: Uninitialized memory read (2 times)
| This is occurring while in:
| bool MathedXIter::Next() [math_iter.C:632]
Ok, should be fixed now.
Lgb
Michael Schmitt <[EMAIL PROTECTED]> writes:
| Hi,
|
| yet another bug report.
Can you have a look at this Jürgen?
Lgb
Michael Schmitt <[EMAIL PROTECTED]> writes:
| I opened a couple of files (it seems like two are not sufficient), made
| _no_ changes, then opened one of them again (reloaded).
Is this repeatable?
And this is the the cvs version, right?
| FMR: Free memory read
| This is occurring whi
Jean-Marc Lasgouttes wrote:
> I am looking now for an easy fix. The theory is that, the more purify
> warning we shut off, the easier it gets to see the others.
Correct! And whenever I get a warning I need to run LyX from scratch
again in order to ensure that one report is not caused by a former
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> I opened a couple of files (it seems like two are not
Michael> sufficient), made _no_ changes, then opened one of them again
Michael> (reloaded).
And if you do make a change, are things different? This is definitely
a bug th
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> Hi, below please find some reports concerning 'math'
Michael> operations. This will be the last report for today (sigh?). I
Michael> hope you will be able to fix at least some of the 'bugs'. It
Michael> should be fairly easy
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> Hi, when closing LyX the following messages occur all the
Michael> time. If I remember correctly, these are well-known messages
Michael> which have been considered harmless.
I think those problems is in your X libraries. For
Hi,
below please find some reports concerning 'math' operations. This will
be the last report for today (sigh?). I hope you will be able to fix at
least some of the 'bugs'. It should be fairly easy to fix Uninitialized
Memory Reads (UMRs). If you think that some of them are corrected, I
will cont
Michael Schmitt <[EMAIL PROTECTED]> writes:
| Hi,
|
| below please find a severe bug (free memory read with a lot of
| operations between free and read operation).
|
| Michael
|
|
|
| I opened a couple of files (it seems like two are not sufficient), made
| _no_ changes, then opened one of t
Hi,
yet another bug report.
I loaded a file with a figure; minimized the figure ('fig' is printed at
the end of a line); deleted the figure.
The purify reports looks similar to the one that it raised when cutting
a region covering two paragraphs.
Michael
FMR: Free memory read
T
Hi,
below please find a severe bug (free memory read with a lot of
operations between free and read operation).
Michael
I opened a couple of files (it seems like two are not sufficient), made
_no_ changes, then opened one of them again (reloaded).
FMR: Free memory read
This is o
Hi,
when closing LyX the following messages occur all the time. If I
remember correctly, these are well-known messages which have been
considered harmless.
Michael
FMR: Free memory read
This is occurring while in:
XDestroyIC [ICWrap.c]
void CloseLyXLookup
Michael Schmitt wrote:
> Hi,
>
> importing the ascii file README (from lyx) results in the following
> message:
I got another warning when clicking at the end of the loaded document:
UMR: Uninitialized memory read
This is occurring while in:
int
WorkArea::work_area_hand
Hi,
importing the ascii file README (from lyx) results in the following
message:
UMR: Uninitialized memory read
This is occurring while in:
void LyXText::SetSelection() [text2.C:1024]
int BufferView::Pimpl::resizeCurrentBuffer()
[BufferView_pimpl.C:260]
Hi,
despite the most recent fixes there is still a problem with cutting a
region covering two paragraphs:
FMR: Free memory read
This is occurring while in:
LyXParagraph*LyXParagraph::Next() [paragraph.C:1197]
void LyXText::CutSelection(bool) [text2.C:2227]
On Fri, Apr 07, 2000 at 03:08:32PM +0200, Jean-Marc Lasgouttes wrote:
> > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
> Dekel> does not effect the language of the existing text (should it be
> Dekel> fixed? namely, after changing the language in the document
> Dekel> layout popup, a new
>
> Dekel> The correct sequence of actions is to first select the language of the
> Dekel> document, and then start writing the text.
>
> Nice try. Not true. In this example file I explicitly set
> the language to english as my first action. Something else
> is going wrong. Sorry.
I DID fix it.
On 07-Apr-2000 Jean-Marc Lasgouttes wrote:
>> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
>
> Dekel> The problem is in the original LyX file: the language of the
> Dekel> document is set to English, but the language of each paragraph
> Dekel> is American. This happens if you started wr
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> The problem is in the original LyX file: the language of the
Dekel> document is set to English, but the language of each paragraph
Dekel> is American. This happens if you started writing the document,
Dekel> and after writing several
Dekel> The problem is in the original LyX file: the language of the document is set
Dekel> to English, but the language of each paragraph is American.
Dekel> This happens if you started writing the document, and after writing several
Dekel> paragraphs you changed the language of the document. Curr
On Fri, Apr 07, 2000 at 09:55:16AM +0100, Angus Leeming wrote:
> When I export a simple document to LaTeX and then
> re-import it into LyX I lose the "Language: english" setting
> in Layout->Document, it being reset to "Language->default".
This is a missing feature in reLyX.
>
> Furthermore, ev
When I export a simple document to LaTeX and then
re-import it into LyX I lose the "Language: english" setting
in Layout->Document, it being reset to "Language->default".
Furthermore, every paragraph is set between \selectlanguage
markers:
\selectlanguage{american} blah blah blah \selectlanguage
Michael Schmitt <[EMAIL PROTECTED]> writes:
| This is a cryptographically signed message in MIME format.
|
| --msD1BD4FC02ACFC9AE47A12547
| Content-Type: text/plain; charset=us-ascii
| Content-Transfer-Encoding: 7bit
|
| Hi,
|
| once again I would like to report a very critical bug
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> once again I would like to report a very critical bug in the
Michael> most current lyx version. If you view a dvi file and change
Michael> the text afterwards, lyx does not allow to update the dvi
Michael> output later. You n
Hi,
once again I would like to report a very critical bug in the most
current lyx version. If you view a dvi file and change the text
afterwards, lyx does not allow to update the dvi output later. You need
to restart lyx!
I looked into my /tmp directory, where lyx writes its output and it
seems
63 matches
Mail list logo
