Re: Bug in export to DocBook
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> On Monday 15 January 2007 9:08:42 am Jean-Marc Lasgouttes wrote: >> Yes, go ahead. José> Done. I have add a reference to status.14x with the respective José> bug number. Thanks. JMarc
Re: Bug in export to DocBook
On Monday 15 January 2007 9:08:42 am Jean-Marc Lasgouttes wrote: > > Yes, go ahead. Done. I have add a reference to status.14x with the respective bug number. > JMarc -- José Abílio
Re: Bug in export to DocBook
On Monday 15 January 2007 6:29:14 am Harshula wrote: > > > > I am sorry for taking so long. :-) > > No probs. It seems that I need 2 weeks for each reply. ;-) > > This patch is right, I don't know why I did not think of it right at > > the time I have implemented the new scheme. So I have returned to the > > place where I coded it to guarantee the same initial conditions... ;-) > > Physically or Psychologically? :-) Both, probably. :-) I was in the same place in Dublin where I wrote the original code. :-) > > My I ask you for a permission to include your code into LyX? > > One example can be found here: > > http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg106786.html > > I (Harshula Jayasuriya) hereby grant permission to licence my > contributions to LyX under the Gnu General Public Licence, version 2 or > later > > > I will apply it to 1.5.0. > > > > Jean-Marc may I apply this to 1.4.x? It closes one bugzilla entry. :-) > > BTW, What's the bugzilla number? Please do apply it to both. Then I > don't have to keep a patched build of Lyx 1.4.3. ;-) http://bugzilla.lyx.org/show_bug.cgi?id=2841 I have applied the fix to both 1.4.4 and 1.5.0svn. > cya, > # Thank you for your contribution and do not hesitate reporting bugs (and fixes ;-) ). Regards, -- José Abílio
Re: Bug in export to DocBook
> "jamatos" == jamatos <[EMAIL PROTECTED]> writes: jamatos> Jean-Marc may I apply this to 1.4.x? It closes one bugzilla jamatos> entry. :-) Yes, go ahead. JMarc
Re: Bug in export to DocBook
On Sun, 2007-01-14 at 23:34 +, [EMAIL PROTECTED] wrote: > Quoting Harshula <[EMAIL PROTECTED]>: > > Hi, > > > > Problem > > === > > > > When exporting a DocBook LyX document to a DocBook SGML/XML file there's > > a problem with the generation of tags. When a sub list > > (embedded list) is present, Lyx opens a new tag for the sub > > list after closing the already open tag instead of including the sub > > list within the already open . > > > > The problem first appeared around April 2006 when I started using Lyx > > 1.4.x and moved from lyxformat 221 to lyxformat 245. I only got a chance > > to debug the issue last week. > > > > LinuxDoc export does not have the same issue, because it doesn't close > > tags. > > I am sorry for taking so long. :-) No probs. > This patch is right, I don't know why I did not think of it right at the > time > I have implemented the new scheme. So I have returned to the place where I > coded it to guarantee the same initial conditions... ;-) Physically or Psychologically? :-) > My I ask you for a permission to include your code into LyX? > One example can be found here: > http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg106786.html I (Harshula Jayasuriya) hereby grant permission to licence my contributions to LyX under the Gnu General Public Licence, version 2 or later > I will apply it to 1.5.0. > > Jean-Marc may I apply this to 1.4.x? It closes one bugzilla entry. :-) BTW, What's the bugzilla number? Please do apply it to both. Then I don't have to keep a patched build of Lyx 1.4.3. ;-) cya, #
Re: Bug in export to DocBook
Quoting Harshula <[EMAIL PROTECTED]>: Hi, Problem === When exporting a DocBook LyX document to a DocBook SGML/XML file there's a problem with the generation of tags. When a sub list (embedded list) is present, Lyx opens a new tag for the sub list after closing the already open tag instead of including the sub list within the already open . The problem first appeared around April 2006 when I started using Lyx 1.4.x and moved from lyxformat 221 to lyxformat 245. I only got a chance to debug the issue last week. LinuxDoc export does not have the same issue, because it doesn't close tags. I am sorry for taking so long. :-) This patch is right, I don't know why I did not think of it right at the time I have implemented the new scheme. So I have returned to the place where I coded it to guarantee the same initial conditions... ;-) My I ask you for a permission to include your code into LyX? One example can be found here: http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg106786.html I will apply it to 1.5.0. Jean-Marc may I apply this to 1.4.x? It closes one bugzilla entry. :-) cya, # Regards, -- José Abílio - A FCUP utiliza o sistema de webmail Horde/IMP (www.horde.org) Visite: http://www.fc.up.pt/
Re: Bug in export to DocBook
On Monday 01 January 2007 5:02 pm, Harshula wrote: > Hi, > > Problem > === > > When exporting a DocBook LyX document to a DocBook SGML/XML file there's > a problem with the generation of tags. When a sub list > (embedded list) is present, Lyx opens a new tag for the sub > list after closing the already open tag instead of including the sub > list within the already open . > > The problem first appeared around April 2006 when I started using Lyx > 1.4.x and moved from lyxformat 221 to lyxformat 245. I only got a chance > to debug the issue last week. Thanks for looking into the problem, I will have a look into the patch tomorrow. :-) Now that the festivities are over I will have more "free time". ;-) Jean-Marc if this patch is correct may I commit it to 1.4.4? > LinuxDoc export does not have the same issue, because it doesn't close > tags. True, that was a specification of linuxdoc. -- José Abílio
Bug in export to DocBook
Hi,
Problem
===
When exporting a DocBook LyX document to a DocBook SGML/XML file there's
a problem with the generation of tags. When a sub list
(embedded list) is present, Lyx opens a new tag for the sub
list after closing the already open tag instead of including the sub
list within the already open .
The problem first appeared around April 2006 when I started using Lyx
1.4.x and moved from lyxformat 221 to lyxformat 245. I only got a chance
to debug the issue last week.
LinuxDoc export does not have the same issue, because it doesn't close
tags.
Patch
=
lyx-1.4.3-docbook-list.patch
The problem is in file: src/output_docbook.C
function: ParagraphList::const_iterator makeEnvironment()
NOTE: The 'break' statement was added only because it made debugging
easier.
Testing
===
* Testcase: testcase-docbook-list.lyx
* Incorrect output: testcase-docbook-list.incorrect.sgml
* Correct output: testcase-docbook-list.correct.sgml
NOTE: 4 files attached.
cya,
#
]>
Depth One Item OneDepth One Item Two
Depth Two Item OneDepth Two Item TwoDepth One Item Three
]>
Depth One Item OneDepth One Item Two
Depth Two Item OneDepth Two Item TwoDepth One Item Three
testcase-docbook-list.lyx
Description: application/lyx
diff -ru lyx-1.4.3.orig/src/output_docbook.C lyx-1.4.3/src/output_docbook.C
--- lyx-1.4.3.orig/src/output_docbook.C 2006-03-24 23:37:15.0 +0600
+++ lyx-1.4.3/src/output_docbook.C 2007-01-01 22:07:38.0 +0530
@@ -160,7 +160,13 @@
sgml::closeTag(os, bstyle->labeltag());
}
wrapper = defaultstyle->latexname();
- sgml::openTag(os, bstyle->itemtag());
+ // If a sub list (embedded list) appears next with a
+ // different depth, then there is no need to open
+ // another tag at the current depth.
+ if(par->params().depth() == pbegin->params().depth()) {
+sgml::openTag(os, bstyle->itemtag());
+ }
+ break;
default:
break;
}
@@ -197,7 +203,17 @@
}
break;
case LATEX_ITEM_ENVIRONMENT:
- sgml::closeTag(os, bstyle->itemtag());
+ // If a sub list (embedded list) appears next, then
+ // there is no need to close the current tag.
+ // par should have already been incremented to the next
+ // element. So we can compare the depth of the next
+ // element with pbegin.
+ // We need to be careful, that we don't dereference par
+ // when par == pend but at the same time that the
+ // current tag is closed.
+ if((par != pend && par->params().depth() == pbegin->params().depth()) || par == pend) {
+sgml::closeTag(os, bstyle->itemtag());
+ }
if (!bstyle->labeltag().empty())
sgml::closeTag(os, bstyle->innertag());
break;
