Small fixes for docbook.

[Jose Abilio Oliveira Matos]

Hi,
following the usual procedure now, I send to list the patch that is docbook 
related.
I know that I have several issues merged under the same roof, but most of it 
are one liners.

-- 
José Abílio


Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.700
diff -u -p -r1.700 ChangeLog
--- src/ChangeLog	2 May 2002 12:45:27 -	1.700
+++ src/ChangeLog	2 May 2002 15:02:35 -
@@ -1,3 +1,10 @@
+2002-05-02  José Matos  [EMAIL PROTECTED]
+	* buffer.C (makeDocBookFile): white space changes, add newline to
+	command styles.
+	(simpleDocBookOnePar): protect emphasis inside a CDATA section.
+
+	* tabular.C (docBook): fix typo.
+
 2002-05-02  Juergen Vigna  [EMAIL PROTECTED]
 
 	* text2.C (fixCursorAfterDelete): check to make sure we don't request
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.332
diff -u -p -r1.332 buffer.C
--- src/buffer.C	2 May 2002 12:21:41 -	1.332
+++ src/buffer.C	2 May 2002 15:02:35 -
@@ -3236,12 +3236,18 @@ void Buffer::makeDocBookFile(string cons
 
 			if (command_flag) {
 if (cmd_depth  command_base) {
-	for (Paragraph::depth_type j = command_depth; j = command_base; --j)
+	for (Paragraph::depth_type j = command_depth;
+	 j = command_base; --j) {
 		sgmlCloseTag(ofs, j, command_stack[j]);
+		ofs  endl;
+	}
 	command_depth = command_base = cmd_depth;
 } else if (cmd_depth = command_depth) {
-	for (int j = command_depth; j = int(cmd_depth); --j)
+	for (int j = command_depth;
+	 j = int(cmd_depth); --j) {
 		sgmlCloseTag(ofs, j, command_stack[j]);
+		ofs  endl;
+	}
 	command_depth = cmd_depth;
 } else
 	command_depth = cmd_depth;
@@ -3396,8 +3402,10 @@ void Buffer::makeDocBookFile(string cons
 	}
 
 	for (int j = command_depth; j = 0 ; --j)
-		if (!command_stack[j].empty())
+		if (!command_stack[j].empty()) {
 			sgmlCloseTag(ofs, j, command_stack[j]);
+			ofs  endl;
+		}
 
 	ofs  \n\n;
 	sgmlCloseTag(ofs, 0, top_element);
@@ -3432,10 +3440,18 @@ void Buffer::simpleDocBookOnePar(ostream
 		// handle emphasis tag
 		if (font_old.emph() != font.emph()) {
 			if (font.emph() == LyXFont::ON) {
+if(style.latexparam() == CDATA)
+	os  ]];
 os  emphasis;
+if(style.latexparam() == CDATA)
+	os  ![CDATA[;
 emph_flag = true;
 			} else if (i) {
+if(style.latexparam() == CDATA)
+	os  ]];
 os  /emphasis;
+if(style.latexparam() == CDATA)
+	os  ![CDATA[;
 emph_flag = false;
 			}
 		}
@@ -3472,7 +3488,11 @@ void Buffer::simpleDocBookOnePar(ostream
 	}
 
 	if (emph_flag) {
+		if(style.latexparam() == CDATA)
+			os  ]];
 		os  /emphasis;
+		if(style.latexparam() == CDATA)
+			os  ![CDATA[;
 	}
 
 	// resets description flag correctly
Index: src/tabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/tabular.C,v
retrieving revision 1.129
diff -u -p -r1.129 tabular.C
--- src/tabular.C	18 Apr 2002 12:14:26 -	1.129
+++ src/tabular.C	2 May 2002 15:02:36 -
@@ -2411,7 +2411,7 @@ int LyXTabular::docBook(Buffer const * b
 ret += docbookRow(buf, os, i);
 			}
 		}
-		os  thead\n;
+		os  /thead\n;
 		++ret;
 	}
 	// output footer info
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.409
diff -u -p -r1.409 ChangeLog
--- src/insets/ChangeLog	1 May 2002 10:23:51 -	1.409
+++ src/insets/ChangeLog	2 May 2002 15:02:37 -
@@ -1,3 +1,7 @@
+2002-05-02  José Matos  [EMAIL PROTECTED]
+
+	* insetgraphics.C (validate): acess params as everyone else.
+
 2002-05-01  Angus Leeming  [EMAIL PROTECTED]
 
 	* InsetgraphicsParams.[Ch]: whitespace.
Index: src/insets/insetgraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.107
diff -u -p -r1.107 insetgraphics.C
--- src/insets/insetgraphics.C	29 Apr 2002 09:24:19 -	1.107
+++ src/insets/insetgraphics.C	2 May 2002 15:02:37 -
@@ -805,7 +805,7 @@ void InsetGraphics::validate(LaTeXFeatur
 	if (params().filename.empty())
 		return ;
 
-	features.includeFile(graphic_label, RemoveExtension(params_.filename));
+	features.includeFile(graphic_label, RemoveExtension(params().filename));
 
 	features.require(graphicx);
 

Small fixes for docbook.

[Jose Abilio Oliveira Matos]

Hi,
following the usual procedure now, I send to list the patch that is docbook 
related.
I know that I have several issues merged under the same roof, but most of it 
are one liners.

-- 
José Abílio


Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.700
diff -u -p -r1.700 ChangeLog
--- src/ChangeLog	2 May 2002 12:45:27 -	1.700
+++ src/ChangeLog	2 May 2002 15:02:35 -
@@ -1,3 +1,10 @@
+2002-05-02  José Matos  <[EMAIL PROTECTED]>
+	* buffer.C (makeDocBookFile): white space changes, add newline to
+	command styles.
+	(simpleDocBookOnePar): protect  inside a CDATA section.
+
+	* tabular.C (docBook): fix typo.
+
 2002-05-02  Juergen Vigna  <[EMAIL PROTECTED]>
 
 	* text2.C (fixCursorAfterDelete): check to make sure we don't request
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.332
diff -u -p -r1.332 buffer.C
--- src/buffer.C	2 May 2002 12:21:41 -	1.332
+++ src/buffer.C	2 May 2002 15:02:35 -
@@ -3236,12 +3236,18 @@ void Buffer::makeDocBookFile(string cons
 
 			if (command_flag) {
 if (cmd_depth < command_base) {
-	for (Paragraph::depth_type j = command_depth; j >= command_base; --j)
+	for (Paragraph::depth_type j = command_depth;
+	 j >= command_base; --j) {
 		sgmlCloseTag(ofs, j, command_stack[j]);
+		ofs << endl;
+	}
 	command_depth = command_base = cmd_depth;
 } else if (cmd_depth <= command_depth) {
-	for (int j = command_depth; j >= int(cmd_depth); --j)
+	for (int j = command_depth;
+	 j >= int(cmd_depth); --j) {
 		sgmlCloseTag(ofs, j, command_stack[j]);
+		ofs << endl;
+	}
 	command_depth = cmd_depth;
 } else
 	command_depth = cmd_depth;
@@ -3396,8 +3402,10 @@ void Buffer::makeDocBookFile(string cons
 	}
 
 	for (int j = command_depth; j >= 0 ; --j)
-		if (!command_stack[j].empty())
+		if (!command_stack[j].empty()) {
 			sgmlCloseTag(ofs, j, command_stack[j]);
+			ofs << endl;
+		}
 
 	ofs << "\n\n";
 	sgmlCloseTag(ofs, 0, top_element);
@@ -3432,10 +3440,18 @@ void Buffer::simpleDocBookOnePar(ostream
 		// handle  tag
 		if (font_old.emph() != font.emph()) {
 			if (font.emph() == LyXFont::ON) {
+if(style.latexparam() == "CDATA")
+	os << "]]>";
 os << "";
+if(style.latexparam() == "CDATA")
+	os << "";
 os << "";
+if(style.latexparam() == "CDATA")
+	os << "";
 		os << "";
+		if(style.latexparam() == "CDATA")
+			os << 

Re: PATCH: fix for #348

[Jose Abilio Oliveira Matos]

On Monday 29 April 2002 15:50, Juergen Vigna wrote:
 Another one for people to have a look at!

  Jug

 P.S.: Q: Why are you sending all this simple patches to the list?
   A: I don't want to risk my karma commiting them :P

  You are so afraid that you even forgot to send the patch. ;-)

-- 
José Abílio

Re: PATCH: fix for #348

[Jose Abilio Oliveira Matos]

On Monday 29 April 2002 15:50, Juergen Vigna wrote:
> Another one for people to have a look at!
>
>  Jug
>
> P.S.: Q: Why are you sending all this simple patches to the list?
>   A: I don't want to risk my "karma" commiting them :P

  You are so afraid that you even forgot to send the patch. ;-)

-- 
José Abílio

Re: DocBook XML

[Jose Abilio Oliveira Matos]

On Sunday 14 April 2002 15:58, John Levon wrote:
 Are there major difficulties in providing support for DocBook XML in
 lyx, or is it a simple matter of providing the export methods for
 everything ?

  Something like that. That is why I have proposed 1.3 for it.

 The LDP lists are discussing GUI editors again. I'm mainly interested as
 I'm about to become an LDP author, and I got really sick of pissing
 around with the XML syntax...

 I noticed that even in current SGML there's no support for things like
 programlisting ???

  Code??

 regards
 john

  :-)
-- 
José Abílio

Re: DocBook XML

[Jose Abilio Oliveira Matos]

On Sunday 14 April 2002 15:58, John Levon wrote:
> Are there major difficulties in providing support for DocBook XML in
> lyx, or is it a "simple" matter of providing the export methods for
> everything ?

  Something like that. That is why I have proposed 1.3 for it.

> The LDP lists are discussing GUI editors again. I'm mainly interested as
> I'm about to become an LDP author, and I got really sick of pissing
> around with the XML syntax...
>
> I noticed that even in current SGML there's no support for things like
>  ???

  Code??

> regards
> john

  :-)
-- 
José Abílio

Re: CJK-LyX-1.2.0pre1

[Jose Abilio Oliveira Matos]

 On Friday, 5. April 2002 11.58,

 I am still unable to produce correct postscript or pdf
 autoput for LyX-document of the Docbook article (SGML)
 class, as it seems that jadetex does not handle unicode
 fonts correctly.

  Do you know if the the xml toolchain ( with fop for the print backend) 
supports unicode? I guess so, but since I don't need it so much I haven't 
tried.

  For 1.3 my goal is to output also xml, so that should be enough for you. For 
the same lyx document, so no need to change old documents.

 Therefore I am restricted to HTML output,
 as a few of SGML styles do not have a counterpart in a
 article class (e.g. code).

  LyX-Code can be used with the same purpose of code, since I started from 
scratch, as I was expecting the latex's guys ;-) to clean the mess that is 
LyX-Code I have implemented code for linuxdoc/docbook.

  What are the others layouts that don't have a counterpart in latex article?

 Regards

-- 
José Abílio

Re: CJK-LyX-1.2.0pre1

[Jose Abilio Oliveira Matos]

> On Friday, 5. April 2002 11.58,

> I am still unable to produce correct postscript or pdf
> autoput for LyX-document of the "Docbook article (SGML)"
> class, as it seems that jadetex does not handle unicode
> fonts correctly.

  Do you know if the the xml toolchain ( with fop for the print backend) 
supports unicode? I guess so, but since I don't need it so much I haven't 
tried.

  For 1.3 my goal is to output also xml, so that should be enough for you. For 
the same lyx document, so no need to change old documents.

> Therefore I am restricted to HTML output,
> as a few of SGML styles do not have a counterpart in a
> "article" class (e.g. code).

  LyX-Code can be used with the same purpose of code, since I started from 
scratch, as I was expecting the latex's guys ;-) to clean the mess that is 
LyX-Code I have implemented code for linuxdoc/docbook.

  What are the others layouts that don't have a counterpart in latex article?

> Regards

-- 
José Abílio

Re: layout as string bug (I think)

[Jose Abilio Oliveira Matos]

On Friday 05 April 2002 15:38, Jean-Marc Lasgouttes wrote:

 No. Having same shortcut for different things is not possible
 currently. I am confident that it will soon, since ANdre' since
 excited about it, and there is not much we can do to stop him.

  Ok. BTW you are lucky since André isn't here today, but you already knew 
this, didn't you?

 JMarc

-- 
José Abílio

Re: layout as string bug (I think)

[Jose Abilio Oliveira Matos]

On Friday 05 April 2002 15:38, Jean-Marc Lasgouttes wrote:
>
> No. Having same shortcut for different things is not possible
> currently. I am confident that it will soon, since ANdre' since
> excited about it, and there is not much we can do to stop him.

  Ok. BTW you are lucky since André isn't here today, but you already knew 
this, didn't you?

> JMarc

-- 
José Abílio

Re: Missing translations

[Jose Abilio Oliveira Matos]

On Tuesday 02 April 2002 17:56, claus_h wrote:
 Jean-Marc Lasgouttes writes:
  Claus The unit drop-down menus share the same flaw (cm, mm, in,
  Claus text%...)
 
  Do we want to translate them? We have to be careful here.

 Inches are called tommer in Danish.

  And polegadas in portuguese, if that counts. :-)
  Yes, they should be translated.

 Also text%, col% etc. ought to be translated.

 Claus

-- 
José Abílio

Re: Missing translations

[Jose Abilio Oliveira Matos]

On Tuesday 02 April 2002 17:56, claus_h wrote:
> Jean-Marc Lasgouttes writes:
> > Claus> The unit drop-down menus share the same flaw (cm, mm, in,
> > Claus> text%...)
> >
> > Do we want to translate them? We have to be careful here.
>
> Inches are called "tommer" in Danish.

  And "polegadas" in portuguese, if that counts. :-)
  Yes, they should be translated.

> Also text%, col% etc. ought to be translated.
>
> Claus

-- 
José Abílio

Re: .lyx - .html

[Jose Abilio Oliveira Matos]

On Tuesday 26 March 2002 11:01, Andre Poenitz wrote:
 On Tue, Mar 26, 2002 at 10:43:30AM +, Angus Leeming wrote:
  It also barfs at natbib citation for example.

 So would converting the document to docbook and using some sgml tool be
 more helpful?

  Most of the time is that what I use. To convert from latex to html I 
usually use hevea. It is much faster indeed.
 Andre'

-- 
José Abílio

Re: .lyx -> .html

[Jose Abilio Oliveira Matos]

On Tuesday 26 March 2002 11:01, Andre Poenitz wrote:
> On Tue, Mar 26, 2002 at 10:43:30AM +, Angus Leeming wrote:
> > It also barfs at natbib citation for example.
>
> So would converting the document to docbook and using some sgml tool be
> more helpful?

  Most of the time is that what I use. To convert from latex to html I 
usually use hevea. It is much faster indeed.
> Andre'

-- 
José Abílio

Do you want a Porto (or the next LyX meeting)

[Jose Abilio Oliveira Matos]

Hi all,
the next LyX meeting will be here in Porto (Portugal), from 13 to 18 of 
June. (2002 of course :-)

All LyX users and developers are invited.

Best regards,
-- 
José Abílio

Do you want a Porto (or the next LyX meeting)

[Jose Abilio Oliveira Matos]

Hi all,
the next LyX meeting will be here in Porto (Portugal), from 13 to 18 of 
June. (2002 of course :-)

All LyX users and developers are invited.

Best regards,
-- 
José Abílio

Re: DocBook-class weirdness

[Jose Abilio Oliveira Matos]

On Monday 11 March 2002 18:48, Niklaus Giger wrote:

 Thank you very much for your hint. But this behaviour
 violates the Principle of least surprise, which I think
 is usually appropriate for a user interface. E.g. I often
 begin sketching my ideas with just one or two words in a
 description. The rest will follow later.

  There is a rationale for the previous behaviour, suppose you have:

  one
  two
  four
natural numbers
  pi
  gamma (Euler's)
real numbers

  This is possible in docbook, where several terms can have the same 
definition. The code was supposed to allow this but it had a bug, so I have 
disabled this for 1.2.0, it will be reworked for 1.3.

 It would be very nice and helpful if you could figure out a
 work around for a upcoming version of LyX.

  I will commit it soon, it is one line. :-)

 Regards

-- 
José Abílio

Re: DocBook-class weirdness

[Jose Abilio Oliveira Matos]

On Monday 11 March 2002 18:48, Niklaus Giger wrote:
>
> Thank you very much for your hint. But this behaviour
> violates the "Principle of least surprise", which I think
> is usually appropriate for a user interface. E.g. I often
> begin sketching my ideas with just one or two words in a
> description. The rest will follow later.

  There is a rationale for the previous behaviour, suppose you have:

  one
  two
  four
natural numbers
  pi
  gamma (Euler's)
real numbers

  This is possible in docbook, where several terms can have the same 
definition. The code was supposed to allow this but it had a bug, so I have 
disabled this for 1.2.0, it will be reworked for 1.3.

> It would be very nice and helpful if you could figure out a
> work around for a upcoming version of LyX.

  I will commit it soon, it is one line. :-)

> Regards

-- 
José Abílio

Error in make (lib)

[Jose Abilio Oliveira Matos]

I get this error with latest cvs

Making all in lib
make[1]: Entering directory `/home/jamatos/lyx/lyx-devel/lib'
Making all in reLyX
make[2]: Entering directory `/home/jamatos/lyx/lyx-devel/lib/reLyX'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/jamatos/lyx/lyx-devel/lib/reLyX'
make[2]: Entering directory `/home/jamatos/lyx/lyx-devel/lib'
configure
make[2]: configure: Command not found
make[2]: *** [lyxrc.defaults] Error 127
make[2]: Leaving directory `/home/jamatos/lyx/lyx-devel/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jamatos/lyx/lyx-devel/lib'
make: *** [all-recursive] Error 1

It should be ./configure

  Am I the only one seeing this error?
--
José Abílio

Error in make (lib)

[Jose Abilio Oliveira Matos]

I get this error with latest cvs

Making all in lib
make[1]: Entering directory `/home/jamatos/lyx/lyx-devel/lib'
Making all in reLyX
make[2]: Entering directory `/home/jamatos/lyx/lyx-devel/lib/reLyX'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/jamatos/lyx/lyx-devel/lib/reLyX'
make[2]: Entering directory `/home/jamatos/lyx/lyx-devel/lib'
configure
make[2]: configure: Command not found
make[2]: *** [lyxrc.defaults] Error 127
make[2]: Leaving directory `/home/jamatos/lyx/lyx-devel/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jamatos/lyx/lyx-devel/lib'
make: *** [all-recursive] Error 1

It should be ./configure

  Am I the only one seeing this error?
--
José Abílio

Abort at cut and paste.

[Jose Abilio Oliveira Matos]

Hi,
when I select some test and then paste it, I get, even for a new document, 
this:

Program received signal SIGABRT, Aborted.
0x402d7ae1 in __kill () from /lib/i686/libc.so.6
Current language:  auto; currently c
(gdb) bt
#0  0x402d7ae1 in __kill () from /lib/i686/libc.so.6
#1  0x402d78ba in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x402d9062 in abort () at ../sysdeps/generic/abort.c:88
#3  0x082d1beb in lyx::abort () at abort.C:9
#4  0x08131285 in LyXTextClass::operator[] (this=0x844e8d8, n=@0x8499670) at 
support/LAssert.h:24
#5  0x0813a626 in Paragraph::getFont (this=0x8499668, bparams=@0x8493260, 
pos=0) at paragraph.C:621
#6  0x0806adc4 in CutAndPaste::pasteSelection (par=0xbfffd9c4, 
endpar=0xbfffd9c8, pos=@0xbfffd9cc, tc=7 '\a') at CutAndPaste.C:307
#7  0x0816dc88 in LyXText::pasteSelection (this=0x8494a78, bview=0x8477040) 
at text2.C:1797
#8  0x08053d1e in BufferView::paste (this=0x8477040) at BufferView2.C:427
#9  0x0805c7de in BufferView::Pimpl::Dispatch (this=0x8477058, 
action=LFUN_PASTE, argument=@0xbfffdf94) at BufferView_pimpl.C:1564
#10 0x0805164b in BufferView::Dispatch (this=0x8477040, action=LFUN_PASTE, 
argument=@0xbfffdf94) at BufferView.C:287
#11 0x08109bba in LyXFunc::dispatch (this=0x8442f80, action=LFUN_PASTE, 
argument=0xbfffdf94) at lyxfunc.C:1656
#12 0x08102732 in LyXFunc::verboseDispatch (this=0x8442f80, 
action=LFUN_PASTE, argument=@0xbfffdff4, show_sc=false) at 
/usr/include/g++-3/std/bastring.h:177
#13 0x08102677 in LyXFunc::verboseDispatch (this=0x8442f80, ac=19, 
show_sc=false) at lyxfunc.C:787
#14 0x08100e1f in LyXFunc::processKeySym (this=0x8442f80, keysym=121, 
state=20) at lyxfunc.C:340
#15 0x08057857 in BufferView::Pimpl::workAreaKeyPress (this=0x8477058, 
keysym=121, state=20) at BufferView_pimpl.C:537
#16 0x082e9513 in SigC::ObjectSlot2_void, unsigned long, unsigned int, 
BufferView::Pimpl::callback (d=0x8478544, p1=121, p2=20) at 
../sigc++/object_slot.h:250
#17 0x082fa479 in SigC::Signal2void, unsigned long, unsigned int, 
SigC::Marshalvoid ::emit (this=0x847708c, p1=@0xbfffe150, p2=@0xbfffe14c) 
at ../sigc++/slot.h:456
#18 0x0809e61b in WorkArea::work_area_handler (ob=0x8478128, event=9, key=25, 
xev=0x4010a0a0) at ../sigc++/basic_signal.h:450
#19 0x0809d1e3 in C_WorkArea_work_area_handler (ob=0x8478128, event=9, 
key=25, xev=0x4010a0a0) at WorkArea.C:70
#20 0x400a78f3 in fl_handle_it () from /usr/X11R6/lib/libforms.so.0.89
#21 0x400a79b5 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89
#22 0x4007c1ea in fl_keyboard () from /usr/X11R6/lib/libforms.so.0.89
#23 0x4007c5e5 in fl_handle_form () from /usr/X11R6/lib/libforms.so.0.89
#24 0x4007c91d in do_keyboard () from /usr/X11R6/lib/libforms.so.0.89
#25 0x4007cfdb in do_interaction_step () from /usr/X11R6/lib/libforms.so.0.89
#26 0x4007d649 in fl_treat_interaction_events () from 
/usr/X11R6/lib/libforms.so.0.89
#27 0x4007d684 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89
#28 0x0829b7ad in GUIRunTime::runTime () at GUIRunTime.C:90
#29 0x080efc14 in LyXGUI::runTime (this=0x841d840) at lyx_gui.C:315
#30 0x080f080b in LyX::LyX (this=0xbfffe5f0, argc=0xbfffe650, 
argv=0xbfffe6b4) at ../boost/boost/smart_ptr.hpp:102
#31 0x081354bd in main (argc=1, argv=0xbfffe6b4) at ../src/main.C:38
#32 0x402c5627 in __libc_start_main (main=0x8135360 main, argc=3, 
ubp_av=0xbfffe6b4, init=0x804f4f4 _init, fini=0x837cf84 _fini, 
rtld_fini=0x4000dcc4 _dl_fini,
stack_end=0xbfffe6ac) at ../sysdeps/generic/libc-start.c:129

  I hope that this is not a duplicate bug report, the cvs was from this 
morning, before Juergen and Angs last commits.
-- 
José Abílio

Re: Abort at cut and paste.

[Jose Abilio Oliveira Matos]

On Wednesday 06 March 2002 12:20, you wrote:

  I hate to reply to my messages but the bug is gone with latest cvs.

  My luck is that we aren't on friday. ;-)
--
José Abílio

Abort at cut and paste.

[Jose Abilio Oliveira Matos]

Hi,
when I select some test and then paste it, I get, even for a new document, 
this:

Program received signal SIGABRT, Aborted.
0x402d7ae1 in __kill () from /lib/i686/libc.so.6
Current language:  auto; currently c
(gdb) bt
#0  0x402d7ae1 in __kill () from /lib/i686/libc.so.6
#1  0x402d78ba in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x402d9062 in abort () at ../sysdeps/generic/abort.c:88
#3  0x082d1beb in lyx::abort () at abort.C:9
#4  0x08131285 in LyXTextClass::operator[] (this=0x844e8d8, n=@0x8499670) at 
support/LAssert.h:24
#5  0x0813a626 in Paragraph::getFont (this=0x8499668, bparams=@0x8493260, 
pos=0) at paragraph.C:621
#6  0x0806adc4 in CutAndPaste::pasteSelection (par=0xbfffd9c4, 
endpar=0xbfffd9c8, pos=@0xbfffd9cc, tc=7 '\a') at CutAndPaste.C:307
#7  0x0816dc88 in LyXText::pasteSelection (this=0x8494a78, bview=0x8477040) 
at text2.C:1797
#8  0x08053d1e in BufferView::paste (this=0x8477040) at BufferView2.C:427
#9  0x0805c7de in BufferView::Pimpl::Dispatch (this=0x8477058, 
action=LFUN_PASTE, argument=@0xbfffdf94) at BufferView_pimpl.C:1564
#10 0x0805164b in BufferView::Dispatch (this=0x8477040, action=LFUN_PASTE, 
argument=@0xbfffdf94) at BufferView.C:287
#11 0x08109bba in LyXFunc::dispatch (this=0x8442f80, action=LFUN_PASTE, 
argument=0xbfffdf94) at lyxfunc.C:1656
#12 0x08102732 in LyXFunc::verboseDispatch (this=0x8442f80, 
action=LFUN_PASTE, argument=@0xbfffdff4, show_sc=false) at 
/usr/include/g++-3/std/bastring.h:177
#13 0x08102677 in LyXFunc::verboseDispatch (this=0x8442f80, ac=19, 
show_sc=false) at lyxfunc.C:787
#14 0x08100e1f in LyXFunc::processKeySym (this=0x8442f80, keysym=121, 
state=20) at lyxfunc.C:340
#15 0x08057857 in BufferView::Pimpl::workAreaKeyPress (this=0x8477058, 
keysym=121, state=20) at BufferView_pimpl.C:537
#16 0x082e9513 in SigC::ObjectSlot2_::callback (d=0x8478544, p1=121, p2=20) at 
../sigc++/object_slot.h:250
#17 0x082fa479 in SigC::Signal2::emit (this=0x847708c, p1=@0xbfffe150, p2=@0xbfffe14c) 
at ../sigc++/slot.h:456
#18 0x0809e61b in WorkArea::work_area_handler (ob=0x8478128, event=9, key=25, 
xev=0x4010a0a0) at ../sigc++/basic_signal.h:450
#19 0x0809d1e3 in C_WorkArea_work_area_handler (ob=0x8478128, event=9, 
key=25, xev=0x4010a0a0) at WorkArea.C:70
#20 0x400a78f3 in fl_handle_it () from /usr/X11R6/lib/libforms.so.0.89
#21 0x400a79b5 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89
#22 0x4007c1ea in fl_keyboard () from /usr/X11R6/lib/libforms.so.0.89
#23 0x4007c5e5 in fl_handle_form () from /usr/X11R6/lib/libforms.so.0.89
#24 0x4007c91d in do_keyboard () from /usr/X11R6/lib/libforms.so.0.89
#25 0x4007cfdb in do_interaction_step () from /usr/X11R6/lib/libforms.so.0.89
#26 0x4007d649 in fl_treat_interaction_events () from 
/usr/X11R6/lib/libforms.so.0.89
#27 0x4007d684 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89
#28 0x0829b7ad in GUIRunTime::runTime () at GUIRunTime.C:90
#29 0x080efc14 in LyXGUI::runTime (this=0x841d840) at lyx_gui.C:315
#30 0x080f080b in LyX::LyX (this=0xbfffe5f0, argc=0xbfffe650, 
argv=0xbfffe6b4) at ../boost/boost/smart_ptr.hpp:102
#31 0x081354bd in main (argc=1, argv=0xbfffe6b4) at ../src/main.C:38
#32 0x402c5627 in __libc_start_main (main=0x8135360 , argc=3, 
ubp_av=0xbfffe6b4, init=0x804f4f4 <_init>, fini=0x837cf84 <_fini>, 
rtld_fini=0x4000dcc4 <_dl_fini>,
stack_end=0xbfffe6ac) at ../sysdeps/generic/libc-start.c:129

  I hope that this is not a duplicate bug report, the cvs was from this 
morning, before Juergen and Angs last commits.
-- 
José Abílio

Re: Abort at cut and paste.

[Jose Abilio Oliveira Matos]

On Wednesday 06 March 2002 12:20, you wrote:

  I hate to reply to my messages but the bug is gone with latest cvs.

  My luck is that we aren't on friday. ;-)
--
José Abílio

Re: DocBook XML...

[Jose Abilio Oliveira Matos]

On Sunday 03 March 2002 23:31, ben wrote:

 Hello,

[...]
 BG

 PS : Jose, you looked at db2lyx some time ago; have you improved the
 configuration process? Have you committed something somewhere?

  Not yet. I'm expecting for 1.2.0 to be released to insert it in cvs, and 
from there fix the configuration stuff. Have you tested the last cvs 
lyx-docbook?

  m4 is not my favorite language, you know? ;-)

  PS: my priority now goes for fixing the remaining bugs with docbook, for 
1.2.0
-- 
José Abílio

Re: DocBook XML...

[Jose Abilio Oliveira Matos]

On Monday 04 March 2002 09:17, Jean-Marc Lasgouttes wrote:

 Jose   m4 is not my favorite language, you know? ;-)

 Feel free to ask me for some help.

  Thanks, I will do. :-)

 JMarc

-- 
José Abílio

Re: putting devguide.html back on the web

[Jose Abilio Oliveira Matos]

On Monday 04 March 2002 13:16, Angus Leeming wrote:

 Since LyX version 1.1 the Standard Template Library (STL) is being used for
 most data structures. See some online references recommended by our
 developers. We also have some simple coding rules that we try and adhere
 to. See development/Code_rules/Rules.

  Why not a link to it using the cvsweb interface?

-- 
José Abílio

Re: Error compiling lyx cvs

[Jose Abilio Oliveira Matos]

On Monday 04 March 2002 15:06, Yann MORERE wrote:
 directory make[3]: *** [lyx] Error 1
 make[3]: Leaving directory `/root/lyxdevel/lyx-devel/src'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory `/root/lyxdevel/lyx-devel/src'
 make[1]: *** [all-recursive-am] Error 2
 make[1]: Leaving directory `/root/lyxdevel/lyx-devel/src'
 make: *** [all-recursive] Error 1
 lyxdevel@yoda:~/lyx-devel$

 Where is the problem?

  just

  ./autogen.sh
  make

  should be enough.

 Yann

 another lyx checkout, and recompiling from the autogen.sh ?

-- 
José Abílio

Re: DocBook XML...

[Jose Abilio Oliveira Matos]

On Sunday 03 March 2002 23:31, ben wrote:
>
> Hello,
>
[...]
> BG
>
> PS : Jose, you looked at db2lyx some time ago; have you improved the
> configuration process? Have you committed something somewhere?

  Not yet. I'm expecting for 1.2.0 to be released to insert it in cvs, and 
from there fix the configuration stuff. Have you tested the last cvs 
lyx-docbook?

  m4 is not my favorite language, you know? ;-)

  PS: my priority now goes for fixing the remaining bugs with docbook, for 
1.2.0
-- 
José Abílio

Re: DocBook XML...

[Jose Abilio Oliveira Matos]

On Monday 04 March 2002 09:17, Jean-Marc Lasgouttes wrote:
>
> Jose>   m4 is not my favorite language, you know? ;-)
>
> Feel free to ask me for some help.

  Thanks, I will do. :-)

> JMarc

-- 
José Abílio

Re: putting devguide.html back on the web

[Jose Abilio Oliveira Matos]

On Monday 04 March 2002 13:16, Angus Leeming wrote:
>
> Since LyX version 1.1 the Standard Template Library (STL) is being used for
> most data structures. See some online references recommended by our
> developers. We also have some simple coding rules that we try and adhere
> to. See development/Code_rules/Rules.

  Why not a link to it using the cvsweb interface?

-- 
José Abílio

Re: Error compiling lyx cvs

[Jose Abilio Oliveira Matos]

On Monday 04 March 2002 15:06, Yann MORERE wrote:
> directory make[3]: *** [lyx] Error 1
> make[3]: Leaving directory `/root/lyxdevel/lyx-devel/src'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/root/lyxdevel/lyx-devel/src'
> make[1]: *** [all-recursive-am] Error 2
> make[1]: Leaving directory `/root/lyxdevel/lyx-devel/src'
> make: *** [all-recursive] Error 1
> lyxdevel@yoda:~/lyx-devel$
>
> Where is the problem?

  just

  ./autogen.sh
  make

  should be enough.

> Yann
>
> another lyx checkout, and recompiling from the "autogen.sh" ?

-- 
José Abílio

Re: [Devel] Bug list is shrinking!

[Jose Abilio Oliveira Matos]

On Thursday 28 February 2002 13:04, Jean-Marc Lasgouttes wrote:

 John THe question is, if this can happen, what sense does looking at
 John niceFile there make ??

 It seems that the idea is to use full path when trying to run latex.

  I use it in linuxdoc and docbook with the same purpose.

 JMarc

-- 
José Abílio

Re: [Devel] Bug list is shrinking!

[Jose Abilio Oliveira Matos]

On Thursday 28 February 2002 13:04, Jean-Marc Lasgouttes wrote:

> John> THe question is, if this can happen, what sense does looking at
> John> niceFile there make ??
>
> It seems that the idea is to use full path when trying to run latex.

  I use it in linuxdoc and docbook with the same purpose.

> JMarc

-- 
José Abílio

Re: [patch] (html)URL - inset

[Jose Abilio Oliveira Matos]

On Wednesday 27 February 2002 15:11, Jean-Marc Lasgouttes wrote:

 I have little experience with hevea, but it seemed to me at the time
 that it got right some things l2h got wrong. But maybe was my l2h
 version too old.

  Yes, hevea analyses the .aux files, that is the reason why it is my 
favorite converter.

 JMarc

-- 
José Abílio

Re: [patch] (html)URL - inset

[Jose Abilio Oliveira Matos]

On Wednesday 27 February 2002 15:11, Jean-Marc Lasgouttes wrote:
>
> I have little experience with hevea, but it seemed to me at the time
> that it got right some things l2h got wrong. But maybe was my l2h
> version too old.

  Yes, hevea analyses the .aux files, that is the reason why it is my 
favorite converter.

> JMarc

-- 
José Abílio

Re: LyX 1.2.0 and CJK (still some problems left)

[Jose Abilio Oliveira Matos]

On Saturday 23 February 2002 16:39, Niklaus Giger wrote:
   What is in your preamble?
 
 --
 José Abílio

 Just the following line:
 \usepackage{hangul}

  Then remove it and all should be fine.
  The preamble is for docbook related stuff.

 Regards

-- 
José Abílio

Re: DocBook-class weirdness

[Jose Abilio Oliveira Matos]

On Saturday 23 February 2002 18:10, Niklaus Giger wrote:
 I had a LyX-file based on the LinuxDoc class. It had some
 Itemize, Description paragraphs. Then I changed the layout
 to DocBook class and I got quit a few errors like this:

 /usr/bin/jade:[EMAIL PROTECTED]:228:12:E: end tag for element
 LISTITEM which is not open
 /usr/bin/jade:[EMAIL PROTECTED]:229:16:E: end tag for
 VARLISTENTRY which is not finished
 /usr/bin/jade:[EMAIL PROTECTED]:240:12:E: end tag for element
 LISTITEM which is not open
 /usr/bin/jade:[EMAIL PROTECTED]:241:16:E: end tag for
 VARLISTENTRY which is not finished
 /usr/bin/jade:[EMAIL PROTECTED]:245:12:E: end tag for element
 LISTITEM which is not open
 /usr/bin/jade:[EMAIL PROTECTED]:246:16:E: end tag for
 VARLISTENTRY which is not finished
 

  That is weird. (So you agree with me, hey? ;-)

 Setting all paragraphs to standard and applying Itemize or
 Description fixed the problem.

  Do you have an example file, please?

 I tried various paragraph layouts and position, but nothing
 works. Can somebody answer this question? Could an example
 for TOC, list of illustrations, etc. be inserted into the
 DocBook example?

  The table of contents, list of ilustrations, etc, are controled by the 
transformation stylesheets, not by the document.

 Regards

-- 
José Abílio

Re: LyX 1.2.0 and CJK (still some problems left)

[Jose Abilio Oliveira Matos]

On Saturday 23 February 2002 16:39, Niklaus Giger wrote:
> >  What is in your preamble?
> >
> >--
> >José Abílio
>
> Just the following line:
> \usepackage{hangul}

  Then remove it and all should be fine.
  The preamble is for docbook related stuff.

> Regards

-- 
José Abílio

Re: DocBook-class weirdness

[Jose Abilio Oliveira Matos]

On Saturday 23 February 2002 18:10, Niklaus Giger wrote:
> I had a LyX-file based on the LinuxDoc class. It had some
> Itemize, Description paragraphs. Then I changed the layout
> to DocBook class and I got quit a few errors like this:
>
> /usr/bin/jade:[EMAIL PROTECTED]:228:12:E: end tag for element
> "LISTITEM" which is not open
> /usr/bin/jade:[EMAIL PROTECTED]:229:16:E: end tag for
> "VARLISTENTRY" which is not finished
> /usr/bin/jade:[EMAIL PROTECTED]:240:12:E: end tag for element
> "LISTITEM" which is not open
> /usr/bin/jade:[EMAIL PROTECTED]:241:16:E: end tag for
> "VARLISTENTRY" which is not finished
> /usr/bin/jade:[EMAIL PROTECTED]:245:12:E: end tag for element
> "LISTITEM" which is not open
> /usr/bin/jade:[EMAIL PROTECTED]:246:16:E: end tag for
> "VARLISTENTRY" which is not finished
> 

  That is weird. (So you agree with me, hey? ;-)

> Setting all paragraphs to standard and applying Itemize or
> Description fixed the problem.

  Do you have an example file, please?

> I tried various paragraph layouts and position, but nothing
> works. Can somebody answer this question? Could an example
> for TOC, list of illustrations, etc. be inserted into the
> DocBook example?

  The table of contents, list of ilustrations, etc, are controled by the 
transformation stylesheets, not by the document.

> Regards

-- 
José Abílio

Re: Shall I create a BRANCH_graphics?

[Jose Abilio Oliveira Matos]

On Friday 22 February 2002 12:55, Lars Gullik Bjønnes wrote:

 btw. I changed some initialization reordering in some constructors as
 well.

 in insetgraphics.C: graphic_label needs to be initialized first.

  It was me who added this variable this week, so I'm the guilty part here.

-- 
José Abílio

Re: Shall I create a BRANCH_graphics?

[Jose Abilio Oliveira Matos]

On Friday 22 February 2002 12:55, Lars Gullik Bjønnes wrote:
>
> btw. I changed some initialization reordering in some constructors as
> well.
>
> in insetgraphics.C: graphic_label needs to be initialized first.

  It was me who added this variable this week, so I'm the guilty part here.

-- 
José Abílio

Re: LyX 1.2.0 and CJK

[Jose Abilio Oliveira Matos]

On Wednesday 20 February 2002 20:44, Niklaus Giger wrote:
[...]
 Two question:
 - Are your planning to integrate CJK-LYX? When?
 - Can I help to fix the SGML problem with  CJK-LYX ?

  If there are bugs that are related to the linuxdoc or docbook output, feel 
free to report them. I would be glad to fix them.

 Thank you in advance.

 Regards

-- 
José Abílio

Re: A bug in DocBook class?

[Jose Abilio Oliveira Matos]

On Thursday 21 February 2002 07:12, [EMAIL PROTECTED] wrote:
 Hello,

 When I try to view a lyx file with DocBook article class, which also
 contains tex style files in the Layout-LaTeX Preamble, it gives me, while
 executing db2dvi,  the error,
   character \ not allowed in declaration subset'.

 Is this a bug, or am I doing something wrong here ?

  the bug is different and present in several other places. In the GUI there 
are references to LaTeX when it should be linuxdoc or docbook depending on 
the buffer (document) type used.

  So here the it should say Layout-docbook preamble, since that is the 
correct name for it.

  Jean-Marc would it be too dificult to change the menu entries, depending on 
the buffer type?

 The exported sgml file is the following:

  That is not a bug a but a feature, the bug as I told is elsewhere. ;-)

 --cghan

-- 
José Abílio

Re: A bug in DocBook class?

[Jose Abilio Oliveira Matos]

On Friday 22 February 2002 04:42, cghan wrote:

 If I apply db2dvi to the exported sgml file, it gives the same error.
 Doesn't this mean that there is something wrong in the exported sgml file?

  Nope. What I intend to say is that your preamble is a latex preamble, not a 
valid docbook preamble. The bug that I refer to was the indication of latex 
preamble when it should refer to docbook preamble.

  If you remove your preamble all should be ok.

 --cghan

-- 
José Abílio

Re: LyX 1.2.0 and CJK (still some problems left)

[Jose Abilio Oliveira Matos]

On Thursday 21 February 2002 23:49, Niklaus Giger wrote:

 Docbook class can be exported to sgml, but trying to
 generate html or postscript results in the following error:

 /usr/bin/jade:[EMAIL PROTECTED]:2:3:E: character \ not
 allowed in declaration subset

  What is in your preamble?

-- 
José Abílio

Re: LyX 1.2.0 and CJK

[Jose Abilio Oliveira Matos]

On Wednesday 20 February 2002 20:44, Niklaus Giger wrote:
[...]
> Two question:
> - Are your planning to integrate CJK-LYX? When?
> - Can I help to fix the SGML problem with  CJK-LYX ?

  If there are bugs that are related to the linuxdoc or docbook output, feel 
free to report them. I would be glad to fix them.

> Thank you in advance.
>
> Regards

-- 
José Abílio

Re: A bug in DocBook class?

[Jose Abilio Oliveira Matos]

On Thursday 21 February 2002 07:12, [EMAIL PROTECTED] wrote:
> Hello,
>
> When I try to view a lyx file with "DocBook article" class, which also
> contains tex style files in the Layout->LaTeX Preamble, it gives me, while
> executing db2dvi,  the error,
>   "character "\" not allowed in declaration subset'.
>
> Is this a bug, or am I doing something wrong here ?

  the bug is different and present in several other places. In the GUI there 
are references to LaTeX when it should be linuxdoc or docbook depending on 
the buffer (document) type used.

  So here the it should say Layout->docbook preamble, since that is the 
correct name for it.

  Jean-Marc would it be too dificult to change the menu entries, depending on 
the buffer type?

> The exported sgml file is the following:

  That is not a bug a but a feature, the bug as I told is elsewhere. ;-)

> --cghan

-- 
José Abílio

Re: A bug in DocBook class?

[Jose Abilio Oliveira Matos]

On Friday 22 February 2002 04:42, cghan wrote:
>
> If I apply "db2dvi" to the exported sgml file, it gives the same error.
> Doesn't this mean that there is something wrong in the exported sgml file?

  Nope. What I intend to say is that your preamble is a latex preamble, not a 
valid docbook preamble. The bug that I refer to was the indication of latex 
preamble when it should refer to docbook preamble.

  If you remove your preamble all should be ok.

> --cghan

-- 
José Abílio

Re: LyX 1.2.0 and CJK (still some problems left)

[Jose Abilio Oliveira Matos]

On Thursday 21 February 2002 23:49, Niklaus Giger wrote:
>
> Docbook class can be exported to sgml, but trying to
> generate html or postscript results in the following error:
>
> /usr/bin/jade:[EMAIL PROTECTED]:2:3:E: character "\" not
> allowed in declaration subset

  What is in your preamble?

-- 
José Abílio

Graphics and docbook (help).

[Jose Abilio Oliveira Matos]

Hi,
there is currently a bug with docbook and graphics, when the graphic is 
located in a slave document. The location of the graphics exported is 
relative to the graphics owner, but it should be relative to the master's 
location.

I have 2 solutions:
a) Always export the absolute graphics path
b) Introduce the same mechanism used in the inset include, where a unique 
label is assigned to each inset. Then using the latexfeatures, the path of 
the label is always exported relative to the master's location.

IMO, the correct fix is b). In that case I would need to move the 
unique_id() function from insetgraphics.C to (where?), maybe src/support/
And add a new private member to insetgraphics.

What do you say?
-- 
José Abílio

Re: Graphics and docbook (help).

[Jose Abilio Oliveira Matos]

Hi,
answering my own question. The following patch does it, any objection?

-- 
José Abílio



patch.gz
Description: GNU Zip compressed data

Graphics and docbook (help).

[Jose Abilio Oliveira Matos]

Hi,
there is currently a bug with docbook and graphics, when the graphic is 
located in a slave document. The location of the graphics exported is 
relative to the graphics owner, but it should be relative to the master's 
location.

I have 2 solutions:
a) Always export the absolute graphics path
b) Introduce the same mechanism used in the inset include, where a unique 
label is assigned to each inset. Then using the latexfeatures, the path of 
the label is always exported relative to the master's location.

IMO, the correct fix is b). In that case I would need to move the 
unique_id() function from insetgraphics.C to (where?), maybe src/support/
And add a new private member to insetgraphics.

What do you say?
-- 
José Abílio

Re: Graphics and docbook (help).

[Jose Abilio Oliveira Matos]

Hi,
answering my own question. The following patch does it, any objection?

-- 
José Abílio



patch.gz
Description: GNU Zip compressed data

Error with last cvs

[Jose Abilio Oliveira Matos]

Jean-Marc,
this seems to be a result of you last commit. What do you say?
$make
Making all in intl
make[1]: Entering directory `/home/jamatos/lyx/lyx-devel/intl'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jamatos/lyx/lyx-devel/intl'
Making all in po
make[1]: Entering directory `/home/jamatos/lyx/lyx-devel/po'
file=./`echo ru | sed 's,.*/,,'`.gmo \
   case /usr/bin/msgfmt in \
   */msgfmt) rm -f $file  /usr/bin/msgfmt --statistics -o $file ru.po;; 
\
   *) touch $file ;; \
 esac
ru.po:11137: parse error
ru.po:11138: end-of-line within string
found 2 fatal errors
make[1]: *** [ru.gmo] Error 1
make[1]: Leaving directory `/home/jamatos/lyx/lyx-devel/po'
make: *** [all-recursive] Error 1
-- 
José Abílio

Re: Error with last cvs

[Jose Abilio Oliveira Matos]

On Monday 18 February 2002 18:17, Jean-Marc Lasgouttes wrote:

 I say try again.

  Done. Now Oll Kright.

 JMarc

-- 
José Abílio

Error with last cvs

[Jose Abilio Oliveira Matos]

Jean-Marc,
this seems to be a result of you last commit. What do you say?
$make
Making all in intl
make[1]: Entering directory `/home/jamatos/lyx/lyx-devel/intl'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/jamatos/lyx/lyx-devel/intl'
Making all in po
make[1]: Entering directory `/home/jamatos/lyx/lyx-devel/po'
file=./`echo ru | sed 's,.*/,,'`.gmo \
  && case "/usr/bin/msgfmt" in \
   */msgfmt) rm -f $file && /usr/bin/msgfmt --statistics -o $file ru.po;; 
\
   *) touch $file ;; \
 esac
ru.po:11137: parse error
ru.po:11138: end-of-line within string
found 2 fatal errors
make[1]: *** [ru.gmo] Error 1
make[1]: Leaving directory `/home/jamatos/lyx/lyx-devel/po'
make: *** [all-recursive] Error 1
-- 
José Abílio

Re: Error with last cvs

[Jose Abilio Oliveira Matos]

On Monday 18 February 2002 18:17, Jean-Marc Lasgouttes wrote:
>
> I say "try again".

  Done. Now Oll Kright.

> JMarc

-- 
José Abílio

Re: [bugzilla-daemon@hardcoregamers.com] [Bug 205] New: Not a bug but a note of congrats and excitement

[Jose Abilio Oliveira Matos]

On Wednesday 23 January 2002 22:22, Michael Koziarski wrote:
 At 10:43 PM 1/23/02 +0100, Lars Gullik Bjønnes wrote:
 Ok, how do we handle these in bugzilla?

 I guess you could say thanks when you mark the bug INVALID.

  No way. I don't mark it as WON'T FIX? ;-)

 Cheers

 Koz

-- 
José Abílio

Re: [bugzilla-daemon@hardcoregamers.com] [Bug 205] New: Not a bug but a note of congrats and excitement

[Jose Abilio Oliveira Matos]

On Wednesday 23 January 2002 22:22, Michael Koziarski wrote:
> At 10:43 PM 1/23/02 +0100, Lars Gullik Bjønnes wrote:
> >Ok, how do we handle these in bugzilla?
>
> I guess you could say thanks when you mark the bug INVALID.

  No way. I don't mark it as WON'T FIX? ;-)

> Cheers
>
> Koz

-- 
José Abílio

Re: Quick dirty patch for tabular (i.e. wishes ;-) )

[Jose Abilio Oliveira Matos]

On Tuesday 22 January 2002 15:20, Alain Castera wrote:

 - I didn't checked that it was safe for SGML.
 
  Don´t worry we don´t check this too we normaly give more work to José by
  changes to the code, but he likes coding so he´s always happy if he can
  add new stuff, isn´t it #:O)

 Hi José, I support Jürgen's motion ;-)

  Are you talking to me? :-)
  Don't worry, I adapt all the features from latex to be valid 
linuxdoc/docbook. I can after your patch to be applied to polish the code for 
docbook.

  I should say that I am glad to see someone that cares with my work. ;-)

 Ho, and you, Jürgen, have fun (I remember you're in vacation).

  Please ear him Jürgen.

   Alain

-- 
José Abílio

Re: Quick & dirty patch for tabular (i.e. wishes ;-) )

[Jose Abilio Oliveira Matos]

On Tuesday 22 January 2002 15:20, Alain Castera wrote:

> > >   - I didn't checked that it was safe for SGML.
> >
> > Don´t worry we don´t check this too we normaly give more work to José by
> > changes to the code, but he likes coding so he´s always happy if he can
> > add new stuff, isn´t it #:O)
>
> Hi José, I support Jürgen's motion ;-)

  Are you talking to me? :-)
  Don't worry, I adapt all the features from latex to be valid 
linuxdoc/docbook. I can after your patch to be applied to polish the code for 
docbook.

  I should say that I am glad to see someone that cares with my work. ;-)

> Ho, and you, Jürgen, have fun (I remember you're in vacation).

  Please ear him Jürgen.

>   Alain

-- 
José Abílio

Reports for #23?

[Jose Abilio Oliveira Matos]

Hi,
#23 says:

The document language isn't preserved.
Also, other other document options aren't preserved
like paper margins,
some papersize options (e.g. a3, or a4wide),
separation (skip/indent) etc.


  I would like to have some example files for it. I have tried to fix most of 
these before.

-- 
José Abílio

Reports for #23?

[Jose Abilio Oliveira Matos]

Hi,
#23 says:
"""
The document language isn't preserved.
Also, other other document options aren't preserved
like paper margins,
some papersize options (e.g. a3, or a4wide),
separation (skip/indent) etc.
"""

  I would like to have some example files for it. I have tried to fix most of 
these before.

-- 
José Abílio

Re: dummy layout and how to get it!

[Jose Abilio Oliveira Matos]

On Thursday 17 January 2002 11:12, Juergen Vigna wrote:
I'm glad that you ask this although you will be soon on vacations.

 #:O)

  I hope you enjoy it. :-)

For latex Standard can have two different meanings. Sometimes it acts
  as a paragraph, and sometimes as a place to put latex code. That is one
  of the

 For me Standard in LaTeX term means that I don't set any special Layout
 I just leave the Default layout of the class I'm in.

  For me it really means that Standard is the Standard paragraph, for most of
 the documents this is the most used layout.

For docbook I have attributed to Standard its usual role and that is
  paragraph - para/para

 In what type of block do you put Empty Layout paragraphs? You have to
 have a block or you don't?

  Some of the insets we have, can have a block property. For example it
 doesn't make sense to insert a TOC in a normal paragraph (docbook doesn't
 allow it), so the TOC inset must be inserted inside an Empty layout.

  Inside the floats for example, I can have  any layout I want, but for
 example most of the time I just want a figure or a table, and I don't want
 them inside a paragraph (in some cases docbook doesn't allow them).

  This means that Empty != SGML, if you want the old SGML, you should use
  Empty+ERT.

 I could think that we could use this Empty or IMO Dummy would be better
 for LaTeX too and it should also be in ALL textclasses AND it should be as
 the Standard a fixed number (we can do this if we force this 2 Layout's
 to be present in all text-classes!)

  That can be a property specified in the layout class, some kind of logical 
style paragraph instead of relying on the order.

Using Juergen's notation Empty is my dummy paragraph.

 We would need this in LaTeX terms ONLY if we have only ERT-Insets in a
 and it seems that it is the same for DocBook, ahh no you still have the
 problem with the table-cells, but IMO this can't be solved as you want it
 you have to solve this in the docBook() code. You have to ask if the
 owner()-owner() of this paragraph is a tabular and then adapt your export
 code to what you need.

  I know that, I use that technic to see if a table is or not inside a float, 
and it works. :-)

  The question is that we should be able to choose the layout I want to in 
each cell.  Imagine that I want an itemized list inside a table, what is the 
problem with it? I should be able to do it.

  Does latex allows lists inside table cells?

 So this leaves us with the question if we use the Empty mechanism ONLY
 for paragrphs which contain only ERT inset's, then do we really need the
 Empty layout? We could say:

 if (layout == Standard  we_only_contain_ERT_inset)
  assume layout empty and only put the contents of the ERT inset out

  I don't want to assume that, as there cases where one or the other are 
valid choices. And to ignore Empty will only imply a load of hacks to fix all 
those particular cases. Not nice.

I intend to provide better documentation so that the users are not
  taken by surprise with this behaviour. What is my problem then?

 Which user will read documentation, before he is surprised! :O)

  That is my point, the users will find that the documentation warns against 
that case, and ashamed will not complain. ;-)

Inside tables I would like to be able to select between Standard and
  Empty, and by default I would like to have Empty.

 See above!

  I want really, really, really to have an Empty layout.

So I would like to have that choice. Is that to ask too much? ;-)

 Yes, you always ask too much ;)

  Who? Me? ;-)

Not enlightment, only troubles. :-)

 Well I hope I confused you completely now ;)

  So it seems that we are only ones not confused. ;-)

 Jug

--
José Abílio

Re: dummy layout and how to get it!

[Jose Abilio Oliveira Matos]

On Thursday 17 January 2002 16:07, Juergen Vigna wrote:
 On 17-Jan-2002 Jose Abilio Oliveira Matos wrote:
I hope you enjoy it. :-)

 Well you know we'll visit parents in Argentina and IMO you all follow the
 news there. So I only hope it will not be too caotic.

  I hope not.

 The problem with this is that I mean that Standard is a paragraph on
 which I don't have to put any special layout. I agree that this can/should
 be done with a logical value in the layout files and we should neighter
 rely on the name nor on the number!

  Ok.

The question is that we should be able to choose the layout I want to
  in each cell.  Imagine that I want an itemized list inside a table, what
  is the problem with it? I should be able to do it.

 Well the problem with your aprach is that you want to tell LyX create this
 table with Empty layouts and this is an even greater hack IMO then the
 one used for export. IMO you anyway need this for the single insets.

  No, I would like to be able to select Empty por all cells if I selected 
them. Now if I do that only the cell where the cursor is gets changed. I 
don't want for now lyx to do it for me.

 Well we could have logical values in the layout-files use_this_layout_as_
 default_layout_for_tabular_cells but I think that is really not nice as
 after tabular cells you want something special for minipages, then for...
 and we would have to change layout files and user would have to chage their
 layout files and so on. So IMO this type of special handling for DocBook
 should be buildin as it is not going to change, isn't it? And it has to be
 handled for any inset specially.

  No, not like that, I would like to change the layout style easily as I do 
if I select multiple paragraphs. Is this clear now? :-)

Does latex allows lists inside table cells?

 Sure if the cell has a fixed lenght!

  If the table doesn't have a fixed lenght then lyx doesn't allow the layout 
change. Am I guessing correctly?

I don't want to assume that, as there cases where one or the other are
  valid choices. And to ignore Empty will only imply a load of hacks to fix
  all those particular cases. Not nice.

 What choices?

  What I say is that sometimes depending on context, you want Standard or 
Empty, it is up to the user the correct choice not to LyX.

I want really, really, really to have an Empty layout.

 The problem here is not to have an Empty-Layout and it's handling inside
 LyX, the problem is that you want that in certain circumstaces we use that
 Layout to create a Paragraph and not as we do till now only Standard,
 that is what I don't like in your proposal.

  The point is that this Paragraph here means a lyx-paragraph and not a 
document paragraph. For lyx we all know what paragraphs are, for docbook a 
paragraph is a block element, that can have lots of things inside. From the 
Docbook: The Definitive Guide

Description

A Para is a paragraph. Paragraphs in DocBook may contain almost all inlines 
and most block elements. Sectioning and higher-level structural elements are 
excluded.


  My point is that sometimes lyx-paragraphs are different from 
docbook-paragraphs. This was always a problems, that become worse now with 
all the power of InsetText (that I really like).

  For example, in linuxdoc there is a special code to deal with the case of 
the toc inset to be the first element of a paragraph, in that case the 
paragraph is ignored.

  It is code like that I don't want to add to docbook, I don't want lots of 
special cases, I just want a fast way to change the paragraph layout if 
necessary.

So it seems that we are only ones not confused. ;-)

 #:O) well you know as it was in the last meeting the southern europe won
  the games (on the tablefootball ;)

  What would you expect, Portugal is in 4th place in the FIFA rank (Ok, 
Jean-Marc France is first) :-)

 Jug

-- 
José Abílio

Re: dummy layout and how to get it!

[Jose Abilio Oliveira Matos]

On Thursday 17 January 2002 11:12, Juergen Vigna wrote:
> >   I'm glad that you ask this although you will be soon on vacations.
>
> #:O)

  I hope you enjoy it. :-)

> >   For latex Standard can have two different meanings. Sometimes it acts
> > as a paragraph, and sometimes as a place to put latex code. That is one
> > of the
>
> For me "Standard" in LaTeX term means that I don't set any special Layout
> I just leave the "Default" layout of the class I'm in.

  For me it really means that Standard is the Standard paragraph, for most of
 the documents this is the most used layout.

> >   For docbook I have attributed to Standard its usual role and that is
> > paragraph -> 
>
> In what type of block do you put "Empty" Layout paragraphs? You have to
> have a block or you don't?

  Some of the insets we have, can have a block property. For example it
 doesn't make sense to insert a TOC in a normal paragraph (docbook doesn't
 allow it), so the TOC inset must be inserted inside an Empty layout.

  Inside the floats for example, I can have  any layout I want, but for
 example most of the time I just want a figure or a table, and I don't want
 them inside a paragraph (in some cases docbook doesn't allow them).

> > This means that Empty != SGML, if you want the old SGML, you should use
> > Empty+ERT.
>
> I could think that we could use this "Empty" or IMO "Dummy" would be better
> for LaTeX too and it should also be in ALL textclasses AND it should be as
> the "Standard" a fixed number (we can do this if we force this 2 Layout's
> to be present in all text-classes!)

  That can be a property specified in the layout class, some kind of logical 
style paragraph instead of relying on the order.

> >   Using Juergen's notation Empty is my dummy paragraph.
>
> We would need this in LaTeX terms ONLY if we have only ERT-Insets in a
> and it seems that it is the same for DocBook, ahh no you still have the
> problem with the table-cells, but IMO this can't be solved as you want it
> you have to solve this in the docBook() code. You have to ask if the
> owner()->owner() of this paragraph is a tabular and then adapt your export
> code to what you need.

  I know that, I use that technic to see if a table is or not inside a float, 
and it works. :-)

  The question is that we should be able to choose the layout I want to in 
each cell.  Imagine that I want an itemized list inside a table, what is the 
problem with it? I should be able to do it.

  Does latex allows lists inside table cells?

> So this leaves us with the question if we use the "Empty" mechanism ONLY
> for paragrphs which contain only ERT inset's, then do we really need the
> Empty layout? We could say:
>
> if (layout == "Standard" && we_only_contain_ERT_inset)
>  assume layout empty and only put the contents of the ERT inset out

  I don't want to assume that, as there cases where one or the other are 
valid choices. And to ignore Empty will only imply a load of hacks to fix all 
those particular cases. Not nice.

> >   I intend to provide better documentation so that the users are not
> > taken by surprise with this behaviour. What is my problem then?
>
> Which user will read documentation, before he is surprised! :O)

  That is my point, the users will find that the documentation warns against 
that case, and ashamed will not complain. ;-)

> >   Inside tables I would like to be able to select between Standard and
> > Empty, and by default I would like to have Empty.
>
> See above!

  I want really, really, really to have an Empty layout.

> >   So I would like to have that choice. Is that to ask too much? ;-)
>
> Yes, you always ask too much ;)

  Who? Me? ;-)

> >   Not enlightment, only troubles. :-)
>
> Well I hope I confused you completely now ;)

  So it seems that we are only ones not confused. ;-)

> Jug

--
José Abílio

Re: dummy layout and how to get it!

[Jose Abilio Oliveira Matos]

On Thursday 17 January 2002 16:07, Juergen Vigna wrote:
> On 17-Jan-2002 Jose Abilio Oliveira Matos wrote:
> >   I hope you enjoy it. :-)
>
> Well you know we'll visit parents in Argentina and IMO you all follow the
> news there. So I only hope it will not be too caotic.

  I hope not.

> The problem with this is that I mean that "Standard" is a paragraph on
> which I don't have to put any special layout. I agree that this can/should
> be done with a logical value in the layout files and we should neighter
> rely on the name nor on the number!

  Ok.

> >   The question is that we should be able to choose the layout I want to
> > in each cell.  Imagine that I want an itemized list inside a table, what
> > is the problem with it? I should be able to do it.
>
> Well the problem with your aprach is that you want to tell LyX create this
> table with "Empty" layouts and this is an even greater hack IMO then the
> one used for export. IMO you anyway need this for the single insets.

  No, I would like to be able to select Empty por all cells if I selected 
them. Now if I do that only the cell where the cursor is gets changed. I 
don't want for now lyx to do it for me.

> Well we could have logical values in the layout-files "use_this_layout_as_
> default_layout_for_tabular_cells" but I think that is really not nice as
> after tabular cells you want something special for minipages, then for...
> and we would have to change layout files and user would have to chage their
> layout files and so on. So IMO this type of special handling for DocBook
> should be buildin as it is not going to change, isn't it? And it has to be
> handled for any inset specially.

  No, not like that, I would like to change the layout style easily as I do 
if I select multiple paragraphs. Is this clear now? :-)

> >   Does latex allows lists inside table cells?
>
> Sure if the cell has a fixed lenght!

  If the table doesn't have a fixed lenght then lyx doesn't allow the layout 
change. Am I guessing correctly?

> >   I don't want to assume that, as there cases where one or the other are
> > valid choices. And to ignore Empty will only imply a load of hacks to fix
> > all those particular cases. Not nice.
>
> What choices?

  What I say is that sometimes depending on context, you want Standard or 
Empty, it is up to the user the correct choice not to LyX.

> >   I want really, really, really to have an Empty layout.
>
> The problem here is not to have an Empty-Layout and it's handling inside
> LyX, the problem is that you want that in certain circumstaces we use that
> Layout to create a Paragraph and not as we do till now only "Standard",
> that is what I don't like in your proposal.

  The point is that this "Paragraph" here means a lyx-paragraph and not a 
document paragraph. For lyx we all know what paragraphs are, for docbook a 
paragraph is a block element, that can have lots of things inside. From the 
"Docbook: The Definitive Guide"
"""
Description

A Para is a paragraph. Paragraphs in DocBook may contain almost all inlines 
and most block elements. Sectioning and higher-level structural elements are 
excluded.
"""

  My point is that sometimes lyx-paragraphs are different from 
docbook-paragraphs. This was always a problems, that become worse now with 
all the power of InsetText (that I really like).

  For example, in linuxdoc there is a special code to deal with the case of 
the toc inset to be the first element of a paragraph, in that case the 
paragraph is ignored.

  It is code like that I don't want to add to docbook, I don't want lots of 
special cases, I just want a fast way to change the paragraph layout if 
necessary.

> >   So it seems that we are only ones not confused. ;-)
>
> #:O) well you know as it was in the last meeting the southern europe won
>  the games (on the tablefootball ;)

  What would you expect, Portugal is in 4th place in the FIFA rank (Ok, 
Jean-Marc France is first) :-)

> Jug

-- 
José Abílio

Re: dummy layout and how to get it!

[Jose Abilio Oliveira Matos]

On Tuesday 08 January 2002 11:11, Juergen Vigna wrote:
 And one other question couldn't we just have Standard layout defaulting
 to layout-no == 0? This would simplify things (when for example I want to
 force Standard layout on a paragraph how can I do this now?) IMO.

  I'm glad that you ask this although you will be soon on vacations.

  I have been fixing some bugs related with docbook that Ben G. sent me, some 
months ago. Ben, I promisse that they will be all fixed before 1.2 (more or 
less :-).

 Also Standard should IMO be forced to be in all possible textclasses at
 least I cannot see a textclass without default paragraph textclass (I
 call it 'Standard' but it name could be another in some other textclasses I
 just don't care about the name it HAS to be no == 0). We could do this by
 forcing a Default Layout in the textclasses. But well we don't have this
 now but I have to force a Standard layout on all paragraphs inside
 normal tabular cells (without width!).

  Between the lyx-latex and lyx-docbook there are lots of common stuff, but 
the one where we differ the most is with Standard layout style.

  For latex Standard can have two different meanings. Sometimes it acts as a 
paragraph, and sometimes as a place to put latex code. That is one of the 
reason why Allan is always worried about the possibility that an extra 
newline is inserted. ;-) Where in docbook that is a non-issue.

  For docbook I have attributed to Standard its usual role and that is 
paragraph - para/para

  For the other role I created another layout style that I'm tempted to call 
Empty. Initially I thought of it as SGML, the equivalent of Latex, but as 
Lars noted it doesn't make sense to have several ways to do the same thing.
This means that Empty != SGML, if you want the old SGML, you should use 
Empty+ERT.

  Using Juergen's notation Empty is my dummy paragraph.

  The question is that there isn't any method to distinguish between the two 
roles for Standard. All the possible solutions involve some hacks that aren't 
worth it. One of the possible solutions that I have discussed with Jean-Marc 
regarding the inset include involved to have elements that would appear 
outside a paragraph... that would solve partially that case but would leave 
all the others, where Empty is the alternative.

  So I propose to split this two different meanings in docbook, Standard and 
Empty for those different purposes.

  I intend to provide better documentation so that the users are not taken by 
surprise with this behaviour. What is my problem then?

  Inside tables I would like to be able to select between Standard and Empty, 
and by default I would like to have Empty.

  So I would like to have that choice. Is that to ask too much? ;-)

 Please give me enlightment!

  Not enlightment, only troubles. :-)

   Jug

  I know that my writing is confuse sometimes, but I would like to hear from 
you all.

--
José Abílio

Re: dummy layout and how to get it!

[Jose Abilio Oliveira Matos]

On Tuesday 08 January 2002 11:11, Juergen Vigna wrote:
> And one other question couldn't we just have "Standard" layout defaulting
> to layout-no == 0? This would simplify things (when for example I want to
> force Standard layout on a paragraph how can I do this now?) IMO.

  I'm glad that you ask this although you will be soon on vacations.

  I have been fixing some bugs related with docbook that Ben G. sent me, some 
months ago. Ben, I promisse that they will be all fixed before 1.2 (more or 
less :-).

> Also Standard should IMO be forced to be in all possible textclasses at
> least I cannot see a textclass without "default" paragraph textclass (I
> call it 'Standard' but it name could be another in some other textclasses I
> just don't care about the name it HAS to be no == 0). We could do this by
> forcing a "Default Layout" in the textclasses. But well we don't have this
> now but I have to "force" a "Standard" layout on all paragraphs inside
> "normal" tabular cells (without width!).

  Between the lyx-latex and lyx-docbook there are lots of common stuff, but 
the one where we differ the most is with Standard layout style.

  For latex Standard can have two different meanings. Sometimes it acts as a 
paragraph, and sometimes as a place to put latex code. That is one of the 
reason why Allan is always worried about the possibility that an extra 
newline is inserted. ;-) Where in docbook that is a non-issue.

  For docbook I have attributed to Standard its usual role and that is 
paragraph -> 

  For the other role I created another layout style that I'm tempted to call 
Empty. Initially I thought of it as SGML, the equivalent of Latex, but as 
Lars noted it doesn't make sense to have several ways to do the same thing.
This means that Empty != SGML, if you want the old SGML, you should use 
Empty+ERT.

  Using Juergen's notation Empty is my dummy paragraph.

  The question is that there isn't any method to distinguish between the two 
roles for Standard. All the possible solutions involve some hacks that aren't 
worth it. One of the possible solutions that I have discussed with Jean-Marc 
regarding the inset include involved to have elements that would appear 
outside a paragraph... that would solve partially that case but would leave 
all the others, where Empty is the alternative.

  So I propose to split this two different meanings in docbook, Standard and 
Empty for those different purposes.

  I intend to provide better documentation so that the users are not taken by 
surprise with this behaviour. What is my problem then?

  Inside tables I would like to be able to select between Standard and Empty, 
and by default I would like to have Empty.

  So I would like to have that choice. Is that to ask too much? ;-)

> Please give me enlightment!

  Not enlightment, only troubles. :-)

>   Jug

  I know that my writing is confuse sometimes, but I would like to hear from 
you all.

--
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 09:24, Angus Leeming wrote:
[...]
 Morning, José. Try with $LYX_XFONTS as an absolute directory path. Does
 that make a difference?

  Nope.
  I have tried a little further and using xset -q I noticed that 
~/.kde/share/fonts belongs to the font path. since the directory was empty I 
applied the script there, so I skipped the xset +fp part but then I have the 
same error with xset fp rehash.

 Angus (who's seen something similar in the past!)

-- 
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 13:28, Dekel Tsur wrote:

 What is your OS/X-server ?

  Red Hat 7.2/ the xfs that comes with that version.

 Did you use 'xset +fp' before ?

  No.

-- 
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 13:53, Jose Abilio Oliveira Matos wrote:
 On Tuesday 15 January 2002 13:28, Dekel Tsur wrote:
  What is your OS/X-server ?

   Red Hat 7.2/ the xfs that comes with that version.

  xfs is obviously the font server.

Regarding the X-server:
$rpm -qi XFree86
Name: XFree86  Relocations: (not relocateable)
Version : 4.1.0 Vendor: Red Hat, Inc.
Release : 3 Build Date: Thu 06 Sep 2001 
05:28:14 AM WEST

-- 
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 13:31, Angus Leeming wrote:

 From the xset man page
  +fp or fp+
   The +fp and fp+ options prepend and append elements to the current
 font path, respectively.  They must be followed by a comma-separated list
 of entries.  The entire font path must be valid; if any element is invalid,
 the path is rejected.

  fp rehash
   The rehash argument resets the font path to its current value,
 causing the server to reread the font databases in the current font path. 
 This is generally only used when adding new fonts to a font directory
 (after running mkfontdir to recreate the font database).

  I have read it.

 So it sounds like something in your font path is bogus. Why not run
   xset fp default
 and then
   xset +fp /absolute_path_to/lyx_xfonts_dir

 Do you still get the error?

  I have tried it and I get the same error:

 Here is what is in my .lyx/xfonts directory:
 aleem@pneumon:aleem- ls ~/.lyx/xfonts
 cmex10.pfb@cmsy10.pfb@fonts.dir  logobf10.pfb@  msbm10.pfb@
 cmmi10.pfb@eufb10.pfb@fonts.scalemarvosym.pfb@  wasy10.pfb@
 cmr10.pfb@ eusb10.pfb@logo10.pfb@msam10.pfb@wasyb10.pfb@

[14:01][jamatos@novalis:~/.kde/share/fonts]$ls -F
cmex10.pfb@  eufb10.pfb@  fonts.scalemarvosym.pfb@  override/
cmmi10.pfb@  eusb10.pfb@  logo10.pfb@msam10.pfb@wasy10.pfb@
cmsy10.pfb@  fonts.dirlogobf10.pfb@  msbm10.pfb@wasyb10.pfb@

 It transpires that the fonts.dir you've created may be incorrect (see
 earlier thread with Dekel, the other day or so). Here's the diff between my
 (corrected) fonts.dir and the original fonts.scale. Note that you'll need
 another symlink too (cmr10.pfb) This correction allows you to see math
 greek in italic and correctly displays things like \Longrightarrow

 --- /usr/users/aleem/.lyx/xfonts/fonts.scaleWed Sep  5 16:02:29 2001
 +++ /usr/users/aleem/.lyx/xfonts/fonts.dir  Wed Jan  9 14:30:31 2002
 @@ -1,5 +1,6 @@
 -12
 -cmmi10.pfb -bluesky-cmr-medium-i-normal--0-0-0-0-p-0-adobe-fontspecific
 +13
 +  cmr10.pfb -bluesky-cmr-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
 +  cmmi10.pfb -bluesky-cmmi-medium-i-normal--0-0-0-0-m-0-adobe-fontspecific
  cmsy10.pfb -bluesky-cmsy-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
  cmex10.pfb -bluesky-cmex-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
  eufb10.pfb -bluesky-eufrak-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific

  I got the same result as you, and I have applied the patch, but again the 
error remains. :(

 Incidentally, I shoved this little snippet in my .xsession file. You too
 might find it useful?

  Certainly it is, thanks.
[script]

 Angus

-- 
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 16:29, Angus Leeming wrote:
Notice that I had the same problem as Angus.
 
Thanks Dekel and Angus, now it looks really neat. :-)

 José, I've just improved mathed.lyx so that the fonts-xlfd file how
 contains the right fonts. Perhaps you'd throw in a few lines about what you
 had to do to get things working under redhat?

  Basically I had allowed the support for Type 1 fonts.
  But I will put there a line warning about it at the beginning.

 Angus

-- 
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 09:24, Angus Leeming wrote:
[...]
> Morning, José. Try with $LYX_XFONTS as an absolute directory path. Does
> that make a difference?

  Nope.
  I have tried a little further and using xset -q I noticed that 
~/.kde/share/fonts belongs to the font path. since the directory was empty I 
applied the script there, so I skipped the xset +fp part but then I have the 
same error with xset fp rehash.

> Angus (who's seen something similar in the past!)

-- 
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 13:28, Dekel Tsur wrote:
>
> What is your OS/X-server ?

  Red Hat 7.2/ the xfs that comes with that version.

> Did you use 'xset +fp' before ?

  No.

-- 
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 13:53, Jose Abilio Oliveira Matos wrote:
> On Tuesday 15 January 2002 13:28, Dekel Tsur wrote:
> > What is your OS/X-server ?
>
>   Red Hat 7.2/ the xfs that comes with that version.

  xfs is obviously the font server.

Regarding the X-server:
$rpm -qi XFree86
Name: XFree86  Relocations: (not relocateable)
Version : 4.1.0 Vendor: Red Hat, Inc.
Release : 3 Build Date: Thu 06 Sep 2001 
05:28:14 AM WEST

-- 
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 13:31, Angus Leeming wrote:

> From the xset man page
>  +fp or fp+
>   The +fp and fp+ options prepend and append elements to the current
> font path, respectively.  They must be followed by a comma-separated list
> of entries.  The entire font path must be valid; if any element is invalid,
> the path is rejected.
>
>  fp rehash
>   The rehash argument resets the font path to its current value,
> causing the server to reread the font databases in the current font path. 
> This is generally only used when adding new fonts to a font directory
> (after running mkfontdir to recreate the font database).

  I have read it.

> So it sounds like something in your font path is bogus. Why not run
>   xset fp default
> and then
>   xset +fp /absolute_path_to/lyx_xfonts_dir
>
> Do you still get the error?

  I have tried it and I get the same error:

> Here is what is in my .lyx/xfonts directory:
> aleem@pneumon:aleem-> ls ~/.lyx/xfonts
> cmex10.pfb@cmsy10.pfb@fonts.dir  logobf10.pfb@  msbm10.pfb@
> cmmi10.pfb@eufb10.pfb@fonts.scalemarvosym.pfb@  wasy10.pfb@
> cmr10.pfb@ eusb10.pfb@logo10.pfb@msam10.pfb@wasyb10.pfb@

[14:01][jamatos@novalis:~/.kde/share/fonts]$ls -F
cmex10.pfb@  eufb10.pfb@  fonts.scalemarvosym.pfb@  override/
cmmi10.pfb@  eusb10.pfb@  logo10.pfb@msam10.pfb@wasy10.pfb@
cmsy10.pfb@  fonts.dirlogobf10.pfb@  msbm10.pfb@wasyb10.pfb@

> It transpires that the fonts.dir you've created may be incorrect (see
> earlier thread with Dekel, the other day or so). Here's the diff between my
> (corrected) fonts.dir and the original fonts.scale. Note that you'll need
> another symlink too (cmr10.pfb) This correction allows you to see math
> greek in italic and correctly displays things like \Longrightarrow
>
> --- /usr/users/aleem/.lyx/xfonts/fonts.scaleWed Sep  5 16:02:29 2001
> +++ /usr/users/aleem/.lyx/xfonts/fonts.dir  Wed Jan  9 14:30:31 2002
> @@ -1,5 +1,6 @@
> -12
> -cmmi10.pfb -bluesky-cmr-medium-i-normal--0-0-0-0-p-0-adobe-fontspecific
> +13
> +  cmr10.pfb -bluesky-cmr-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
> +  cmmi10.pfb -bluesky-cmmi-medium-i-normal--0-0-0-0-m-0-adobe-fontspecific
>  cmsy10.pfb -bluesky-cmsy-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
>  cmex10.pfb -bluesky-cmex-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
>  eufb10.pfb -bluesky-eufrak-bold-r-normal--0-0-0-0-p-0-adobe-fontspecific

  I got the same result as you, and I have applied the patch, but again the 
error remains. :(

> Incidentally, I shoved this little snippet in my .xsession file. You too
> might find it useful?

  Certainly it is, thanks.
[script]

> Angus

-- 
José Abílio

Re: lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

On Tuesday 15 January 2002 16:29, Angus Leeming wrote:
> >   Notice that I had the same problem as Angus.
> >
> >   Thanks Dekel and Angus, now it looks really neat. :-)
>
> José, I've just improved mathed.lyx so that the fonts-xlfd file how
> contains the right fonts. Perhaps you'd throw in a few lines about what you
> had to do to get things working under redhat?

  Basically I had allowed the support for Type 1 fonts.
  But I will put there a line warning about it at the beginning.

> Angus

-- 
José Abílio

lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

When I follow the instructions in mathed.lyx I always get an error when I 
call xset:

xset +fp $LYX_XFONTS
X Error of failed request:  86
  Major opcode of failed request:  51 (X_SetFontPath)
  Serial number of failed request:  9
  Current serial number in output stream:  11

  Since the script runs without much fuss, saying which fonts are found, and 
the symbolic links are correct what could be the problem?

  Thanks.
-- 
José Abílio

lib/examples/mathed.lyx

[Jose Abilio Oliveira Matos]

When I follow the instructions in mathed.lyx I always get an error when I 
call xset:

xset +fp $LYX_XFONTS
X Error of failed request:  86
  Major opcode of failed request:  51 (X_SetFontPath)
  Serial number of failed request:  9
  Current serial number in output stream:  11

  Since the script runs without much fuss, saying which fonts are found, and 
the symbolic links are correct what could be the problem?

  Thanks.
-- 
José Abílio

Re: Undo leaking

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 11:09:35AM +0100, Juergen Vigna wrote:

 I think that the docbook export should be done as the LaTeX one and that
 is in the paragraph  buffer. Have a look how I made the LaTeX code work.
 IMO a similar aproch should be done for all InsetText export code in ANY
 format. So we don't have code duplication. You can always see if a paragraph
 is inside an inset by looking at it's inset_owner (if you need that).

  This wasn't possible in 1.1.6. Was it?
  Ok, thanks for the idea. It is much better now, but even so...
  
  There is too much code trying to get all the cases, but it looks
better than before.

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
 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
 
 The perfect lover is one who turns into a pizza at 4:00 A.M.
 -- Charles Pierce

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)

Re: Undo & leaking

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 11:09:35AM +0100, Juergen Vigna wrote:

> I think that the docbook export should be done as the LaTeX one and that
> is in the paragraph & buffer. Have a look how I made the LaTeX code work.
> IMO a similar aproch should be done for all InsetText export code in ANY
> format. So we don't have code duplication. You can always see if a paragraph
> is inside an inset by looking at it's inset_owner (if you need that).

  This wasn't possible in 1.1.6. Was it?
  Ok, thanks for the idea. It is much better now, but even so...
  
  There is too much code trying to get all the cases, but it looks
better than before.

>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
> -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
> 
> The perfect lover is one who turns into a pizza at 4:00 A.M.
> -- Charles Pierce

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)

Re: Undo leaking

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 09:15:19AM +0100, Jean-Marc Lasgouttes wrote:
  Ben == Ben Stanley [EMAIL PROTECTED] writes:
 
 Ben But, als while we are at it, can someone explain to me why a
 Ben Paragraph is not some kind of Inset? I suppose it's historical...
 
 An inset is something one can insert in a paragraph. You can't insert
 a paragraph in a paragraph directly, and you don't want in general to
 insert directly an inset in a document (without enclosing paragraph).
 
 That's only my view of things. I think Lars disagress (at least at
 times).

  That distintion comes is becoming more and more arbitrary, as we
have now insets that can include paragraphs, that can include insets
that can include paragraphs.

  So you mean that insets can't be top level elements. That is
discrimination, and I as a self-proclaimed president of the
Assotiation for Free Insets demand you to retreat those words. If not
all the insets that you have in your document will start a strike
starting today at 12h GMT, until you recognise its rights.

  You have been warned!
  
  On a less serious note the code for docbook generation in insettext,
line 1407, is almost the same as the code for global docbook generation
in buffer.C, line 3038, with the only exception that I don't expect
command type paragraphs inside insets. ( For docbook-lyx command means
belonging to the hierarquical document structure: chapter, sections,
parts, ...).

  Or maybe that's me.  What do you think of this?
  
 JMarc

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)
The above smile is not valid on fridays, ignore it today!

Re: Undo leaking

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 09:44:09AM +0100, Jean-Marc Lasgouttes wrote:
 
 So you will be able to insert a paragraph in a paragraph. How will
 that look like? You need some kind of wrapper around it, and it's
 called an inset nowadays. 

  Imagine a section inside a chapter. Why not.
  
  The you want to fold that chapter, and voilá, it is automatic as we
have now for ert inset. You view it inlined, or collapsed.

  Or is there any other objection?
  
 I am not saying these should be completely different. Maybe they
 should both inherit from a common base. But I think they are
 conceptually different things.

  Why?
  
[...]

 JMarc

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)

Paragraphs inside ert, don't change style.

[Jose Abilio Oliveira Matos]

Hi,
   If I copy some text outside ERT and paste it inside, then I can't
change the paragraph styles inside ert. The styles that are shown are
the same the I had before.

  This haappens both using the menu or the keystrokes.
  
  To change it again I need to do those operations outside.
  
  Is this known?
  
-- 
José Abílio

Crash exporting, from command line, documents with new graphics

[Jose Abilio Oliveira Matos]

When I try to export some document from the command line it crashes
with the following output:

$~/lyx/lyx-devel/src/lyx --export docbook master.lyx
About to handle -x 'buffer-export docbook'
imageConverted, conversion succeeded.
Loading XPM Image...
lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help-Introduction and send us a bug report, if
necessary. Thanks !
Bye.
Aborted

  If I export it to docbook inside lyx, then no problem. The output is
correct.

  I will add it to bugzilla if not known.
  
-- 
José Abílio

Re: Paragraphs inside ert, don't change style.

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 09:26:08AM +, John Levon wrote:
 
 what do you mean by style ?

  read style as layout.

 You should only be allowed standard normal text inside ert ...

  Makes sense, but then the layout should be automatically changed to
standard and not left as it is.

 regards
 john
 
 -- 
 Of all manifestations of power, restraint impresses the most.
   - Thucydides

-- 
José Abílio Matos
LyX and docbook a perfect match.

Re: Crash exporting, from command line, documents with new graphics

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 09:56:50AM +, John Levon wrote:

I will add it to bugzilla if not known.
 
 please do, and make it bug 53 depend on your bug please

  done.
  
 regards
 john
 
 -- 
 Of all manifestations of power, restraint impresses the most.
   - Thucydides

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)

Re: Paragraphs inside ert, don't change style.

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 06:21:36AM -0400, Garst R. Reese wrote:
  
 And don't assume that Standard means the first style. This may be the
 same problem I reported with the hollywood layout, where the first style
 is Dialogue, and my ERT's ended up with that style.

  Yep. That is hardocoded in several places.
  
  One examples is when inserting the include inset. It always reverts
the layout to the first layout. If it is not Standard...

 Garst

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)

Re: Paragraphs inside ert, don't change style.

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 11:07:40AM +, Jose Abilio Oliveira Matos wrote:
   
   One examples is when inserting the include inset. It always reverts
 the layout to the first layout. If it is not Standard...

  Oops, spoke too soon.
  In the Insert menu, the TeX and Insert File entries have the same
key assigned_ t. This should be easy to fix.

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)

Re: Undo & leaking

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 09:15:19AM +0100, Jean-Marc Lasgouttes wrote:
> > "Ben" == Ben Stanley <[EMAIL PROTECTED]> writes:
> 
> Ben> But, als while we are at it, can someone explain to me why a
> Ben> Paragraph is not some kind of Inset? I suppose it's historical...
> 
> An inset is something one can insert in a paragraph. You can't insert
> a paragraph in a paragraph directly, and you don't want in general to
> insert directly an inset in a document (without enclosing paragraph).
> 
> That's only my view of things. I think Lars disagress (at least at
> times).

  That distintion comes is becoming more and more arbitrary, as we
have now insets that can include paragraphs, that can include insets
that can include paragraphs.

  So you mean that insets can't be top level elements. That is
discrimination, and I as a self-proclaimed president of the
Assotiation for Free Insets demand you to retreat those words. If not
all the insets that you have in your document will start a strike
starting today at 12h GMT, until you recognise its rights.

  You have been warned!
  
  On a less serious note the code for docbook generation in insettext,
line 1407, is almost the same as the code for global docbook generation
in buffer.C, line 3038, with the only exception that I don't expect
command type paragraphs inside insets. ( For docbook-lyx command means
belonging to the hierarquical document structure: chapter, sections,
parts, ...).

  Or maybe that's me.  What do you think of this?
  
> JMarc

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)
The above smile is not valid on fridays, ignore it today!

Re: Undo & leaking

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 09:44:09AM +0100, Jean-Marc Lasgouttes wrote:
> 
> So you will be able to insert a paragraph in a paragraph. How will
> that look like? You need some kind of wrapper around it, and it's
> called an inset nowadays. 

  Imagine a section inside a chapter. Why not.
  
  The you want to fold that chapter, and voilá, it is automatic as we
have now for ert inset. You view it inlined, or collapsed.

  Or is there any other objection?
  
> I am not saying these should be completely different. Maybe they
> should both inherit from a common base. But I think they are
> conceptually different things.

  Why?
  
[...]

> JMarc

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)

Paragraphs inside ert, don't change style.

[Jose Abilio Oliveira Matos]

Hi,
   If I copy some text outside ERT and paste it inside, then I can't
change the paragraph styles inside ert. The styles that are shown are
the same the I had before.

  This haappens both using the menu or the keystrokes.
  
  To change it again I need to do those operations outside.
  
  Is this known?
  
-- 
José Abílio

Crash exporting, from command line, documents with new graphics

[Jose Abilio Oliveira Matos]

When I try to export some document from the command line it crashes
with the following output:

$~/lyx/lyx-devel/src/lyx --export docbook master.lyx
About to handle -x 'buffer-export docbook'
imageConverted, conversion succeeded.
Loading XPM Image...
lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help->Introduction and send us a bug report, if
necessary. Thanks !
Bye.
Aborted

  If I export it to docbook inside lyx, then no problem. The output is
correct.

  I will add it to bugzilla if not known.
  
-- 
José Abílio

Re: Paragraphs inside ert, don't change style.

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 09:26:08AM +, John Levon wrote:
> 
> what do you mean by "style" ?

  read "style" as layout.

> You should only be allowed standard normal text inside ert ...

  Makes sense, but then the layout should be automatically changed to
standard and not left as it is.

> regards
> john
> 
> -- 
> "Of all manifestations of power, restraint impresses the most."
>   - Thucydides

-- 
José Abílio Matos
LyX and docbook a perfect match.

Re: Crash exporting, from command line, documents with new graphics

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 09:56:50AM +, John Levon wrote:

> >   I will add it to bugzilla if not known.
> 
> please do, and make it bug 53 depend on your bug please

  done.
  
> regards
> john
> 
> -- 
> "Of all manifestations of power, restraint impresses the most."
>   - Thucydides

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)

Re: Paragraphs inside ert, don't change style.

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 06:21:36AM -0400, Garst R. Reese wrote:
> > 
> And don't assume that Standard means the first style. This may be the
> same problem I reported with the hollywood layout, where the first style
> is Dialogue, and my ERT's ended up with that style.

  Yep. That is hardocoded in several places.
  
  One examples is when inserting the include inset. It always reverts
the layout to the first layout. If it is not Standard...

> Garst

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)

Re: Paragraphs inside ert, don't change style.

[Jose Abilio Oliveira Matos]

On Fri, Dec 14, 2001 at 11:07:40AM +, Jose Abilio Oliveira Matos wrote:
>   
>   One examples is when inserting the include inset. It always reverts
> the layout to the first layout. If it is not Standard...

  Oops, spoke too soon.
  In the Insert menu, the TeX and Insert File entries have the same
key assigned_ t. This should be easy to fix.

-- 
José Abílio Matos
LyX and docbook a perfect match. :-)