Journal home page
General information
Submit an item
Download style files
Copyright
Contact us
logo for The PracTeX Journal TUG logo

Feedback

From the Readers

tpjlogo

I am a rather new user to Latex and installed in on my computer some month ago. I have to admit that the learning curve has been steep. The Mori paper in issue 2008-1, http://tug.org/pracjourn/2008-1/mori/ was indeed very useful and informativ. Beginners as me do not necessary need all details and proof why, but good recommedations. You experts know what is working and why, and how to modify everything. For the time being, I need information what is working. Therefore, this article was exellent.

Kind regards,

Sveinung Heggen, Norway

[Thanks for your feedback! We're glad the paper was useful to you. — The Editors.]

tpjlogo

Sir,

I don't know much about pstricks but I used Asymptote to draw the same curve (or so it seems to me) and I got the following picture. It looks a bit different from what I see in the distractions in issue 2008-1, http://tug.org/pracjourn/2008-1/distract/. Do you see any reason? Am I drawing a different curve?

My asymptote code is:

import graph;

currentpicture=new picture;

size(10cm,10cm);
real R, r, d;

R=100;
r=2;
d=80;

real x(real t){return (R-r)*Cos(t)+d*Cos(((R-r)/2)*t);}
real y(real t){return (R-r)*Sin(t)-d*Sin(((R-r)/2)*t);}

draw(graph(x,y,0,360,n=10000,operator ..));


shipout("ipertrocoide");
Maurizio Vianello, Italy

[Dear Maurizio, it seems you are using 10000 evaluation points whereas I used only 1000. This might explain the small inaccuracies in my version which lead to every line being drawn multiple times slightly displaced. Your version seems the better one. — Yuri Robbers]

tpjlogo

Just read (skimmed, to be honest) Ista Zahn's article "Learning to Sweave in APA Style" in issue 2008-1, http://tug.org/pracjourn/2008-1/zahn/. It reminds me of something we're trying to do in computational linguistics, where we're using Literate Programming to embed linguistic rules in a document. We're actually using DocBook, but we use dblatex to convert the DocBook document into LaTeX form, and XeTeX to format that into a printable or displayable document.

One of the problems we've encountered is that of long tables. It seems to me that LaTeX is very good about formatting tables--if you know in advance how much room the table is going to occupy on the page. If you don't know that, then you can wind up with a table that runs off the end of the page, or tables that are split when they should have been floated, depending on which table package you use. There doesn't appear to be a single table package that handles both floating tables, and tables that are longer than a single page.

In our case, we can look at the final result and change the kind of DocBook table we use, and as a result the kind of LaTeX table that dblatex gives us. But that seems like it shouldn't be necessary; there ought to be a table package that looks at the size of a formatted table, and decides whether to leave it where it is, float it, or break it over a page (or perhaps both float it and break it over pages). This is surely not too hard for a computer to do (although maybe it was too hard for most people's computers to do fifteen or so years ago, when the table packages were written).

Even when we choose the right kind of table for a particular document, later changes to the document (or changes to the page size) may reveal other places where we should have chosen a different kind of table.

In the case of tables that are automatically produced by sweave, this seems like an even more severe problem. The table is not produced by hand--that's the whole point of using sweave--so there is no direct control over the length of the table.

So my question: On the assumption that the tables produced by sweave are normally floated, does it ever happen that sweave produces a table that is too long to fit on a single page? And if so, does sweave automatically compensate by using a different table package (one that allows multi-page tables) for that table?

If not (and I'm guessing it doesn't), isn't it time to have a table package that can float a table, or split a table over a page boundary, and figure out on its own when to do one or the other?

Mike Maxwell, USA

[I don't feel that I have much insight to offer on this issue. However, I'm happy to share what very little I do know.

I agree that it would be very nice to have a table environment that does "the right thing" depending on the size of the table. It is true that the xtable package in R defaults to a regular floating table environment, and that this will sometimes produce tables that do not fit on the page. The xtable R package can be used with the longtable packge (it can also be used with ctable, and sideways) but I am not aware of a way to have the program intelligently decide which environment to use. In my own personal use this is generally not too troublesome, because I rarely make use of long tables, and when I do I usually know ahead of time that the table will be too long to fit on a single page. So while I agree that it would be useful to have a package smart enough to place tables appropriately no matter what size they are, unfortunately I haven't the slightest idea how to go about doing this. Please let me know if you figure out a way!

Sincerely,

Ista Zahn]

tpjlogo


Page generated June 9, 2010 ; TUG home page; search; contact webmaster.