date:20060104


Georg Baum wrote:

Am Dienstag, 3. Januar 2006 16:50 schrieb Uwe Stöhr:


Bo Peng asked:


2. It is not safe to put .bst files in a path with spaces. .lyx files
and all figure files are OK, as well as .bib files.


Also yes. The problem is only a problem of bibtex not of LyX. I sent a
bug report to the MiKTeX developer. Perhaps he has a fix for this.



I doubt that, but we can work around this. See 
http://bugzilla.lyx.org/show_bug.cgi?id=2186. We should do the same 
with .bst files that we are doing with .bib files already.


no, bst and bib files are not handled in the same way. The
usual way to modify a bst file is to edit it and then saving
it in a the _local_ tree and still keeping the old bst file.

Your solution works only, if you use the TeX search path for
files.

Herbert

[Patch] (Re: Screen update improvements)

On Tue, 2006-01-03 at 21:40 +0100, Michael Gerz wrote:
 Martin Vermeer wrote:
 
 Yes, it works... apparently because !vi.singlerow implies select, in a
 way that I haven't been able to figure out. So you don't actually save
 anything.
 
 Still might be wise to delete select from the two places where it occurs
 together with || vi.singlerow.
   
 
 Could you please remove the conditions? I don't feel authorized to do so 
 by myself... :-)

Instead, consider the attached patch. What it achieves is making all
inside-paragraph selecting operations, whether by keyboard or by mouse,
of single-paragraph type. This _should_ produce a speed-up as long as
the selection remains within a paragraph.

I tried to test that there are no turds or other side effects, and it
seems to be OK. Please test some more if you can.

I think this is clean enough for 1.4.0, or else 1.4.1. Depends a bit on
how much of a useful speed-up it produces.

- Martin

BTW I find the attached second patch, for RowPainter profiling, useful.
As we have been talking so much about real profiling, this is like a
lightweight proto-profiler. Would this be welcome in CVS?

- M

Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.189
diff -u -p -r1.189 BufferView.h
--- BufferView.h	1 Dec 2005 10:28:47 -	1.189
+++ BufferView.h	4 Jan 2006 09:09:24 -
@@ -40,7 +40,8 @@ namespace Update {
 	enum flags {
 		FitCursor = 1,
 		Force = 2,
-		SinglePar = 4
+		SinglePar = 4,
+		MultiParSel = 8
 	};
 
 inline flags operator|(flags const f, flags const g)
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.600
diff -u -p -r1.600 BufferView_pimpl.C
--- BufferView_pimpl.C	29 Nov 2005 15:08:32 -	1.600
+++ BufferView_pimpl.C	4 Jan 2006 09:09:25 -
@@ -36,6 +36,7 @@
 #include intl.h
 #include insetiterator.h
 #include LaTeXFeatures.h
+#include LyXAction.h
 #include lyx_cb.h // added for Dispatch functions
 #include lyx_main.h
 #include lyxfind.h
@@ -658,6 +659,17 @@ bool BufferView::Pimpl::fitCursor()
 }
 
 
+bool BufferView::Pimpl::multiParSel()
+{
+	if (!cursor_.selection())
+		return false;
+	bool ret = multiparsel_cache_;
+	multiparsel_cache_ = cursor_.selBegin().pit() != cursor_.selEnd().pit();
+	// Either this, or previous selection spans paragraphs
+	return ret || multiparsel_cache_;
+}
+
+
 void BufferView::Pimpl::update(Update::flags flags)
 {
 	lyxerr[Debug::DEBUG]
@@ -682,12 +694,16 @@ void BufferView::Pimpl::update(Update::f
 
 		// First drawing step
 		ViewMetricsInfo vi = metrics(flags  Update::SinglePar);
-		bool forceupdate(flags  Update::Force);
+		bool forceupdate(flags  (Update::Force | Update::SinglePar));
 
 		if ((flags  Update::FitCursor)  fitCursor()) {
 			forceupdate = true;
 			vi = metrics();
 		}
+		if ((flags  Update::MultiParSel)  multiParSel()) {
+			forceupdate = true;
+			vi = metrics();
+		}
 		if (forceupdate) {
 			// Second drawing step
 			screen().redraw(*bv_, vi);
@@ -989,7 +1005,7 @@ bool BufferView::Pimpl::workAreaDispatch
 		if (cur.result().update())
 			update(Update::FitCursor | Update::Force);
 		else
-			update();
+			update(Update::FitCursor | Update::MultiParSel);
 	}
 
 	// See workAreaKeyPress
Index: BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.129
diff -u -p -r1.129 BufferView_pimpl.h
--- BufferView_pimpl.h	7 Nov 2005 15:06:42 -	1.129
+++ BufferView_pimpl.h	4 Jan 2006 09:09:25 -
@@ -59,6 +59,8 @@ public:
 	void resizeCurrentBuffer();
 	//
 	bool fitCursor();
+	//
+	bool multiParSel();
 	///
 	void update(Update::flags flags = Update::Force);
 	///
@@ -183,6 +185,7 @@ private:
 	///
 	LCursor cursor_;
 	///
+	bool multiparsel_cache_;
 	///
 	lyx::pit_type anchor_ref_;
 	///
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.323
diff -u -p -r1.323 text3.C
--- text3.C	31 Dec 2005 11:40:32 -	1.323
+++ text3.C	4 Jan 2006 09:09:26 -
@@ -1531,10 +1531,14 @@ void LyXText::dispatch(LCursor  cur, Fu
 
 	if (singleParUpdate)
 		// Inserting characters does not change par height
-	   	if (cur.bottom().paragraph().dim().height() 
+		if (cur.bottom().paragraph().dim().height() 
 		== olddim.height()) {
 			// if so, update _only_ this paragraph
-			cur.bv().update(Update::SinglePar | Update::Force);
+			cur.bv().update(Update::SinglePar |
+	Update::FitCursor |
+	Update::MultiParSel);
+			cur.noUpdate();
+			return;
 		} else
 			needsUpdate = true;
 	if (!needsUpdate
Index: LyXAction.C
===
RCS file:

Re: Linking failure on Mac

 Bennett == Bennett Helm [EMAIL PROTECTED] writes:

Bennett Most recent cvs fails to link on Mac with gcc-3.3. Any hints?

It seems that libtool eats the -framework options that the mac needs.
Probably related to Lars' recent update.

JMarc

Re: LyX 1.4.0-pre3 on Mac

 Martin == Martin Vermeer [EMAIL PROTECTED] writes:

 Finally, LyX-1.4.0-pre3 does not contain Martin's singlerow6.diff
 patch necessary for decent typing speed on the Mac. I applied that
 patch manually before posting a test version; should I do this for
 the final version of 1.4.0? (I've lost track of where we stood on
 this)

Martin That patch will require a lot of work still. It won't be in
Martin 1.4.0. If users are happy with a version plagued by rendering
Martin turds I suppose 1.4.1 would be doable.

I am not sure that Bennett is referring to this patch. The
singlerow/crc patch has been applied after 1.4.0pre3, and it should
make a difference.

JMarc

Re: broken link on web page Internationalization Effort

 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus Tomasz ?uczak wrote:
 Hi
 
 Here http://www.lyx.org/devel/translation.php in section Web Pages,
 there is broken link http://www.lyx.org/devel/about/i18n.php
 instead http://www.lyx.org/about/i18n.php

Angus Fixed.

Angus, I see you fixed Tomasz' name in i18n.php. This is pretty
useless, since the name is extracted from pl.po by the postats.sh
script. I am not sure what we should do here, since I guess the L+/
character is not in latin1. So the postats.sh script should extract
the encoding from the po file and convert the translator name
accordingly. Somehow I feel a bit lazy about it :)

JMarc

Re: How to speed up LyXText::breakParagraph?


Martin Vermeer a écrit :

On Tue, Jan 03, 2006 at 07:52:13PM +0100, Abdel wrote:

Hello,

On windows with 1.4.0cvs on for big documents (ex: Extended.lyx), there 
is a big delay (~1s) before a Carriage Return is shown on screen after 
typing the enter key in the middle of a paragraph. The same will 
happen when you type Backspace at the beginning of a paragraph. On the 
contrary, if you type Ctrl-Z immediately after, the screen update is 
instantaneous.


For both keys, 1.3.7pre is very quick.

I am trying to investigate if I could speed-up this a bit because this 
is very, very irritating. I found that the big delay is in 
LyXText::breakParagraph and more precisely in ::breakParagraph, 
paragraph_funcs.C:97. The time consuming operation is the insertion of a 
new paragraph inside the ParagraphList which is in fact a std::vector :


ParagraphList::iterator tmp =
pars.insert(pars.begin() + par_offset + 1, Paragraph());

I have compiled this file with -O3 but the slowness is still there. 
Indeed insertion inside a vector is known to be inefficient. I have read 
the history about ParagraphList_fwd.h 
(http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ParagraphList_fwd.h) 
and I guess there might be some valid reason to choose a vector instead 
of a list but performance wise, it shows, definitely. I have tried to 
replace with a list but this won't compile because some source needs the 
[] operator. I have also tried a deque and the results are a bit better. 
The weird thing is that the slowness is not at the same place. Indeed, 
within a Standard environment, the paragraph insertion at the 
beginning seems to be very fast but the following operation is slowing 
things down:


for (pos_type i = pos_end; i = pos; --i)
par.eraseIntern(i);

Within a List environment, the behavior is the same as with a vector 
based class: the slowness is in the paragraph insertion at the beginning.


But I don't know if this is safe, so my question is: is there any 
assumption in the code that the ParagraphList use a contiguous memory? 
Deque does not... But Extended.lyx loads fine and all seems correct 
(math, table, etc...).


There is a pending patch which could use the vector property... or
not (bug 2015) ;-)


From what I see it uses size() and operator[] so deque would be fine 
here also. But maybe rewriting this patch to use ParagraphList::iterator 
and algorithm::find would be better, wouldn't it? This way we won't rely 
on vector property.




I think a better solution would be to use a map or maybe a vector of 
pointer.
Like it is now, IMHO, lyx-1.4 is close to unusable under window. Is 
there some unofficial patch that would speed up things a bit?


Andre had something that IIRC would replace the official insert() by a
homegrown one, presumably faster. (What's the status of that?)


I think it is possible to rewrite the ParagraphList class that would not 
need the removal of the official insert(), only a cosmetic change.
IMHO, a good solution would be to use a listParagraph member to store 
the paragraphs and a vectorlistParagraph::iterator for the 
interface. This way ParagraphList::insert would call list::insert and 
then update the vector or list iterator. I believe this would imply 
minimal change to the code using ParagraphList; we would just need to 
replace insert(XXX.begin()+pos, Par) with insert(pos, Par). Here is 
a class prototype (not tested):


class ParagraphList
{
public:
///
typedef std::vector Paragraph* BaseType;
typedef std::vector Paragraph*::iterator Iter;
typedef std::vector Paragraph*::const_iterator ConstIter;

typedef std::listParagraph::iterator Pli;   
typedef std::listParagraph::const_iterator Iter;

protected:
typedef std::vectorPli::iterator Iter;
listParagraph ParList_;
vectorPli PliVector_;

public:
///
ParagraphList()
{
// Reserve Memory for 10 iterators
// which would represent 100 paragraph
// I guess this is enough?
PliVector_.reserve(10);
}

Paragrah get(size_t pos)
{
BOOST_ASSERT(pos  PliVector_.size())
return *PliVector_[pos];
}

/// Erases the paragraph at position pos.
bool erase(size_t pos)
{
if (pos = PliVector_.size())
{
// What happened here?
return false
}

size_t new_size=PliVector_.size()-1;
PliVector.resize(new_size);

if (pos == PliVector_.size())
{
PliVector[pos] = ParList_.pop_back(Par);
}
else
{
ParList_.erase(PliVector_[pos]);
}

// Warning:

Math subscript deletion causes crash in 1.3

2006-01-04 Thread John C. McCabe-Dansted

I have found that under LyX 1.3.6 and 1.3.7cvs, if I follow the following 
steps I get a crash.

1. Enter mathmode
2. type: T_E X  
3. move the cursor before the E
4. press delete
5. press the up arrow twice.

This bug does not occur in 1.4.0pre3.

My system: Kubuntu 5.10, gcc 4.02, QT 3.3.4, KDE 3.5

-- 
John C. McCabe-Dansted
Masters Student

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

 Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:

Juergen I have tried to enhance my witness a bit this year. Here's
Juergen how I understand this case:

I think the problem is in DEPM: since it deletes a paragraph, the
recordUndo call should span two paragraphs (think about deleting a
selection that spans more than a paragraph).

I propose the following patch. What do you think?

JMarc

Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2351
diff -u -p -r1.2351 ChangeLog
--- src/ChangeLog	1 Jan 2006 23:06:22 -	1.2351
+++ src/ChangeLog	4 Jan 2006 11:36:04 -
@@ -1,3 +1,8 @@
+2006-01-04  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
+
+	* text2.C (deleteEmptyParagraphMechanism): since we delete a
+	paragraph, recordUndo should span two paragraphs (bug 2155).
+
 2006-01-01  Martin Vermeer  [EMAIL PROTECTED]
 
 	* rowpainter.C (paintPar): always repaint the row with the
Index: src/text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.636
diff -u -p -r1.636 text2.C
--- src/text2.C	6 Dec 2005 14:54:23 -	1.636
+++ src/text2.C	4 Jan 2006 11:36:04 -
@@ -1234,7 +1234,8 @@ bool LyXText::deleteEmptyParagraphMechan
 
 	if (oldpar.empty() || (oldpar.size() == 1  oldpar.isLineSeparator(0))) {
 		// Delete old par.
-		recordUndo(old, Undo::ATOMIC, old.pit());
+		recordUndo(old, Undo::ATOMIC, 
+			   old.pit(), min(old.pit() + 1, old.lastpit()));
 		ParagraphList  plist = old.text()-paragraphs();
 		plist.erase(plist.begin() + old.pit());

Re: Math subscript deletion causes crash in 1.3

John C. McCabe-Dansted wrote:
 I have found that under LyX 1.3.6 and 1.3.7cvs, if I follow the following
 steps I get a crash.

 1. Enter mathmode
 2. type: T_E X      
 3. move the cursor before the E
 4. press delete
 5. press the up arrow twice.

There's already a report for this on bugzilla (can't remember the number). The 
bug has been fixed for 1.4.

Jürgen

Re: Screen update improvements

 Abdel == Abdel  [EMAIL PROTECTED] writes:

Abdel Michael Gerz a écrit :
 Martin, your row signature patch is excellent as it reduces screen
 flickering significantly (you could the flicking on Windows with
 qtwin).

Abdel FYI, without this patch (I have not update my cvs yet), my Qt4
Abdel port has zero flickering :-) I think this patch is solving here
Abdel a problem which is in the Qt3 frontend. During my port, I have
Abdel erased all the calls to the QWidget::repaint function and I
Abdel just have one update to the screen. In other word, I let Qt
Abdel decide when to draw. 

Concerning flicker, I read that using setBackgroundMode(NoBackground)
on a custom Widget help avoiding clearing the windows first. Is that
true?

Reference:
http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html

There are also some double bufferning tricks there.

JMarc

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

Jean-Marc Lasgouttes wrote:
 I think the problem is in DEPM: since it deletes a paragraph, the
 recordUndo call should span two paragraphs (think about deleting a
 selection that spans more than a paragraph).

 I propose the following patch. What do you think?

I think you are right. I wonder why I did no see this.

Jürgen

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

 Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:

Juergen Jean-Marc Lasgouttes wrote:
 I think the problem is in DEPM: since it deletes a paragraph, the
 recordUndo call should span two paragraphs (think about deleting a
 selection that spans more than a paragraph).
 
 I propose the following patch. What do you think?

I had this nagging feeling that something had to be wrong in dEPM...
That's why I was not satisfied with your patches. 

Juergen I think you are right. I wonder why I did no see this.

Can you test it a little bit? I may not have thought about everything
(for example the min was added after I tried to delete the last line
of a paragraph with backspace).

JMarc

Re: Screen update improvements


Jean-Marc Lasgouttes a écrit :

Abdel == Abdel  [EMAIL PROTECTED] writes:


Abdel Michael Gerz a écrit :

Martin, your row signature patch is excellent as it reduces screen
flickering significantly (you could the flicking on Windows with
qtwin).


Abdel FYI, without this patch (I have not update my cvs yet), my Qt4
Abdel port has zero flickering :-) I think this patch is solving here
Abdel a problem which is in the Qt3 frontend. During my port, I have
Abdel erased all the calls to the QWidget::repaint function and I
Abdel just have one update to the screen. In other word, I let Qt
Abdel decide when to draw. 


Concerning flicker, I read that using setBackgroundMode(NoBackground)
on a custom Widget help avoiding clearing the windows first. Is that
true?


I guess so yes. Following patch will do so.



Reference:
http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html

There are also some double bufferning tricks there.

JMarc



Index: QWorkArea.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/QWorkArea.C,v
retrieving revision 1.29
diff -u -r1.29 QWorkArea.C
--- QWorkArea.C 18 Jul 2005 00:29:12 -  1.29
+++ QWorkArea.C 4 Jan 2006 11:52:18 -
@@ -57,7 +57,10 @@

content_-show();

-   content_-setBackgroundColor(lcolorcache.get(LColor::background));
+   // It is said that this help reduce flicker
+   content_-setBackgroundMode(NoBackground);
+   // If we go back to a custom backgound call:
+   // 
content_-setBackgroundColor(lcolorcache.get(LColor::background));


QHBoxLayout * vl = new QHBoxLayout(this);
vl-addWidget(content_, 5);

[Patch] (Re: Bugs status)

On Mon, Jan 02, 2006 at 08:52:06PM +0200, Martin Vermeer wrote:
 On Mon, Jan 02, 2006 at 06:17:31PM +0200, Martin Vermeer wrote:
 
...

 Bugzilla has a fix which simply disables font attribute editing inside a
 charstyle inset; see above theory. Problem solved :-)

...

 See attached, tested and works. OK to commit?
 
 - Martin

Ping...


 Index: insetcharstyle.C
 ===
 RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
 retrieving revision 1.39
 diff -u -p -r1.39 insetcharstyle.C
 --- insetcharstyle.C  25 Nov 2005 14:40:32 -  1.39
 +++ insetcharstyle.C  2 Jan 2006 18:59:02 -
 @@ -249,6 +249,19 @@ bool InsetCharStyle::getStatus(LCursor 
   case LFUN_BREAKPARAGRAPH:
   case LFUN_BREAKPARAGRAPHKEEPLAYOUT:
   case LFUN_BREAKPARAGRAPH_SKIP:
 + // font attributes also not allowed
 + case LFUN_DEFAULT:
 + case LFUN_CODE:
 + case LFUN_ROMAN:
 + case LFUN_SANS:
 + case LFUN_BOLD:
 + case LFUN_ITAL:
 + case LFUN_EMPH:
 + case LFUN_NOUN:
 + case LFUN_UNDERLINE:
 + case LFUN_FONT_SIZE:
 + case LFUN_FREEFONT_APPLY:
 + case LFUN_FREEFONT_UPDATE:
   status.enabled(false);
   return true;
  



pgprG9vBaGq3N.pgp
Description: PGP signature

Re: [Patch] (Re: Bugs status)

Martin Vermeer wrote:

 On Mon, Jan 02, 2006 at 08:52:06PM +0200, Martin Vermeer wrote:
 On Mon, Jan 02, 2006 at 06:17:31PM +0200, Martin Vermeer wrote:
 
 ...
 
 Bugzilla has a fix which simply disables font attribute editing inside a
 charstyle inset; see above theory. Problem solved :-)
 
 ...
 
 See attached, tested and works. OK to commit?
 
 - Martin
 
 Ping...

One dumb question: What happens with existing documents? Do wee need a file
format change?


Georg

Re: [Patch] (Re: Bugs status)

On Wed, Jan 04, 2006 at 01:48:15PM +0100, Georg Baum wrote:
 Martin Vermeer wrote:
 
  On Mon, Jan 02, 2006 at 08:52:06PM +0200, Martin Vermeer wrote:
  On Mon, Jan 02, 2006 at 06:17:31PM +0200, Martin Vermeer wrote:
  
  ...
  
  Bugzilla has a fix which simply disables font attribute editing inside a
  charstyle inset; see above theory. Problem solved :-)
  
  ...
  
  See attached, tested and works. OK to commit?
  
  - Martin
  
  Ping...
 
 One dumb question: What happens with existing documents? Do wee need a file
 format change?

No.

This is about adding font attributes to the text inside charstyle
insets. The patch makes that effectively impossible.

Existing documents (created by people writing their own LaTeX layout
files containing charstyle definitions) will, while valid .lyx files, 
continue to misbehave like reported in the bug ;-)

I expect there will be very few of them, as charstyles were added only
in 1.4, which isn't released yet. As all people running into this
problem are knowledgable users, a note in the Release Notes will do.

- Martin



pgptzcOzZ1dNE.pgp
Description: PGP signature

Re: How to speed up LyXText::breakParagraph?

Oups I just notice a CutPaste problem. The prototype I am proposing is 
as follow, sorry about that. Optionnally, insert could return a 
reference or a pointer to the newly inserted paragraph but I think that 
the get(size_t) function is cleaner.


class ParagraphList
{
public:
/// 
typedef std::listParagraph::iterator Pli;   
typedef std::listParagraph::const_iterator Iter;

protected:
typedef std::vectorPli::iterator Iter;
listParagraph ParList_;
vectorPli PliVector_;

public:
///
ParagraphList()
{
// Reserve Memory for 10 iterators
// which would represent 100 paragraph
// I guess this is enough?
PliVector_.reserve(10);
}

Paragrah get(size_t pos)
{
BOOST_ASSERT(pos  PliVector_.size())
return *PliVector_[pos];
}

/// Erases the paragraph at position pos.
bool erase(size_t pos)
{
if (pos = PliVector_.size())
{
// What happened here?
return false
}

size_t new_size=PliVector_.size()-1;
PliVector.resize(new_size);

if (pos == PliVector_.size())
{
PliVector[pos] = ParList_.pop_back(Par);
}
else
{
ParList_.erase(PliVector_[pos]);
}

// Warning: I think Vector resize does not keep data
// in this case. So it is safer to update the vector
// entirely
Pli pli = ParList_.begin();
for (size_t i=0; inew_size; ++i)
{
PliVector[i]=pli
++pli;
}
return true;
}

/// Inserts the paragraph par at position pos.
/// The subsequent paragraph are shifted toward the end.
bool insert(size_t pos, const Paragraph par)
{   
if (pos  PliVector_.size())
{
// What happened here?
return false;
}

size_t new_size=PliVector_.size()+1;
PliVector.resize(new_size);
if (pos == PliVector_.size())
{
PliVector[pos] = ParList_.push_back(Par);
}
else
{
Pli pli = ParList_.insert(PliVector_[pos], Par);
for (size_t i=pos; inew_sizepli; ++i)
{
PliVector[i]=pli
++pli;
}
}
return true;
}
};

Abdel a écrit :

Martin Vermeer a écrit :

On Tue, Jan 03, 2006 at 07:52:13PM +0100, Abdel wrote:

Hello,

On windows with 1.4.0cvs on for big documents (ex: Extended.lyx), 
there is a big delay (~1s) before a Carriage Return is shown on 
screen after typing the enter key in the middle of a paragraph. The 
same will happen when you type Backspace at the beginning of a 
paragraph. On the contrary, if you type Ctrl-Z immediately after, the 
screen update is instantaneous.


For both keys, 1.3.7pre is very quick.

I am trying to investigate if I could speed-up this a bit because 
this is very, very irritating. I found that the big delay is in 
LyXText::breakParagraph and more precisely in ::breakParagraph, 
paragraph_funcs.C:97. The time consuming operation is the insertion 
of a new paragraph inside the ParagraphList which is in fact a 
std::vector :


ParagraphList::iterator tmp =
pars.insert(pars.begin() + par_offset + 1, Paragraph());

I have compiled this file with -O3 but the slowness is still there. 
Indeed insertion inside a vector is known to be inefficient. I have 
read the history about ParagraphList_fwd.h 
(http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ParagraphList_fwd.h) 
and I guess there might be some valid reason to choose a vector 
instead of a list but performance wise, it shows, definitely. I have 
tried to replace with a list but this won't compile because some 
source needs the [] operator. I have also tried a deque and the 
results are a bit better. The weird thing is that the slowness is not 
at the same place. Indeed, within a Standard environment, the 
paragraph insertion at the beginning seems to be very fast but the 
following operation is slowing things down:


for (pos_type i = pos_end; i = pos; --i)
par.eraseIntern(i);

Within a List environment, the behavior is the same as with a 
vector based class: the slowness is in the paragraph insertion at the 
beginning.


But I don't know if this is safe, so my question is: is there

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

Jean-Marc Lasgouttes wrote:
 Can you test it a little bit? I may not have thought about everything
 (for example the min was added after I tried to delete the last line
 of a paragraph with backspace).

I do not have much time for testing ATM. I tested the cases that I also tested 
with my patches, and they all work as expected. I'd propose to commit your 
patch.

Jürgen

Re: Bugs status

 Martin == Martin Vermeer [EMAIL PROTECTED] writes:

Martin On Mon, Jan 02, 2006 at 09:21:09AM +0100, Juergen Spitzmueller
Martin wrote:
 Martin Vermeer wrote:  I believe bug 822 is fixed.  Is 1561 still
 major? Was partly fixed by Andre.
 
  Are these (and 2155) the only major bugs left for 1.4.0?
 
 and 1656.

Martin I remember that this can be fixed, but in a way that
Martin terminates LyX without an emergency save -- unacceptable.
Martin Jean-Marc knows this one.

Since the bug was present in 1.3.x too (wasn't it?) and we do not know
of a good fix yet, we could schedule it for later... 

I just tried it here and I cannot reproduce the crash. This is with
gnome 2.6 and qt 3.3.3.

So, in which conditions does the exit happen (note that this is not
really a crash).

JMarc

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

 Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:

Juergen Jean-Marc Lasgouttes wrote:
 Can you test it a little bit? I may not have thought about
 everything (for example the min was added after I tried to delete
 the last line of a paragraph with backspace).

Juergen I do not have much time for testing ATM. I tested the cases
Juergen that I also tested with my patches, and they all work as
Juergen expected. I'd propose to commit your patch.

OK, I applied it.

JMarc

Re: Bugs status

Jean-Marc Lasgouttes wrote:
 Since the bug was present in 1.3.x too (wasn't it?) and we do not know
 of a good fix yet, we could schedule it for later...

I was about to propose this too. The bug should definitely also apply to 
1.3.x, so it's not a regression. We should try and implement a solid session 
managment for 1.5

 I just tried it here and I cannot reproduce the crash. This is with
 gnome 2.6 and qt 3.3.3.

I cannot reproduce it either (I never could).

So, what's left? There are bugs 2026 and 1973, for which Georg has announced 
fixes-to-come, 2015, for which a tentative fix (from Martin exists) and 2019, 
which could be left as is or fixed with Martin's proposed fix.

I doubt we can fix  for 1.4, so there's only 1934 (a tricky one) and the 
ct/rowSignature issues.

Anything else?

Jürgen

Re: Bugs status

 Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:

Juergen Jean-Marc Lasgouttes wrote:
 Since the bug was present in 1.3.x too (wasn't it?) and we do not
 know of a good fix yet, we could schedule it for later...

Juergen I was about to propose this too. The bug should definitely
Juergen also apply to 1.3.x, so it's not a regression. We should try
Juergen and implement a solid session managment for 1.5

Yes, I think so.

Juergen So, what's left? There are bugs 2026 and 1973, for which
Juergen Georg has announced fixes-to-come, 2015, for which a
Juergen tentative fix (from Martin exists) and 2019, which could be
Juergen left as is or fixed with Martin's proposed fix.

I am not very happy with Martin's fix to 2019, I'll try to have a look.

Juergen I doubt we can fix  for 1.4, so there's only 1934 (a
Juergen tricky one) and the ct/rowSignature issues.

I added 2177. I think the code that sets the locale is not correct
yet.

Also, we need to get rid of all the debug messages on the console.

JMarc

Re: LyX 1.4.0-pre3 on Mac

2006-01-04 Thread Lars Gullik Bjønnes

Bennett Helm [EMAIL PROTECTED] writes:

| I'm back and finally able to look at LyX-1.4.0-pre3. I notice right
| off that some files relevant to the Mac are simply missing (though
| they are present in CVS):

I bet your tar is too old and is unable to handle the ustar format.
Note that I switch to using this format specifically for supporting the
uber long paths MacOS uses (in developemnt).

-- 
Lgb

Re: broken link on web page Internationalization Effort


Jean-Marc Lasgouttes wrote:

Angus, I see you fixed Tomasz' name in i18n.php. This is pretty
useless, since the name is extracted from pl.po by the postats.sh
script.


Ahh, yes. Mea culpa.


I am not sure what we should do here, since I guess the L+/
character is not in latin1. So the postats.sh script should extract
the encoding from the po file and convert the translator name
accordingly. Somehow I feel a bit lazy about it :)


Well that's OK, John-Mark ;-)

Anyway, how hard can this be? Extract the encoding as:

$ sed -n '/^Content-Type: text\/plain;/{
[EMAIL PROTECTED]Content-Type: text/plain; charset=\([^\\]\{1,\}\)\\n[EMAIL 
PROTECTED]@p
q
}' pl.po
ISO-8859-2

(I've just tested this and it works on every single .po file in the 13x tree.)

And use this data to convert the encoding of the translator's name to utf-8 
using iconv or recode. I can't do this bit for you ATM because running 
iconv on this Windows box results in:


 This application has failed to start because libintl-2.dll was
 not found. Reinstalling the application may fix this problem.
[OK]

I too am feeling lazy :)

Angus

Re: LyX 1.4.0-pre3 on Mac

 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Bennett Helm [EMAIL PROTECTED] writes: | I'm back and
Lars finally able to look at LyX-1.4.0-pre3. I notice right | off
Lars that some files relevant to the Mac are simply missing (though |
Lars they are present in CVS):

Lars I bet your tar is too old and is unable to handle the ustar
Lars format. Note that I switch to using this format specifically for
Lars supporting the uber long paths MacOS uses (in developemnt).

Well, if it is the default OSX tar (whch is probably the case), we'll
have to find an alternative solution...

JMarc

Re: LyX 1.4.0-pre3 on Mac

 Bennett == Bennett Helm [EMAIL PROTECTED] writes:

Bennett Also, with the new requirement of automake 1.9 and the
Bennett possibility of using gcc = 3.3, I've updated the
Bennett INSTALL.MacOSX file (diff attached).

I applied this.

Concerning the rest, I agree with Lars, your tar cannot read the file.
Do you have a way to shorten the paths used in your bundle (the
spotlight stuff actually)?

JMarc

Re: Bugs status

Juergen Spitzmueller wrote:

 So, what's left? There are bugs 2026 and 1973, for which Georg has
 announced fixes-to-come,

I don't plan anything for 2026, because I don't know what to do (reintroduce
stdletters.inc or add ObsoletedBy statements for the missing layouts).

The fix for 1973 is finished, but needs to be extracted from a dirty tree.
I'll do that as soon as possible.

Then I sent a patch for 2153 (this is a regression) to the list which is
waiting for testing/comments.

I also think that 2174 would be good to have (it does not make so much sense
anymore after 1.4.0 is out for some time).


Georg

Re: [prerelease] LyX 1.4.0pre3 - memory for screen graphics

2006-01-04 Thread Peter Mountfort

Hi All

I have compiled

Re: Bugs status

Georg Baum wrote:
 Then I sent a patch for 2153 (this is a regression) to the list which is
 waiting for testing/comments.

I had a quick look some days ago; I have to admit that I didn't get the report 
down to the ground. Do does problem only occur in LaTeX export (not view 
DVI/PDF) and only if the included file is completely missing? (That was my 
impression, but the report implies otherwise).

Jürgen

Re: LyX 1.4.0-pre3 on Mac


On Jan 4, 2006, at 9:45 AM, Jean-Marc Lasgouttes wrote:


Bennett == Bennett Helm [EMAIL PROTECTED] writes:


Bennett Also, with the new requirement of automake 1.9 and the
Bennett possibility of using gcc = 3.3, I've updated the
Bennett INSTALL.MacOSX file (diff attached).

I applied this.

Concerning the rest, I agree with Lars, your tar cannot read the file.
Do you have a way to shorten the paths used in your bundle (the
spotlight stuff actually)?


LyX-Metadata.mdimporter is the only long name, isn't it? It can  
certainly be renamed -- to, say, LyX.mdimporter. (The .mdimporter  
extension is dictated by Apple and cannot be changed, and the  
directory structure of LyX.app is also dictated by Apple.)


This doesn't explain why INSTALL.MacOSX and the LyX.app/Contents/ 
Resources and LyX.app/Contents/MacOS folders were missing, though,  
does it?


Bennett

Re: [prerelease] LyX 1.4.0pre3 - memory for screen graphics

2006-01-04 Thread Peter Mountfort

Hi All

Apologies for the incomplete post earlier.

I have compiled lyx-1.4.0pre3 on SuSE 10.0 and 9.2 using the qt frontend. In 
both cases the memory usage of LyX and the X-server grow without bound, when 
editing documents containing graphics.

In the simplest case, it seems that cutting and pasting a paragraph above a 
graphics insert which is shown in LyX causes the image to be reconverted, 
without freeing the memory from the previous conversion.

Attached are the debug output (on SuSE 9.2) from LyX and some runs of ps for a 
minimal session which illustrates the problem:
1. Open lyx document which contains one image
2. Scroll down until image is displayed
   log shows image is converted
   memory grows 2.5 MB
3. Scroll up until image is off screen
4. Select and cut a paragraph
5. Paste the paragraph back
   log shows image is reconverted
   memory grows 1 MB
6. Undo and Redo
   log shows image is reconverted
   memory grows 2 MB
7. Exit and discard changes

The problem was discovered while editing a document with many images when the 
memory usage of LyX and the X-server each grew to 1.5 GB.

I have searched unsuccessfully for reports of this problem in bugzilla and the 
mail list archive.

Regards

Peter
lyx4 -dbg info,gui,action,graphics
Setting debug level to info,gui,action,graphics
Debugging `info' (General information)
Debugging `gui' (GUI handling)
Debugging `action' (User commands)
Debugging `graphics' (Graphics conversion and loading)
Could not find  Qt translations for locale en_GB.UTF-8
LoaderQueue:  priority set to 10 images at a time, 100 milliseconds between calls
Recognised Fileformat: agr
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
File type not recognised before EOF!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
filetools(getFormatFromContents)
Couldn't find a known format!
Language code:C
Setting new locale for Qt:C
LoaderQueue: waking up
Full icon name is `/usr/local/share/lyx/images/buffer-new.xpm'
Full icon name is `/usr/local/share/lyx/images/file-open.xpm'
Full icon name is `/usr/local/share/lyx/images/buffer-write.xpm'
Full icon name is `/usr/local/share/lyx/images/dialog-show_print.xpm'
Full icon name is `/usr/local/share/lyx/images/undo.xpm'
Full icon name is `/usr/local/share/lyx/images/redo.xpm'
Full icon name is `/usr/local/share/lyx/images/cut.xpm'
Full icon name is `/usr/local/share/lyx/images/copy.xpm'
Full icon name is `/usr/local/share/lyx/images/paste.xpm'
Full icon name is `/usr/local/share/lyx/images/dialog-show_findreplace.xpm'
Full icon name is `/usr/local/share/lyx/images/font-emph.xpm'
Full icon name is `/usr/local/share/lyx/images/font-noun.xpm'
Full icon name is `/usr/local/share/lyx/images/font-free-apply.xpm'
Full icon name is `/usr/local/share/lyx/images/math-mode.xpm'
Full icon name is `/usr/local/share/lyx/images/dialog-show-new-inset_graphics.xpm'
Full icon name is `/usr/local/share/lyx/images/tabular-insert.xpm'
Full icon name is `/usr/local/share/lyx/images/layout_Enumerate.xpm'
Full icon name is `/usr/local/share/lyx/images/layout_Itemize.xpm'
Full icon name is `/usr/local/share/lyx/images/layout_List.xpm'
Full icon name is `/usr/local/share/lyx/images/layout_Description.xpm'
Full icon name is `/usr/local/share/lyx/images/depth-increment.xpm'
Full icon name is `/usr/local/share/lyx/images/depth-decrement.xpm'
Full icon name is `/usr/local/share/lyx/images/float-insert_figure.xpm'
Full icon name is `/usr/local/share/lyx/images/float-insert_table.xpm'
Full icon name is `/usr/local/share/lyx/images/label-insert.xpm'
Full icon name is `/usr/local/share/lyx/images/dialog-show-new-inset_ref.xpm'
Full icon name is `/usr/local/share/lyx/images/dialog-show-new-inset_citation.xpm'
Full icon name is `/usr/local/share/lyx/images/index-insert.xpm'
Full icon name is `/usr/local/share/lyx/images/footnote-insert.xpm'
Full icon name is `/usr/local/share/lyx/images/marginalnote-insert.xpm'
Full icon name is `/usr/local/share/lyx/images/note-insert.xpm'
Full icon name is `/usr/local/share/lyx/images/url-insert.xpm'
Full icon name is `/usr/local/share/lyx/images/ert-insert.xpm'
Full icon name is `/usr/local/share/lyx/images/dialog-show-new-inset_include.xpm'
Full icon

Re: Bugs status

Juergen Spitzmueller wrote:

 Georg Baum wrote:
 Then I sent a patch for 2153 (this is a regression) to the list which is
 waiting for testing/comments.
 
 I had a quick look some days ago; I have to admit that I didn't get the
 report down to the ground. Do does problem only occur in LaTeX export (not
 view DVI/PDF) and only if the included file is completely missing? (That
 was my impression, but the report implies otherwise).

Your impression is right.


Georg

GUI Language Problems on Mac

A couple users have reported to me in response to my posting of LyX/ 
Mac-140-pre3 that GUI languages do not display properly: accents  
appear before characters in the menus ('Editer instead of Éditer,  
for example). (I can reproduce this.)


This was previously discussed in http://www.mail-archive.com/lyx- 
[EMAIL PROTECTED]/msg70996.html. The solution I outlined there  
(using LANG=fr_FR.ISO8859-1 instead of just LANG=fr or LANG=fr_FR)  
now seems to have no effect.


Any suggestions?

Bennett

LyXWin137preSmall-0-6.exe and TeXLive2005

2006-01-04 Thread Tomasz Łuczak


Hi

I use TeXLive2005 and path to latex.exe is in PATH variable.
After run LyXWin137preSmall-0-6.exe appear a message:
No LaTeX-distribution could be found!...

I see in lyx_installer-small.nsi:
ReadRegStr $String HKLM SYSTEM\CurrentControlSet\Control\Session 
Manager\Environment Path

StrCpy $Search TeXLive

In my opinion this is wrong way to recognize of TeXLive distribution.

TeXLive2003 had own installer, TeXLive2004 hadn't windows installer, but 
later appear native windows installer: tlpm.exe (text mode) + 
tlpmgui.exe (gui for tlpm.exe written in Tcl/Tk).
TeXLive2005 become with native wininstaller (new edition of tlpm.exe + 
tlpmgui.exe).

I hope, that older version of TL aren't in use.

Several edition of TeXLive have different variables: TEXMF, TEXMFMAIN, 
TEXMFCNF. In my opinion better way to recognize of TeXLive is recognize 
environment variables TEX* depend on edition of TeXLive instead parsing 
path for texlive string.


Environment variables of TeXLive 2005:
TLroot - path to root of TeXLive - used by installer, in my system: 
C:\Apps\TL2005, default is C:\TeXLive2005

TEXMFCNF - in my system: C:\Apps\TL2005\texmf-var\web2c
Default path to executables is %TLroot%\bin\win32

Installer add variables in key: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session 
Manager\Environment


Sources of tlpmgui.exe are here: http://www.team-tl.livenet.pl/tlpmgui 
or here: ftp://ftp.gust.org.pl/pub/Projekty/tlpmgui

file: tl100.zip


Second way is use UnxUtils (http://unxutils.sourceforge.net ) instead 
minsys. UnxUtils contain nice command which.



Best regards
Tomasz
--
  Tomasz Łuczak

 TECHNODAT Sp. z o.o.tel +48 32 2382337
 ul. Kościuszki 1c   tel +48 32 3314484
 44-100 Gliwice, PL  mob +48 602 524713
 http://www.technodat.com.pl http://www.emrm.pl

Re: Bugs status

 Georg == Georg Baum [EMAIL PROTECTED] writes:

Georg I also think that 2174 would be good to have (it does not make
Georg so much sense anymore after 1.4.0 is out for some time).

Note that I'd like to release 1.3.7 as soon as possible, so that 1.3
people will actually be able to read 1.4 files.

Isn't it possible to define a lyx13 format, so that people can export
to that?

JMarc

Re: broken link on web page Internationalization Effort

2006-01-04 Thread Tomasz Łuczak


Jean-Marc Lasgouttes wrote:

Angus == Angus Leeming [EMAIL PROTECTED] writes:


Angus Tomasz ?uczak wrote:


Hi

Here http://www.lyx.org/devel/translation.php in section Web Pages,
there is broken link http://www.lyx.org/devel/about/i18n.php
instead http://www.lyx.org/about/i18n.php


Angus Fixed.

Angus, I see you fixed Tomasz' name in i18n.php. This is pretty
useless, since the name is extracted from pl.po by the postats.sh
script. I am not sure what we should do here, since I guess the L+/
character is not in latin1. So the postats.sh script should extract
the encoding from the po file and convert the translator name
accordingly. Somehow I feel a bit lazy about it :)


I change Luczak to Łuczak in next update of pl.po

Tomasz
--
  Tomasz Łuczak

 TECHNODAT Sp. z o.o.tel +48 32 2382337
 ul. Kościuszki 1c   tel +48 32 3314484
 44-100 Gliwice, PL  mob +48 602 524713
 http://www.technodat.com.pl http://www.emrm.pl

Re: LyX 1.4.0-pre3 on Mac

 Bennett == Bennett Helm [EMAIL PROTECTED] writes:

Bennett LyX-Metadata.mdimporter is the only long name, isn't it? It
Bennett can certainly be renamed -- to, say, LyX.mdimporter. (The
Bennett .mdimporter extension is dictated by Apple and cannot be
Bennett changed, and the directory structure of LyX.app is also
Bennett dictated by Apple.)

The names of the directories are pretty long too. If we want to fix
this, we shall put all the files in a flat structure and have 
'make bundle' create the bundle at the right place.

Bennett This doesn't explain why INSTALL.MacOSX and the
Bennett LyX.app/Contents/ Resources and LyX.app/Contents/MacOS
Bennett folders were missing, though, does it?

They come after the spotlight stuff in the tar file. I bet you do not
have the toplevel ChangeLog either.

JMarc

Re: Bugs status

Jean-Marc Lasgouttes wrote:

 Georg == Georg Baum
 [EMAIL PROTECTED]
 writes:
 
 Georg I also think that 2174 would be good to have (it does not make
 Georg so much sense anymore after 1.4.0 is out for some time).
 
 Note that I'd like to release 1.3.7 as soon as possible, so that 1.3
 people will actually be able to read 1.4 files.
 
 Isn't it possible to define a lyx13 format, so that people can export
 to that?

That is what the patch in bugzilla does :-) See
http://bugzilla.lyx.org/show_bug.cgi?id=2174, sorry that I forgot to
mention that I had a patch.


Georg

Re: Bugs status

2006-01-04 Thread Jose' Matos

On Wednesday 04 January 2006 15:20, Jean-Marc Lasgouttes wrote:
 Isn't it possible to define a lyx13 format, so that people can export
 to that?

  Could you give an example?

  If if find a reasonable call syntax it is easy to implement it...

 JMarc

-- 
José Abílio

Re: Bugs status


On Jan 4, 2006, at 10:20 AM, Jean-Marc Lasgouttes wrote:


Note that I'd like to release 1.3.7 as soon as possible, so that 1.3
people will actually be able to read 1.4 files.


Note that I still cannot compile 1.3.7 on Mac (Nor, at this  
point, 1.4.0.)


Bennett

Re: LyX 1.4.0-pre3 on Mac

2006-01-04 Thread Lars Gullik Bjønnes

Bennett Helm [EMAIL PROTECTED] writes:

| On Jan 4, 2006, at 9:45 AM, Jean-Marc Lasgouttes wrote:
| 
|  Bennett == Bennett Helm [EMAIL PROTECTED] writes:
| 
|  Bennett Also, with the new requirement of automake 1.9 and the
|  Bennett possibility of using gcc = 3.3, I've updated the
|  Bennett INSTALL.MacOSX file (diff attached).
| 
|  I applied this.
| 
|  Concerning the rest, I agree with Lars, your tar cannot read the file.
|  Do you have a way to shorten the paths used in your bundle (the
|  spotlight stuff actually)?
| 
| LyX-Metadata.mdimporter is the only long name, isn't it? It can
| certainly be renamed -- to, say, LyX.mdimporter. (The .mdimporter
| extension is dictated by Apple and cannot be changed, and the
| directory structure of LyX.app is also dictated by Apple.)

It is the full length of the path that matters...
 
| This doesn't explain why INSTALL.MacOSX and the LyX.app/Contents/
| Resources and LyX.app/Contents/MacOS folders were missing, though,
| does it?

sure it does, if your tar is unable to read the ustar format.
(and they are not missing...)

-- 
Lgb

Re: Bugs status

 Georg == Georg Baum [EMAIL PROTECTED] writes:

 Isn't it possible to define a lyx13 format, so that people can
 export to that?

Georg That is what the patch in bugzilla does :-) See
Georg http://bugzilla.lyx.org/show_bug.cgi?id=2174, sorry that I
Georg forgot to mention that I had a patch.

I like it, although I do not see why you add a menu entry. Doesn't it
appear in FileExport?

Also, if you keep the extension to .lyx, you are going to overwrite
the file. What about exporting to .lyx13?

JMarc

Re: Bugs status

Jean-Marc Lasgouttes wrote:

 I like it, although I do not see why you add a menu entry. Doesn't it
 appear in FileExport?

No, because Exporter::GetExportableFormats() only considers formats that can
be reached from the backends and not from .lyx directly.
I am not sure whether this is a bug or a feature.

 Also, if you keep the extension to .lyx, you are going to overwrite
 the file. What about exporting to .lyx13?

Fine with me.


Georg

Re: Instant preview in LyX/Win 1.4.0pre3

Angus Leeming [EMAIL PROTECTED] writes:
 
 Enrico Forestieri wrote:
  Perhaps you mean that the dpi variable is *proportional* to
  preview_scale_factor. Indeed, when not setting preview_scale_factor I
  obtain dpi=112, whereas setting it to 1.02 I obtain dpi=127. However, I
  don't know the default value of preview_scale_factor (and obviously it is
  not equal to 1), so I am not able to evaluate preview_scale_factor from
  the knowledge of dpi.
 
 0.9

Uhm... this value is doesn't look right to me. Perhaps it was ok in the
old xforms days, but anyway...

 In src/graphics/PreviewLoader.C you'll find:
 
 font_scaling_factor_ = 0.01 * lyxrc.dpi * lyxrc.zoom *
 convertdouble(lyxrc.preview_scale_factor);
 
 ...
 
 cs  pconverter_-command  ' '  pconverter_-to  ' '
 support::QuoteName(latexfile)  ' ' 
 int(font_scaling_factor_)  ' '
 lyx_gui::hexname(LColor::preview)  ' '
 lyx_gui::hexname(LColor::background);
 
 This is the command used to launch the script. 'dpi' inside the script is
 'int(font_scaling_factor_) outside it.
 
 Thereafter, the metrics info is used in setAscentFractions() in the same
 file.

Thanks for the pointer Angus, but, perhaps due to the fact that I don't
grok well C++, I was not able to figure out the program flow and
eventually I came to the conclusion that there was any, as everything
seems to be signal driven :-(

However, I did some experiments using the lyx file pasted at the bottom.
In my preference file I have
  \screen_zoom 130
  \screen_font_roman Times New Roman
and the Screen DPI is at its default value of 96.
Using the default value of 0.9 for preview_scale_factor, the various
n's and H's are not aligned with each other.
Then I changed preview_scale_factor with a step of 0.05, successively
trying the values 0.95, 1.0, 1.05.
At preview_scale_factor=1.05, magically everything lines up and even
the baseline of the previewed images is correctly aligned with the
baseline of the surrounding text!

With these settings I tried other real world lyx files and everything
seems fine.

Things break again if one chooses pslatex fonts. Instead, changing
\screen_zoom to 150, the n's and H's are still aligned with each
other but their baseline does not correspond anymore to that of the
surrounding text.

I think that the conclusion is that there are complex interactions
between too much parameters and it is very difficult to get it right.

I am sorry that my scarce knowledge of C++ and of the LyX sources does
not let me to be of help here, and, frankly, I don't know how much this
effort would be worth.

  As regards why we need to use it twice, I don't know the way the images
  are imported. What I know is that if leave untouched the value of the
  frac variable *and* preview_scale_factor is set to something different
  than its default value, then the inlined images do not perfectly line up
  with the surrounding text.
 
 Right. But you'll understand that I'm unhappy about making a change I don't
 understand.

You're a wise man ;-)

--
Enrico


#LyX 1.4.0pre3 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header

\begin_body

\begin_layout Standard

\family roman
\series medium
\shape up
\size normal
\emph off
\bar no
\noun off
\color none

\begin_inset Formula $n$
\end_inset

xxx
\family default
\series default
\shape default
\size default
\emph default
\bar default
\noun default

\begin_inset Formula $n_{i}$
\end_inset

xxx
\begin_inset Formula $n^{2}$
\end_inset

xxx
\begin_inset Formula $n_{i}^{2}$
\end_inset

xxx
\begin_inset Formula $H$
\end_inset

xxx
\begin_inset Formula $H_{1}$
\end_inset

xxx
\begin_inset Formula $H^{2}$
\end_inset

xxx
\begin_inset Formula $H_{i}^{2}$
\end_inset

xxx
\end_layout

\end_body
\end_document

No automake-1.9 on mingw/msys yet...


The latest version of automake available at
  http://www.mingw.org/download.shtml
is
  msys-automake-1.8.2.tar.bz2

There's also
  automake-1.9.5-mingwPORT.tar.bz2
which is essentially a script that enables one to unpack, build and install 
the official automake sources from

  http://ftp.gnu.org/gnu/automake/

I've done that. Unfortunately, the result is rather sad :( Having removed 
the old autom4te.cache, aclocal.m4 and acinclude.m4 from my LyX tree and 
modified autogen.sh to point to the new aclocal, automake, so:


#!/bin/sh

ACLOCAL=aclocal-1.9 -I ${PWD}/m4
AUTOHEADER=autoheader
AUTOMAKE=automake-1.9 --add-missing --copy --force-missing --foreign

I find that running autogen.sh produces the attached output.

Any clues?

As things stand, I'm afraid that the port of automake 1.9 to Windows isn't 
yet ready for prime time. (Hence it isn't part of MSYS yet). That means I 
can build neither LyX 1.4 nor tex2lyx on Windows using mingw/msys. (This is 
with an otherwise pristine source tree.)


Angus




autogen.log.bz2
Description: Binary data

Re: Instant preview in LyX/Win 1.4.0pre3


Enrico Forestieri wrote:

At preview_scale_factor=1.05, magically everything lines up and even
the baseline of the previewed images is correctly aligned with the
baseline of the surrounding text!

With these settings I tried other real world lyx files and everything
seems fine.

Things break again if one chooses pslatex fonts. Instead, changing
\screen_zoom to 150, the n's and H's are still aligned with each
other but their baseline does not correspond anymore to that of the
surrounding text.

I think that the conclusion is that there are complex interactions
between too much parameters and it is very difficult to get it right.


That does sound to be the case indeed. (It may even be something wrong in 
the way Qt/WinFree lines up fonts...)



Right. But you'll understand that I'm unhappy about making a change I don't
understand.



You're a wise man ;-)


And you're a patient and methodical one :)

I'd suggest that we just leave things as they are. The fix is available 
to you; you can fudge your script file.


Regards,
Angus

Re: Bugs status

 Bennett == Bennett Helm [EMAIL PROTECTED] writes:

Bennett On Jan 4, 2006, at 10:20 AM, Jean-Marc Lasgouttes wrote:
 Note that I'd like to release 1.3.7 as soon as possible, so that
 1.3 people will actually be able to read 1.4 files.

Bennett Note that I still cannot compile 1.3.7 on Mac (Nor, at
Bennett this point, 1.4.0.)

Note that you can compile it, but it does not run ;) 

This is one of the main things that makes 1.3.7 wait, and I have run
out of ideas. 

Did I ask you to try to compile with --disable-optimization already?

JMarc

Re: Instant preview in LyX/Win 1.4.0pre3

Paul A. Rubin [EMAIL PROTECTED] writes:

 It may be the format files rather than the package database.  The MiKTeX 
 Options app has a button on the General tab, Format files section 
 labeled Update Now.  Enrico should give that a whirl.  I ran into 
 something similar, albeit not with preview, where METAFONT abruptly lost 
 the ability to generate fonts.  It turned out that I'd updated some core 
 MiKTeX package(s) and the format files had not been properly updated.

Thanks for the tip Paul! I almost always work from the command line, so
I was missing that button. I am getting close. Now I have:

$ python /path/to/lyxpreview2bitmap.py png 0lyxpreview.tex 128 00 f0f0f0
C:\texmf\miktex\bin\dvipng.exe warning: at (0,0) ignored header
 \special{!/[EMAIL PROTECTED](11.81)def}
Failed to extract metrics info from dvipng

where the last message is from lyxpreview2bitmap.py, and indeed the metrics
file produced by dvipng is empty. I'll investigate further.

--
Enrico

LyX 1.3.7pre6 available


Dear all,

I've just uploaded LyX 1.3.7pre6 to the wiki. Grab it from 
http://wiki.lyx.org/Windows/LyX137pre


Improvements over LyX 1.3.7pre5:
* Many changes to qt-mt3.dll.
* Update of Danish, Hungarian and Spanish translations.
* Add a Polish Translation to the Windows Installer.
* Speed up the searching for math fonts.
* Small bug fix to the sciword bindings.

As ever, the changes to qt-mt3.dll may or may not make the thing more 
stable ;-) Caveat emptor.


No doubt Uwe will be packaging this up in his super installer as time allows.

Regards,
Angus

LyX 1.3.7pre6 question


Hello Angus,

I can't find the file exdll.h in CVS, where is it?
I just compiled your latest lyx_configure.C and got two warnings that 
things defined in the exdll.h (a one from Juli 2005) aren't used. So no 
real problem but perhaps you have a more actual one.

Btw. what are the changes in the lyx_configure.C from today are for?

thanks and best regards
Uwe

Re: LyX 1.3.7pre6 question


Uwe Stöhr wrote:

Hello Angus,

I can't find the file exdll.h in CVS, where is it?


C:\Program Files\NSIS\Contrib\ExDLL\exdll.h

I just compiled your latest lyx_configure.C and got two warnings that 
things defined in the exdll.h (a one from Juli 2005) aren't used. So no 
real problem but perhaps you have a more actual one.


I think that this is something that was fixed in more recent versions of 
NSIS, but here's mine anyway.



Btw. what are the changes in the lyx_configure.C from today are for?


They make it more robust. I've used it for the last several LyX1.3.7preX 
releases.



thanks and best regards
Uwe


Happy New Year!
Angus


#ifndef _EXDLL_H_
#define _EXDLL_H_

// only include this file from one place in your DLL.
// (it is all static, if you use it in two places it will fail)

#define EXDLL_INIT()   {  \
g_stringsize=string_size; \
g_stacktop=stacktop;  \
g_variables=variables; }

// For page showing plug-ins
#define WM_NOTIFY_OUTER_NEXT (WM_USER+0x8)
#define WM_NOTIFY_CUSTOM_READY (WM_USER+0xd)
#define NOTIFY_BYE_BYE 'x'

typedef struct _stack_t {
  struct _stack_t *next;
  char text[1]; // this should be the length of string_size
} stack_t;


static unsigned int g_stringsize;
static stack_t **g_stacktop;
static char *g_variables;

static int __stdcall popstring(char *str); // 0 on success, 1 on empty stack
static void __stdcall pushstring(const char *str);

enum
{
INST_0, // $0
INST_1, // $1
INST_2, // $2
INST_3, // $3
INST_4, // $4
INST_5, // $5
INST_6, // $6
INST_7, // $7
INST_8, // $8
INST_9, // $9
INST_R0,// $R0
INST_R1,// $R1
INST_R2,// $R2
INST_R3,// $R3
INST_R4,// $R4
INST_R5,// $R5
INST_R6,// $R6
INST_R7,// $R7
INST_R8,// $R8
INST_R9,// $R9
INST_CMDLINE,   // $CMDLINE
INST_INSTDIR,   // $INSTDIR
INST_OUTDIR,// $OUTDIR
INST_EXEDIR,// $EXEDIR
INST_LANG,  // $LANGUAGE
__INST_LAST
};

typedef struct exec_flags_ {
  int autoclose;
  int all_user_var;
  int exec_error;
  int abort;
  int exec_reboot;
  int reboot_called;
  int XXX_cur_insttype; // deprecated
  int XXX_insttype_changed; // deprecated
  int silent;
  int instdir_error;
  int rtl;
  int errlvl;
} exec_flags;

typedef struct {
  struct exec_flags_ *exec_flags;
  int (__stdcall *ExecuteCodeSegment)(int, HWND);
} extra_parameters;

// utility functions (not required but often useful)
static int __stdcall popstring(char *str)
{
  stack_t *th;
  if (!g_stacktop || !*g_stacktop) return 1;
  th=(*g_stacktop);
  lstrcpy(str,th-text);
  *g_stacktop = th-next;
  GlobalFree((HGLOBAL)th);
  return 0;
}

static void __stdcall pushstring(const char *str)
{
  stack_t *th;
  if (!g_stacktop) return;
  th=(stack_t*)GlobalAlloc(GPTR,sizeof(stack_t)+g_stringsize);
  lstrcpyn(th-text,str,g_stringsize);
  th-next=*g_stacktop;
  *g_stacktop=th;
}

static char * __stdcall getuservariable(const int varnum)
{
  if (varnum  0 || varnum = __INST_LAST) return NULL;
  return g_variables+varnum*g_stringsize;
}

static void __stdcall setuservariable(const int varnum, const char *var)
{
if (var != NULL  varnum = 0  varnum  __INST_LAST) 
lstrcpy(g_variables + varnum*g_stringsize, var);
}



#endif//_EXDLL_H_

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


 I use TeXLive2005 and path to latex.exe is in PATH variable.
 After run LyXWin137preSmall-0-6.exe appear a message:
 No LaTeX-distribution could be found!...

Hmm, not good but I cannot reproduce it. My TeXLive2005 doesn't write 
things to the PATH variable. But anyway could you please send me your 
complete PATH?


Only for information: When you have problems of getting LaTeX recognized 
you can use the network version of my installer. This is designed to set 
the path to latex.exe manually.


 I see in lyx_installer-small.nsi:

 ReadRegStr $String HKLM SYSTEM\CurrentControlSet\Control\Session
 Manager\Environment Path
 StrCpy $Search TeXLive

 In my opinion this is wrong way to recognize of TeXLive distribution.

The code you mention is for TeXLive2004. For TeXLive2005 this code is used:

   ReadRegStr $String HKCU Environment Path
   StrCpy $Search texlive
   StrCpy $2 TeXLive

 TeXLive2003 had own installer, TeXLive2004 hadn't windows installer,
 but later appear native windows installer: tlpm.exe (text mode) +
 tlpmgui.exe...
 Several edition of TeXLive have different variables: TEXMF, TEXMFMAIN
 TEXMFCNF.

This is one of the reasons why I can't give support for TeXLive. The 
distribution is changed massively every year. To avoid these troubles I 
recommend to use the network version of my installer.


BUT!: As I wrote in my announcement for version 0.6 of my installer:

I tried to use TeXLive together with my LyX installer but failed.
 - TeXLive comes with its own (very old) Ghostscript version 7.07, that 
is incompatible with the version 8.x that is used in my installer. To 
avoid  this problem, install TeXLive without Ghostscript or delete the 
folder ~\etc\Ghostscript in LyX's install directory and delete its path 
in LyX preferences.
 - I found also incompatibilities in the programs dt2dv and dv2dt, that 
are used by LyX for the DVI-output. I don't know how to fix this.
 - TeXLive don't have the program epstopdf so that you have to 
redefine the EPS - PDF converter in LyX using the program ps2pdf.


These problems and possibly more implies that I don't give support that 
LyXWin works together with TeXLive.


I bought the official TeXLive2005 DVD and fiddled aroud for three days 
after I gave up to get it to work properly. I focus now on the MiKTeX 
distribution.


regards Uwe

Re: LyX 1.3.7pre6 question


Angus Leeming wrote:


I can't find the file exdll.h in CVS, where is it?


C:\Program Files\NSIS\Contrib\ExDLL\exdll.h


This file isn't part of NSIS 2.10, 2.11, and 2.12 (I don't have prior 
versions). But it is in NSIS' CVS:


http://cvs.sourceforge.net/viewcvs.py/nsis/NSIS/Contrib/ExDLL/

So we perhaps have it in our CVS to assure that anybody could compile 
lyx_configure.C. (I also ship it in my package repository.)



Happy New Year!


Same to you!

regards Uwe

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Uwe Stöhr wrote:


  TeXLive2003 had own installer, TeXLive2004 hadn't windows installer,
  but later appear native windows installer: tlpm.exe (text mode) +
  tlpmgui.exe...
  Several edition of TeXLive have different variables: TEXMF, TEXMFMAIN
  TEXMFCNF.


just like with LyX, every version has its own file format :-)

This is one of the reasons why I can't give support for TeXLive. The 


there is no reason to support old TeXLive versions.


I tried to use TeXLive together with my LyX installer but failed.
 - TeXLive comes with its own (very old) Ghostscript version 7.07, that 
is incompatible with the version 8.x that is used in my installer. To 
avoid  this problem, install TeXLive without Ghostscript or delete the 
folder ~\etc\Ghostscript in LyX's install directory and delete its path 
in LyX preferences.
 - I found also incompatibilities in the programs dt2dv and dv2dt, that 
are used by LyX for the DVI-output. I don't know how to fix this.
 - TeXLive don't have the program epstopdf so that you have to 
redefine the EPS - PDF converter in LyX using the program ps2pdf.


eps2pdf is a shell script, if it is missing write a short
note to the texlive mailing list.

These problems and possibly more implies that I don't give support that 
LyXWin works together with TeXLive.


I bought the official TeXLive2005 DVD and fiddled aroud for three days 
after I gave up to get it to work properly. I focus now on the MiKTeX 
distribution.


TeXLive has proTeXt as official windows distribution, which is
the same as MiKTeX, except that it installs additionally Ghostscript,
GhostView and a GUI, if the user need one.

Herbert

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Herbert Voss wrote:


there is no reason to support old TeXLive versions.


I couldn't expect that users upgrade their TeXLive every year.

 - TeXLive don't have the program epstopdf so that you have to 
redefine the EPS - PDF converter in LyX using the program ps2pdf.


eps2pdf is a shell script, if it is missing write a short
note to the texlive mailing list.


Could you do this for me please. You know more details about this than I do.


TeXLive has proTeXt as official windows distribution, which is
the same as MiKTeX, except that it installs additionally Ghostscript,
GhostView and a GUI, if the user need one.


proTeXt works fine with LyX. It is very similar to my LyXWinInstaller, 
the difference is that I ship LyX as editor, protext comes with 
TeXnicCenter and WinEdt.


thanks and regards
Uwe

Re: LyXWin137preSmall-0-6.exe and TeXLive2005

2006-01-04 Thread Jean-Pierre Chrétien

Uwe Stöhr [EMAIL PROTECTED] writes:
[...]
 These problems and possibly more implies that I don't give support that 
 LyXWin works together with TeXLive.
 
 I bought the official TeXLive2005 DVD and fiddled aroud for three days 
 after I gave up to get it to work properly. I focus now on the MiKTeX 
 distribution.

To come back to an earlier discussion in this list about TeXLive and
ProTeXt (aka MiKTeXLive, if I can propose this new denomination),
proTeXt-1.3 IS a MikTeX distribution with the TeXLive 2005 files
(thats's why its size is 406 Mo compressed and near 700 Mo decompressed).
IMHO, the only argumnet for  using TeXLive on Windows is the similarity of the
TDS on the various platforms (MiKTeX only knows texmf and localtexmf,
which is less powerful than the texmf, texmf-dist, texmf-var, texmf-local
structure of TeXlive).

As proTeXt offers a very complete distribution, I tend to recommend
installing it first, the run a LyX installer (ignoring the applications
which come with proTeXt like Winshell, GS, and such).
Both proTeXt and the installer may be burnt to provide a LyXWin CD,
prone to distribution to people having a low bandpass connection, 
or no connection at all.
The LyXWin CD itself can be distributed, unless there are legal issues,
as an ISO image (using jigdo e.g.)

Regards

-- 
Jean-Pierre

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Uwe Stöhr wrote:
 - I found also incompatibilities in the programs dt2dv and dv2dt, that 
are used by LyX for the DVI-output.


Could you expand?

Angus

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Jean-Pierre Chrétien wrote:

Uwe Stöhr [EMAIL PROTECTED] writes:
[...]

These problems and possibly more implies that I don't give support that 
LyXWin works together with TeXLive.


I bought the official TeXLive2005 DVD and fiddled aroud for three days 
after I gave up to get it to work properly. I focus now on the MiKTeX 
distribution.



To come back to an earlier discussion in this list about TeXLive and
ProTeXt (aka MiKTeXLive, if I can propose this new denomination),
proTeXt-1.3 IS a MikTeX distribution with the TeXLive 2005 files
(thats's why its size is 406 Mo compressed and near 700 Mo decompressed).
IMHO, the only argumnet for  using TeXLive on Windows is the similarity of the
TDS on the various platforms (MiKTeX only knows texmf and localtexmf,
which is less powerful than the texmf, texmf-dist, texmf-var, texmf-local
structure of TeXlive).


this depends only to the way MiKTeX works. Unless no one did
a cab of any file/package it cannot be part of the texmf tree.
On the other hand it is true, that people uses about 30% of
the installed files, e.g. omega, ConTeXt, sources of tex, ...
So I would say, that MiKTeX is also powerful than a teTeX
or texlive installtion.

Herbert

Re: LyX 1.3.7pre6 question


Uwe Stöhr wrote:

Angus Leeming wrote:

I can't find the file exdll.h in CVS, where is it?

C:\Program Files\NSIS\Contrib\ExDLL\exdll.h
This file isn't part of NSIS 2.10, 2.11, and 2.12 (I don't have prior 
versions). But it is in NSIS' CVS:

http://cvs.sourceforge.net/viewcvs.py/nsis/NSIS/Contrib/ExDLL/


I'd rather have a pointer to the file in the lyx_configure.C blurb.

Could you ask on the NSIS forum why it was removed? (If it was removed...)

Angus

Re: Instant preview in LyX/Win 1.4.0pre3

Angus Leeming [EMAIL PROTECTED] writes:

 I'd suggest that we just leave things as they are. The fix is available 
 to you; you can fudge your script file.

Angus,
sorry to be a PITA, but I would like to get your attention to the fact
that a regular expression in lyxpreview2bitmap.py may be needs to be
revised.

After Paul's suggestion, I fixed the problem with dvipng, but the metrics
file turned out to be empty. I manually called dvipng and saw that its
output is as follows:

$ dvipng ... 0lyxpreview.dvi
...
[1 (preview-latex beginning-of-page-hook detected) (preview-latex tightpage \
option detected, will use its bounding box) depth=1 height=9]

So, I modified the following snippet in lyxpreview2bitmap.py:

def extract_metrics_info(dvipng_stdout, metrics_file):
metrics = open(metrics_file, 'w')
-   metrics_re = re.compile(\[([0-9]+) depth=(-?[0-9]+) height=(-?[0-9]+))
+   metrics_re = re.compile(\[([0-9]+).* depth=(-?[0-9]+) height=(-?[0-9]+))

and everything was fine. However, changing the document fonts to pslatex,
the same problem (empty metrics file) showed up again. Calling manually
dvipng on the offending dvi, I got this:

$ dvipng ... 0lyxpreview.dvi
...
[1 (preview-latex beginning-of-page-hook detected)Trying to make \
PK font psyr (at 512 DPI)...
makemf --verbose psyr
ttf2pk -q -t psyr
Creating psyr.512pk...
gsf2pk psyr StandardSymL   usyr.pfb 512 psyr.512pk
Reading TFM file C:\texmf\fonts\tfm\adobe\symbol\psyr.tfm...
Starting Ghostscript:
C:\texmf\miktex\bin\mgs.exe -dNODISPLAY -dNOGC -sSUBSTFONT=StandardSymL \
-q -- C:/texmf/dvips/gsftopk/render.ps StandardSymL
(C:/texmf/fonts/type1/urw/urwstd/usyr.pfb) brun  512
Writing Pk file psyr.512pk...
Trying to make PK font ptmri8r (at 512 DPI)...
makemf --verbose ptmri8r
ttf2pk -q -t ptmri8r
Creating ptmri8r.512pk...
gsf2pk ptmri8r NimbusRomNo9L-ReguItal TeXBase1Encoding ReEncodeFont
 8r.enc utmri8a.pfb 512 ptmri8r.512pk
Reading TFM file C:\texmf\fonts\tfm\adobe\times\ptmri8r.tfm...
Starting Ghostscript:
C:\texmf\miktex\bin\mgs.exe -dNODISPLAY -dNOGC
 -sSUBSTFONT=NimbusRomNo9L-ReguItal -q -- C:/texmf/dvips/gsftopk/render.ps
 NimbusRomNo9L-ReguItal (C:/texmf/fonts/type1/urw/urwstd/utmri8a.pfb) brun
 (C:/texmf/fonts/enc/dvips/fontname/8r.enc ) run TeXBase1Encoding
ReEncodeFont 512
Writing Pk file ptmri8r.512pk...
 depth=1 height=8]

That is what really goes to stdout, so IMO the RE should be changed to
account for the possible presence of newlines between [1  and  depth=
Or, the thing could be changed such that to catch separately the [x 
and the  depth=

My first impression is that the dvipng generated previews are much better
than those obtained through the ghostscript route.

--
Enrico

Re: Instant preview in LyX/Win 1.4.0pre3

Enrico Forestieri wrote:

 Angus Leeming [EMAIL PROTECTED] writes:
 
 I'd suggest that we just leave things as they are. The fix is
 available to you; you can fudge your script file.
 
 Angus,
 sorry to be a PITA,

You're not.

 but I would like to get your attention to the fact 
 that a regular expression in lyxpreview2bitmap.py may be needs to be
 revised.
 
 After Paul's suggestion, I fixed the problem with dvipng, but the metrics
 file turned out to be empty. I manually called dvipng and saw that its
 output is as follows:
 
 $ dvipng ... 0lyxpreview.dvi
 ...
 [1 (preview-latex beginning-of-page-hook detected) (preview-latex
 [tightpage \
 option detected, will use its bounding box) depth=1 height=9]

Oh, that's horrid and the one that follows is worse.
What I think you should do is talk to David Kastrup and Jan-Åke Larsson on
the AucTeX mailing list (gmane.emacs.auc-tex) and see why they're messing
up the output that they devised for us.

 That is what really goes to stdout, so IMO the RE should be changed to
 account for the possible presence of newlines between [1  and 
 depth= Or, the thing could be changed such that to catch separately
 the [x  and the  depth=

Let's see what they have to say first...

 My first impression is that the dvipng generated previews are much better
 than those obtained through the ghostscript route.

and much faster too. The one limitation it appears to have is its handling
of PostScript specials although I'm sure that things have evolved since
last I looked. (A couple of years ago...)

-- 
Angus

Re: LyX 1.3.7pre6 question


Angus Leeming wrote:


C:\Program Files\NSIS\Contrib\ExDLL\exdll.h


Could you ask on the NSIS forum why it was removed? (If it was removed...)


I'll do so.

 Btw. what are the changes in the lyx_configure.C from today are for?

 They make it more robust. I've used it for the last several
 LyX1.3.7preX releases.

This isn't that robust:

You know that we have several user reports that the configuration script 
doesn't start. I also get this error now with the new lyx_configure.
My installer uses the old one from june and I never had this problem. 
I'll send you the old one, perhaps you have an idea what causes the problem.


(I'm using NSIS 2.12)

regards Uwe
/*
 * \file lyx_configure.C
 * This file is part of LyX, the document processor.
 * http://www.lyx.org/
 * Licence details can be found in the file COPYING or copy at
 * http://www.lyx.org/about/license.php3

 * \author Angus Leeming
 * Full author contact details are available in file CREDITS or copy at
 * http://www.lyx.org/about/credits.php
 *
 * Define four functions that can be called from the NSIS installer:
 *
 * set_path_prefix [ configure_file, path_prefix ]
 * create_bat_files [ bin_dir, lang ]
 * run_configure [ configure_file, path_prefix ]
 * set_env [ var_name, var_value ]
 *
 * The quantities in [ ... ] are the variables that the functions exxpect
 * to find on the stack. They push -1 onto the stack on failure and 0
 * onto the stack on success.
 *
 * Compile the code with
 *
 * g++ -I/c/Program\ Files/NSIS/Contrib -Wall -shared \
 *lyx_configure.C -o lyx_configure.dll
 *
 * Move resulting .dll to /c/Program\ Files/NSIS/Plugins
 */

#include cstdio
#include cstdlib
#include fstream
#include iostream
#include list
#include sstream
#include string

#include windows.h
#include ExDLL/exdll.h


namespace {

std::string const subst(std::string const  a,
std::string const  oldstr,
std::string const  newstr)
{
std::string lstr = a;
std::string::size_type i = 0;
std::string::size_type const olen = oldstr.length();
while ((i = lstr.find(oldstr, i)) != std::string::npos) {
lstr.replace(i, olen, newstr);
i += newstr.length();
}
return lstr;
}


std::string const basename(std::string const  path)
{
std::string::size_type const final_slash = path.find_last_of('\\');
return (final_slash == std::string::npos) ?
path :
path.substr(final_slash+1);
}


std::string const dirname(std::string const  path)
{
std::string::size_type const final_slash = path.find_last_of('\\');
return (final_slash == std::string::npos) ?
std::string() :
path.substr(0, final_slash);
}


std::string const pop_from_stack()
{
char data[10*MAX_PATH];
popstring(data);
return data;
}


void push_to_stack(int data)
{
std::ostringstream os;
os  data;
pushstring(os.str().c_str());
}


std::liststd::string const tokenize(std::string data,
  char const separator)
{
std::liststd::string result;
while (true) {
std::string::size_type const end = data.find(separator);
if (end == std::string::npos) {
result.push_back(data);
break;
}
result.push_back(data.substr(0, end));
data = data.substr(end+1);
}
return result;
}


void remove_duplicates(std::liststd::string  data)
{
typedef std::liststd::string::iterator iterator;
for (iterator it = data.begin(); it != data.end(); ++it) {
iterator next = it;
++next;
if (next == data.end())
break;
iterator end = std::remove(next, data.end(), *it);
data.erase(end, data.end());
}
}


std::string concatenate(std::liststd::string const  data,
char const separator)
{
typedef std::liststd::string::const_iterator iterator;
iterator it = data.begin();
iterator const end = data.end();
if (it == end)
return std::string();

std::ostringstream result;
result  *it;
++it;
for (; it != end; ++it) {
result  separator  *it;
}
return result.str();
}


std::string const sanitize_path(std::string const  in)
{
// Replace multiple, adjacent directory separators.
std::string out = subst(in, , \\);
std::liststd::string out_list = tokenize(out, ';');
remove_duplicates(out_list);
return concatenate(out_list, ';');
}


bool replace_path_prefix(std::string  data,
 std::string::size_type prefix_pos,
 std::string const  path_prefix)
{
std::string::size_type

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Angus Leeming wrote:

 - I found also incompatibilities in the programs dt2dv and dv2dt, 
that are used by LyX for the DVI-output.


Could you expand?


TeXLive has its own dt2dv versions, I expect old ones. The are called 
when I want to generate a DVI and give me spurious error messages. I 
deleted the dv2dt files from LyX's install directory but got the same 
errors. When I replace TeXLive's dt2dv files by the ones from LyX it 
also don't work (other error messages). I currently don't have TeXLive 
installed to send you exactly the error messages.


regards Uwe

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Herbert Voss schrieb:


So I would say, that MiKTeX is also powerful than a teTeX
or texlive installtion.


It is. Personally I like the automatic(on the fly) installation of 
missing LaTeX-packages, so that the user isn't bothered with 
LaTeX-errors that xxx.sty is missing.
This feature is very useful for LyX because all missing packages are 
installed while LyX reconfigures.


regards Uwe

Re: LyXWin137preSmall-0-6.exe and TeXLive2005

On Wednesday 04 January 2006 19:26, Uwe Stöhr wrote:
 Angus Leeming wrote:
   - I found also incompatibilities in the programs dt2dv and dv2dt,
  that are used by LyX for the DVI-output.
 
  Could you expand?

 TeXLive has its own dt2dv versions, I expect old ones. The are called
 when I want to generate a DVI and give me spurious error messages. I
 deleted the dv2dt files from LyX's install directory but got the same
 errors. When I replace TeXLive's dt2dv files by the ones from LyX it
 also don't work (other error messages). I currently don't have TeXLive
 installed to send you exactly the error messages.

Herbert,

do you know where I should post fixes to these files? (See attached)

Angus
diff -p -N -r -U 4 dtl/dt2dv.c dtl_orig/dt2dv.c
--- dtl/dt2dv.c	2005-07-27 11:19:58.0 +0100
+++ dtl_orig/dt2dv.c	1995-03-08 22:00:00.0 +
@@ -1,12 +1,10 @@
 /* dt2dv - convert human-readable DTL file to DVI format
  - this is intended to invert dv2dt version 0.6.0
-   - version 0.6.2 - 27 July 2005
+   - version 0.6.1 - 14:38 GMT +11  Thu 9 March 1995
- Geoffrey Tobin[EMAIL PROTECTED]
- fixes:  Michal Tomczak-Jaegermann[EMAIL PROTECTED]
  Nelson H. F. Beebe[EMAIL PROTECTED]
-	 Angus Leeming [EMAIL PROTECTED]: Enable dt2dv to handle
-	 .dvi files containing strings longer than 1024 chars.
- Reference:  The DVI Driver Standard, Level 0,
  by  The TUG DVI Driver Standards Committee.
  Appendix A, Device-Independent File Format.
 */
@@ -2224,24 +,23 @@ xfer_len_string
 #endif
 /* transfer (length and) quoted string from dtl to dvi file, */
 /* return number of bytes written to dvi file. */
 {
-  U4 k, k2, lstr_maxsize;
+  U4 k, k2;
   Lstring lstr;
 
   if (debug)
   {
 PRINT_PROGNAME;
 fprintf (stderr, (xfer_len_string) : entering xfer_len_string.\n);
   }
 
+  init_Lstring (lstr, LSIZE);
+
   /* k[n] : length of special string */
 
   k = get_unsigned (dtl);
 
-  lstr_maxsize = (k  LSIZE) ? k : LSIZE;
-  init_Lstring (lstr, lstr_maxsize);
-
   if (debug)
   {
 PRINT_PROGNAME;
 fprintf (stderr, (xfer_len_string) : string's nominal length k = );
@@ -2569,9 +2566,9 @@ fontdef
 
 #ifdef HEX_CHECKSUM
   /* c[4] : (hexadecimal) checksum : I (gt) would prefer this */
   xfer_hex (4, dtl, dvi);
-#else /*NOT HEX_CHECKSUM */
+#else /NOT HEX_CHECKSUM */
   /* c[4] : checksum (octal, for comparison with tftopl's .pl file) */
   xfer_oct (4, dtl, dvi);
 #endif
 
diff -p -N -r -U 4 dtl/dtl.doc dtl_orig/dtl.doc
--- dtl/dtl.doc	2005-06-09 11:04:29.0 +0100
+++ dtl_orig/dtl.doc	1995-03-08 17:50:00.0 +
@@ -12,17 +12,17 @@ Note:  `DTL' stands for `Device-Independ
 ASCII text representation of a DVI file.
 
 References for DVI file structure:
 --
-
+ 
 In this distribution:
 
 dvi.doc
 
 In the TeX archives:
 
 CTAN:  dviware/driv-standard/level-0/dvistd0.tex
-
+ 
 The DVI Driver Standard, Level 0,
 by  The TUG DVI Driver Standards Committee  (now defunct)
 chaired by Joachim Schrod.
 Appendix A, Device-Independent File Format,
@@ -38,9 +38,9 @@ Naturally, `variety' has no DVI equivale
 The other DTL commands correspond one-to-one with DVI commands, but I
 have used briefer names (except for `special') than those used in the
 DVI standards document.
 
-DTL  :  DVI
+DTL  :  DVI 
 
 (text)  :  series of set_char commands, for printable ASCII text
 \(   :  literal ASCII left parenthesis in (text)
 \)   :  literal ASCII right parenthesis in (text)
diff -p -N -r -U 4 dtl/dvi.doc dtl_orig/dvi.doc
--- dtl/dvi.doc	2005-06-09 11:04:36.0 +0100
+++ dtl_orig/dvi.doc	1995-03-01 03:38:00.0 +
@@ -21,9 +21,9 @@ DVI Commands
 
 Listed in the free format:
 Opcode  Symbol  Parameter[Signed? Bytes]  ...  Action.
 
-
+
 0set_char_0-  set character 0 from current font
 ...
 127  set_char_127  -  set character 127 from current font
 
diff -p -N -r -U 4 dtl/Makefile dtl_orig/Makefile
--- dtl/Makefile	2005-07-27 19:06:45.0 +0100
+++ dtl_orig/Makefile	1995-03-08 22:00:00.0 +
@@ -2,16 +2,8 @@
 # Version 0.6.1
 # Thu 9 March 1995
 # Geoffrey Tobin
 # Nelson H. F. Beebe
-#
-# Changes 27 July 2005 by Angus Leeming to enable the Makefile to
-# work out of the box on both *nix and Windows machines under
-# the MinSYS environment.
-#
-# The Makefile can also be used unaltered to build a Windows executable
-# from a Linux box if make is invoked as:
-# $ make EXEEXT='.exe' CC='i386-mingw32-gcc'
 #===
 
 BINDIR  = /usr/local/bin
 CATDIR		= $(MANDIR)/../cat$(MANEXT)
@@ -23,24 +15,12 @@ CHMOD   = /bin/chmod
 COL		= col -b
 CP  = /bin/cp
 DITROFF		= ditroff
 DITROFF		= groff
-
-# This is a GNU make extension.
-# If you're flavour of make refuses to accept it,
-# then simply hardcode

Re: LyX-140 Crash on Quit

This bug has gotten lost in the shuffle, so I thought I'd repost it.  
(Others are now reporting the same problem when using LyX/Mac-140pre3.)


Bennett

On Oct 4, 2005, at 1:40 PM, Bennett Helm wrote:

I've occasionally been having lyx-140 crash on quitting. It doesn't  
happen often enough that I've seen a pattern, and I can't reliably  
reproduce it.


Here's the backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00050a9b
0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252

252 {
(gdb) bt
#0  0x000ff270 in  
boost::signals::detail::call_notification::call_notification  
(this=0xbfffd3f0, [EMAIL PROTECTED]) at ../../../../boost/boost/ 
shared_ptr.hpp:252
#1  0x0069cb88 in boost::signal2void, std::string const,  
InsetBase*, boost::last_valuevoid, int, std::lessint,  
boost::functionvoid ()(std::string const, InsetBase*),  
std::allocatorvoid  ::operator() (this=0xb4460f0, [EMAIL PROTECTED],  
a2=0x1184f2d0) at ../../boost/boost/signals/signal_template.hpp:335
#2  0x000e46b0 in Dialogs::hide ([EMAIL PROTECTED], inset=0x1184f2d0)  
at Dialogs.C:32
#3  0x0016085c in InsetERT::~InsetERT (this=0x1184f2d0,  
__in_chrg=3) at insetert.C:107
#4  0x0001451c in InsetList::~InsetList (this=0xcb192d0,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_iterator.h:602
#5  0x0009f380 in Paragraph::~Paragraph (this=0xcb192cc,  
__in_chrg=189030640) at /usr/include/gcc/darwin/3.3/c++/bits/ 
stl_alloc.h:242
#6  0x00627d7c in __static_initialization_and_destruction_0  
(__initialize_p=0, __priority=65535) at /usr/include/gcc/darwin/3.3/ 
c++/bits/stl_construct.h:125
#7  0x8fe109dc in  
__dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkCont 
extE ()

#8  0x8fe038ec in __dyld__ZN4dyld14runTerminatorsEv ()
#9  0x90013a5c in __cxa_finalize ()
#10 0x90013904 in exit ()
#11 0x00171b08 in lyx_gui::exit () at lyx_gui.C:285
#12 0x00062de4 in QuitLyX (noask=8210760) at lyx_cb.C:219
#13 0x000760a8 in LyXFunc::dispatch (this=0xb44fbf0,  
[EMAIL PROTECTED]) at /usr/include/gcc/darwin/3.3/c++/bits/ 
basic_string.h:1136
#14 0x004562a0 in lyx::frontend::QLPopupMenu::fire (this=0xb4577a0,  
index=5002) at ../../../src/MenuBackend.h:97
#15 0x00506418 in lyx::frontend::QLPopupMenu::qt_invoke  
(this=0xb4577a0, _id=57, _o=0xbfffe560) at /Users/bennett/lyx/ 
gcc-3.3/qt-mac-free-3.3.5/include/private/qucom_p.h:388
#16 0x001e0920 in QObject::activate_signal () at  
ControlCommandBuffer.C:137
#17 0x001e0bb0 in QObject::activate_signal () at  
ControlCommandBuffer.C:137

#18 0x002a6878 in QPopupMenu::actSig () at GraphicsCacheItem.C:443
#19 0x002acd30 in QPopupMenu::activateItemAt () at  
GraphicsCacheItem.C:443

#20 0x0038b44c in QMenuBar::activateCommand () at command_inset.C:80
#21 0x00232384 in QApplication::globalEventProcessor () at  
lcolorcache.C:40

#22 0x931288d4 in DispatchEventToHandlers ()
#23 0x9312802c in SendEventToEventTargetInternal ()
#24 0x9312edb0 in SendEventToEventTarget ()
#25 0x931a7cb0 in SendHICommandEvent ()
#26 0x931d7cf4 in SendMenuItemSelectedEvent ()
#27 0x931f3258 in HandleKeyboardEvent ()
#28 0x931288d4 in DispatchEventToHandlers ()
#29 0x9312802c in SendEventToEventTargetInternal ()
#30 0x93127ea8 in SendEventToEventTargetWithOptions ()
#31 0x931f2568 in HandleKeyboardEvent ()
#32 0x9312f12c in ToolboxEventDispatcherHandler ()
#33 0x93128b24 in DispatchEventToHandlers ()
#34 0x9312802c in SendEventToEventTargetInternal ()
#35 0x9312edb0 in SendEventToEventTarget ()
#36 0x0022ec08 in qt_mac_send_event () at lcolorcache.C:40
#37 0x00369e24 in QEventLoop::processEvents () at fileiter.cpp:875
#38 0x003476cc in QEventLoop::enterLoop () at GraphicsCacheItem.C:443
#39 0x003475b8 in QEventLoop::exec () at GraphicsCacheItem.C:443
#40 0x001719b0 in lyx_gui::start ([EMAIL PROTECTED],  
[EMAIL PROTECTED]) at lyx_gui.C:253
#41 0x00065f64 in LyX::priv_exec (this=0xb406e60, [EMAIL PROTECTED],  
argv=0xb850) at lyx_main.C:282
#42 0x00065198 in LyX::exec ([EMAIL PROTECTED], argv=0xb850)  
at ../boost/boost/scoped_ptr.hpp:93

#43 0x2b58 in main (argc=1, argv=0xb850) at main.C:47

Bennett


--
Bennett W. Helm
Department of Philosophy
Franklin  Marshall College
Lancaster, PA 17604-3003
Voice: 717-291-4392
FAX: 717-291-4369
Homepage: http://www.fandm.edu/Departments/Philosophy/staticpages/ 
index.php?page=helm

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Uwe Stöhr wrote:

Herbert Voss schrieb:


So I would say, that MiKTeX is also powerful than a teTeX
or texlive installtion.



It is. Personally I like the automatic(on the fly) installation of 
missing LaTeX-packages, so that the user isn't bothered with 
LaTeX-errors that xxx.sty is missing.


There is a Linux Version of the MiKTeX package manager

This feature is very useful for LyX because all missing packages are 
installed while LyX reconfigures.


no, this works as along as Christian has build a cab file of
such a package. For example: for PSTricks he did this not
for all packages. If a user uses package pst-vue3d, then it is
much more difficult for newbies to install this package by
hand. In this case it is easier with Linux! What the TeX-World
really needs is a good package manager for Linux/Windows/Mac. The
MiKTeX one is no _real_ one, because it cannot install
_all_ packages.

Herbert

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Angus Leeming wrote:

On Wednesday 04 January 2006 19:26, Uwe Stöhr wrote:


Angus Leeming wrote:


- I found also incompatibilities in the programs dt2dv and dv2dt,
that are used by LyX for the DVI-output.


Could you expand?


TeXLive has its own dt2dv versions, I expect old ones. The are called
when I want to generate a DVI and give me spurious error messages. I
deleted the dv2dt files from LyX's install directory but got the same
errors. When I replace TeXLive's dt2dv files by the ones from LyX it
also don't work (other error messages). I currently don't have TeXLive
installed to send you exactly the error messages.



Herbert,

do you know where I should post fixes to these files? (See attached)


as I said, there is _no real_ Windows installer on TeXLive and
the interest in this area is low. However, you can post to the
TeXLive people, maybe that one is interesting in the
Windows part.
texlive mailing list - http://tug.org/mailman/listinfo/tex-live

Herbert

Re: Bugs status


On Jan 4, 2006, at 11:08 AM, Jean-Marc Lasgouttes wrote:


Bennett Note that I still cannot compile 1.3.7 on Mac (Nor, at
Bennett this point, 1.4.0.)

Note that you can compile it, but it does not run ;)


Thbpbpthpt!


This is one of the main things that makes 1.3.7 wait, and I have run
out of ideas.

Did I ask you to try to compile with --disable-optimization already?


No, but it doesn't help:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x0014c0b0 in std::basic_streambufchar, std::char_traitschar  
::sputn () at ../../../../boost/boost/regex.hpp:1374

1374  ref = newref;
(gdb) bt
#0  0x0014c0b0 in std::basic_streambufchar, std::char_traitschar  
::sputn () at ../../../../boost/boost/regex.hpp:1374
#1  0x00739928 in debugbuf::xsputn (this=0xb103580, p=0xb817834 LyX:  
Creating directory , n=24) at DebugStream.C:133
#2  0x0013f064 in std::operator char, std::char_traitschar,  
std::allocatorchar  () at insettext.C:2815
#3  0x0002c21c in boost::operator char, std::char_traitschar   
([EMAIL PROTECTED], [EMAIL PROTECTED]) at ../boost/boost/format/free_funcs.hpp:53
#4  0x000629bc in LyX::queryUserLyXDir (this=0xb730,  
explicit_userdir=false) at lyx_main.C:546
#5  0x00060148 in LyX::init (this=0xb730, gui=true) at lyx_main.C: 
298
#6  0x0005f748 in LyX::LyX (this=0xb730, [EMAIL PROTECTED],  
argv=0xb828) at lyx_main.C:147
#7  0x0005f3ac in LyX::LyX (this=0xb730, [EMAIL PROTECTED],  
argv=0xb828) at lyx_main.C:98

#8  0x0008f5c0 in main (argc=1, argv=0xb828) at ../src/main.C:31
(gdb)

Bennett

Re: LyXWin137preSmall-0-6.exe and TeXLive2005

Herbert Voss wrote:
 Herbert,
 
 do you know where I should post fixes to these files? (See attached)
 
 as I said, there is _no real_ Windows installer on TeXLive and
 the interest in this area is low. However, you can post to the
 TeXLive people, maybe that one is interesting in the
 Windows part.
 texlive mailing list - http://tug.org/mailman/listinfo/tex-live

Thanks. But what I really meant is: I pulled the dt2dv package off CTAN.
How do I go about getting these improvements into it?

-- 
Angus

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Angus Leeming wrote:


Thanks. But what I really meant is: I pulled the dt2dv package off CTAN.
How do I go about getting these improvements into it?


to the people listed in the header, e.g. Nelson Beebe. But I do not
know any person, who uses or needs this file ...

Herbert

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Herbert Voss wrote:

This feature is very useful for LyX because all missing packages are 
installed while LyX reconfigures.


no, this works as along as Christian has build a cab file of
such a package.


But you can build it and send it to him. I did this in the past to have 
actual versions of beamer, xcolor and pgf. Christian uploaded the files 
then within one or two days.



What the TeX-World
really needs is a good package manager for Linux/Windows/Mac. The
MiKTeX one is no _real_ one, because it cannot install
_all_ packages.


Christian is currently hard working to build MiKTeX on Linux. I don't 
know his plans about the package manager. But he's mostly interested in 
proposals. So if you have an idea how to make it better, you should 
contact him.


regards Uwe

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Uwe Stöhr wrote:

Herbert Voss wrote:

This feature is very useful for LyX because all missing packages are 
installed while LyX reconfigures.



no, this works as along as Christian has build a cab file of
such a package.



But you can build it and send it to him. I did this in the past to have 
actual versions of beamer, xcolor and pgf. Christian uploaded the files 
then within one or two days.


you don't want to tell me, that this is an acceptable way ...
Have a look at the CPAN, then you understand what a
package manager means.

Herbert

Re: Bugs status

2006-01-04 Thread Bo Peng

  Also, if you keep the extension to .lyx, you are going to overwrite
  the file. What about exporting to .lyx13?

 Fine with me.

But a more common approach is that the user is prompted for a new filename.

Bo

Re: LyX 1.3.7pre6 question


I wrote:

I just compiled your latest lyx_configure.C and got two warnings that 
things defined in the exdll.h (a one from Juli 2005) aren't used. So 
no real problem but perhaps you have a more actual one.


I get these warnings:

ExDLL/exdll.h:103: warning: 'char* getuservariable(int)' defined but not 
used
ExDLL/exdll.h:109: warning: 'void setuservariable(int, const char*)' 
defined but

not used

only for information.

regards Uwe

Re: LyXWin137preSmall-0-6.exe and TeXLive2005

2006-01-04 Thread Tomasz Łuczak

Uwe Stöhr wrote:

I use TeXLive2005 and path to latex.exe is in PATH variable.
After run LyXWin137preSmall-0-6.exe appear a message:
No LaTeX-distribution could be found!...

Hmm, not good but I cannot reproduce it. My TeXLive2005 doesn't write
things to the PATH variable. But anyway could you please send me your
complete PATH?

My variables:
PATH=C:\Apps\Tcl\bin;C:\Apps\Perl\bin\;C:\Apps\TL2005\bin\win32;c:\apps\im;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem
TLroot=C:\Apps\TL2005
TEXMFCNF=C:\TeXLive2005\texmf-var\web2c

The code you mention is for TeXLive2004. For TeXLive2005 this code is
used:

ReadRegStr $String HKCU Environment Path
StrCpy $Search texlive
StrCpy $2 TeXLive

It's same wrong way.
For TL2005 and TL2004 (if used tlpmgui for install) installer should
check whether variable TLroot exist. Then path to latex.exe is
%TLroot%\bin\win32

My proposition to recognize TL2005 (and TL2004 installed by tlpmgui):
ReadRegStr $String HKCU Environment Path
ReadRegStr $tlroot HKCU Environment TLroot
StrCpy $Search $tlroot
StrCpy $2 TeXLive
Call LaTeXCheck

TeXLive2003 had own installer, TeXLive2004 hadn't windows installer,
but later appear native windows installer: tlpm.exe (text mode) +
tlpmgui.exe...
Several edition of TeXLive have different variables: TEXMF, TEXMFMAIN
TEXMFCNF.

This is one of the reasons why I can't give support for TeXLive. The

Probably TL2006 will use tlpmgui for windows too. that variable TLroot
will available.

distribution is changed massively every year. To avoid these troubles
I recommend to use the network version of my installer.

Network installation working fine.

BUT!: As I wrote in my announcement for version 0.6 of my installer:

I tried to use TeXLive together with my LyX installer but failed.

For me network version of lyxwininstaller working without problems.
I compiled into pdf several big documents (almost 200 pages with
pictures) without errors.

- TeXLive comes with its own (very old) Ghostscript version 7.07,
that is incompatible with the version 8.x that is used in my installer.
To avoid this problem, install TeXLive without Ghostscript or delete
the folder ~\etc\Ghostscript in LyX's install directory and delete its
path in LyX preferences.

Or uninstall from TL

- I found also incompatibilities in the programs dt2dv and dv2dt,
that are used by LyX for the DVI-output. I don't know how to fix this.

LyX 1.3.7pre6 exports to dvi simple documents without errors.

- TeXLive don't have the program epstopdf so that you have to
redefine the EPS - PDF converter in LyX using the program ps2pdf.

Better way is uninstall gs from TL, for avoid problems with gs.

These problems and possibly more implies that I don't give support
that LyXWin works together with TeXLive.

I expect only chance to use TeXLive when I install in other directory
instead default.

I bought the official TeXLive2005 DVD and fiddled aroud for three
days after I gave up to get it to work properly. I focus now on the
MiKTeX distribution.

I suggested only way to improve recognize of TeXLive, nothing more.

best regards
Tomasz
--
Tomasz Łuczak

TECHNODAT Sp. z o.o.tel +48 32 2382337
ul. Kościuszki 1c tel +48 32 3314484
44-100 Gliwice, PL mob +48 602 524713
http://www.technodat.com.pl http://www.emrm.pl

Re: [Patch] (Re: Screen update improvements)

2006-01-04 Thread Michael Gerz


Martin Vermeer wrote:

Could you please remove the conditions? I don't feel authorized to do so 
by myself... :-)
   



Instead, consider the attached patch. What it achieves is making all
inside-paragraph selecting operations, whether by keyboard or by mouse,
of single-paragraph type. This _should_ produce a speed-up as long as
the selection remains within a paragraph.

I tried to test that there are no turds or other side effects, and it
seems to be OK. Please test some more if you can.

I think this is clean enough for 1.4.0, or else 1.4.1. Depends a bit on
how much of a useful speed-up it produces.
 


I will do some testing tomorrow evening.

I think we have to speed up selections and reduce flickering for 1.4.0. 
Right now, it is not a great joy to select text if the LyX windows 
covers the full screen.


Michael

Re: No automake-1.9 on mingw/msys yet...

2006-01-04 Thread Michael Gerz


Angus Leeming wrote:


I find that running autogen.sh produces the attached output.

Any clues?

As things stand, I'm afraid that the port of automake 1.9 to Windows 
isn't yet ready for prime time. (Hence it isn't part of MSYS yet). 
That means I can build neither LyX 1.4 nor tex2lyx on Windows using 
mingw/msys. (This is with an otherwise pristine source tree.)


Hi Angus,

I also noticed that MinGW no longer allows you to build 1.4.0cvs. As a 
workaround, I use cygwin's automake to generate the Makefiles. It works 
as expected but, of course, it isn't nice to have to install and use 
cygwin in addition to MinGW. Thank god, we ship the final 1.4.0 source 
distribution with the auto-generated files so that the users do not have 
to run automake by themselves.


Michael

Re: No automake-1.9 on mingw/msys yet...

Michael Gerz [EMAIL PROTECTED] writes:

 I also noticed that MinGW no longer allows you to build 1.4.0cvs. As a 
 workaround, I use cygwin's automake to generate the Makefiles. It works 
 as expected but, of course, it isn't nice to have to install and use 
 cygwin in addition to MinGW. Thank god, we ship the final 1.4.0 source 
 distribution with the auto-generated files so that the users do not have 
 to run automake by themselves.

A MinGW version of both Qt and LyX can be built by using the cygwin g++
with the -mno-cygwin switch. If there is interest I'll post my howto.
It is not for the faint-heart, though ;-)

--
Enrico

Re: Instant preview in LyX/Win 1.4.0pre3

Angus Leeming [EMAIL PROTECTED] writes:

 Oh, that's horrid and the one that follows is worse.
 What I think you should do is talk to David Kastrup and Jan-Åke Larsson on
 the AucTeX mailing list (gmane.emacs.auc-tex) and see why they're messing
 up the output that they devised for us.

I tried dvipng 1.7 on linux and its output is exactly equal to what that
RE matches. So it is not a problem with dvipng itself but seemingly with
the dvipng shipped with MikTeX.

--
Enrico

Re: LyXWin137preSmall-0-6.exe and TeXLive2005


Uwe Stöhr wrote:

Herbert Voss wrote:


there is no reason to support old TeXLive versions.



I couldn't expect that users upgrade their TeXLive every year.

 - TeXLive don't have the program epstopdf so that you have to 


anwer from Staszek (texlive):

TeX Live2005 *has* epstopdf for Windows. eps2pdf has never been used in TL.

Herbert

Re: [announce] sixth release of LyXWinInstaller


Georg Baum wrote:

Am Dienstag, 3. Januar 2006 16:50 schrieb Uwe Stöhr:


Bo Peng asked:


2. It is not safe to put .bst files in a path with spaces. .lyx files
and all figure files are OK, as well as .bib files.


Also yes. The problem is only a problem of bibtex not of LyX. I sent a
bug report to the MiKTeX developer. Perhaps he has a fix for this.



I doubt that, but we can work around this. See 
http://bugzilla.lyx.org/show_bug.cgi?id=2186. We should do the same 
with .bst files that we are doing with .bib files already.


no, bst and bib files are not handled in the same way. The
usual way to modify a bst file is to edit it and then saving
it in a the _local_ tree and still keeping the old bst file.

Your solution works only, if you use the TeX search path for
files.

Herbert

[Patch] (Re: Screen update improvements)

On Tue, 2006-01-03 at 21:40 +0100, Michael Gerz wrote:
> Martin Vermeer wrote:
> 
> >Yes, it works... apparently because !vi.singlerow implies select, in a
> >way that I haven't been able to figure out. So you don't actually save
> >anything.
> >
> >Still might be wise to delete select from the two places where it occurs
> >together with || vi.singlerow.
> >  
> >
> Could you please remove the conditions? I don't feel authorized to do so 
> by myself... :-)

Instead, consider the attached patch. What it achieves is making all
inside-paragraph selecting operations, whether by keyboard or by mouse,
of single-paragraph type. This _should_ produce a speed-up as long as
the selection remains within a paragraph.

I tried to test that there are no "turds" or other side effects, and it
seems to be OK. Please test some more if you can.

I think this is clean enough for 1.4.0, or else 1.4.1. Depends a bit on
how much of a useful speed-up it produces.

- Martin

BTW I find the attached second patch, for RowPainter profiling, useful.
As we have been talking so much about "real" profiling, this is like a
lightweight proto-profiler. Would this be welcome in CVS?

- M

Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.189
diff -u -p -r1.189 BufferView.h
--- BufferView.h	1 Dec 2005 10:28:47 -	1.189
+++ BufferView.h	4 Jan 2006 09:09:24 -
@@ -40,7 +40,8 @@ namespace Update {
 	enum flags {
 		FitCursor = 1,
 		Force = 2,
-		SinglePar = 4
+		SinglePar = 4,
+		MultiParSel = 8
 	};
 
 inline flags operator|(flags const f, flags const g)
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.600
diff -u -p -r1.600 BufferView_pimpl.C
--- BufferView_pimpl.C	29 Nov 2005 15:08:32 -	1.600
+++ BufferView_pimpl.C	4 Jan 2006 09:09:25 -
@@ -36,6 +36,7 @@
 #include "intl.h"
 #include "insetiterator.h"
 #include "LaTeXFeatures.h"
+#include "LyXAction.h"
 #include "lyx_cb.h" // added for Dispatch functions
 #include "lyx_main.h"
 #include "lyxfind.h"
@@ -658,6 +659,17 @@ bool BufferView::Pimpl::fitCursor()
 }
 
 
+bool BufferView::Pimpl::multiParSel()
+{
+	if (!cursor_.selection())
+		return false;
+	bool ret = multiparsel_cache_;
+	multiparsel_cache_ = cursor_.selBegin().pit() != cursor_.selEnd().pit();
+	// Either this, or previous selection spans paragraphs
+	return ret || multiparsel_cache_;
+}
+
+
 void BufferView::Pimpl::update(Update::flags flags)
 {
 	lyxerr[Debug::DEBUG]
@@ -682,12 +694,16 @@ void BufferView::Pimpl::update(Update::f
 
 		// First drawing step
 		ViewMetricsInfo vi = metrics(flags & Update::SinglePar);
-		bool forceupdate(flags & Update::Force);
+		bool forceupdate(flags & (Update::Force | Update::SinglePar));
 
 		if ((flags & Update::FitCursor) && fitCursor()) {
 			forceupdate = true;
 			vi = metrics();
 		}
+		if ((flags & Update::MultiParSel) && multiParSel()) {
+			forceupdate = true;
+			vi = metrics();
+		}
 		if (forceupdate) {
 			// Second drawing step
 			screen().redraw(*bv_, vi);
@@ -989,7 +1005,7 @@ bool BufferView::Pimpl::workAreaDispatch
 		if (cur.result().update())
 			update(Update::FitCursor | Update::Force);
 		else
-			update();
+			update(Update::FitCursor | Update::MultiParSel);
 	}
 
 	// See workAreaKeyPress
Index: BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.129
diff -u -p -r1.129 BufferView_pimpl.h
--- BufferView_pimpl.h	7 Nov 2005 15:06:42 -	1.129
+++ BufferView_pimpl.h	4 Jan 2006 09:09:25 -
@@ -59,6 +59,8 @@ public:
 	void resizeCurrentBuffer();
 	//
 	bool fitCursor();
+	//
+	bool multiParSel();
 	///
 	void update(Update::flags flags = Update::Force);
 	///
@@ -183,6 +185,7 @@ private:
 	///
 	LCursor cursor_;
 	///
+	bool multiparsel_cache_;
 	///
 	lyx::pit_type anchor_ref_;
 	///
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.323
diff -u -p -r1.323 text3.C
--- text3.C	31 Dec 2005 11:40:32 -	1.323
+++ text3.C	4 Jan 2006 09:09:26 -
@@ -1531,10 +1531,14 @@ void LyXText::dispatch(LCursor & cur, Fu
 
 	if (singleParUpdate)
 		// Inserting characters does not change par height
-	   	if (cur.bottom().paragraph().dim().height() 
+		if (cur.bottom().paragraph().dim().height() 
 		== olddim.height()) {
 			// if so, update _only_ this paragraph
-			cur.bv().update(Update::SinglePar | Update::Force);
+			cur.bv().update(Update::SinglePar |
+	Update::FitCursor |
+	Update::MultiParSel);
+			cur.noUpdate();
+			return;
 		} else
 			needsUpdate = true;
 	if (!needsUpdate
Index: LyXAction.C
===
RCS

Re: Linking failure on Mac

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:

Bennett> Most recent cvs fails to link on Mac with gcc-3.3. Any hints?

It seems that libtool eats the -framework options that the mac needs.
Probably related to Lars' recent update.

JMarc

Re: LyX 1.4.0-pre3 on Mac

> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

>> Finally, LyX-1.4.0-pre3 does not contain Martin's singlerow6.diff
>> patch necessary for decent typing speed on the Mac. I applied that
>> patch manually before posting a test version; should I do this for
>> the final version of 1.4.0? (I've lost track of where we stood on
>> this)

Martin> That patch will require a lot of work still. It won't be in
Martin> 1.4.0. If users are happy with a version plagued by rendering
Martin> turds I suppose 1.4.1 would be doable.

I am not sure that Bennett is referring to this patch. The
singlerow/crc patch has been applied after 1.4.0pre3, and it should
make a difference.

JMarc

Re: broken link on web page Internationalization Effort

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Tomasz ?uczak wrote:
>> Hi
>> 
>> Here http://www.lyx.org/devel/translation.php in section Web Pages,
>> there is broken link http://www.lyx.org/devel/about/i18n.php
>> instead http://www.lyx.org/about/i18n.php

Angus> Fixed.

Angus, I see you fixed Tomasz' name in i18n.php. This is pretty
useless, since the name is extracted from pl.po by the postats.sh
script. I am not sure what we should do here, since I guess the L+/
character is not in latin1. So the postats.sh script should extract
the encoding from the po file and convert the translator name
accordingly. Somehow I feel a bit lazy about it :)

JMarc

Re: How to speed up LyXText::breakParagraph?


Martin Vermeer a écrit :

On Tue, Jan 03, 2006 at 07:52:13PM +0100, Abdel wrote:

Hello,

On windows with 1.4.0cvs on for big documents (ex: Extended.lyx), there 
is a big delay (~1s) before a "Carriage Return" is shown on screen after 
typing the "enter" key in the middle of a paragraph. The same will 
happen when you type "Backspace" at the beginning of a paragraph. On the 
contrary, if you type Ctrl-Z immediately after, the screen update is 
instantaneous.


For both keys, 1.3.7pre is very quick.

I am trying to investigate if I could speed-up this a bit because this 
is very, very irritating. I found that the big delay is in 
"LyXText::breakParagraph" and more precisely in "::breakParagraph", 
paragraph_funcs.C:97. The time consuming operation is the insertion of a 
new paragraph inside the ParagraphList which is in fact a std::vector :


ParagraphList::iterator tmp =
pars.insert(pars.begin() + par_offset + 1, Paragraph());

I have compiled this file with -O3 but the slowness is still there. 
Indeed insertion inside a vector is known to be inefficient. I have read 
the history about ParagraphList_fwd.h 
(http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/ParagraphList_fwd.h) 
and I guess there might be some valid reason to choose a vector instead 
of a list but performance wise, it shows, definitely. I have tried to 
replace with a list but this won't compile because some source needs the 
[] operator. I have also tried a deque and the results are a bit better. 
The weird thing is that the slowness is not at the same place. Indeed, 
within a "Standard" environment, the paragraph insertion at the 
beginning seems to be very fast but the following operation is slowing 
things down:


for (pos_type i = pos_end; i >= pos; --i)
par.eraseIntern(i);

Within a "List" environment, the behavior is the same as with a vector 
based class: the slowness is in the paragraph insertion at the beginning.


But I don't know if this is safe, so my question is: is there any 
assumption in the code that the ParagraphList use a contiguous memory? 
Deque does not... But "Extended.lyx" loads fine and all seems correct 
(math, table, etc...).


There is a pending patch which could use the  property... or
not (bug 2015) ;-)


From what I see it uses size() and operator[] so deque would be fine 
here also. But maybe rewriting this patch to use ParagraphList::iterator 
and algorithm::find would be better, wouldn't it? This way we won't rely 
on vector property.




I think a better solution would be to use a map or maybe a vector of 
pointer.
Like it is now, IMHO, lyx-1.4 is close to unusable under window. Is 
there some unofficial patch that would speed up things a bit?


Andre had something that IIRC would replace the official insert() by a
homegrown one, presumably faster. (What's the status of that?)


I think it is possible to rewrite the ParagraphList class that would not 
need the removal of the official insert(), only a cosmetic change.
IMHO, a good solution would be to use a list member to store 
the paragraphs and a vector for the 
interface. This way ParagraphList::insert would call list::insert and 
then update the vector or list iterator. I believe this would imply 
minimal change to the code using ParagraphList; we would just need to 
replace "insert(XXX.begin()+pos, Par)" with "insert(pos, Par)". Here is 
a class prototype (not tested):


class ParagraphList
{
public:
///
typedef std::vector  BaseType;
typedef std::vector ::iterator Iter;
typedef std::vector ::const_iterator ConstIter;

typedef std::list::iterator Pli;   
typedef std::list::const_iterator Iter;

protected:
typedef std::vector::iterator Iter;
list ParList_;
vector PliVector_;

public:
///
ParagraphList()
{
// Reserve Memory for 10 iterators
// which would represent 100 paragraph
// I guess this is enough?
PliVector_.reserve(10);
}

Paragrah& get(size_t pos)
{
BOOST_ASSERT(pos < PliVector_.size())
return *PliVector_[pos];
}

/// Erases the paragraph at position pos.
bool erase(size_t pos)
{
if (pos >= PliVector_.size())
{
// What happened here?
return false
}

size_t new_size=PliVector_.size()-1;
PliVector.resize(new_size);

if (pos == PliVector_.size())
{
PliVector[pos] = ParList_.pop_back(Par);
}
else
{
ParList_.erase(PliVector_[pos]);
}

// Warning: I think Vector resize

Math subscript deletion causes crash in 1.3

2006-01-04 Thread John C. McCabe-Dansted

I have found that under LyX 1.3.6 and 1.3.7cvs, if I follow the following 
steps I get a crash.

1. Enter mathmode
2. type: T_E X  
3. move the cursor before the E
4. press delete
5. press the up arrow twice.

This bug does not occur in 1.4.0pre3.

My system: Kubuntu 5.10, gcc 4.02, QT 3.3.4, KDE 3.5

-- 
John C. McCabe-Dansted
Masters Student

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:

Juergen> I have tried to enhance my witness a bit this year. Here's
Juergen> how I understand this case:

I think the problem is in DEPM: since it deletes a paragraph, the
recordUndo call should span two paragraphs (think about deleting a
selection that spans more than a paragraph).

I propose the following patch. What do you think?

JMarc

Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.2351
diff -u -p -r1.2351 ChangeLog
--- src/ChangeLog	1 Jan 2006 23:06:22 -	1.2351
+++ src/ChangeLog	4 Jan 2006 11:36:04 -
@@ -1,3 +1,8 @@
+2006-01-04  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
+
+	* text2.C (deleteEmptyParagraphMechanism): since we delete a
+	paragraph, recordUndo should span two paragraphs (bug 2155).
+
 2006-01-01  Martin Vermeer  <[EMAIL PROTECTED]>
 
 	* rowpainter.C (paintPar): always repaint the row with the
Index: src/text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.636
diff -u -p -r1.636 text2.C
--- src/text2.C	6 Dec 2005 14:54:23 -	1.636
+++ src/text2.C	4 Jan 2006 11:36:04 -
@@ -1234,7 +1234,8 @@ bool LyXText::deleteEmptyParagraphMechan
 
 	if (oldpar.empty() || (oldpar.size() == 1 && oldpar.isLineSeparator(0))) {
 		// Delete old par.
-		recordUndo(old, Undo::ATOMIC, old.pit());
+		recordUndo(old, Undo::ATOMIC, 
+			   old.pit(), min(old.pit() + 1, old.lastpit()));
 		ParagraphList & plist = old.text()->paragraphs();
 		plist.erase(plist.begin() + old.pit());

Re: Math subscript deletion causes crash in 1.3

John C. McCabe-Dansted wrote:
> I have found that under LyX 1.3.6 and 1.3.7cvs, if I follow the following
> steps I get a crash.
>
> 1. Enter mathmode
> 2. type: T_E X      
> 3. move the cursor before the E
> 4. press delete
> 5. press the up arrow twice.

There's already a report for this on bugzilla (can't remember the number). The 
bug has been fixed for 1.4.

Jürgen

Re: Screen update improvements

> "Abdel" == Abdel  <[EMAIL PROTECTED]> writes:

Abdel> Michael Gerz a écrit :
>> Martin, your row signature patch is excellent as it reduces screen
>> flickering significantly (you could the flicking on Windows with
>> qtwin).

Abdel> FYI, without this patch (I have not update my cvs yet), my Qt4
Abdel> port has zero flickering :-) I think this patch is solving here
Abdel> a problem which is in the Qt3 frontend. During my port, I have
Abdel> erased all the calls to the "QWidget::repaint" function and I
Abdel> just have one "update" to the screen. In other word, I let Qt
Abdel> decide when to draw. 

Concerning flicker, I read that using setBackgroundMode(NoBackground)
on a custom Widget help avoiding clearing the windows first. Is that
true?

Reference:
http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html

There are also some double bufferning tricks there.

JMarc

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

Jean-Marc Lasgouttes wrote:
> I think the problem is in DEPM: since it deletes a paragraph, the
> recordUndo call should span two paragraphs (think about deleting a
> selection that spans more than a paragraph).
>
> I propose the following patch. What do you think?

I think you are right. I wonder why I did no see this.

Jürgen

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:

Juergen> Jean-Marc Lasgouttes wrote:
>> I think the problem is in DEPM: since it deletes a paragraph, the
>> recordUndo call should span two paragraphs (think about deleting a
>> selection that spans more than a paragraph).
>> 
>> I propose the following patch. What do you think?

I had this nagging feeling that something had to be wrong in dEPM...
That's why I was not satisfied with your patches. 

Juergen> I think you are right. I wonder why I did no see this.

Can you test it a little bit? I may not have thought about everything
(for example the min was added after I tried to delete the last line
of a paragraph with backspace).

JMarc

Re: Screen update improvements


Jean-Marc Lasgouttes a écrit :

"Abdel" == Abdel  <[EMAIL PROTECTED]> writes:


Abdel> Michael Gerz a écrit :

Martin, your row signature patch is excellent as it reduces screen
flickering significantly (you could the flicking on Windows with
qtwin).


Abdel> FYI, without this patch (I have not update my cvs yet), my Qt4
Abdel> port has zero flickering :-) I think this patch is solving here
Abdel> a problem which is in the Qt3 frontend. During my port, I have
Abdel> erased all the calls to the "QWidget::repaint" function and I
Abdel> just have one "update" to the screen. In other word, I let Qt
Abdel> decide when to draw. 


Concerning flicker, I read that using setBackgroundMode(NoBackground)
on a custom Widget help avoiding clearing the windows first. Is that
true?


I guess so yes. Following patch will do so.



Reference:
http://developer.kde.org/documentation/books/kde-2.0-development/ch09lev1sec2.html

There are also some double bufferning tricks there.

JMarc



Index: QWorkArea.C
===
RCS file: /var/cvs/lyx/lyx-devel/src/frontends/qt2/QWorkArea.C,v
retrieving revision 1.29
diff -u -r1.29 QWorkArea.C
--- QWorkArea.C 18 Jul 2005 00:29:12 -  1.29
+++ QWorkArea.C 4 Jan 2006 11:52:18 -
@@ -57,7 +57,10 @@

content_->show();

-   content_->setBackgroundColor(lcolorcache.get(LColor::background));
+   // It is said that this help reduce flicker
+   content_->setBackgroundMode(NoBackground);
+   // If we go back to a custom backgound call:
+   // 
content_->setBackgroundColor(lcolorcache.get(LColor::background));


QHBoxLayout * vl = new QHBoxLayout(this);
vl->addWidget(content_, 5);

[Patch] (Re: Bugs status)

On Mon, Jan 02, 2006 at 08:52:06PM +0200, Martin Vermeer wrote:
> On Mon, Jan 02, 2006 at 06:17:31PM +0200, Martin Vermeer wrote:
> 
...

> Bugzilla has a fix which simply disables font attribute editing inside a
> charstyle inset; see above theory. Problem solved :-)

...

> See attached, tested and works. OK to commit?
> 
> - Martin

Ping...


> Index: insetcharstyle.C
> ===
> RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
> retrieving revision 1.39
> diff -u -p -r1.39 insetcharstyle.C
> --- insetcharstyle.C  25 Nov 2005 14:40:32 -  1.39
> +++ insetcharstyle.C  2 Jan 2006 18:59:02 -
> @@ -249,6 +249,19 @@ bool InsetCharStyle::getStatus(LCursor &
>   case LFUN_BREAKPARAGRAPH:
>   case LFUN_BREAKPARAGRAPHKEEPLAYOUT:
>   case LFUN_BREAKPARAGRAPH_SKIP:
> + // font attributes also not allowed
> + case LFUN_DEFAULT:
> + case LFUN_CODE:
> + case LFUN_ROMAN:
> + case LFUN_SANS:
> + case LFUN_BOLD:
> + case LFUN_ITAL:
> + case LFUN_EMPH:
> + case LFUN_NOUN:
> + case LFUN_UNDERLINE:
> + case LFUN_FONT_SIZE:
> + case LFUN_FREEFONT_APPLY:
> + case LFUN_FREEFONT_UPDATE:
>   status.enabled(false);
>   return true;
>  



pgprG9vBaGq3N.pgp
Description: PGP signature

Re: [Patch] (Re: Bugs status)

Martin Vermeer wrote:

> On Mon, Jan 02, 2006 at 08:52:06PM +0200, Martin Vermeer wrote:
>> On Mon, Jan 02, 2006 at 06:17:31PM +0200, Martin Vermeer wrote:
>> 
> ...
> 
>> Bugzilla has a fix which simply disables font attribute editing inside a
>> charstyle inset; see above theory. Problem solved :-)
> 
> ...
> 
>> See attached, tested and works. OK to commit?
>> 
>> - Martin
> 
> Ping...

One dumb question: What happens with existing documents? Do wee need a file
format change?


Georg

Re: [Patch] (Re: Bugs status)

On Wed, Jan 04, 2006 at 01:48:15PM +0100, Georg Baum wrote:
> Martin Vermeer wrote:
> 
> > On Mon, Jan 02, 2006 at 08:52:06PM +0200, Martin Vermeer wrote:
> >> On Mon, Jan 02, 2006 at 06:17:31PM +0200, Martin Vermeer wrote:
> >> 
> > ...
> > 
> >> Bugzilla has a fix which simply disables font attribute editing inside a
> >> charstyle inset; see above theory. Problem solved :-)
> > 
> > ...
> > 
> >> See attached, tested and works. OK to commit?
> >> 
> >> - Martin
> > 
> > Ping...
> 
> One dumb question: What happens with existing documents? Do wee need a file
> format change?

No.

This is about adding font attributes to the text inside charstyle
insets. The patch makes that effectively impossible.

Existing documents (created by people writing their own LaTeX layout
files containing charstyle definitions) will, while valid .lyx files, 
continue to misbehave like reported in the bug ;-)

I expect there will be very few of them, as charstyles were added only
in 1.4, which isn't released yet. As all people running into this
problem are knowledgable users, a note in the Release Notes will do.

- Martin



pgptzcOzZ1dNE.pgp
Description: PGP signature

Re: How to speed up LyXText::breakParagraph?

Oups I just notice a Cut problem. The prototype I am proposing is 
as follow, sorry about that. Optionnally, insert could return a 
reference or a pointer to the newly inserted paragraph but I think that 
the get(size_t) function is cleaner.


class ParagraphList
{
public:
/// 
typedef std::list::iterator Pli;   
typedef std::list::const_iterator Iter;

protected:
typedef std::vector::iterator Iter;
list ParList_;
vector PliVector_;

public:
///
ParagraphList()
{
// Reserve Memory for 10 iterators
// which would represent 100 paragraph
// I guess this is enough?
PliVector_.reserve(10);
}

Paragrah& get(size_t pos)
{
BOOST_ASSERT(pos < PliVector_.size())
return *PliVector_[pos];
}

/// Erases the paragraph at position pos.
bool erase(size_t pos)
{
if (pos >= PliVector_.size())
{
// What happened here?
return false
}

size_t new_size=PliVector_.size()-1;
PliVector.resize(new_size);

if (pos == PliVector_.size())
{
PliVector[pos] = ParList_.pop_back(Par);
}
else
{
ParList_.erase(PliVector_[pos]);
}

// Warning: I think Vector resize does not keep data
// in this case. So it is safer to update the vector
// entirely
Pli pli = ParList_.begin();
for (size_t i=0; i PliVector_.size())
{
// What happened here?
return false;
}

size_t new_size=PliVector_.size()+1;
PliVector.resize(new_size);
if (pos == PliVector_.size())
{
PliVector[pos] = ParList_.push_back(Par);
}
else
{
Pli pli = ParList_.insert(PliVector_[pos], Par);
for (size_t i=pos; i= pos; --i)
par.eraseIntern(i);

Within a "List" environment, the behavior is the same as with a 
vector based class: the slowness is in the paragraph insertion at the 
beginning.


But I don't know if this is safe, so my question is: is there any 
assumption in

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

Jean-Marc Lasgouttes wrote:
> Can you test it a little bit? I may not have thought about everything
> (for example the min was added after I tried to delete the last line
> of a paragraph with backspace).

I do not have much time for testing ATM. I tested the cases that I also tested 
with my patches, and they all work as expected. I'd propose to commit your 
patch.

Jürgen

Re: Bugs status