Re: Problems with Longtable 1.4.0pre3
Samar,
the problem is not a 1.4. problem but a general problem how lyx handles
the different table-types of latex. It based on the difference between
latex tables (i.e. 1 page, normally embedded in a Float environment to
be shifted to a position where it looks nice) and latex- longtables ( 1
page ; page breaks) and the different handling of captions.
The problem is as follows:
tables have two containers, the caption is placed between the outer and
the inner hull:
\begin{table} % start of float
\caption{xxx}
\begin{tabular}
ABC\tabularnewline
123\tabularnewline
\end{tabular}
\end{table}
longtables however only have on container and the possiblility of
subdividing the contents with the \endhead, \endfirsthead, \endfoot
\endlastfoot command. Normally these blocks can also contain captions.
so its valid to write the following latex code
\begin longtable
\caption{xxx}
% goes into the list of tables and advances the tab-counter
ABC\tabularnewline % the header line for the first part of lt
\endfirsthead
\caption[]{xxx (cont.)}
%the opt. argument (i.e. nothing) is inserted into LOT no advance
ABC\tabularnewline % the header of the subsequent pages
\endhead
123\tabularnewline
\end{longtable}
Lyx longtables however only allow to switch endhead and endfirsthead for
table lines.
A kludge to overcome this problem is ERT (I think first posted by Dekel
Tsur). First define in the preamble a latex macro \supress with on
argument, which simply swallows the argument and does nothing with it.
\newcommand{\suppress}[1]{\relax}
Then write your longtable as follows
1. an empty line
2. the header line(s)
both with the endfirsthead flag in the table dialog
3 another empty line
4. the header line(s) for the subsequent pages
both with the endhead flag in the table dialog
then insert the following ERT in the first cell of 1 and 3 accordingly.
\caption{your captiontext goes here}\supress{
and the following ERT in the first cell of 2 and 4 accordingly
} , ie simply the closing brace.
With longer captions its ugly to edit, but anyhow.
this translates to the following latex code
\begin{longtable}
\caption{your captiontext goes here}\supress{\tabularnewline}
ABC\tabualarnewline ...
I wrote a program to convert csv-Files to lyx-code (with a few more
bells and whistles) where the longtable code goes that way. I hope I can
post it soon.
--
Joachim Heidemeier [EMAIL PROTECTED]
Re: Problems with Longtable 1.4.0pre3
Samar,
the problem is not a 1.4. problem but a general problem how lyx handles
the different table-types of latex. It based on the difference between
latex tables (i.e. < 1 page, normally embedded in a Float environment to
be shifted to a position where it looks nice) and latex- longtables (> 1
page ; page breaks) and the different handling of captions.
The problem is as follows:
tables have two containers, the caption is placed between the outer and
the inner hull:
\begin{table} % start of float
\caption{xxx}
\begin{tabular}
A\tabularnewline
1&2&3\tabularnewline
\end{tabular}
\end{table}
longtables however only have on container and the possiblility of
subdividing the contents with the \endhead, \endfirsthead, \endfoot
\endlastfoot command. Normally these blocks can also contain captions.
so its valid to write the following latex code
\begin longtable
\caption{xxx}
% goes into the list of tables and advances the tab-counter
A\tabularnewline % the header line for the first part of lt
\endfirsthead
\caption[]{xxx (cont.)}
%the opt. argument (i.e. nothing) is inserted into LOT no advance
A&\tabularnewline % the header of the subsequent pages
\endhead
1&2&3\tabularnewline
\end{longtable}
Lyx longtables however only allow to switch endhead and endfirsthead for
table lines.
A kludge to overcome this problem is ERT (I think first posted by Dekel
Tsur). First define in the preamble a latex macro \supress with on
argument, which simply swallows the argument and does nothing with it.
\newcommand{\suppress}[1]{\relax}
Then write your longtable as follows
1. an empty line
2. the header line(s)
both with the endfirsthead flag in the table dialog
3 another empty line
4. the header line(s) for the subsequent pages
both with the endhead flag in the table dialog
then insert the following ERT in the first cell of 1 and 3 accordingly.
\caption{your captiontext goes here}\supress{
and the following ERT in the first cell of 2 and 4 accordingly
} , ie simply the closing brace.
With longer captions its ugly to edit, but anyhow.
this translates to the following latex code
\begin{longtable}
\caption{your captiontext goes here}\supress{&&\tabularnewline}
A\tabualarnewline ...
I wrote a program to convert csv-Files to lyx-code (with a few more
bells and whistles) where the longtable code goes that way. I hope I can
post it soon.
--
Joachim Heidemeier <[EMAIL PROTECTED]>
Re: table design flaws in lyx / possible improvements (was: longtable caption again)
Am Sonntag, 28. September 2003 17:03 schrieb Herbert Voß: Helge Hafting schrieb: You have a point. Note that the people here can change lyx but not latex, and part of the problem here is how latex works. no, the point is in which way LyX should support LaTeX packages, should it be for 100% or is a minimal support better than no support. LyX supports the longtable package in a minimal way, which may be frustrating when you want a caption. I would even go a step further. The charm of LyX IMHO is that it hides the complexity of LaTeX in fairly standard cases very well. In lyx you can view a document from a high level view. You write a paragraph and just have to assign a layout to a paragraph. You don't have to worry about margins, hyphenation etc., you are encouraged to use fonts which harmonize etc. . And this model does not work so well with tables, possibly because such a higher level mechanism is only introduced with an extension package (array.sty). I would propose to define array.sty as a prerequisite for table support in lyx and use the format mechanism via \newcolumntype as the standard way for lyx. It is from the perspective of an Office-trained user much easier to understand. In tables, you have to use column or cell formats, too... Latex support two kinds of tables. One that is never broken up - this kind may go directly in a document or in some kind of floating object or in a text wrapping construct. The long table is the other kind, it will be broken up to fit the pages. TeX supports only _one_ kind of table, all other are supported by special packages: longtable, tabularx, LTXtable, threeparttable, ... I think one should define a set of reasonable standard cases for tables in typical lyx documents - and define the necessary latex packages as prerequisites (I think at least array, longtable and dcolumn are necessary). These standard tables should be handled by lyx in a consistent way from the lyx typical high level view - the latex complexity should be handled from the lyx2latex backend. The borders of this approch - where you have to switch to ERT - should be clearly marked in the documentation. Other table-related stuff like captions and automatic listing in a list of tables isn't table properties, it is properties of the float object. it is right, that a float has nothing to do with its contents and only for some historical reasons there exists the _predefined_ float types table and figure. The table user interface could easily be modified to have a four-way choice of floating/wrapped/nonfloating/longtable as a table property. But then people would wonder why the caption disappears when they switch the table to non-floating - because latex don't support a caption in that case. Well, perhaps the dirty tricks mentioned could become part of the conversion from .lyx to .tex if you use the longtable checkbox in the LyX tabular, you need some dirty tricks to get a caption, which has nothing to do with the floating object. And this dirty tricks are annoying for users, because he thinks, that LyX supports the longtable _with_ caption. Another problem: A user might want to do stuff like I do - such as putting a figure+a table in the same float. That works fine if you start with an empty float and fills it in with the other stuff. But what should your user do if he started with one of your kind of table with the floating option checked? Will there be an easy conversion from table that is implicitly floating to a float inset that happens to contain a table? And how about reversing such a conversion - what if there is more stuff in the float than just the table? I think that a this is another type of table - a table as subfigure, which should be also supported from the lyx standard approach. the user has to decide, if he wants a caption or not. This is exactly what LyX supports. And it is no problem to change the floating type, especially in my personal LyX, where I can change this on the fly, but in standard LyX, if you want another caption type than the predefined one, then you have to use ERT. But this was not Joachims point ... For me the main questions are, if it is worth to try to redesign the lyx table support along the lines I explained, has it a chance to go into lyx when it the design is fleshed out an who is willing to help in doing so (I'm neither familiar with lyx's internals nor with the probable subtle latex incompatibilites and I'm not at all a C++ programmer). All I can offer is preparing a first draft and participate in the discussion. YOURS -- Dr. Joachim Heidemeier Tel. +49-30-8903-2780 Fachgebiet II 3.2 [EMAIL PROTECTED] Umweltbundesamt, Bismarckplatz 1 D-14191 Berlin
Re: table design flaws in lyx / possible improvements (was: longtable caption again)
Am Sonntag, 28. September 2003 17:03 schrieb Herbert Voß: > Helge Hafting schrieb: > > You have a point. Note that the people here can change lyx but > > not latex, and part of the problem here is how latex works. > > no, the point is in which way LyX should support LaTeX > packages, should it be for 100% or is a minimal support > better than no support. > > LyX supports the longtable package in a minimal way, which > may be frustrating when you want a caption. I would even go a step further. The charm of LyX IMHO is that it hides the complexity of LaTeX in fairly standard cases very well. In lyx you can view a document from a high level view. You write a paragraph and just have to assign a layout to a paragraph. You don't have to worry about margins, hyphenation etc., you are encouraged to use fonts which harmonize etc. . And this model does not work so well with tables, possibly because such a higher level mechanism is only introduced with an extension package (array.sty). I would propose to define array.sty as a prerequisite for table support in lyx and use the format mechanism via \newcolumntype as the standard way for lyx. It is from the perspective of an "Office-trained" user much easier to understand. "In tables, you have to use column or cell formats, too..." > > > Latex support two kinds of tables. One that is never broken > > up - this kind may go directly in a document or in some kind > > of floating object or in a text wrapping construct. > > > > The long table is the other kind, it will be broken up to fit > > the pages. > > TeX supports only _one_ kind of table, all other are supported > by special packages: longtable, tabularx, LTXtable, > threeparttable, ... I think one should define a set of reasonable standard cases for tables in typical lyx documents - and define the necessary latex packages as prerequisites (I think at least array, longtable and dcolumn are necessary). These standard tables should be handled by lyx in a consistent way from the lyx typical high level view - the latex complexity should be handled from the lyx2latex backend. The borders of this approch - where you have to switch to ERT - should be clearly marked in the documentation. > > > Other table-related stuff like captions and automatic listing > > in a "list of tables" isn't table properties, it is > > properties of the float object. > > it is right, that a float has nothing to do with its > contents and only for some historical reasons there > exists the _predefined_ float types table and figure. > > > The table user interface could easily be modified to have a > > four-way choice of floating/wrapped/nonfloating/longtable as > > a table property. But then people would wonder why > > the caption disappears when they switch the table > > to non-floating - because latex don't support a caption > > in that case. > > Well, perhaps the "dirty tricks" mentioned could become > > part of the conversion from .lyx to .tex > > if you use the longtable checkbox in the LyX tabular, > you need some dirty tricks to get a caption, which has > nothing to do with the floating object. And this dirty > tricks are annoying for users, because he thinks, that > LyX supports the longtable _with_ caption. > > > Another problem: > > A user might want to do stuff like I do - such as putting > > a figure+a table in the same float. That works fine > > if you start with an empty float and fills it in with > > the other stuff. But what should your user do if he > > started with one of your kind of "table with the > > floating option checked"? Will there be an easy conversion > > from "table that is implicitly floating" to a float > > inset that happens to contain a table? And how about > > reversing such a conversion - what if there is more > > stuff in the float than just the table? I think that a this is another type of table - a table as subfigure, which should be also supported from the lyx standard approach. > > the user has to decide, if he wants a caption or not. > This is exactly what LyX supports. And it is no problem > to change the floating type, especially in my personal > LyX, where I can change this on the fly, but in standard LyX, > if you want another caption type than the predefined one, > then you have to use ERT. But this was not Joachims point ... For me the main questions are, if it is worth to try to redesign the lyx table support along the lines I explained, has it a chance to go into lyx when it the design is fleshed out an who is willing to help in doing so (I'm neither familiar with lyx's internals nor with the probable subtle latex incompatibilites and I'm not at all a C++ programmer). All I can offer is preparing a first draft and participate in the discussion. YOURS -- Dr. Joachim Heidemeier Tel. +49-30-8903-2780 Fachgebiet II 3.2 [EMAIL PROTECTED] Umweltbundesamt, Bismarckplatz 1 D-14191 Berlin
microscripting in lyx-documents - dynamic insets ?
Hello lyx-developers, I now have the problem, that parts of a document I'm working on has very often changing tables, generated from csv-tables or even a database-backend. So I have the idea to process template files with included tcl-code. This code is substituted and the result ist the actual lyx-document, which in turn can be cached. Well, to be honest, this is not my idea but the mechanism how Brent Welch's tclhttp server handles its templates and I'd adapt this code to handling lyx-documents. The problem I have is how to best mark the tcl-code best in a .tlx (template-lyx :-) file. One idea is to use: \begin_inset x-tcl-subst tclcode \end_inset. So a template file: ... \layout standard blah \begin_inset x-tcl-subst [clock format [clock seconds]] \end_inset ... would become ... \layout standard blah Mon Jul 22 10:19:08 CEST 2002 ... . But how does lyx react on unknown inset-types or does this idea breaks any existing concepts? Comments welcome. Yours -- Dr. Joachim Heidemeier Tel. +49-30-8903-2780 Fachgebiet II 3.2 [EMAIL PROTECTED] Umweltbundesamt, Bismarckplatz 1 D-14191 Berlin
microscripting in lyx-documents - dynamic insets ?
Hello lyx-developers, I now have the problem, that parts of a document I'm working on has very often changing tables, generated from csv-tables or even a database-backend. So I have the idea to process template files with included tcl-code. This code is substituted and the result ist the actual lyx-document, which in turn can be cached. Well, to be honest, this is not my idea but the mechanism how Brent Welch's tclhttp server handles its templates and I'd adapt this code to handling lyx-documents. The problem I have is how to best mark the tcl-code best in a .tlx (template-lyx :-) file. One idea is to use: \begin_inset x-tcl-subst tclcode \end_inset. So a template file: ... \layout standard blah \begin_inset x-tcl-subst [clock format [clock seconds]] \end_inset ... would become ... \layout standard blah Mon Jul 22 10:19:08 CEST 2002 ... . But how does lyx react on unknown inset-types or does this idea breaks any existing concepts? Comments welcome. Yours -- Dr. Joachim Heidemeier Tel. +49-30-8903-2780 Fachgebiet II 3.2 [EMAIL PROTECTED] Umweltbundesamt, Bismarckplatz 1 D-14191 Berlin
Re: importing tables into lyx
I think it doesn't solve the main problem that reLyX didn't handle longtables. I'm working on a tcl-package which supports the new tabular-format. joachim -- joachim heidemeier ([EMAIL PROTECTED]) On Wed, 13 Jun 2001, Herbert Voss wrote: On Wed, 13 Jun 2001, joachim heidemeier wrote: as I urgently need importing RTF-documents into Lyx I have the problem that I'm stuck with table imports (C.f the Thread rereLyX and import of MS-Word resp. RFT documents from April 2001). I now would like to try the route: Table copy from Word-Doc to Exel - csv Export - transformation form csv to a simple lyx-file with reasonable default values - import to the mail document without the tables. have you ever tried the package excel2latex, available at CTAN? Herbert
Re: importing tables into lyx
I think it doesn't solve the main problem that reLyX didn't handle longtables. I'm working on a tcl-package which supports the new tabular-format. joachim -- joachim heidemeier ([EMAIL PROTECTED]) On Wed, 13 Jun 2001, Herbert Voss wrote: > > On Wed, 13 Jun 2001, joachim heidemeier wrote: > > > as I urgently need importing RTF-documents into Lyx I have the problem > > that I'm stuck with table imports (C.f the Thread "rereLyX and import of > > MS-Word resp. RFT documents" from April 2001). > > I now would like to try the route: > > Table copy from Word-Doc to Exel -> csv Export -> transformation form > > csv to a simple lyx-file with reasonable default values -> import to the > > mail document without the tables. > > have you ever tried the package excel2latex, available > at CTAN? > > Herbert > > >
importing tables into lyx
dear lyx developers, as I urgently need importing RTF-documents into Lyx I have the problem that I'm stuck with table imports (C.f the Thread rereLyX and import of MS-Word resp. RFT documents from April 2001). I now would like to try the route: Table copy from Word-Doc to Exel - csv Export - transformation form csv to a simple lyx-file with reasonable default values - import to the mail document without the tables. For the transformation I would write a tcl script. For this purpose I need a description of the table (or longtable) coding in lyx and a parameter list affecting the tables. The idea is not to do a very smart copying and preserving all attribus but to read a simple table in the document which is then refined within lyx. If others are interested in the script I'll publish it of course. Please direct your answers to my email-account at work [EMAIL PROTECTED] Thanks in advance. -- joachim heidemeier ([EMAIL PROTECTED])
importing tables into lyx
dear lyx developers, as I urgently need importing RTF-documents into Lyx I have the problem that I'm stuck with table imports (C.f the Thread "rereLyX and import of MS-Word resp. RFT documents" from April 2001). I now would like to try the route: Table copy from Word-Doc to Exel -> csv Export -> transformation form csv to a simple lyx-file with reasonable default values -> import to the mail document without the tables. For the transformation I would write a tcl script. For this purpose I need a description of the table (or longtable) coding in lyx and a parameter list affecting the tables. The idea is not to do a very smart copying and preserving all attribus but to read a simple table in the document which is then refined within lyx. If others are interested in the script I'll publish it of course. Please direct your answers to my email-account at work [EMAIL PROTECTED] Thanks in advance. -- joachim heidemeier ([EMAIL PROTECTED])
