On the purpose of a LaTeX exporter



Hello everyone,

These are some thoughts on the LaTeX exporter in Gnumeric:

The LaTeX exporter is out of date and needs to be updated (or discarded). These
thoughts are intended to begin the discussion. I'm kindda hoping to try my hand
at the coding but since I am not very good at it someone else may end up doing
this in an evening's work. Regardless some decisons need to be made.

While LaTeX export is currently a "save as" option, I would distinguish the
capability to save a gnumeric workbook (which, to me, implies the ability to
restore from the same file) with the ability to export (only impling only the
ability to render the spreadsheet in a new format). The only use I see for a
LaTeX plugin is as this later function. I distinguish this from, say, an xml
exporter which might have as ambition to export an xml with dtd that can
present the data in an xml aware browser, and retrieve the data back into
gnumeric for later use. The html export capability might have a similar
ambition as the LaTeX exporter, simply to place data and simple formating into
an html table.


Note, first of all, that we can already export the exactly rendered gnumeric
spreadsheet in a form that can be include into a LaTeX document:
1) Select what you want to export and copy to an empty worksheet
(this will become unnecessary when we can "Print selected region").
2) In the print setup, make sure that the headers and footers are empty.
3) Print to postscript file.
4) ps2epsi the file
(this makes a bounding box around the selection rather than on the entire page.
This step may also become redundant if gnome-print gains the ability to export
ps/pdf of only the region (independent of a page size)).
5) include as is or convert to pdf and include (note that neither ggv nor xpdf
display the converted file correctly but acroread does. This is a problem I run
into quite often).
The ability to include all the information from a gnumeric spreadsheet (data,
formating, graphs...) in a LaTeX document could well be considered to obviate
the need for a LaTeX exporter. It certainly
suggests that an exporter should be much less ambtious, explicitly aiming for a
restricted capability.

I still see a use for a limited export capability. If others agree, then we
should decide first if it is resonable that this functionality be
"export-only". Secondly, the decision should be made about what formating it
makes sense to export and should only be available through gnome-print.

For instance, it might make sense to restrict LaTeX export to black and white
only. Another question I have yet to resolve for myself is whether a cell with
a long text content, long enough that it is hidden by its right-hand neighbour
should be included fully or only included partially. WYSIWYG or make a table of
the data? Should columns be the width defined in the sheet or adaptable? (see
bug #20898) Do we attempt to handle fonts or simply use the LaTeX documented
chosen fonts? It would be useful to come to some concensus on how the function
of the limited exporter. If no one agrees, then the coder's decision wins. :-)
Some of these decisions might eventually be allowed to be made in an export
wizard but that's way down the road and much more complex.

Similar to decisions have to be made for html export. The main difference
between the two is that html can be placed in a table of infinite size whereas
the LaTeX exporter must be capable of fitting the table on a printed page (how
to handle huge tables is problematic. I'm going to have to check how LaTeX
pagebreaks large tables. I know that it invariably sets it later in the
document.) Note that for neither LaTeX nor HTML export do I see any use in
exporting a whole workbook at once. So much of the decisions of how to handle
layout of the multiple tables lies in the non-gnumeric side (this layout is
indeed the entire reason for the export of the tables, isn't it?).

Okay, enough for now, I'll be interested to hear any thoughts,
thanks for reading and THANKS to the gnumeric hackers for this seminal piece of
free software, :-)

adrian
acuster nature berkeley educational





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]