Re: More graphics disaster

[Andre Poenitz]

On Tue, Jan 29, 2002 at 11:09:06PM +0100, Herbert Voss wrote:
 config file, where you can declare the file suffixes.
 It's better to choose .cmp.eps, .sol.eps a.s.o. than it's
 easy for lyx to check what type.
 But it maybe a good idea to define other extensions in
 the preferences or to get the graphic type from it's
 contents, when unknown.

Maybe we should really just look at the contents. Usually the first few
bytes are enough. Of course, this is more expensive, but more robust, too...

Andre' 

-- 
André Pönitz .. [EMAIL PROTECTED]

Latest CVS: Problem with Win32 LyX

[Kayvan A. Sylvan]

This is a recent problem (within the last week or so).

On Win32/Cygwin under Win2K:

Trying to generate postscript from a document of class literate-article,
I was getting many LaTeX errors after updating from CVS.

I looked at the generated latex from Linux and from Win2k.

The difference is that on Win2K, I am missing the Textclass-specific
commands (see below for the diff). Any idea of why this could be happening?

--- /cygdrive/z/knightgame.tex  Wed Jan 30 00:33:16 2002
+++ knightgame.tex  Tue Jan 29 23:21:05 2002
@@ -1,9 +1,9 @@
 \batchmode% === this file was generated automatically by noweave --- better not edit 
it
 \makeatletter
-\def\input@path{{/net/home/kayvan//}}
+\def\input@path{{C:/cygwin/home/Kayvan/src/knightgame/}}
 \makeatother
 \documentclass[english]{article}
-\usepackage[T1]{fontenc}
+\usepackage[]{fontenc}
 \usepackage[latin1]{inputenc}
 \IfFileExists{url.sty}{\usepackage{url}}
   {\newcommand{\url}{\texttt}}
@@ -12,9 +12,6 @@
 
 %% LyX specific LaTeX commands.
 \providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
-
-%% Textclass specific LaTeX commands.
- \usepackage{noweb}
 
 %% User specified LaTeX commands.
 %

-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)



msg32165/pgp0.pgp
Description: PGP signature

Ò»¸öȫеÄÃâ·Ñ¹©Çó·¢²¼ÍøÕ¾µÈ×ÅÄãµÄ¹âÁÙ!

[ll]

Ç×°®µÄµÄÅóÓÑ£¬ÔÚ´ËÏòÄãÍƼöÕâ¸öÍøÕ¾£¬ËüÓµÓй㶫ÆóÒµ¡¢×¨¼ÒÈ˲š¢´úÀíÉ̼ҡ¢
±ÏÒµÉú×ÊÁÏËÄ´óÊý¾Ý¿âµÄÃâ·Ñ¼È룬±ÏÒµÉúÍøÉÏÇóÖ°¿ÉÃâ·Ñ¼Èë¸öÈË×ÊÁÏ£¬¿ÉÃâ·Ñ
ÍÆÏú±¾¹«Ë¾µÄ²úÆ·£¬Ñ°ÕÒºÏ×÷»ï°é¡£»¹¿ÉÒÔÃâ·ÑÌáÉý×ÔÉíµÄÖªÃû¶È£¬»ú²»¿Éʧ£¬Ê±
²»ÔÙÀ´£¬¿ì¿ì·ÃÎÊwww.fcfree.com!!


ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡
ÏÂÔØÍøÖ·£ºhttp://love2net.51.net/£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡­¡­


INFORMATION
This message has been sent using a trial-run version
of the TSmtpRelayServer Delphi Component.

Re: CVS Update: lyx-devel

[Edwin Leuven]

 Hummm, what do we want this for ?

viewing latex style files from the texinfo dialog?

 The Qt2 way is to use QWhatsThis.

but this is like a big tooltip right? not so suitable for viewing large files 
though...

you want it out?

Just getting rid of xforms cruft, Ed.

Re: More graphics disaster

[Herbert Voss]

On Wed, 30 Jan 2002, Lars Gullik [iso-8859-1] Bjønnes wrote:

 Andre Poenitz [EMAIL PROTECTED] writes:

 | On Tue, Jan 29, 2002 at 11:09:06PM +0100, Herbert Voss wrote:
  config file, where you can declare the file suffixes.
  It's better to choose .cmp.eps, .sol.eps a.s.o. than it's
  easy for lyx to check what type.
  But it maybe a good idea to define other extensions in
  the preferences or to get the graphic type from it's
  contents, when unknown.
 
 | Maybe we should really just look at the contents. Usually the first few
 | bytes are enough. Of course, this is more expensive, but more robust, too...

 Then we should use file(1) or a lib that accesses the same magic
 file(s).

maybe that we should have a look at this part and
try a bit more. I didn't changed this code and it all works well for me.

Herbert

Re: CVS Update: lyx-devel

[John Levon]

On Wed, Jan 30, 2002 at 10:14:17AM +0100, Edwin Leuven wrote:

  Hummm, what do we want this for ?
 
 viewing latex style files from the texinfo dialog?

ah OK I thought it only got used for the short help files. My mistake.

regards
john

-- 
24-hour boredom
I'm convicted instantly
- Manic Street Preachers

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[Andre Poenitz]

On Wed, Jan 30, 2002 at 08:08:22AM +0200, Martin Vermeer wrote:
 ...and feel free to explain what you mean... if this is clear to both of you,
 to me it is Chinese ;-)

The 'InsetCode' stuff is (from a strict OO point of view at least - which I
not always support) a bad thing.

An object should identify itself by its behaviour, not by providing some
magic value and pushing the responsibility to 'get it right' to 'user code'.

The 'clean solution' would be to create some 

  virtual bool canBePutIntoALabel() const { return false; }

into the inset base class and override this by putting 

  virtual bool canBePutIntoALabel() const { return true; }

in the classes that 'have this property'. User code simply has to call

  inset-canBePutIntoALabel()

to learn whether this inset can be put in a label or not.

If religious reasons don't count much for you imagine what happens when
we add a new inset that derives from and inset with canBePutIntoALabel() ==
true.  With the InsetCode 'solution' you have to add the proper InsetCode
to the if() in the user code, with the 'proper' solution you do not have to
do anything. It just works.

Now you might argue that adding another case to the if() is not much work.
Fair enough... But how do you tell which user code is affected without
checking _each_ file manually? And what happens to your if-clauses if we
have 30 insets? 

Andre'


-- 
André Pönitz .. [EMAIL PROTECTED]

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[John Levon]

On Wed, Jan 30, 2002 at 11:11:59AM +0100, Andre Poenitz wrote:

   virtual bool canBePutIntoALabel() const { return false; }

 true.  With the InsetCode 'solution' you have to add the proper InsetCode

of course, both solutions suck, and we really want proper RTTI or an inset_traits
or something ... but the current locking / containing inset  scheme prevents that ...

john

-- 
This is mindless pedantism up with which I will not put.
- Donald Knuth on Pascal's lack of default: case statement

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[Andre Poenitz]

On Wed, Jan 30, 2002 at 10:19:39AM +, John Levon wrote:
 of course, both solutions suck, and we really want proper RTTI

This would still make the user code decide which inset is 'ok' and which
not... 

 or an inset_traits or something

This is 'usability-wise' not very different from the virtual function
method, is it?

I think there generally there is no perfect method, so given a selection of
more or less equivalent items I'd pick the one which suits best to the rest
of the project. And we have virtual functions already, but no RTTI and no
traits of our own that I am aware of...

 ... but the current locking/ containing inset scheme prevents that ...

The current locking scheme has made it to the top of my personal list of
'10 reasons why LyX source suck'. --- Yes. That's the position in front of
the paragraph list stuff...

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[Martin Vermeer]

On Wed, Jan 30, 2002 at 11:11:59AM +0100, Andre Poenitz wrote:
 
 On Wed, Jan 30, 2002 at 08:08:22AM +0200, Martin Vermeer wrote:
  ...and feel free to explain what you mean... if this is clear to both of you,
  to me it is Chinese ;-)
 
 The 'InsetCode' stuff is (from a strict OO point of view at least - which I
 not always support) a bad thing.
 
 An object should identify itself by its behaviour, not by providing some
 magic value and pushing the responsibility to 'get it right' to 'user code'.
 
 The 'clean solution' would be to create some 
 
   virtual bool canBePutIntoALabel() const { return false; }
 
 into the inset base class and override this by putting 
 
   virtual bool canBePutIntoALabel() const { return true; }
 
 in the classes that 'have this property'. User code simply has to call
 
   inset-canBePutIntoALabel()
 
 to learn whether this inset can be put in a label or not.
 
 If religious reasons don't count much for you imagine what happens when
 we add a new inset that derives from and inset with canBePutIntoALabel() ==
 true.  With the InsetCode 'solution' you have to add the proper InsetCode
 to the if() in the user code, with the 'proper' solution you do not have to
 do anything. It just works.
 
 Now you might argue that adding another case to the if() is not much work.
 Fair enough... But how do you tell which user code is affected without
 checking _each_ file manually? And what happens to your if-clauses if we
 have 30 insets? 
 
 Andre'

Ah, I see. Great explanation.

I don't think this is undoable. The same functionality would require
touching only five inset*.[hC] file pairs IIUC.

Should I do it?

-- Martin



msg32173/pgp0.pgp
Description: PGP signature

Re: Slackware package

[Jean-Marc Lasgouttes]

 Matej == Matej Cepl [EMAIL PROTECTED] writes:

Matej Have you already done so? I would love to remove the package
Matej from the website (I need to put there something else and I am
Matej so close to the quota).

Done.

JMarc

Re: Bugs

[Jean-Marc Lasgouttes]

 John == John Levon [EMAIL PROTECTED] writes:

John On Sun, Jan 27, 2002 at 10:05:22AM +0100, Michael Schmitt wrote:
 - New document; enter some letter; undo; undo again - misleading
 minibuffer message

John hmm the problem is simple, and in lots of lyxfuncs.

John Perhaps we should add a disable(bool, string const 
John disabledmsg); ??

And then the status message would have to be moved inside FuncStatus.
This would probably be better in the long term.

John JMarc how about this :

Looks like a reasonable workaround. Why do you use N_()?

JMarc

Re: Bugs

[John Levon]

On Wed, Jan 30, 2002 at 12:08:57PM +0100, Jean-Marc Lasgouttes wrote:

 John Perhaps we should add a disable(bool, string const 
 John disabledmsg); ??
 
 And then the status message would have to be moved inside FuncStatus.
 This would probably be better in the long term.

mm yeah

 John JMarc how about this :
 
 Looks like a reasonable workaround. Why do you use N_()?

just because the other bits do there. I didn't and don't understand the
N_() thing, I was too lazy to read the last round of explanations of it
vs. _()

regards
john

-- 
This is mindless pedantism up with which I will not put.
- Donald Knuth on Pascal's lack of default: case statement

Re: Latest CVS: Problem with Win32 LyX

[Jean-Marc Lasgouttes]

 Kayvan == Kayvan A Sylvan [EMAIL PROTECTED] writes:

Kayvan This is a recent problem (within the last week or so). On
Kayvan Win32/Cygwin under Win2K:

Kayvan Trying to generate postscript from a document of class
Kayvan literate-article, I was getting many LaTeX errors after
Kayvan updating from CVS.

Kayvan I looked at the generated latex from Linux and from Win2k.

Kayvan The difference is that on Win2K, I am missing the
Kayvan Textclass-specific commands (see below for the diff). Any idea
Kayvan of why this could be happening?

Interesting. This really looks like the problem Angus has been seeing
with compaq cxx. Might it be that we are not using ostringstream correctly?

JMarc

Re: Latest CVS: Problem with Win32 LyX

[Angus Leeming]

On Wednesday 30 January 2002 11:15 am, Jean-Marc Lasgouttes wrote:
  Kayvan == Kayvan A Sylvan [EMAIL PROTECTED] writes:
 
 Kayvan This is a recent problem (within the last week or so). On
 Kayvan Win32/Cygwin under Win2K:
 
 Kayvan Trying to generate postscript from a document of class
 Kayvan literate-article, I was getting many LaTeX errors after
 Kayvan updating from CVS.
 
 Kayvan I looked at the generated latex from Linux and from Win2k.
 
 Kayvan The difference is that on Win2K, I am missing the
 Kayvan Textclass-specific commands (see below for the diff). Any idea
 Kayvan of why this could be happening?
 
 Interesting. This really looks like the problem Angus has been seeing
 with compaq cxx. Might it be that we are not using ostringstream correctly?

Well if that is the case, then this band aid works on my machine. What's your 
milage Kayvan?

Note that I'm not suggesting this goes in the LyX source. Just that me might 
get some feel for the problem.

Angus


Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.53
diff -u -p -r1.53 LaTeXFeatures.C
--- src/LaTeXFeatures.C	2002/01/10 10:05:43	1.53
+++ src/LaTeXFeatures.C	2002/01/18 17:57:13
@@ -339,14 +339,18 @@ string const LaTeXFeatures::getTClassPre
 	// the text class specific preamble 
 	LyXTextClass const  tclass = textclasslist.TextClass(params.textclass);
 	ostringstream tcpreamble;
-	
+
 	tcpreamble  tclass.preamble();
 
 	for (layout_type i = 0; i  tclass.numLayouts(); ++i) {
 		if (layout[i]) {
-			tcpreamble   tclass[i].preamble();
+			tcpreamble  tclass[i].preamble();
 		}
 	}
+
+	// DEC's implementation of ostringstream has a bug which can be
+	// overcome with this forcing.
+	tcpreamble.seekp(std::ios::beg);
 
 	return tcpreamble.str().c_str();
 }	

Re: Latest CVS: Problem with Win32 LyX

[Andre Poenitz]

On Wed, Jan 30, 2002 at 12:15:28PM +0100, Jean-Marc Lasgouttes wrote:
 Interesting. This really looks like the problem Angus has been seeing
 with compaq cxx. Might it be that we are not using ostringstream correctly?

Could you direct me again to the code in question?

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: Latest CVS: Problem with Win32 LyX

[Jean-Marc Lasgouttes]

 Andre == Andre Poenitz [EMAIL PROTECTED] writes:

Andre On Wed, Jan 30, 2002 at 12:15:28PM +0100, Jean-Marc Lasgouttes
Andre wrote:
 Interesting. This really looks like the problem Angus has been
 seeing with compaq cxx. Might it be that we are not using
 ostringstream correctly?

Andre Could you direct me again to the code in question?

LaTeXFeatures::getTClassPreamble at LaTeXFeatures.C:337.

JMarc

Re: Latest CVS: Problem with Win32 LyX

[Angus Leeming]

On Wednesday 30 January 2002 12:13 pm, Lars Gullik Bjønnes wrote:
 Angus Leeming [EMAIL PROTECTED] writes:
 
 | +
 | +   // DEC's implementation of ostringstream has a bug which can be
 | +   // overcome with this forcing.
 | +   tcpreamble.seekp(std::ios::beg);
 |  
 | return tcpreamble.str().c_str();
 
 Oooo dirty...
 
 How can we avoid this?
 
 because if we use it we need it all over... and that is not
 acceptable.

I'm not saying that this is the answer, just that this appears to resolve the 
problem here. 

I assumed that the true problem lies in my version of std::ostringstream, but 
if Kayvan experiences the same problem and it is cured in the same way, then 
perhaps the problem lies elsewhere.

Anyway, it'll be intersting to get Kayvan's results with this.

A

Re: Patch for Lyx on Win32/Cygnus

[Jean-Marc Lasgouttes]

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

Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars | Lars Use of ios::binary should be ok. (but I guess it really
Lars should | Lars be ios_base::binary)

Lars | What's the difference?

Lars ios_base:: what the standard says...

Lars ios:: some sub class that inherits from ios_base

So how come LyX oly uses ios and never ios_base? I'll stick to ios for
simplicity.

JMarc

Re: Latest CVS: Problem with Win32 LyX

[Andre Poenitz]

On Wed, Jan 30, 2002 at 12:19:53PM +, Angus Leeming wrote:
 I assumed that the true problem lies in my version of std::ostringstream, but 
 if Kayvan experiences the same problem and it is cured in the same way, then 
 perhaps the problem lies elsewhere.

What does your library's std::ostringstream::str() return?

'string' or 'string const '?

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: Patch for Lyx on Win32/Cygnus

[Andre Poenitz]

On Wed, Jan 30, 2002 at 01:25:59PM +0100, Jean-Marc Lasgouttes wrote:
 So how come LyX oly uses ios and never ios_base? I'll stick to ios for
 simplicity.

g++ 2.95.2's standard library has no ios_base.

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: Latest CVS: Problem with Win32 LyX

[Angus Leeming]

On Wednesday 30 January 2002 12:35 pm, Andre Poenitz wrote:
 On Wed, Jan 30, 2002 at 12:19:53PM +, Angus Leeming wrote:
  I assumed that the true problem lies in my version of std::ostringstream, 
but 
  if Kayvan experiences the same problem and it is cured in the same way, 
then 
  perhaps the problem lies elsewhere.
 
 What does your library's std::ostringstream::str() return?
 
 'string' or 'string const '?
 
 Andre'

string.
Here's the class definition.
Angus

templateclass charT, class traits, class Allocator
class basic_ostringstream : public basic_ostreamcharT, traits {
 public:

typedef basic_stringbufcharT, traits, Allocatorsb_type;
typedef basic_ioscharT, traits ios_type;
typedef basic_stringcharT, traits, Allocator   string_type;

typedef traits   traits_type;
typedef charTchar_type;
typedef _TYPENAME traits::int_typeint_type;
typedef _TYPENAME traits::pos_typepos_type;
typedef _TYPENAME traits::off_typeoff_type;

_EXPLICIT basic_ostringstream(ios_base::openmode which = ios_base::out);
_EXPLICIT basic_ostringstream(const string_type str,
 ios_base::openmode which = ios_base::out);

virtual ~basic_ostringstream();

basic_stringbufcharT, traits, Allocator *rdbuf() const;
string_type str() const;

void str(const string_type str);

  protected:

  private:

sb_typesb_;

};

Re: Latest CVS: Problem with Win32 LyX

[Andre Poenitz]

On Wed, Jan 30, 2002 at 01:00:42PM +, Angus Leeming wrote:
 string.

That should be correct then.
*shrug*

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: [Bug 225] Entering \dot\vec\beta doesn't work properly

[Jean-Marc Lasgouttes]

 Andre == Andre Poenitz [EMAIL PROTECTED] writes:

 (bug 224 is the different 1.1.6 bug btw)
Andre I am fairly sure that there won't be any math fixes for 1.1.6,
Andre so it's basically a waste of time to put them into the
Andre bugtracker...

This was submitted by one of our user. I hope you are not telling me
we should tell them not to waste their time reportig bugs to
bugzilla

JMArc

Re: Purify report #2

[Jürgen Vigna]

 Next  old bug:

 Copy and paste text from any paragraph style into ERT works well now.
 But not vice versa: the textcolor is not changed, it's always red
 (latex) and LyX produces a memory access error when viewing dvi.

I sent a patch for this it should only be applied and will then fix
this bug definitively and make ERT inset nearer a Edit-Inset.

   Jug

-- 
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Tuesday 29 January 2002 8:04 pm, Juergen Spitzmueller wrote:
 Angus Leeming wrote:
  One someone like to volunteer to do this to the xforms dialog.
 
 Here it is. I tried to do it similar to the qt-dialog (within the 
 natural limitations of xforms).

Thank you. It's in my tree.

 I have added two things:
 
 1. A text_warning field and input filters like in the other dialogs 
 (only xforms related)

Good.

 2. An option Default for Screen Display, which takes the settings of 
 Preferences (lyxrc.display_graphics). Edwin, perhaps you will want to 
 add this to qt2, too?

I haven't persued this further, but think that this isn't needed. 

It can/should be set when the insetgraphicsParams instance passed to the 
dilaog is created. Either we copy an existing params instance, in which case 
we use it's value for this, or we create a new one, in which case we use 
lyxrc.display_graphics.

It's the inset that should be clever, not the frontend.

 One small issue: IMHO the Screen Display choice should be set to 
 default when the user inserts a new graphic. But it is always set to 
 Monochrome, no matter what I do. Hell knows why. Maybe someone else 
 could have a look. 

I will, although it doesn't seem to happen here.
Angus

Re: (Jug) [Devel] Revised bug list - tables

[Jürgen Vigna]

 In XML, you can define default values for attributes in the DTD.
 So with XML, it will be even easier to handle this.

 I think we should accept a patch to reduce the bloat.

I didn´t see the patch but I would like to do this myself. But if any
of the others think the patch is clean and can guarantee for it then
apply it.

   Jug

-- 
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Wednesday 30 January 2002 2:26 pm, Jean-Marc Lasgouttes wrote:
  Angus == Angus Leeming [EMAIL PROTECTED] writes:
 
  2. An option Default for Screen Display, which takes the settings
  of Preferences (lyxrc.display_graphics). Edwin, perhaps you will
  want to add this to qt2, too?
 
 Angus I haven't persued this further, but think that this isn't
 Angus needed.
 
 Angus It can/should be set when the insetgraphicsParams instance
 Angus passed to the dilaog is created. Either we copy an existing
 Angus params instance, in which case we use it's value for this, or
 Angus we create a new one, in which case we use
 Angus lyxrc.display_graphics.
 
 But I I like monochrome rendering and you like color rendering, when I
 send a file to you it should be possible for us to have different
 prefs and see different things on screen, no?
 
 JMarc

A. Understood. I'll stop messing around!

A

Re: patches to the frontends

[Martin Vermeer]

On Tue, Jan 29, 2002 at 12:52:23PM +, Angus Leeming wrote:
 
 I think that cvs now contains all the frontends patches that have been posted 
 to this list over the last few days. If I've missed anything, then sorry but 
 could you please shout loudly and tell me the address in the mail archives!
 
 Angus
 

Angus,

does the maths styles and fonts sub-panel really work correctly for you?
It appears the image file style.xbm in CVS is corrupted in a way that makes
it unuseable. Doesn't even load by xloadimage until the attached patch.

Weird.

-- Martin



Index: style.xbm
===
RCS file: /cvs/lyx/lyx-devel/images/style.xbm,v
retrieving revision 1.2
diff -u -b -B -p -r1.2 style.xbm
--- style.xbm   2002/01/29 12:43:58 1.2
+++ style.xbm   2002/01/30 14:35:04
@@ -1,5 +1,5 @@
 #define style1_width 135
-#define style1_height 270
+#define style1_height 110
 static unsigned char const style1_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,



msg32199/pgp0.pgp
Description: PGP signature

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Wednesday 30 January 2002 2:40 pm, Juergen Spitzmueller wrote:
 Jean-Marc Lasgouttes wrote:
  Angus I haven't persued this further, but think that this isn't
  Angus needed.
 
  Angus It can/should be set when the insetgraphicsParams instance
  Angus passed to the dilaog is created. Either we copy an existing
  Angus params instance, in which case we use it's value for this, or
  Angus we create a new one, in which case we use
  Angus lyxrc.display_graphics.
 
  But I I like monochrome rendering and you like color rendering, when
  I send a file to you it should be possible for us to have different
  prefs and see different things on screen, no?
 
 Yes. Unfortunately, my implementation is not that clever (yet). It just 
 choses the setting from lyxrc.display_graphics, e.g. if you have 
 monochrome there, your graphic will be set to monochrome (and stored as 
 monochrome).
 That's quite stupid, but maybe it can be enhanced (but this looks a 
 little bit more complicated to me).
 
 Anyway, it's just a proposal.

Well that sounds easy enough. Add a DEFAULT entry to 
InsetGraphicsParams::DisplayType and use it apropriately. (ie, use the 
lyxrc.display_graphics variable in InsetGraphics when 
InsetGraphicsParams::display == DEFAULT

No clever stuff in the frontends. All clever stuff in the inset.

Angus

Re: qt2: just in case [PATCH]

[Herbert Voss]

Jean-Marc Lasgouttes wrote:

Angus == Angus Leeming [EMAIL PROTECTED] writes:

 
2. An option Default for Screen Display, which takes the settings
of Preferences (lyxrc.display_graphics). Edwin, perhaps you will
want to add this to qt2, too?

 
 Angus I haven't persued this further, but think that this isn't
 Angus needed.
 
 Angus It can/should be set when the insetgraphicsParams instance
 Angus passed to the dilaog is created. Either we copy an existing
 Angus params instance, in which case we use it's value for this, or
 Angus we create a new one, in which case we use
 Angus lyxrc.display_graphics.
 
 But I I like monochrome rendering and you like color rendering, when I
 send a file to you it should be possible for us to have different
 prefs and see different things on screen, no?


I can't see the problem? it's a oneliner to get the pref-default
when creating a new graphic-inset.
on the other hand it's obvious that a single definition depends
to the local image and you'll see this in color if color was
chosen for this single image.

Herbert


-- 
http://www.lyx.org/help/

Re: qt2: just in case [PATCH]

[Juergen Spitzmueller]

Angus Leeming wrote:
 Well that sounds easy enough. Add a DEFAULT entry to
 InsetGraphicsParams::DisplayType and use it apropriately. (ie, use
 the lyxrc.display_graphics variable in InsetGraphics when
 InsetGraphicsParams::display == DEFAULT

OK, thanks for the hint. I'll try to implement it after the first patch 
has gone through CVS.

 No clever stuff in the frontends. All clever stuff in the inset.

the problem is that I don't know much about the insets, so I try to put 
all my cleverness into frontends ;-)

Juergen.

Re: patches to the frontends

[Angus Leeming]

On Wednesday 30 January 2002 2:43 pm, Martin Vermeer wrote:
 does the maths styles and fonts sub-panel really work correctly for you?
 It appears the image file style.xbm in CVS is corrupted in a way that makes
 it unuseable. Doesn't even load by xloadimage until the attached patch.
 
 Weird.

Indeed. Committed the fix. Now it appears corrrectly in LyX but not in xv.
A

Re: patches to the frontends

[Martin Vermeer]

On Wed, Jan 30, 2002 at 02:51:41PM +, Angus Leeming wrote:

 On Wednesday 30 January 2002 2:43 pm, Martin Vermeer wrote:
  does the maths styles and fonts sub-panel really work correctly for you?
  It appears the image file style.xbm in CVS is corrupted in a way that makes
  it unuseable. Doesn't even load by xloadimage until the attached patch.
  
  Weird.
 
 Indeed. Committed the fix. Now it appears corrrectly in LyX but not in xv.
 A
 

Meaning no doubt that xv reponds poorly to multi-image xbm files and reads
only the first height definition to infer the total height. Not good.
Perhaps worth a bug report ;-)

-- Martin




msg32204/pgp0.pgp
Description: PGP signature

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Wednesday 30 January 2002 2:53 pm, Juergen Spitzmueller wrote:
 Angus Leeming wrote:
  Well that sounds easy enough. Add a DEFAULT entry to
  InsetGraphicsParams::DisplayType and use it apropriately. (ie, use
  the lyxrc.display_graphics variable in InsetGraphics when
  InsetGraphicsParams::display == DEFAULT
 
 OK, thanks for the hint. I'll try to implement it after the first patch 
 has gone through CVS.

Well what are you waiting for! I've just committed it.

  No clever stuff in the frontends. All clever stuff in the inset.
 
 the problem is that I don't know much about the insets, so I try to put 
 all my cleverness into frontends ;-)

Well it isn't too complicated but currently it's all a bit of a mess. IMO 
GraphicscCacheItem shouldn't know about lyxrc.display_graphics (it does 
currently).

Having looked at the code, you should pass an extra variable to the 
GraphicsCacheItem c-tor from InsetGraphics.

GraphicsCacheItem::GraphicsCacheItem(string const  filename, DisplayType);

you should also have a GraphicsCacheItem::setDisplayType(DisplayType) method, 
so that you can change this if you so desire.

If this sounds too complicated after all, then don't worry, I'll have a look 
this evening.

A

Re: qt2: just in case [PATCH]

[Herbert Voss]

Angus Leeming wrote:

 On Wednesday 30 January 2002 2:53 pm, Juergen Spitzmueller wrote:
 
Angus Leeming wrote:

Well that sounds easy enough. Add a DEFAULT entry to
InsetGraphicsParams::DisplayType and use it apropriately. (ie, use
the lyxrc.display_graphics variable in InsetGraphics when
InsetGraphicsParams::display == DEFAULT

OK, thanks for the hint. I'll try to implement it after the first patch 
has gone through CVS.

 
 Well what are you waiting for! I've just committed it.
 


it's a bit confusing when you commit patches before the first

one runs well! there are still some problems to get the whole
graphic inset running. And the real problems are not located in
the gui but in the inset. It makes life not easier to me, when
those patches were committed before the whole stuff works
so well, that we can change the environments ...

HErbert



-- 
http://www.lyx.org/help/

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Wednesday 30 January 2002 3:21 pm, Herbert Voss wrote:
 Angus Leeming wrote:
 it's a bit confusing when you commit patches before the first
 
 one runs well! there are still some problems to get the whole
 graphic inset running. And the real problems are not located in
 the gui but in the inset. It makes life not easier to me, when
 those patches were committed before the whole stuff works
 so well, that we can change the environments ...

Sorry, but that's the whole point of incremental patches isn't it? You 
committed an enormous patch with bugs. Jürgen has cleaned up the dialog a 
little that's all. If the real problems lie in the inset, then nothing has 
changed there at all.

So apologies if I have made life difficult for you, but I don't think I have.

A

[PATCH] Citation Dialog

[Juergen Spitzmueller]

This dialog is still a real pain on a 800x600 Screen (it covers the 
whole screen, which strikes me sick).
However, with a little rearrangement I managed to get it remarkably 
smaller.

If you want to see the differences on my screen, have a look at the 
following screenshots:
http://omnibus.uni-freiburg.de/~spitzmue/cit_before.png
http://omnibus.uni-freiburg.de/~spitzmue/cit_after.png

The patch additionally features some small tweaks to form_graphics.fd 
(sorry, I must have been tired yesterday).
All in all safe to apply.

Thanks,
Jürgen.


citation.diff.gz
Description: GNU Zip compressed data

Re: Latest CVS: Problem with Win32 LyX

[Kayvan A. Sylvan]

On Wed, Jan 30, 2002 at 11:23:12AM +, Angus Leeming wrote:
 On Wednesday 30 January 2002 11:15 am, Jean-Marc Lasgouttes wrote:
   Kayvan == Kayvan A Sylvan [EMAIL PROTECTED] writes:
  
  Kayvan This is a recent problem (within the last week or so). On
  Kayvan Win32/Cygwin under Win2K:
  
  Kayvan Trying to generate postscript from a document of class
  Kayvan literate-article, I was getting many LaTeX errors after
  Kayvan updating from CVS.
  
  Kayvan I looked at the generated latex from Linux and from Win2k.
  
  Kayvan The difference is that on Win2K, I am missing the
  Kayvan Textclass-specific commands (see below for the diff). Any idea
  Kayvan of why this could be happening?
  
  Interesting. This really looks like the problem Angus has been seeing
  with compaq cxx. Might it be that we are not using ostringstream correctly?
 
 Well if that is the case, then this band aid works on my machine. What's your 
 milage Kayvan?
 
 Note that I'm not suggesting this goes in the LyX source. Just that me might 
 get some feel for the problem.
 
 Angus

Thanks!

Yes, this seems to be related.

It looks like Angus's DEC fix is *in* the current CVS. The above makes
it appear as if this was not intentional.

I had to do this (basically undoing the fix) to get it to run correctly
on Cygwin:

--- lyx/src/LaTeXFeatures.C Tue Jan 29 11:21:43 2002
+++ lyx-1.2.0cvs/src/LaTeXFeatures.CWed Jan 30 08:32:44 2002
@@ -350,7 +350,7 @@
 
// DEC's implementation of ostringstream has a bug which can be
// overcome with this forcing.
-   tcpreamble.seekp(std::ios::beg);
+   // tcpreamble.seekp(std::ios::beg);
 
return tcpreamble.str().c_str();
 }  

-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)



msg32209/pgp0.pgp
Description: PGP signature

Re: Latest CVS: Problem with Win32 LyX

[Kayvan A. Sylvan]

On Wed, Jan 30, 2002 at 01:13:29PM +0100, Lars Gullik Bjønnes wrote:
 Angus Leeming [EMAIL PROTECTED] writes:
 
 | +
 | +   // DEC's implementation of ostringstream has a bug which can be
 | +   // overcome with this forcing.
 | +   tcpreamble.seekp(std::ios::beg);
 |  
 | return tcpreamble.str().c_str();
 
 Oooo dirty...
 
 How can we avoid this?
 
 because if we use it we need it all over... and that is not
 acceptable.

It also does not appear to work. At least for Cygwin.

---Kayvan
-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)



msg32210/pgp0.pgp
Description: PGP signature

graphics dialog.

[Herbert Voss]

I'm not so happy with the graphic gui patch.

- filefolder
   - what does Screen Display here??
- bounding box folder
   - clip to bounding box depends to sizefolder
   - draft has nothing to do with bounding box

I don't want to push my gui-version(!), but it's better
for the user when importants things are hold together.

there are still some new bugs:

insert 75p% - not possible, invalid length
insert 75% in the width field and it will be accepted
but the width is set to 0cm!

this is what I mean, when saying: lets try the first
heavily and than do some things better.


Herbert


-- 
http://www.lyx.org/help/

Re: Latest CVS: Problem with Win32 LyX

[Angus Leeming]

On Wednesday 30 January 2002 4:46 pm, Kayvan A. Sylvan wrote:
 It looks like Angus's DEC fix is *in* the current CVS. The above makes
 it appear as if this was not intentional.

Ouch! Indeed it isn't meant to be in cvs. My apologies.

Now fixed.

Angus

Lyx-1.1.6fix4.ppc.rpm

[Niklas Werner]

[Kayvan's note: The following is now available in the usual place,
 ftp://ftp.sylvan.com/pub/lyx ]

Hi There!
I uploaded the ppc.rpm with md5 and a short README.

please make it available

thanks a lot and happy lyxing!


Niklas
-- 
***
Niklas Werner

http://user.cs.tu-berlin.de/~wernern/
***

Re: graphics dialog.

[Juergen Spitzmueller]

Herbert Voss wrote:
 I'm not so happy with the graphic gui patch.

 - filefolder
- what does Screen Display here??

Showing the screen display ;-)

 - bounding box folder
- clip to bounding box depends to sizefolder
- draft has nothing to do with bounding box

Well you had it (both) in the same tab as bounding box, too (file), not 
in size. So what? But of course things can be changed.

 there are still some new bugs:

 insert 75p%   - not possible, invalid length

No, not invalid. The problem is that you can only enter three 
characters into the input field (try 7p%). But I have not done this! 
I'll have a look. 

 insert 75% in the width field and it will be accepted
 but the width is set to 0cm!

True :-( 
Strange, it works in Minipage (and it's the same input filter).
I'll look. 

 this is what I mean, when saying: lets try the first
 heavily and than do some things better.

IMHO the two things are not related.

Thanks for the report.
Juergen.

 Herbert

Re: graphics dialog [PATCH]

[Juergen Spitzmueller]

Juergen Spitzmueller wrote:
 Herbert Voss wrote:
  there are still some new bugs:
 
  insert 75p% - not possible, invalid length

 No, not invalid. The problem is that you can only enter three
 characters into the input field (try 7p%). But I have not done this!
 I'll have a look.

Fixed (patch attached).

  insert 75% in the width field and it will be accepted
  but the width is set to 0cm!

 True :-(
 Strange, it works in Minipage (and it's the same input filter).
 I'll look.

I'm shure now that this has nothing to do with my changes. Are /you/ 
shure that % worked before? I have removed the filter and it didn't 
work either. Is % a valid lenght for Graphics? If not, it should be 
removed from the choices!

BTW: In the Graphics and Minipage dialogs, changing just the choice 
doesn't enable OK/ Apply, while in Paragraph and Document it 
(correctly) does. Why?

Juergen.


Index: src/frontends/xforms/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.267
diff -u -r1.267 ChangeLog
--- src/frontends/xforms/ChangeLog	2002/01/30 14:55:27	1.267
+++ src/frontends/xforms/ChangeLog	2002/01/30 18:21:13
@@ -1,5 +1,9 @@
 2002-01-29  Jürgen Spitzmüller  [EMAIL PROTECTED]

+	* FormGraphics.C: Fix MAXDIGIT values for height and width.
+
+2002-01-29  Jürgen Spitzmüller  [EMAIL PROTECTED]
+
 	* forms/form_graphics.fd: Change the dialog to look similar as
 	the nice QT2-Version (added tabfolder Bounding Box, rearrangements);
 	added text_warning field..
Index: src/frontends/xforms/FormGraphics.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/FormGraphics.C,v
retrieving revision 1.38
diff -u -r1.38 FormGraphics.C
--- src/frontends/xforms/FormGraphics.C	2002/01/30 14:55:27	1.38
+++ src/frontends/xforms/FormGraphics.C	2002/01/30 18:21:14
@@ -37,8 +37,8 @@
 
 // Bound the number of input characters
 int const SCALE_MAXDIGITS = 3;
-int const WIDTH_MAXDIGITS = 3;
-int const HEIGHT_MAXDIGITS = 3;
+int const WIDTH_MAXDIGITS = 10;
+int const HEIGHT_MAXDIGITS = 10;
 int const ROTATE_MAXCHARS = 4;
 int const FILENAME_MAXCHARS = 1024;
  

Re: CVS Update: lyx-devel

[Herbert Voss]

it would be nice if you can commit my patch from yesterday
evening, too.

Herbert



-- 
http://www.lyx.org/help/

Re: graphics dialog [PATCH]

[Angus Leeming]

On Wednesday 30 January 2002 6:28 pm, Juergen Spitzmueller wrote:
 Juergen Spitzmueller wrote:
  Herbert Voss wrote:
   there are still some new bugs:
  
   insert 75p%   - not possible, invalid length
 
  No, not invalid. The problem is that you can only enter three
  characters into the input field (try 7p%). But I have not done this!
  I'll have a look.
 
 Fixed (patch attached).

Phew! I'm running to stand still here! Thanks.

   insert 75% in the width field and it will be accepted
   but the width is set to 0cm!
 
  True :-(
  Strange, it works in Minipage (and it's the same input filter).
  I'll look.
 
 I'm shure now that this has nothing to do with my changes. Are /you/ 
 shure that % worked before? I have removed the filter and it didn't 
 work either. Is % a valid lenght for Graphics? If not, it should be 
 removed from the choices!
 
 BTW: In the Graphics and Minipage dialogs, changing just the choice 
 doesn't enable OK/ Apply, while in Paragraph and Document it 
 (correctly) does. Why?

They enable things here and indeed they have all have callbacks defined (at 
least if they're called choice_??? they do! 

Angus

graphix inset

[Herbert Voss]

the next patch to get the file type from it's contents.
Especially to Garst, please try.


Herbert

-- 
http://www.lyx.org/help/


Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.128
diff -u -r1.128 ChangeLog
--- src/frontends/controllers/ChangeLog 2002/01/30 19:14:09 1.128
+++ src/frontends/controllers/ChangeLog 2002/01/30 20:04:03
@@ -1,3 +1,8 @@
+2002-01-30  Herbert Voss  [EMAIL PROTECTED]
+
+   * ControlGraphic.[C]: do not search the whole file, when
+   getting the bb
+
 2002-01-29  Herbert Voss  [EMAIL PROTECTED]
 
* ControlGraphic.[C]: added a button for document path
Index: src/frontends/controllers/ControlGraphics.C
===
RCS file: 
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlGraphics.C,v
retrieving revision 1.16
diff -u -r1.16 ControlGraphics.C
--- src/frontends/controllers/ControlGraphics.C 2002/01/30 19:14:09 1.16
+++ src/frontends/controllers/ControlGraphics.C 2002/01/30 20:04:04
@@ -40,7 +40,6 @@
 
 using std::pair;
 using std::make_pair;
-
 using std::ifstream;
 
 ControlGraphics::ControlGraphics(LyXView  lv, Dialogs  d)
@@ -107,7 +106,9 @@
 // to check a bit more. 
 // ControlGraphics::bbChanged = false;
std::ifstream is(file.c_str());
-   while (is) {
+   int count = 0;
+   int const max_count = 50;   // don't search the whole file
+   while (is  (++count  max_count)) {
string s;
is  s;
if (contains(s,%%BoundingBox:)) {
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.299
diff -u -r1.299 ChangeLog
--- src/insets/ChangeLog2002/01/30 18:16:12 1.299
+++ src/insets/ChangeLog2002/01/30 20:04:06
@@ -1,3 +1,9 @@
+2002-01-30  Herbert Voss  [EMAIL PROTECTED]
+
+   * insetgraphic.C: get the filetyp from it's contents
+   * insetgraphicparams.C: add token scale and lyxrc.display when
+   creating a new inset
+
 2002-01-30  Angus Leeming  [EMAIL PROTECTED]
 
* figinset.C: added using std::ios directive.
Index: src/insets/insetgraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.68
diff -u -r1.68 insetgraphics.C
--- src/insets/insetgraphics.C  2002/01/29 09:26:24 1.68
+++ src/insets/insetgraphics.C  2002/01/30 20:04:06
@@ -81,6 +81,7 @@
  * Image format
  * fromto
  * EPS epstopdf
+ * PS  ps2pdf
  * JPG/PNG direct
  * PDF direct
  * others  PNG
@@ -161,8 +162,7 @@
 }
 
 
-string const
-InsetGraphics::statusMessage() const
+string const InsetGraphics::statusMessage() const
 {
string msg;
if (cacheHandle.get()) {
@@ -258,32 +258,25 @@
paint.image(old_x + 2, baseline - lascent,
lwidth - 4, lascent + ldescent,
cacheHandle-getImage());
-   } else {
-   
+   } else {
// Get the image status, default to unknown error.
GraphicsCacheItem::ImageStatus status = 
GraphicsCacheItem::UnknownError;
-   if (lyxrc.display_graphics != no  lyxrc.use_gui
-params.display != InsetGraphicsParams::NONE 
+   if (lyxrc.use_gui  params.display != InsetGraphicsParams::NONE 
cacheHandle.get())
status = cacheHandle-getImageStatus();
-   
// Check if the image is now ready.
if (status == GraphicsCacheItem::Loaded) {
imageLoaded = true;
-
// Tell BufferView we need to be updated!
bv-text-status(bv, LyXText::CHANGED_IN_DRAW);
return;
}
-
paint.rectangle(old_x + 2, baseline - lascent,
lwidth - 4,
lascent + ldescent);
-
// Print the file name.
LyXFont msgFont(font);
msgFont.setFamily(LyXFont::SANS_FAMILY);
-
string const justname = OnlyFilename (params.filename);
if (!justname.empty()) {
msgFont.setSize(LyXFont::SIZE_FOOTNOTE);
@@ -291,7 +284,6 @@
   baseline - lyxfont::maxAscent(msgFont) - 4,
   justname, msgFont);
}
-
// Print the message.
string const msg = statusMessage();
if (!msg.empty()) {
@@ -500,57 +492,53 @@
 namespace {
 
 

Graphs with IEEEtran style and draft option?

[Ronald Holzloehner]

Hi everybody,

I know this is not a LyX but a LaTeX problem, but some of you might use
the IEEEtran template file and know the answer to this question: How do
I get LaTeX2e to display figures, using the IEEEtran style with the
draft option? You can get the IEEEtran style files at

http://www.ieee.org/organizations/pubs/transactions/ieeetran.tar.Z

The sample file comes out fine, but if you choose the draft option in
the preamble and include an EPS figure in the file, it comes out as a
frame with only the EPS file name in it--no figure. That happens both
with \includegraphics{} and \epsfig{}.

Optimally, I would like all the figures to appear on separate pages in
the end of the document. Any ideas of how to do this automatically?

Thanks,
Ron

P.S.: Please cc your answers to   [EMAIL PROTECTED]

Re: graphix inset

[Herbert Voss]

Lars Gullik Bjønnes wrote:

 Herbert Voss [EMAIL PROTECTED] writes:
 
 | the next patch to get the file type from it's contents.
 | Especially to Garst, please try.
 
 You forget that some eps files has the BoundingBox at the end.


never heard about this. Maybe that's not a real problem, but
eps-files of 2 megs are possible.

 (And some have a HiresBoundingBox)


yes, but makes no difference, we search for BoundingBox


Herbert




-- 
http://www.lyx.org/help/

Re: graphix inset

[Herbert Voss]

Lars Gullik Bjønnes wrote:

 If I remember correctly it is then something like:
 
 BoundingBox: At End


makes life easier

 The old code handled this.
 (Probably by just reading the whole file)

will have a look

Herbert

-- 
http://www.lyx.org/help/

Re: graphix inset

[Herbert Voss]

Garst R. Reese wrote:

 Didn't work, but I don't see why :(
 Attached is the header to one of my files.
 
 %!PS-Adobe-1.0


forgot to say, this this is a ps-file and LyX doesn't has
a converter for this. Look at preferences converters, if
a ps-xpm is missing install one. it's just the same than
the one from eps-xpm

HErbert



-- 
http://www.lyx.org/help/

Re: graphix inset

[Herbert Voss]

Lars Gullik Bjønnes wrote:

 Herbert Voss [EMAIL PROTECTED] writes:
 
 | Lars Gullik Bjønnes wrote:
 
If I remember correctly it is then something like:
BoundingBox: At End


 | makes life easier
 
 Or it is perhaps:
 
 Comments: At End


I read in my old postscript book and it said that the
bb had to appear in the header.

 we can't really know without having one of those ps/eps files.

let's wait until somebody has such file.

Herbert


-- 
http://www.lyx.org/help/

Re: graphix inset

[Herbert Voss]

Garst R. Reese wrote:

 %%Pages: (atend)
 blah blah
 %%Trailer
 %%Pages: 5
 I did not find anything with %%BoundingBox (atend) or the like.
 Note: atend is one word.


I suppose that this is only possible for standard

ps-output with no bounding box, which has some other
problems. but will also think about it until weekend.

Herbert



-- 
http://www.lyx.org/help/

Re: graphix inset

[Mike Ressler]

On Thu, 31 Jan 2002, Herbert Voss wrote:
 Garst R. Reese wrote:
  %%Pages: (atend)
  blah blah
  %%Trailer
  %%Pages: 5
  I did not find anything with %%BoundingBox (atend) or the like.
  Note: atend is one word.

From a figure I have:

%!PS-Adobe-3.0 EPSF-3.0
%%For: brucew
%%Title: PGPLOT PostScript plot
%%Creator: PGPLOT
%%CreationDate: 13-Jun-2000 14:59
%%BoundingBox: (atend)
%%DocumentFonts: (atend)
%%LanguageLevel: 1
%%Orientation: Portrait
%%Pages: (atend)
%%EndComments
%%BeginProlog
blah blah
PGPLOT restore showpage
%%PageTrailer
%%PageBoundingBox: 40 28 535 757

%%Trailer
%%BoundingBox: 40 28 535 757
%%DocumentFonts:
%%Pages: 1
%%EOF


Note the use of PageBoundingBox as well ...

Mike

-- 
Mike Ressler
[EMAIL PROTECTED]
OK, I'm lame: I don't have my own website ...

Scrollbar-slider initally not scrolling.

[R. Lahaye]

Hi,

I'm using present CVS on FreeBSD PC.

When I start LyX and open a (large enough) document, then I
cannot grab the scroll-slider to move downwards in the text.

This problem only occurs at the very beginning after opening.

Once I've clicked inside the void space of the scroll bar,
to move page-wise downwards, the scrollbar works again as usual.


Anybody else seeing this? It's not a big problem, but I thought
I'll report it anyway.

Cheers,
Rob.

Re: graphix inset

[Herbert Voss]

Mike Ressler wrote:

From a figure I have:
 
 %!PS-Adobe-3.0 EPSF-3.0
 %%For: brucew
 %%Title: PGPLOT PostScript plot
 %%Creator: PGPLOT
 %%CreationDate: 13-Jun-2000 14:59
 %%BoundingBox: (atend)
 %%DocumentFonts: (atend)


can you send me the whole file for testing?


Herbert



-- 
http://www.lyx.org/help/

Re: graphix inset

[Herbert Voss]

Garst R. Reese wrote:

 While you are hopefully sleeping well and not plagued by Garst
 nightmares, I tried some experiments with tonight's CVS + your test


:-)

it works now, send you a patch in my afternoon.


Herbert



-- 
http://www.lyx.org/help/

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[Martin Vermeer]

On Wed, Jan 30, 2002 at 11:11:59AM +0100, Andre Poenitz wrote:

 On Wed, Jan 30, 2002 at 08:08:22AM +0200, Martin Vermeer wrote:
  ...and feel free to explain what you mean... if this is clear to both of you,
  to me it is Chinese ;-)
 
 The 'InsetCode' stuff is (from a strict OO point of view at least - which I
 not always support) a bad thing.
 
 An object should identify itself by its behaviour, not by providing some
 magic value and pushing the responsibility to 'get it right' to 'user code'.
 
 The 'clean solution' would be to create some 
 
   virtual bool canBePutIntoALabel() const { return false; }
 
 into the inset base class and override this by putting 
 
   virtual bool canBePutIntoALabel() const { return true; }
 
 in the classes that 'have this property'. User code simply has to call
 
   inset-canBePutIntoALabel()
 
 to learn whether this inset can be put in a label or not.
 
 If religious reasons don't count much for you imagine what happens when
 we add a new inset that derives from and inset with canBePutIntoALabel() ==
 true.  With the InsetCode 'solution' you have to add the proper InsetCode
 to the if() in the user code, with the 'proper' solution you do not have to
 do anything. It just works.
 
 Now you might argue that adding another case to the if() is not much work.
 Fair enough... But how do you tell which user code is affected without
 checking _each_ file manually? And what happens to your if-clauses if we
 have 30 insets? 
 
 Andre'

Apropos of this discussion, I just had a look at lyxfunc.C, where there
is this huge switch at lines 563-661 that only seems to do this:
Find out what type of inset we have, assign the code value to 'code', 
and then at the end, test if anything has happened to 'code' so it is
no longer NO_CODE, and draw the consequences from that. No more.

Do I miss something? Or is there a reason why the local variable 'code'
is given any specific values? I don't see it used anywhere else.

If I am right this would be the place to start sanitizing :-)

- Martin



msg32232/pgp0.pgp
Description: PGP signature

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[Andre Poenitz]

On Thu, Jan 31, 2002 at 09:48:11AM +0200, Martin Vermeer wrote:
 Do I miss something?

The value of code is used in the call to insetAllowed.

Of course this is not nice code, but when Lars has finished playing around
with stuff that officially has to wait until 1.3 he will probably tell you
that it is not the right time to mess around with that switch.

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: More graphics disaster

[Andre Poenitz]

On Tue, Jan 29, 2002 at 11:09:06PM +0100, Herbert Voss wrote:
> config file, where you can declare the file suffixes.
> It's better to choose .cmp.eps, .sol.eps a.s.o. than it's
> easy for lyx to check what type.
> But it maybe a good idea to define other extensions in
> the preferences or to get the graphic type from it's
> contents, when unknown.

Maybe we should really just look at the contents. Usually the first few
bytes are enough. Of course, this is more expensive, but more robust, too...

Andre' 

-- 
André Pönitz .. [EMAIL PROTECTED]

Latest CVS: Problem with Win32 LyX

[Kayvan A. Sylvan]

This is a recent problem (within the last week or so).

On Win32/Cygwin under Win2K:

Trying to generate postscript from a document of class literate-article,
I was getting many LaTeX errors after updating from CVS.

I looked at the generated latex from Linux and from Win2k.

The difference is that on Win2K, I am missing the Textclass-specific
commands (see below for the diff). Any idea of why this could be happening?

--- /cygdrive/z/knightgame.tex  Wed Jan 30 00:33:16 2002
+++ knightgame.tex  Tue Jan 29 23:21:05 2002
@@ -1,9 +1,9 @@
 \batchmode% ===> this file was generated automatically by noweave --- better not edit 
it
 \makeatletter
-\def\input@path{{/net/home/kayvan//}}
+\def\input@path{{C:/cygwin/home/Kayvan/src/knightgame/}}
 \makeatother
 \documentclass[english]{article}
-\usepackage[T1]{fontenc}
+\usepackage[]{fontenc}
 \usepackage[latin1]{inputenc}
 \IfFileExists{url.sty}{\usepackage{url}}
   {\newcommand{\url}{\texttt}}
@@ -12,9 +12,6 @@
 
 %% LyX specific LaTeX commands.
 \providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
-
-%% Textclass specific LaTeX commands.
- \usepackage{noweb}
 
 %% User specified LaTeX commands.
 %

-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)



msg32165/pgp0.pgp
Description: PGP signature

Ò»¸öȫеÄÃâ·Ñ¹©Çó·¢²¼ÍøÕ¾µÈ×ÅÄãµÄ¹âÁÙ!

[ll]

Ç×°®µÄµÄÅóÓÑ£¬ÔÚ´ËÏòÄãÍƼöÕâ¸öÍøÕ¾£¬ËüÓµÓй㶫ÆóÒµ¡¢×¨¼ÒÈ˲š¢´úÀíÉ̼ҡ¢
±ÏÒµÉú×ÊÁÏËÄ´óÊý¾Ý¿âµÄÃâ·Ñ¼È룬±ÏÒµÉúÍøÉÏÇóÖ°¿ÉÃâ·Ñ¼Èë¸öÈË×ÊÁÏ£¬¿ÉÃâ·Ñ
ÍÆÏú±¾¹«Ë¾µÄ²úÆ·£¬Ñ°ÕÒºÏ×÷»ï°é¡£»¹¿ÉÒÔÃâ·ÑÌáÉý×ÔÉíµÄÖªÃû¶È£¬»ú²»¿Éʧ£¬Ê±
²»ÔÙÀ´£¬¿ì¿ì·ÃÎÊwww.fcfree.com!!


ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡
ÏÂÔØÍøÖ·£ºhttp://love2net.51.net/£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡­¡­


INFORMATION
This message has been sent using a trial-run version
of the TSmtpRelayServer Delphi Component.

Re: CVS Update: lyx-devel

[Edwin Leuven]

> Hummm, what do we want this for ?

viewing latex style files from the texinfo dialog?

> The Qt2 way is to use QWhatsThis.

but this is like a big tooltip right? not so suitable for viewing large files 
though...

you want it out?

Just getting rid of xforms cruft, Ed.

Re: More graphics disaster

[Herbert Voss]

On Wed, 30 Jan 2002, Lars Gullik [iso-8859-1] Bjønnes wrote:

> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Tue, Jan 29, 2002 at 11:09:06PM +0100, Herbert Voss wrote:
> >> config file, where you can declare the file suffixes.
> >> It's better to choose .cmp.eps, .sol.eps a.s.o. than it's
> >> easy for lyx to check what type.
> >> But it maybe a good idea to define other extensions in
> >> the preferences or to get the graphic type from it's
> >> contents, when unknown.
> >
> | Maybe we should really just look at the contents. Usually the first few
> | bytes are enough. Of course, this is more expensive, but more robust, too...
>
> Then we should use file(1) or a lib that accesses the same magic
> file(s).

maybe that we should have a look at this part and
try a bit more. I didn't changed this code and it all works well for me.

Herbert

Re: CVS Update: lyx-devel

[John Levon]

On Wed, Jan 30, 2002 at 10:14:17AM +0100, Edwin Leuven wrote:

> > Hummm, what do we want this for ?
> 
> viewing latex style files from the texinfo dialog?

ah OK I thought it only got used for the short help files. My mistake.

regards
john

-- 
"24-hour boredom
I'm convicted instantly"
- Manic Street Preachers

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[Andre Poenitz]

On Wed, Jan 30, 2002 at 08:08:22AM +0200, Martin Vermeer wrote:
> ...and feel free to explain what you mean... if this is clear to both of you,
> to me it is Chinese ;-)

The 'InsetCode' stuff is (from a strict OO point of view at least - which I
not always support) a bad thing.

An object should identify itself by its behaviour, not by providing some
magic value and pushing the responsibility to 'get it right' to 'user code'.

The 'clean solution' would be to create some 

  virtual bool canBePutIntoALabel() const { return false; }

into the inset base class and override this by putting 

  virtual bool canBePutIntoALabel() const { return true; }

in the classes that 'have this property'. User code simply has to call

  inset->canBePutIntoALabel()

to learn whether this inset can be put in a label or not.

If religious reasons don't count much for you imagine what happens when
we add a new inset that derives from and inset with canBePutIntoALabel() ==
true.  With the InsetCode 'solution' you have to add the proper InsetCode
to the if() in the user code, with the 'proper' solution you do not have to
do anything. It just works.

Now you might argue that adding another case to the if() is not much work.
Fair enough... But how do you tell which user code is affected without
checking _each_ file manually? And what happens to your if-clauses if we
have 30 insets? 

Andre'


-- 
André Pönitz .. [EMAIL PROTECTED]

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[John Levon]

On Wed, Jan 30, 2002 at 11:11:59AM +0100, Andre Poenitz wrote:

>   virtual bool canBePutIntoALabel() const { return false; }

> true.  With the InsetCode 'solution' you have to add the proper InsetCode

of course, both solutions suck, and we really want proper RTTI or an inset_traits
or something ... but the current locking / containing inset  scheme prevents that ...

john

-- 
"This is mindless pedantism up with which I will not put."
- Donald Knuth on Pascal's lack of default: case statement

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[Andre Poenitz]

On Wed, Jan 30, 2002 at 10:19:39AM +, John Levon wrote:
> of course, both solutions suck, and we really want proper RTTI

This would still make the user code decide which inset is 'ok' and which
not... 

> or an inset_traits or something

This is 'usability-wise' not very different from the virtual function
method, is it?

I think there generally there is no perfect method, so given a selection of
more or less equivalent items I'd pick the one which suits best to the rest
of the project. And we have virtual functions already, but no RTTI and no
traits of our own that I am aware of...

> ... but the current locking/ containing inset scheme prevents that ...

The current locking scheme has made it to the top of my personal list of
'10 reasons why LyX source suck'. --- Yes. That's the position in front of
the paragraph list stuff...

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: FIX-ish... sort-of (Re: BUG: float inside description para)

[Martin Vermeer]

On Wed, Jan 30, 2002 at 11:11:59AM +0100, Andre Poenitz wrote:
> 
> On Wed, Jan 30, 2002 at 08:08:22AM +0200, Martin Vermeer wrote:
> > ...and feel free to explain what you mean... if this is clear to both of you,
> > to me it is Chinese ;-)
> 
> The 'InsetCode' stuff is (from a strict OO point of view at least - which I
> not always support) a bad thing.
> 
> An object should identify itself by its behaviour, not by providing some
> magic value and pushing the responsibility to 'get it right' to 'user code'.
> 
> The 'clean solution' would be to create some 
> 
>   virtual bool canBePutIntoALabel() const { return false; }
> 
> into the inset base class and override this by putting 
> 
>   virtual bool canBePutIntoALabel() const { return true; }
> 
> in the classes that 'have this property'. User code simply has to call
> 
>   inset->canBePutIntoALabel()
> 
> to learn whether this inset can be put in a label or not.
> 
> If religious reasons don't count much for you imagine what happens when
> we add a new inset that derives from and inset with canBePutIntoALabel() ==
> true.  With the InsetCode 'solution' you have to add the proper InsetCode
> to the if() in the user code, with the 'proper' solution you do not have to
> do anything. It just works.
> 
> Now you might argue that adding another case to the if() is not much work.
> Fair enough... But how do you tell which user code is affected without
> checking _each_ file manually? And what happens to your if-clauses if we
> have 30 insets? 
> 
> Andre'

Ah, I see. Great explanation.

I don't think this is undoable. The same functionality would require
touching only five inset*.[hC] file pairs IIUC.

Should I do it?

-- Martin



msg32173/pgp0.pgp
Description: PGP signature

Re: Slackware package

[Jean-Marc Lasgouttes]

> "Matej" == Matej Cepl <[EMAIL PROTECTED]> writes:

Matej> Have you already done so? I would love to remove the package
Matej> from the website (I need to put there something else and I am
Matej> so close to the quota).

Done.

JMarc

Re: Bugs

[Jean-Marc Lasgouttes]

> "John" == John Levon <[EMAIL PROTECTED]> writes:

John> On Sun, Jan 27, 2002 at 10:05:22AM +0100, Michael Schmitt wrote:
>> - New document; enter some letter; undo; undo again -> misleading
>> minibuffer message

John> hmm the problem is simple, and in lots of lyxfuncs.

John> Perhaps we should add a disable(bool, string const &
John> disabledmsg); ??

And then the status message would have to be moved inside FuncStatus.
This would probably be better in the long term.

John> JMarc how about this :

Looks like a reasonable workaround. Why do you use N_()?

JMarc

Re: Bugs

[John Levon]

On Wed, Jan 30, 2002 at 12:08:57PM +0100, Jean-Marc Lasgouttes wrote:

> John> Perhaps we should add a disable(bool, string const &
> John> disabledmsg); ??
> 
> And then the status message would have to be moved inside FuncStatus.
> This would probably be better in the long term.

mm yeah

> John> JMarc how about this :
> 
> Looks like a reasonable workaround. Why do you use N_()?

just because the other bits do there. I didn't and don't understand the
N_() thing, I was too lazy to read the last round of explanations of it
vs. _()

regards
john

-- 
"This is mindless pedantism up with which I will not put."
- Donald Knuth on Pascal's lack of default: case statement

Re: Latest CVS: Problem with Win32 LyX

[Jean-Marc Lasgouttes]

> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:

Kayvan> This is a recent problem (within the last week or so). On
Kayvan> Win32/Cygwin under Win2K:

Kayvan> Trying to generate postscript from a document of class
Kayvan> literate-article, I was getting many LaTeX errors after
Kayvan> updating from CVS.

Kayvan> I looked at the generated latex from Linux and from Win2k.

Kayvan> The difference is that on Win2K, I am missing the
Kayvan> Textclass-specific commands (see below for the diff). Any idea
Kayvan> of why this could be happening?

Interesting. This really looks like the problem Angus has been seeing
with compaq cxx. Might it be that we are not using ostringstream correctly?

JMarc

Re: Latest CVS: Problem with Win32 LyX

[Angus Leeming]

On Wednesday 30 January 2002 11:15 am, Jean-Marc Lasgouttes wrote:
> > "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:
> 
> Kayvan> This is a recent problem (within the last week or so). On
> Kayvan> Win32/Cygwin under Win2K:
> 
> Kayvan> Trying to generate postscript from a document of class
> Kayvan> literate-article, I was getting many LaTeX errors after
> Kayvan> updating from CVS.
> 
> Kayvan> I looked at the generated latex from Linux and from Win2k.
> 
> Kayvan> The difference is that on Win2K, I am missing the
> Kayvan> Textclass-specific commands (see below for the diff). Any idea
> Kayvan> of why this could be happening?
> 
> Interesting. This really looks like the problem Angus has been seeing
> with compaq cxx. Might it be that we are not using ostringstream correctly?

Well if that is the case, then this band aid works on my machine. What's your 
milage Kayvan?

Note that I'm not suggesting this goes in the LyX source. Just that me might 
get some feel for the problem.

Angus


Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.53
diff -u -p -r1.53 LaTeXFeatures.C
--- src/LaTeXFeatures.C	2002/01/10 10:05:43	1.53
+++ src/LaTeXFeatures.C	2002/01/18 17:57:13
@@ -339,14 +339,18 @@ string const LaTeXFeatures::getTClassPre
 	// the text class specific preamble 
 	LyXTextClass const & tclass = textclasslist.TextClass(params.textclass);
 	ostringstream tcpreamble;
-	
+
 	tcpreamble << tclass.preamble();
 
 	for (layout_type i = 0; i < tclass.numLayouts(); ++i) {
 		if (layout[i]) {
-			tcpreamble  << tclass[i].preamble();
+			tcpreamble << tclass[i].preamble();
 		}
 	}
+
+	// DEC's implementation of ostringstream has a bug which can be
+	// overcome with this forcing.
+	tcpreamble.seekp(std::ios::beg);
 
 	return tcpreamble.str().c_str();
 }	

Re: Latest CVS: Problem with Win32 LyX

[Andre Poenitz]

On Wed, Jan 30, 2002 at 12:15:28PM +0100, Jean-Marc Lasgouttes wrote:
> Interesting. This really looks like the problem Angus has been seeing
> with compaq cxx. Might it be that we are not using ostringstream correctly?

Could you direct me again to the code in question?

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: Latest CVS: Problem with Win32 LyX

[Jean-Marc Lasgouttes]

> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:

Andre> On Wed, Jan 30, 2002 at 12:15:28PM +0100, Jean-Marc Lasgouttes
Andre> wrote:
>> Interesting. This really looks like the problem Angus has been
>> seeing with compaq cxx. Might it be that we are not using
>> ostringstream correctly?

Andre> Could you direct me again to the code in question?

LaTeXFeatures::getTClassPreamble at LaTeXFeatures.C:337.

JMarc

Re: Latest CVS: Problem with Win32 LyX

[Angus Leeming]

On Wednesday 30 January 2002 12:13 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> | +
> | +   // DEC's implementation of ostringstream has a bug which can be
> | +   // overcome with this forcing.
> | +   tcpreamble.seekp(std::ios::beg);
> |  
> | return tcpreamble.str().c_str();
> 
> Oooo dirty...
> 
> How can we avoid this?
> 
> because if we use it we need it all over... and that is not
> acceptable.

I'm not saying that this is the answer, just that this appears to resolve the 
problem here. 

I assumed that the true problem lies in my version of std::ostringstream, but 
if Kayvan experiences the same problem and it is cured in the same way, then 
perhaps the problem lies elsewhere.

Anyway, it'll be intersting to get Kayvan's results with this.

A

Re: Patch for Lyx on Win32/Cygnus

[Jean-Marc Lasgouttes]

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

Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>
Lars> | Lars> Use of ios::binary should be ok. (but I guess it really
Lars> should | Lars> be ios_base::binary)
>>
Lars> | What's the difference?

Lars> ios_base:: what the standard says...

Lars> ios:: some sub class that inherits from ios_base

So how come LyX oly uses ios and never ios_base? I'll stick to ios for
simplicity.

JMarc

Re: Latest CVS: Problem with Win32 LyX

[Andre Poenitz]

On Wed, Jan 30, 2002 at 12:19:53PM +, Angus Leeming wrote:
> I assumed that the true problem lies in my version of std::ostringstream, but 
> if Kayvan experiences the same problem and it is cured in the same way, then 
> perhaps the problem lies elsewhere.

What does your library's std::ostringstream::str() return?

'string' or 'string const &'?

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: Patch for Lyx on Win32/Cygnus

[Andre Poenitz]

On Wed, Jan 30, 2002 at 01:25:59PM +0100, Jean-Marc Lasgouttes wrote:
> So how come LyX oly uses ios and never ios_base? I'll stick to ios for
> simplicity.

g++ 2.95.2's standard library has no ios_base.

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: Latest CVS: Problem with Win32 LyX

[Angus Leeming]

On Wednesday 30 January 2002 12:35 pm, Andre Poenitz wrote:
> On Wed, Jan 30, 2002 at 12:19:53PM +, Angus Leeming wrote:
> > I assumed that the true problem lies in my version of std::ostringstream, 
but 
> > if Kayvan experiences the same problem and it is cured in the same way, 
then 
> > perhaps the problem lies elsewhere.
> 
> What does your library's std::ostringstream::str() return?
> 
> 'string' or 'string const &'?
> 
> Andre'

string.
Here's the class definition.
Angus

template
class basic_ostringstream : public basic_ostream {
 public:

typedef basic_stringbufsb_type;
typedef basic_ios ios_type;
typedef basic_string   string_type;

typedef traits   traits_type;
typedef charTchar_type;
typedef _TYPENAME traits::int_typeint_type;
typedef _TYPENAME traits::pos_typepos_type;
typedef _TYPENAME traits::off_typeoff_type;

_EXPLICIT basic_ostringstream(ios_base::openmode which = ios_base::out);
_EXPLICIT basic_ostringstream(const string_type& str,
 ios_base::openmode which = ios_base::out);

virtual ~basic_ostringstream();

basic_stringbuf *rdbuf() const;
string_type str() const;

void str(const string_type& str);

  protected:

  private:

sb_typesb_;

};

Re: Latest CVS: Problem with Win32 LyX

[Andre Poenitz]

On Wed, Jan 30, 2002 at 01:00:42PM +, Angus Leeming wrote:
> string.

That should be correct then.
*shrug*

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: [Bug 225] Entering \dot\vec\beta doesn't work properly

[Jean-Marc Lasgouttes]

> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:

>> (bug 224 is the different 1.1.6 bug btw)
Andre> I am fairly sure that there won't be any math fixes for 1.1.6,
Andre> so it's basically a waste of time to put them into the
Andre> bugtracker...

This was submitted by one of our user. I hope you are not telling me
we should tell them not to waste their time reportig bugs to
bugzilla

JMArc

Re: Purify report #2

[Jürgen Vigna]

> Next  old bug:
>
> Copy and paste text from any paragraph style into ERT works well now.
> But not vice versa: the textcolor is not changed, it's always red
> (latex) and LyX produces a memory access error when viewing dvi.

I sent a patch for this it should only be applied and will then fix
this bug definitively and make ERT inset nearer a Edit-Inset.

   Jug

-- 
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Tuesday 29 January 2002 8:04 pm, Juergen Spitzmueller wrote:
> Angus Leeming wrote:
> > One someone like to volunteer to do this to the xforms dialog.
> 
> Here it is. I tried to do it similar to the qt-dialog (within the 
> natural limitations of xforms).

Thank you. It's in my tree.

> I have added two things:
> 
> 1. A text_warning field and input filters like in the other dialogs 
> (only xforms related)

Good.

> 2. An option "Default" for Screen Display, which takes the settings of 
> Preferences (lyxrc.display_graphics). Edwin, perhaps you will want to 
> add this to qt2, too?

I haven't persued this further, but think that this isn't needed. 

It can/should be set when the insetgraphicsParams instance passed to the 
dilaog is created. Either we copy an existing params instance, in which case 
we use it's value for this, or we create a new one, in which case we use 
lyxrc.display_graphics.

It's the inset that should be clever, not the frontend.

> One small issue: IMHO the Screen Display choice should be set to 
> "default" when the user inserts a new graphic. But it is always set to 
> "Monochrome", no matter what I do. Hell knows why. Maybe someone else 
> could have a look. 

I will, although it doesn't seem to happen here.
Angus

Re: (Jug) [Devel] Revised bug list - tables

[Jürgen Vigna]

> In XML, you can define default values for attributes in the DTD.
> So with XML, it will be even easier to handle this.
>
> I think we should accept a patch to reduce the bloat.

I didn´t see the patch but I would like to do this myself. But if any
of the others think the patch is clean and can guarantee for it then
apply it.

   Jug

-- 
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Wednesday 30 January 2002 2:26 pm, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> >> 2. An option "Default" for Screen Display, which takes the settings
> >> of Preferences (lyxrc.display_graphics). Edwin, perhaps you will
> >> want to add this to qt2, too?
> 
> Angus> I haven't persued this further, but think that this isn't
> Angus> needed.
> 
> Angus> It can/should be set when the insetgraphicsParams instance
> Angus> passed to the dilaog is created. Either we copy an existing
> Angus> params instance, in which case we use it's value for this, or
> Angus> we create a new one, in which case we use
> Angus> lyxrc.display_graphics.
> 
> But I I like monochrome rendering and you like color rendering, when I
> send a file to you it should be possible for us to have different
> prefs and see different things on screen, no?
> 
> JMarc

A. Understood. I'll stop messing around!

A

Re: patches to the frontends

[Martin Vermeer]

On Tue, Jan 29, 2002 at 12:52:23PM +, Angus Leeming wrote:
 
> I think that cvs now contains all the frontends patches that have been posted 
> to this list over the last few days. If I've missed anything, then sorry but 
> could you please shout loudly and tell me the address in the mail archives!
> 
> Angus
> 

Angus,

does the maths styles and fonts sub-panel really work correctly for you?
It appears the image file style.xbm in CVS is corrupted in a way that makes
it unuseable. Doesn't even load by xloadimage until the attached patch.

Weird.

-- Martin



Index: style.xbm
===
RCS file: /cvs/lyx/lyx-devel/images/style.xbm,v
retrieving revision 1.2
diff -u -b -B -p -r1.2 style.xbm
--- style.xbm   2002/01/29 12:43:58 1.2
+++ style.xbm   2002/01/30 14:35:04
@@ -1,5 +1,5 @@
 #define style1_width 135
-#define style1_height 270
+#define style1_height 110
 static unsigned char const style1_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,



msg32199/pgp0.pgp
Description: PGP signature

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Wednesday 30 January 2002 2:40 pm, Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
> > Angus> I haven't persued this further, but think that this isn't
> > Angus> needed.
> >
> > Angus> It can/should be set when the insetgraphicsParams instance
> > Angus> passed to the dilaog is created. Either we copy an existing
> > Angus> params instance, in which case we use it's value for this, or
> > Angus> we create a new one, in which case we use
> > Angus> lyxrc.display_graphics.
> >
> > But I I like monochrome rendering and you like color rendering, when
> > I send a file to you it should be possible for us to have different
> > prefs and see different things on screen, no?
> 
> Yes. Unfortunately, my implementation is not that clever (yet). It just 
> choses the setting from lyxrc.display_graphics, e.g. if you have 
> monochrome there, your graphic will be set to monochrome (and stored as 
> monochrome).
> That's quite stupid, but maybe it can be enhanced (but this looks a 
> little bit more complicated to me).
> 
> Anyway, it's just a proposal.

Well that sounds easy enough. Add a DEFAULT entry to 
InsetGraphicsParams::DisplayType and use it apropriately. (ie, use the 
lyxrc.display_graphics variable in InsetGraphics when 
InsetGraphicsParams::display == DEFAULT

No clever stuff in the frontends. All clever stuff in the inset.

Angus

Re: qt2: just in case [PATCH]

[Herbert Voss]

Jean-Marc Lasgouttes wrote:

>>"Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>>
> 
>>>2. An option "Default" for Screen Display, which takes the settings
>>>of Preferences (lyxrc.display_graphics). Edwin, perhaps you will
>>>want to add this to qt2, too?
>>>
> 
> Angus> I haven't persued this further, but think that this isn't
> Angus> needed.
> 
> Angus> It can/should be set when the insetgraphicsParams instance
> Angus> passed to the dilaog is created. Either we copy an existing
> Angus> params instance, in which case we use it's value for this, or
> Angus> we create a new one, in which case we use
> Angus> lyxrc.display_graphics.
> 
> But I I like monochrome rendering and you like color rendering, when I
> send a file to you it should be possible for us to have different
> prefs and see different things on screen, no?


I can't see the problem? it's a oneliner to get the pref-default
when creating a new graphic-inset.
on the other hand it's obvious that a single definition depends
to the local image and you'll see this in color if color was
chosen for this single image.

Herbert


-- 
http://www.lyx.org/help/

Re: qt2: just in case [PATCH]

[Juergen Spitzmueller]

Angus Leeming wrote:
> Well that sounds easy enough. Add a DEFAULT entry to
> InsetGraphicsParams::DisplayType and use it apropriately. (ie, use
> the lyxrc.display_graphics variable in InsetGraphics when
> InsetGraphicsParams::display == DEFAULT

OK, thanks for the hint. I'll try to implement it after the first patch 
has gone through CVS.

> No clever stuff in the frontends. All clever stuff in the inset.

the problem is that I don't know much about the insets, so I try to put 
all my cleverness into frontends ;-)

Juergen.

Re: patches to the frontends

[Angus Leeming]

On Wednesday 30 January 2002 2:43 pm, Martin Vermeer wrote:
> does the maths styles and fonts sub-panel really work correctly for you?
> It appears the image file style.xbm in CVS is corrupted in a way that makes
> it unuseable. Doesn't even load by xloadimage until the attached patch.
> 
> Weird.

Indeed. Committed the fix. Now it appears corrrectly in LyX but not in xv.
A

Re: patches to the frontends

[Martin Vermeer]

On Wed, Jan 30, 2002 at 02:51:41PM +, Angus Leeming wrote:

> On Wednesday 30 January 2002 2:43 pm, Martin Vermeer wrote:
> > does the maths styles and fonts sub-panel really work correctly for you?
> > It appears the image file style.xbm in CVS is corrupted in a way that makes
> > it unuseable. Doesn't even load by xloadimage until the attached patch.
> > 
> > Weird.
> 
> Indeed. Committed the fix. Now it appears corrrectly in LyX but not in xv.
> A
> 

Meaning no doubt that xv reponds poorly to multi-image xbm files and reads
only the first height definition to infer the total height. Not good.
Perhaps worth a bug report ;-)

-- Martin




msg32204/pgp0.pgp
Description: PGP signature

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Wednesday 30 January 2002 2:53 pm, Juergen Spitzmueller wrote:
> Angus Leeming wrote:
> > Well that sounds easy enough. Add a DEFAULT entry to
> > InsetGraphicsParams::DisplayType and use it apropriately. (ie, use
> > the lyxrc.display_graphics variable in InsetGraphics when
> > InsetGraphicsParams::display == DEFAULT
> 
> OK, thanks for the hint. I'll try to implement it after the first patch 
> has gone through CVS.

Well what are you waiting for! I've just committed it.

> > No clever stuff in the frontends. All clever stuff in the inset.
> 
> the problem is that I don't know much about the insets, so I try to put 
> all my cleverness into frontends ;-)

Well it isn't too complicated but currently it's all a bit of a mess. IMO 
GraphicscCacheItem shouldn't know about lyxrc.display_graphics (it does 
currently).

Having looked at the code, you should pass an extra variable to the 
GraphicsCacheItem c-tor from InsetGraphics.

GraphicsCacheItem::GraphicsCacheItem(string const & filename, DisplayType);

you should also have a GraphicsCacheItem::setDisplayType(DisplayType) method, 
so that you can change this if you so desire.

If this sounds too complicated after all, then don't worry, I'll have a look 
this evening.

A

Re: qt2: just in case [PATCH]

[Herbert Voss]

Angus Leeming wrote:

> On Wednesday 30 January 2002 2:53 pm, Juergen Spitzmueller wrote:
> 
>>Angus Leeming wrote:
>>
>>>Well that sounds easy enough. Add a DEFAULT entry to
>>>InsetGraphicsParams::DisplayType and use it apropriately. (ie, use
>>>the lyxrc.display_graphics variable in InsetGraphics when
>>>InsetGraphicsParams::display == DEFAULT
>>>
>>OK, thanks for the hint. I'll try to implement it after the first patch 
>>has gone through CVS.
>>
> 
> Well what are you waiting for! I've just committed it.
> 


it's a bit confusing when you commit patches before the first

one runs well! there are still some problems to get the whole
graphic inset running. And the real problems are not located in
the gui but in the inset. It makes life not easier to me, when
those patches were committed before the whole stuff works
so well, that we can change the environments ...

HErbert



-- 
http://www.lyx.org/help/

Re: qt2: just in case [PATCH]

[Angus Leeming]

On Wednesday 30 January 2002 3:21 pm, Herbert Voss wrote:
> Angus Leeming wrote:
> it's a bit confusing when you commit patches before the first
> 
> one runs well! there are still some problems to get the whole
> graphic inset running. And the real problems are not located in
> the gui but in the inset. It makes life not easier to me, when
> those patches were committed before the whole stuff works
> so well, that we can change the environments ...

Sorry, but that's the whole point of incremental patches isn't it? You 
committed an enormous patch with bugs. Jürgen has cleaned up the dialog a 
little that's all. If the real problems lie in the inset, then nothing has 
changed there at all.

So apologies if I have made life difficult for you, but I don't think I have.

A

[PATCH] Citation Dialog

[Juergen Spitzmueller]

This dialog is still a real pain on a 800x600 Screen (it covers the 
whole screen, which strikes me sick).
However, with a little rearrangement I managed to get it remarkably 
smaller.

If you want to see the differences on my screen, have a look at the 
following screenshots:
http://omnibus.uni-freiburg.de/~spitzmue/cit_before.png
http://omnibus.uni-freiburg.de/~spitzmue/cit_after.png

The patch additionally features some small tweaks to form_graphics.fd 
(sorry, I must have been tired yesterday).
All in all safe to apply.

Thanks,
Jürgen.


citation.diff.gz
Description: GNU Zip compressed data

Re: Latest CVS: Problem with Win32 LyX

[Kayvan A. Sylvan]

On Wed, Jan 30, 2002 at 11:23:12AM +, Angus Leeming wrote:
> On Wednesday 30 January 2002 11:15 am, Jean-Marc Lasgouttes wrote:
> > > "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:
> > 
> > Kayvan> This is a recent problem (within the last week or so). On
> > Kayvan> Win32/Cygwin under Win2K:
> > 
> > Kayvan> Trying to generate postscript from a document of class
> > Kayvan> literate-article, I was getting many LaTeX errors after
> > Kayvan> updating from CVS.
> > 
> > Kayvan> I looked at the generated latex from Linux and from Win2k.
> > 
> > Kayvan> The difference is that on Win2K, I am missing the
> > Kayvan> Textclass-specific commands (see below for the diff). Any idea
> > Kayvan> of why this could be happening?
> > 
> > Interesting. This really looks like the problem Angus has been seeing
> > with compaq cxx. Might it be that we are not using ostringstream correctly?
> 
> Well if that is the case, then this band aid works on my machine. What's your 
> milage Kayvan?
> 
> Note that I'm not suggesting this goes in the LyX source. Just that me might 
> get some feel for the problem.
> 
> Angus

Thanks!

Yes, this seems to be related.

It looks like Angus's DEC "fix" is *in* the current CVS. The above makes
it appear as if this was not intentional.

I had to do this (basically undoing the fix) to get it to run correctly
on Cygwin:

--- lyx/src/LaTeXFeatures.C Tue Jan 29 11:21:43 2002
+++ lyx-1.2.0cvs/src/LaTeXFeatures.CWed Jan 30 08:32:44 2002
@@ -350,7 +350,7 @@
 
// DEC's implementation of ostringstream has a bug which can be
// overcome with this forcing.
-   tcpreamble.seekp(std::ios::beg);
+   // tcpreamble.seekp(std::ios::beg);
 
return tcpreamble.str().c_str();
 }  

-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)



msg32209/pgp0.pgp
Description: PGP signature

Re: Latest CVS: Problem with Win32 LyX

[Kayvan A. Sylvan]

On Wed, Jan 30, 2002 at 01:13:29PM +0100, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> | +
> | +   // DEC's implementation of ostringstream has a bug which can be
> | +   // overcome with this forcing.
> | +   tcpreamble.seekp(std::ios::beg);
> |  
> | return tcpreamble.str().c_str();
> 
> Oooo dirty...
> 
> How can we avoid this?
> 
> because if we use it we need it all over... and that is not
> acceptable.

It also does not appear to work. At least for Cygwin.

---Kayvan
-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)



msg32210/pgp0.pgp
Description: PGP signature