Menu
▾
▴
db2latex-devel — DB2LaTeX Developers' mailing list.
You can subscribe to this list here.
| 2003 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(13) |
May
(9) |
Jun
(7) |
Jul
(13) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(15) |
May
(4) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <je...@ki...> - 2007-06-28 23:45:02
|
Hi, The following error occurs with file given below. The file is a trimmed down version of a db2latex sample file (test_book). The following link suggests to me that the xsl:param is now incorrect (towards the bottom of the bug report). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401337 -jeff ................................... error ....................................... ################################################################################ XSLT stylesheets DocBook - LaTeX 2e Reqs: LaTeX 2e installation common packages ################################################################################ RELEASE : 0.8pre1 VERSION : $Id: VERSION.xml,v 1.6 2004/01/31 12:47:11 j-devenish Exp $ TAG : DB2LATEX_0_8PRE1 WWW : http://db2latex.sourceforge.net SUMMARY : http://www.sourceforge.net/projects/db2latex AUTHOR : Ramon Casellas cas...@in... AUTHOR : James Devenish j-d...@us... USING : libxslt/xsltproc ################################################################################ runtime error: file /usr/share/xml/docbook/stylesheet/db2latex/latex/lists.mod.xsl line 273 element param Unexpected XSLT element 'param'. runtime error: file /usr/share/xml/docbook/stylesheet/db2latex/latex/lists.mod.xsl line 274 element value-of Variable 'object' has not been declared. xmlXPathCompOpEval: parameter error xmlXPathCompiledEval: evaluation failed runtime error: file /usr/share/xml/docbook/stylesheet/db2latex/latex/lists.mod.xsl line 274 element value-of XPath evaluation returned no result. ................................... xml file ....................................... <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE book SYSTEM "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> <book id="book" lang="en" status="draft"> <bookinfo> <title>Thèses et Thésards</title> </bookinfo> <toc/> <part> <title>Part One Title</title> <chapter> <title>List Tests</title> <sect1> <title>OrderedLists</title> <variablelist> <title>Font Filename Extensions</title> <varlistentry><term><filename>TTF</filename></term> <listitem> <para> TrueType fonts. </para> </listitem> </varlistentry> </variablelist> </sect1> </chapter> </part> </book> |
|
From: Philip R. <phi...@ch...> - 2005-06-29 15:38:38
|
Hi, I'm part of the KDE documentation team. You might from remember Lauri Watts' message from April about our intention to produce PDF versions of the KDE documentation. As Lauri said, we'd very much prefer to use a system that is actively maintained, and nico's dblatex seems to fit the bill. nico, are you still working on dblatex? Nikolai, ISTR that you were also interested in using dblatex for the Debian documentation. Would you be interested in co-ordinating with nico and the KDE team on dblatex? As Lauri mentioned before, it would be a shame to see dblatex stagnate, but hopefully together we can all benefit each other :-) Regards, Philip -- KDE Documentation Team: http://i18n.kde.org/doc KDE Documentation Online: http://docs.kde.org |
|
From: nico <nic...@li...> - 2005-05-30 19:00:05
|
Hello, > > I added a support for the scalefit and align="center" attribute of > graphic of DocBook. The scalefit attribute crates a resizebox which > makes the graphic to the size of the column (\columnwidth). maybe this > should overwritten, in a costum style sheet. > If the width and the height are specified, a bb= attibut is appended to > the \includegraphics command. this is important for rendering png images > with LaTeX. > The scalefit and the width attribut is abused, actuallay the semantic of > this paramters is different, but it works mostly in a way a user would > expect. The height parameter does not exist in DocBook and the > validation should fail ... There should be a better solution. I would suggest to use directly the \includegraphics options. Example: \includegraphics[scale=0.5,width=5cm,height=10cm,keepaspectratio=true] Please find attached the stylesheet I use to render <imagedata>. Most of the imagadata attributes combinations are supported. Any comment is welcome. Regards, BG |
|
From: Karsten O. <wid...@t-...> - 2005-05-30 18:09:22
|
Hello,
I'm finished. Unfortunately again a patch of my own patch. I hate it.
What's left:
I had to include one patch in the qandaset.mod.xsl, which removes a
template which is not used and let every XSLT processor fail. This patch
was already there, but not included in the CVS
A missing '' in preamble.mod.xsl in line 523 for saxon 8
+ <xsl:if test="$latex.use.varioref='1'">
- <xsl:if test="$latex.use.varioref=1">
I added a support for the scalefit and align="center" attribute of
graphic of DocBook. The scalefit attribute crates a resizebox which
makes the graphic to the size of the column (\columnwidth). maybe this
should overwritten, in a costum style sheet.
If the width and the height are specified, a bb= attibut is appended to
the \includegraphics command. this is important for rendering png images
with LaTeX.
The scalefit and the width attribut is abused, actuallay the semantic of
this paramters is different, but it works mostly in a way a user would
expect. The height parameter does not exist in DocBook and the
validation should fail ... There should be a better solution.
Default now text is not justified, it is ragged right. A parameter for
this would be a better solution. Does one exist?
I added an attribut latex.customcommand. You can redefine in your custom
stylesheet custom Latex commands. E.g. the following defines a abstract
environment for the report class. (I had the problem, that the
pagenumbers or wrong else (Why? Don't know.)).
<xsl:param name="latex.customcommand">
<xsl:text><![CDATA[
\makeatletter
\renewenvironment{abstract}{%
\if@twocolumn
\section*{\abstractname}%
\else
\small
\begin{center}%
{\bfseries \abstractname\vspace{-.5em}\vspace{\z@}}%
\end{center}%
\quotation
\fi}
{\if@twocolumn\else\endquotation\fi}
\makeatother
]]>
</xsl:text>
Bye, Karsten
|
|
From: Karsten O. <wid...@t-...> - 2005-05-30 00:24:24
|
Hello,
I corrected something else from the last mail. The patch includes now
the following:
Toto be able to work, I had to include one patch in the
qandaset.mod.xsl, which removes a template which is not used and let
every XSLT processor fail. This patch was already there, but not
included in the CVS. Why?
Another bug was a missing '' in preamble.mod.xsl in line 523 for saxon 8
- <xsl:if test="$latex.use.varioref='1'">
+ <xsl:if test="$latex.use.varioref=1">
I added a support for the scale and align="center" attribute of graphic
of DocBook. Additional the scale attribute is honored and creates a
\scalebox. If the width and the height are specified, a bb= attibut is
appended to the \includegraphics command. this is important for
rendering png images with latex.
Default now text is not justified, it is ragged right. A paramter for
this would be a better solution.
I added an attribut latex.customcommand. You can define in your custom
stylesheet custom Latex commands. E.g. the following defines a abstract
environment for the book class.
<xsl:param name="latex.customcommand">
<xsl:text><![CDATA[
\makeatletter
\renewenvironment{abstract}{%
\if@twocolumn
\section*{\abstractname}%
\else
\small
\begin{center}%
{\bfseries \abstractname\vspace{-.5em}\vspace{\z@}}%
\end{center}%
\quotation
\fi}
{\if@twocolumn\else\endquotation\fi}
\makeatother
]]>
</xsl:text>
Please include this.
Bye, Karsten
|
|
From: Karsten O. <wid...@t-...> - 2005-05-27 15:02:14
|
Hello, Toto be able to work, I had to include one patch in the qandaset.mod.xsl, which removes a template which is not used and let every XSLT processor fail. This patch was already there, but not included in the CVS. Why? Another bug was a missing '' in preamble.mod.xsl in line 523 for saxon 8 - <xsl:if test="$latex.use.varioref='1'"> + <xsl:if test="$latex.use.varioref=1"> I added a support for the scale and align="center" attribute of graphic of DocBook. The xref to biblioentries did not generate a label. I used the XrefLabel to do this. Beyonf this xalan cannot compile the stylesheets. Somebody a solution? Please include this. Bye, Karsten |
|
From: nico <nic...@li...> - 2005-04-28 20:59:33
|
Sorry, I forgot the piece. ------- Forwarded message ------- From: nico <nic...@li...> To: "db2...@li..." <db2...@li...> Subject: Re: [DB2LaTeX-devel] XSL Table Code (repost) Date: Thu, 28 Apr 2005 22:59:09 +0200 On Thu, 28 Apr 2005 11:33:15 +0100, David Hedley <da...@he...> wrote: > > Hi Nico & others, > >> The >> only limitation I found is when an <entry> contains blank >> lines like this: >> >> <entry> >> >> This is a buggy entry, isn't it? >> >> </entry> >> >> Latex then complains about the multicolumn: [...] > > I can't reproduce this with my setup - it handles this case fine. What > could > cause this is if you're using the 'morerows' attribute and haven't > tweaked > multirow.sty as advised in my original email. If you are still having > problems then please let me have your test case and let me know which > version etc of pdflatex you're using. I don't use the attribute 'morerows', and it really seems to come from multicolumn. Please find attached the simple test case that shows the behaviour I have. It contains the XSL used (main.xsl), the XML test file (doc.xml), the LaTeX result (doc.tex), and the pdflatex compilation log (doc.log) whose first line gives the pdflatex version. > >> Anyway, great work. Would you mind if I put your file in a >> future dblatex >> release (not db2latex since I have no rights for this :-)? [...] > > No of course not. Help yourself to it. Thanks! BG ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ DB2LaTeX-devel mailing list DB2...@li... https://lists.sourceforge.net/lists/listinfo/db2latex-devel -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
|
From: nico <nic...@li...> - 2005-04-28 20:57:12
|
On Thu, 28 Apr 2005 07:37:53 +0200, Torsten Bronger
<br...@ph...> wrote:
> Hallöchen!
Salut ! ;-)
>
> nico <nic...@li...> writes:
>
>> [...]
>>
>> Well, the perl processing is used for three purposes:
>>
>> - for fast systematic string replacement, e.g. a "\" is change to
>> a "\\" to make latex happy. Doing this task with XSL is quite
>> possible but really slow. I wanted something really faster because
>> I need to drive books containing more than 200 pages. This said,
>> maybe that EXSL functions now exist that can do this far
>> better. Is it the case?
>
> I don't know EXSL well enough, but while I too had once thought that
> it's good to have everything in XSLT, I quickly realised that
> there's always the right tool for the right purpose, and doing
> everything in XSLT means that you do it sub-optimally in one way or
> the other.
That's why I use the perl processing, indeed.
>
> So I wrote tbrplent (in C++) which replaces UTF-8 sequences with
> LaTeX commands. It works well. The idea is that the XSLT
> stylesheet deploys delimiters. Every text node is enclosed by them,
> every formula, and every text-within-formula. So the replacements
> can fit in their context. My XSLT typically contains:
That's exactly the way I do.
>
> <xsl:variable name="start-delimiter" select="'˜'"/>
> <xsl:variable name="end-delimiter" select="'œ'"/>
>
> <xsl:template match="text()" priority="0">
> <xsl:value-of select="$start-delimiter"/>
> <xsl:value-of select="."/>
> <xsl:value-of select="$end-delimiter"/>
> </xsl:template>
>
> Unfortunately, my ambitions have grown since then, and I plan a
> re-write. I needed three pairs of delimiters, but I want to replace
> them by one pair plus numerical parameter, in order to have as many
> "modes" as I need. For example, there must be a special mode for
> headings, because in PDF bookmarks some characters must be written
> differently.
I understand.
>
> tbrplent was written for my tbook project ("TBook RePLace ENTities),
> but I now use it for texi2latex, too.
>
> If you are interested, we can try a re-implementation (under a new
> name) together. It's not a big thing after all. The replacement
> tables exist already, they just need to be expanded to the new
> modes. And we have to decide for a language. I planed to use
> Python, but probably most of you are Perl hackers.
Yes it's interesting. Personally I would vote for Python: powerfull, clean
and maintanable code, well suited for text processing, compilable if hard
performance is needed, available on almost every platform.
>
> C++ would produce a small executable program, which is especially
> pleasing for a Windows distribution. Since no regexes are involved,
> it should be as easy to program and as fast as in Perl. So I vote
> for C++.
>
> Tschö,
> Torsten.
>
Regards,
BG
|
|
From: nico <nic...@li...> - 2005-04-28 20:39:52
|
On Thu, 28 Apr 2005 11:33:15 +0100, David Hedley <da...@he...> wrote: > > Hi Nico & others, > >> The >> only limitation I found is when an <entry> contains blank >> lines like this: >> >> <entry> >> >> This is a buggy entry, isn't it? >> >> </entry> >> >> Latex then complains about the multicolumn: [...] > > I can't reproduce this with my setup - it handles this case fine. What > could > cause this is if you're using the 'morerows' attribute and haven't > tweaked > multirow.sty as advised in my original email. If you are still having > problems then please let me have your test case and let me know which > version etc of pdflatex you're using. I don't use the attribute 'morerows', and it really seems to come from multicolumn. Please find attached the simple test case that shows the behaviour I have. It contains the XSL used (main.xsl), the XML test file (doc.xml), the LaTeX result (doc.tex), and the pdflatex compilation log (doc.log) whose first line gives the pdflatex version. > >> Anyway, great work. Would you mind if I put your file in a >> future dblatex >> release (not db2latex since I have no rights for this :-)? [...] > > No of course not. Help yourself to it. Thanks! BG |
|
From: David H. <da...@he...> - 2005-04-28 10:33:06
|
Hi Nico & others,
> The =20
> only limitation I found is when an <entry> contains blank=20
> lines like this:
>=20
> <entry>
>=20
> This is a buggy entry, isn't it?
>=20
> </entry>
>=20
> Latex then complains about the multicolumn:
> "{
> ! Paragraph ended before \multicolumn was complete.
> <to be read again>
> \par
> l.60
> \par
> l.60
>=20
> I suspect you've forgotten a `}', causing me to apply this=20
> control sequence to too much text. How can we recover?"
>
I can't reproduce this with my setup - it handles this case fine. What =
could
cause this is if you're using the 'morerows' attribute and haven't =
tweaked
multirow.sty as advised in my original email. If you are still having
problems then please let me have your test case and let me know which
version etc of pdflatex you're using.
> Anyway, great work. Would you mind if I put your file in a=20
> future dblatex =20
> release (not db2latex since I have no rights for this :-)? Of=20
> course I =20
> keep your file untouched with your header. I must do some=20
> other tests, but =20
> I think that with this implementation I can remove the table perl =20
> dependency I have in my implementation.
>=20
No of course not. Help yourself to it.
Best wishes,
David
|
|
From: Torsten B. <br...@ph...> - 2005-04-28 05:38:03
|
Hall=C3=B6chen!
nico <nic...@li...> writes:
> [...]
>
> Well, the perl processing is used for three purposes:
>
> - for fast systematic string replacement, e.g. a "\" is change to
> a "\\" to make latex happy. Doing this task with XSL is quite
> possible but really slow. I wanted something really faster because
> I need to drive books containing more than 200 pages. This said,
> maybe that EXSL functions now exist that can do this far
> better. Is it the case?
I don't know EXSL well enough, but while I too had once thought that
it's good to have everything in XSLT, I quickly realised that
there's always the right tool for the right purpose, and doing
everything in XSLT means that you do it sub-optimally in one way or
the other.
So I wrote tbrplent (in C++) which replaces UTF-8 sequences with
LaTeX commands. It works well. The idea is that the XSLT
stylesheet deploys delimiters. Every text node is enclosed by them,
every formula, and every text-within-formula. So the replacements
can fit in their context. My XSLT typically contains:
<xsl:variable name=3D"start-delimiter" select=3D"'˜'"/>
<xsl:variable name=3D"end-delimiter" select=3D"'œ'"/>
<xsl:template match=3D"text()" priority=3D"0">
<xsl:value-of select=3D"$start-delimiter"/>
<xsl:value-of select=3D"."/>
<xsl:value-of select=3D"$end-delimiter"/>
</xsl:template>
Unfortunately, my ambitions have grown since then, and I plan a
re-write. I needed three pairs of delimiters, but I want to replace
them by one pair plus numerical parameter, in order to have as many
"modes" as I need. For example, there must be a special mode for
headings, because in PDF bookmarks some characters must be written
differently.
tbrplent was written for my tbook project ("TBook RePLace ENTities),
but I now use it for texi2latex, too.
If you are interested, we can try a re-implementation (under a new
name) together. It's not a big thing after all. The replacement
tables exist already, they just need to be expanded to the new
modes. And we have to decide for a language. I planed to use
Python, but probably most of you are Perl hackers.
C++ would produce a small executable program, which is especially
pleasing for a Windows distribution. Since no regexes are involved,
it should be as easy to program and as fast as in Perl. So I vote
for C++.
Tsch=C3=B6,
Torsten.
--=20
Torsten Bronger, aquisgrana, europa vetus
|
|
From: nico <nic...@li...> - 2005-04-27 23:05:35
|
On Sun, 24 Apr 2005 00:15:42 +0200, Nikolai Prokoschenko <ni...@pr...> wrote: > On Apr 22, 2005 at 07:48:05PM +0200, nico wrote: > >> What is the docbook test suite you're talking about? Is it the >> 'testdocs' entry under the docbook sourceforge site? > > Exactly. I hasn't been "released" in a long time, but Norman Walsh seems > to update the CVS repository on a regular basis. Current version is for > Docbook 4.4. I think that this test suite is comprehensive enough to find > most "big" mistakes - at least I could verify that my table morerows code > needs rewriting badly. Ok. > >> >So my opinion is that a lot of work needs to be done, especially in >> >ensuring flexibility and Docbook-compliance. >> If you have suggestions to improve flexibility, or even some hack, >> please tell it on the list. You can send all your wishes, at least to >> see the amount of work to do. > > I don't think I've explored the code deeply enough to give qualified > reasons, but I didn't like the idea of "mapping", for example. I've got > the impession that it just replaces certain elements with certain > LaTeX-macros, which is not quite right, at least not without an obvious > way to overload this _consistently_ throughout the code. > > But please note that I haven't read the code extensively and I cannot say > I understand all the background for this or that decision. I agree. I think it comes from the XSL language translation code by N. Walsh stylesheets to map how to say "chapter" in spanish for instance. It is well suited for the original purpose, but not really to translate structural things to others. In dblatex I don't use it heavily. > >> >Another field is ensuring TeX works the way we want it to (Unicode). If >> >we get clearance from the developers, we might need to setup an >> >automated test suite processing so that we can see which areas need >> >work. >> Good idea. > > This is actually something I can setup rather quickly. I just need some > place to host it. > > Another item on the agenda: I know you used Perl for post-processing. I'm > not quite sure it's sane enough, but I also can't tell you why we > shouldn't be doing that. I would like to have a plain XSL solution - or > else we can just take Perl and scrap XSLT. I know XSLT is PITA (I've > spent > several days on the rather trivial task of adding morerows ;)), but if we > choose that way, we should walk along it. Well, the perl processing is used for three purposes: - for fast systematic string replacement, e.g. a "\" is change to a "\\" to make latex happy. Doing this task with XSL is quite possible but really slow. I wanted something really faster because I need to drive books containing more than 200 pages. This said, maybe that EXSL functions now exist that can do this far better. Is it the case? - "to do the things I cannot do with XSL". I confess my poor XSL programming skills with this point. Currently it's for table support. - to do some compilation stuff once the latex file is available. Typically it detects and converts some figures format to the expected one for the tex compiler. For example it converts EPS figures to PDF when pdflatex is used. So I would say that: - Having all the XML translation done by XSL would be the best (and cleanest) thing provided that the two first points are really possible to do with XSL. I confident with this. At least the string replacement is not a functionnal problem (XSL can do this) even if it is still a performance issue. Besides the David Hedley contribution skip the table coding I needed to do with perl. - The last perl processing seems to me interesting (I don't have to care how to compile the file) but is not a part of the XML translation. It's only a convenient way to do things after. - Perl post-processing can become completely optional. > > Considering the structure of the project: a wiki might be good to store > all Docbook definitions, rendering proposals and possibly an algorithms > for translating that to LaTeX and of course some discussion. > > I will hopefully be looking into db2latex-xsl's code soon, so I can tell > what I would like to see changed. > Even if dblatex is different from db2latex in some aspects I'm sure that we can converge to a common set of well defined core XSL stylesheets. And maybe a wiki is a good way to do the necessary exchanges, but I don't know how this can be installed. At least the mailing list is a good start to do exchanges ;-) Regards, BG |
|
From: nico <nic...@li...> - 2005-04-27 22:10:37
|
>
> Fellow db2latex'ers,
>
> Please find attached my table code for db2latex which I'm releasing
> under the GPL.
>
> This is a complete rewrite of the table code in XSL.
Wow, what a terrific piece of code! I've used it without any problem. The
only limitation I found is when an <entry> contains blank lines like this:
<entry>
This is a buggy entry, isn't it?
</entry>
Latex then complains about the multicolumn:
"{
! Paragraph ended before \multicolumn was complete.
<to be read again>
\par
l.60
\par
l.60
I suspect you've forgotten a `}', causing me to apply this
control sequence to too much text. How can we recover?"
I guess that it's a normal behaviour but do know if something can be done
to have this command less fragile?
>
> Notes:
>
> [...]
> * The 'node-set' extension is used extensively. Your XSLT processor
> must be able to support this extension (most do).
I was really not possible to use only pure XSL language?
Anyway, great work. Would you mind if I put your file in a future dblatex
release (not db2latex since I have no rights for this :-)? Of course I
keep your file untouched with your header. I must do some other tests, but
I think that with this implementation I can remove the table perl
dependency I have in my implementation.
Thanks,
BG
|
|
From: David H. <da...@he...> - 2005-04-25 15:04:48
|
(Note: this is a repost. There appears to be a 40k limit on mail to this list. Please visit http://www.vistair.com/newtbl for message attachments) Fellow db2latex'ers, Please find attached my table code for db2latex which I'm releasing under the GPL. This is a complete rewrite of the table code in XSL. Notes: * All templates run in the 'newtbl' mode and new and old tables can be freely interchanged. The example XSL file test.xsl uses the new code for all informaltable elements. * Handles row and column spanning, named column starts, missing 'entry' elements * Handles rowsep and colsep with inheritance * Handles rotated cells * Handles horizontal and vertical alignment (within the capabilities of Latex tables) * Doesn't handle 'char' and 'charoff' attributes. * Doesn't support 'entrytbl' (although nested tables will work) * Requires 'calc' and 'multirow' packages. Note I strongly recommend editing multirow.sty and changing \def\@xmultirow... to \long\def\@xmultirow * Handles absolute and relative column widths (i.e. starred columns, including widths of the format '5*+3in') * Uses the 'tabular' environment but can use other packages (e.g. supertabular) by passing the 'tabletype' parameter. * The 'node-set' extension is used extensively. Your XSLT processor must be able to support this extension (most do). * rowseps and colseps are off by default as that seems to be what docbook's tests expect. However this isn't clear in the CALS spec. If in doubt, always give a default rowsep and colsep attribute in the 'tgroup' element. Problems and differences from the original table code: * Each table cell is effectively set inside a 'parbox'. This means that pretty much anything can be put in a table cell without problems, but it does mean that cell contents will line-wrap. You should always try to set appropriate column widths. * The 'multirow' latex package makes some assumptions about the number of rows it's spanning. This can lead to strange spacing and overlapping cells. There's no easy fix for this that I know of except to use struts in the problem cells. I usually define a processing instruction as follows: <xsl:template match="processing-instruction('strut')"> <xsl:text>\rule{0pt}{</xsl:text> <xsl:value-of select="."/> <xsl:text>}</xsl:text> </xsl:template> You can then put <? strut 1.5em ?> or similar to open up problem rows. Testing: * Tested with xsltproc only (libxml 20619, libxslt 10114 and libexslt 812) * The code passes the 18 'table' and 'informal' table tests with docbook 4.4 with the following caveats: o You will need the use template for 'para' given in test.xsl for informaltable test 017 as the standard db2latex paragraph handling is a bit broken. o informaltable test 015 fails as one of the column widths is given as '4in*' which seems pretty meaningless to me. o table tests 009 and 013 don't work properly as they use 'entrytbl' o table test 016 fails as it uses HTML table tags. * The code works fine with all 1100+ tables listed in the Airbus Flight Crew Operating Manuals (for which they were originally developed) Best wishes, David Hedley |
|
From: David H. <dav...@vi...> - 2005-04-25 14:16:40
|
(Note: this is a repost. There appears to be a 40k limit on mail to this list. Please visit http://www.vistair.com/newtbl for message attachments) Fellow db2latex'ers, Please find attached my table code for db2latex which I'm releasing under the GPL. This is a complete rewrite of the table code in XSL. Notes: * All templates run in the 'newtbl' mode and new and old tables can be freely interchanged. The example XSL file test.xsl uses the new code for all informaltable elements. * Handles row and column spanning, named column starts, missing 'entry' elements * Handles rowsep and colsep with inheritance * Handles rotated cells * Handles horizontal and vertical alignment (within the capabilities of Latex tables) * Doesn't handle 'char' and 'charoff' attributes. * Doesn't support 'entrytbl' (although nested tables will work) * Requires 'calc' and 'multirow' packages. Note I strongly recommend editing multirow.sty and changing \def\@xmultirow... to \long\def\@xmultirow * Handles absolute and relative column widths (i.e. starred columns, including widths of the format '5*+3in') * Uses the 'tabular' environment but can use other packages (e.g. supertabular) by passing the 'tabletype' parameter. * The 'node-set' extension is used extensively. Your XSLT processor must be able to support this extension (most do). * rowseps and colseps are off by default as that seems to be what docbook's tests expect. However this isn't clear in the CALS spec. If in doubt, always give a default rowsep and colsep attribute in the 'tgroup' element. Problems and differences from the original table code: * Each table cell is effectively set inside a 'parbox'. This means that pretty much anything can be put in a table cell without problems, but it does mean that cell contents will line-wrap. You should always try to set appropriate column widths. * The 'multirow' latex package makes some assumptions about the number of rows it's spanning. This can lead to strange spacing and overlapping cells. There's no easy fix for this that I know of except to use struts in the problem cells. I usually define a processing instruction as follows: <xsl:template match="processing-instruction('strut')"> <xsl:text>\rule{0pt}{</xsl:text> <xsl:value-of select="."/> <xsl:text>}</xsl:text> </xsl:template> You can then put <? strut 1.5em ?> or similar to open up problem rows. Testing: * Tested with xsltproc only (libxml 20619, libxslt 10114 and libexslt 812) * The code passes the 18 'table' and 'informal' table tests with docbook 4.4 with the following caveats: o You will need the use template for 'para' given in test.xsl for informaltable test 017 as the standard db2latex paragraph handling is a bit broken. o informaltable test 015 fails as one of the column widths is given as '4in*' which seems pretty meaningless to me. o table tests 009 and 013 don't work properly as they use 'entrytbl' o table test 016 fails as it uses HTML table tags. * The code works fine with all 1100+ tables listed in the Airbus Flight Crew Operating Manuals (for which they were originally developed) Best wishes, David Hedley Scanned for viruses by MailDefender |
|
From: Nikolai P. <ni...@pr...> - 2005-04-23 22:47:13
|
On Apr 22, 2005 at 07:48:05PM +0200, nico wrote: > If you have suggestions to improve flexibility, or even some hack, please > tell it on the list. You can send all your wishes, at least to see the > amount of work to do. Some other items: - I've looked into the mappings - it seems that this is just a simplified way of mass-defining templates. I think to ensure flexibility each element should get a separate template in XSL. - There should be some general considerations on naming the templates. The current system seems rather chaotic to me, especially with all the "generate.*" templates. - Connected to the item above: we might need some generic XSL function library. For example, I needed to build up some kind of array structure to be able to implement morerows. There will certainly be a whole lot of other helping functions, which we'll need all over the code especially for the complex things. Maybe something like this exists already? (http://sourceforge.net/projects/xsltsl/ and http://fxsl.sourceforge.net/ have some material) - We'll also need some prototyping language for XSLT - all the <xsl:if>s are just nasty. I've seen something like that on the internet, but I do not have a link right now. It plainly lets you write if a=b {} and converts it to <xsl:if test="a=b"></xsl:if>. Maybe, if we find something really working and useful, we might switch to that format and generate XSLT only automatically? - General file structure. How about an xsl-file for each Docbook element or something like it? -- Nikolai Prokoschenko ni...@pr... / Jabber: pr...@ja... |
|
From: Nikolai P. <ni...@pr...> - 2005-04-23 22:16:16
|
On Apr 22, 2005 at 07:48:05PM +0200, nico wrote: > What is the docbook test suite you're talking about? Is it the > 'testdocs' entry under the docbook sourceforge site? Exactly. I hasn't been "released" in a long time, but Norman Walsh seems to update the CVS repository on a regular basis. Current version is for Docbook 4.4. I think that this test suite is comprehensive enough to find most "big" mistakes - at least I could verify that my table morerows code needs rewriting badly. > Besides, I am still interested in using your XSL table implementation. It was rather a hack to be able to use db2latex-xsl at all for the Debian project. Generally, I think the tables support should be rewritten. > >So my opinion is that a lot of work needs to be done, especially in > >ensuring flexibility and Docbook-compliance. > If you have suggestions to improve flexibility, or even some hack, > please tell it on the list. You can send all your wishes, at least to > see the amount of work to do. I don't think I've explored the code deeply enough to give qualified reasons, but I didn't like the idea of "mapping", for example. I've got the impession that it just replaces certain elements with certain LaTeX-macros, which is not quite right, at least not without an obvious way to overload this _consistently_ throughout the code. But please note that I haven't read the code extensively and I cannot say I understand all the background for this or that decision. > >Another field is ensuring TeX works the way we want it to (Unicode). If > >we get clearance from the developers, we might need to setup an > >automated test suite processing so that we can see which areas need > >work. > Good idea. This is actually something I can setup rather quickly. I just need some place to host it. Another item on the agenda: I know you used Perl for post-processing. I'm not quite sure it's sane enough, but I also can't tell you why we shouldn't be doing that. I would like to have a plain XSL solution - or else we can just take Perl and scrap XSLT. I know XSLT is PITA (I've spent several days on the rather trivial task of adding morerows ;)), but if we choose that way, we should walk along it. Considering the structure of the project: a wiki might be good to store all Docbook definitions, rendering proposals and possibly an algorithms for translating that to LaTeX and of course some discussion. I will hopefully be looking into db2latex-xsl's code soon, so I can tell what I would like to see changed. -- Nikolai Prokoschenko ni...@pr... / Jabber: pr...@ja... |
|
From: Lauri W. <la...@kd...> - 2005-04-22 19:58:56
|
On Friday 22 April 2005 09.44, Nikolai Prokoschenko wrote: > On Apr 21, 2005 at 11:24:48AM +0200, Lauri Watts wrote: > I'm lurking in this mailing list, if anything big happens, I'd be glad to > help. I do not consider myself capable of managing the project alone, but > I'd like to see it evolve into a general documentation typesetting > solution, as opposed to FOP and JadeTeX (which is plain ugly and > non-flexible). I think we're in the same situation precisely here. I also think nico's re= ply=20 further down the thread may be the answer to both our problems :) Regards, =2D-=20 Lauri Watts KDE Documentation: http://docs.kde.org KDE on FreeBSD: http://freebsd.kde.org |
|
From: nico <nic...@li...> - 2005-04-22 17:28:50
|
Oups, I forgot the list. ------- Forwarded message ------- From: nico <nic...@li...> To: "Nikolai Prokoschenko" <ni...@pr...> Subject: Re: [DB2LaTeX-devel] Status of project, and where to next Date: Fri, 22 Apr 2005 19:44:44 +0200 On Fri, 22 Apr 2005 09:44:55 +0200, Nikolai Prokoschenko <ni...@pr...> wrote: > On Apr 21, 2005 at 11:24:48AM +0200, Lauri Watts wrote: > >> What we'd like to know is, what is the status of the project as it is >> now? > > I'm not a developer of DB2LaTeX-XSL, but I'm very interested in it, as > I'm > trying to get the Debian Project's Documentation (at the moment only the > Debian Installer Manual) to look clean and nice. I've found out that > db2latex-xsl is rather good for our goals, but it should be rehauled at > some places because these are not yet DocBook-compliant - it also fails > the Docbook Test Suite miserably. I've managed to patch it to support the > morerows property of tables to the extent we needed, but it's still not > really good. Hello, I've done a db2latex clone (http://dblatex.sf.net) some time ago that started with the db2latex stylesheets. Maybe some of the rewritten stylesheets could be reused, especialy those to render the graphics. Anyway, this thread is a good occasion to list what is missing, what should change, etc. What is the docbook test suite you're talking about? Is it the 'testdocs' entry under the docbook sourceforge site? Besides, I am still interested in using your XSL table implementation. > Another problem is that the documentation we have comes in several > languages and also several scripts. The TeX/LaTeX support for these > differs significantly and sometimes DB2LaTeX is not flexible enough to > support all necessary steps. For example, I couldn't generate proper > Japanese without converting from UTF-8 to legacy Japanese (using only > free > fonts). > > So my opinion is that a lot of work needs to be done, especially in > ensuring flexibility and Docbook-compliance. If you have suggestions to improve flexibility, or even some hack, please tell it on the list. You can send all your wishes, at least to see the amount of work to do. > Another field is ensuring TeX > works the way we want it to (Unicode). If we get clearance from the > developers, we might need to setup an automated test suite processing so > that we can see which areas need work. Good idea. Bye, BG -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
|
From: Nikolai P. <ni...@pr...> - 2005-04-22 07:45:29
|
On Apr 21, 2005 at 11:24:48AM +0200, Lauri Watts wrote: > What we'd like to know is, what is the status of the project as it is now? I'm not a developer of DB2LaTeX-XSL, but I'm very interested in it, as I'm trying to get the Debian Project's Documentation (at the moment only the Debian Installer Manual) to look clean and nice. I've found out that db2latex-xsl is rather good for our goals, but it should be rehauled at some places because these are not yet DocBook-compliant - it also fails the Docbook Test Suite miserably. I've managed to patch it to support the morerows property of tables to the extent we needed, but it's still not really good. Another problem is that the documentation we have comes in several languages and also several scripts. The TeX/LaTeX support for these differs significantly and sometimes DB2LaTeX is not flexible enough to support all necessary steps. For example, I couldn't generate proper Japanese without converting from UTF-8 to legacy Japanese (using only free fonts). So my opinion is that a lot of work needs to be done, especially in ensuring flexibility and Docbook-compliance. Another field is ensuring TeX works the way we want it to (Unicode). If we get clearance from the developers, we might need to setup an automated test suite processing so that we can see which areas need work. I'm lurking in this mailing list, if anything big happens, I'd be glad to help. I do not consider myself capable of managing the project alone, but I'd like to see it evolve into a general documentation typesetting solution, as opposed to FOP and JadeTeX (which is plain ugly and non-flexible). -- Nikolai Prokoschenko ni...@pr... / Jabber: pr...@ja... |
|
From: Lauri W. <la...@kd...> - 2005-04-21 09:28:21
|
Hi all, KDE (http://www.kde.org) would like to use the db2latex stylesheets for pdf= =20 processing of our documentation repository (http://docs.kde.org) There are= =20 some enormous advantages to this method of pdf generation over any of the=20 others for us, and the list of open issues we have for them is actually=20 pretty small. =20 What we'd like to know is, what is the status of the project as it is now? = I=20 don't see any activity in the CVS repository for 8 months (and that was the= =20 first for some time), there are several open issues in the tracker, and som= e=20 useful looking patches in the mailing list.=20 Are the original developers still around? Does the offer of some new blood = =20 help at all inspire you to come back to us? We'd certainly love to see you= =20 back in action, and if you are simply burned out or feeling a lack of=20 appreciation, please trust me, you are very appreciated and just tell us wh= at=20 we can do to help out. If you've moved on, or the issue is lack of time,= =20 would you be willing to add CVS access for some people, to allow some forwa= rd=20 movement, or at least fix up the few bugs that have turned up with xsltproc= =20 now being much stricter in it's processing? Or would you be ok with someon= e=20 taking over the project entirely in some form (whether here, with another=20 name, or in another location?) How about other readers out there - I'm fairly certain we are not alone in= =20 wanting to see this work bitrotting? Is there anyone else (especially thos= e=20 of you already having posted patches) who are interested in helping to keep= =20 this project alive?=20 We (KDE) also have developers already with XSLT and TeX skills that can hel= p=20 out, but we're generally in the business of developing (and documenting)=20 desktop software, so if someone more qualified wants to step up and run wi= th=20 this, I have a really nice big repository of test documents to work on. To summarise: What I'd most like to see, is for the original developers to = pop=20 up and get back to work (because hey, they already know all this code bette= r=20 than anyone else, and I like what they've done so far). If that's not=20 possible, I'd really like their blessing to put together a working group of= =20 some kind to continue development. Regards, =2D-=20 Lauri Watts KDE Documentation: http://docs.kde.org KDE on FreeBSD: http://freebsd.kde.org |
|
From: Eric J. <jo...@co...> - 2005-03-30 10:22:43
|
Hello! I was quite excited about using db2latex for my thesis, but I've run into a bit of a snag. Trying the latest examples, I get: [jonas@modulation ~/db2latex/db2latex-xsl-0.8pre1/xsl/sample/test_article]$ xsltproc ../docbook.xsl article.xml compilation error: file ../../qandaset.mod.xsl line 366 element template xsl:template: error duplicate name 'question.answer.label' with no output. Am I doing something wrong, or might this be a bug? Thanks, ...Eric |
|
From: Nikolai P. <ni...@pr...> - 2005-01-24 21:19:01
|
Hello, James, Ramon and whoever reads this on the list! Let me introduce myself to you. My name is Nikolai Prokoschenko. I'm a 22-year-old computer science student from Germany, coming in the ex-USSR. I have been doing some translation work for the Debian Installer project and currently became involved into building a better manual - on the technical side of the process, because I did not like the looks of its russian translation. Here comes DB2LaTeX, which I've chosen to do the work on the manual, as Debian needs truly free software to rely on - thus XSL:FO and FOP have never been an option. However, I've noticed that the morerows option in tables has not been supported, so I decided to implement that myself to have good looking manuals ;) I'm a complete novice to XSLT, however I've managed to accomplish this task! On the way, I've implemented LTXtable support, so this one can now also be used. I'm attaching my current patch to this mail. WARNING: it's not production-ready! I've made it work, but it can fail without any particular reason, no guarantees etc., you know the game. It's also missing consistent naming, good algorithm, documentation and possible interferes with other things. Please test it and tell me what you think. I'd pleased if this patch would make it upstream. I'd also like to know, where DB2LaTeX is heading right now. The project seems kind of stalled -- is there any plan, todo-list or something like it? Thank you and I hope I can help the project to some extent. It would be a shame if it would die, as documentation under linux would then become a real mess, even worse than it is now. PS. James and Ramon, sorry for CC:ing you, but I hope I can reach you this way, don't know if you're still subscribed to the list. -- Nikolai Prokoschenko ni...@pr... / Jabber: pr...@ja... |
|
From: Sebastian F. <fe...@ne...> - 2004-12-09 09:59:47
|
Hi,
I have some problems with a simple citation and the bibliography. The
stylesheet creates a \hypertaget after creating
\begin{thebibliography}{WIDELABEL}. There are no problems using pdflatex
but still using latex itself (with the snapshot of 2004-12-08).
Any suggestions?
One workaround could be: move the \hypertaget before the beginning of
the bibliography in biblio.mod.xsl.
I attached a simple citaion file cite.xml for testing.
Best regards
Sebastian
--
Sebastian Felis <fe...@ne...>
NEC Network Laboratories Heidelberg
|
|
From: Stefan H. <re...@tu...> - 2004-09-18 15:02:01
|
Hi, I am trying out db2latex, looks like good work. :) I tried to download Norman Walsh's Resolver for Java, but the link is broken. Google brought me this link: http://sources.redhat.com/ml/docbook-apps/2002-q2/msg00647.html So the resolver has moved to Apache's xml-commons an can be downloaded there. The path in the CatalogManager.properties needs to be adapted like this: catalog-class-name=org.apache.xml.resolver.Resolver I am using the documentation provided with version 0.8pre1: ~/db2latex/db2latex-xsl-0.8pre1/doc/using.html Greetings, Stefan |
