Thomas S. Dye <t...@tsdye.com> wrote:
> Suvayu Ali <fatkasuvayu+li...@gmail.com> writes:
>
> > I am not very familiar with org-latex internals. Based on my limited
> > understanding I wrote the attached patch to the org manual. I hope it
> > is up to par.
> >
>
> [patch snipped]
>
> This looks like an improvement to me. I'd be interested to hear what
> Nick and Seb might have to say. They often catch things I miss.
>
> If you don't get other comments, I'd encourage you to submit this as a
> patch (I think this requires [PATCH] in the subject line) to see what
> Carsten and crew have to say about it.
>
> Thanks again for finding this solution to specifying the font size for
> floating tables on a table-by-table basis in LaTeX export. I'd been
> looking for your solution, and for Nick's solution that works on a
> per-document or buffer basis, for many months without success.
>
Maybe I can contribute some commentary to the code and ask Suvayu to perhaps
amend the patch to clarify some things (but see my editorial comment at
the end of the email):
<code commentary>
There are two parts to the code: one is in org-exp.el,
org-export-attach-captions-and-attributes(), which matches caption,
label and attr_latex lines and adds text properties for later use by the
export backend. It figures out whether the following item is a table or
a link and it adds the appropriate text property (or properties - one or
more can be present for a given itme) to the item: either the whole
table[fn:1] or the line containing the link. There are three different
properties corresponding to the #+foo construct: 'org-caption,
'org-labeland and 'org-attributes.
The second part is in the specific backend - latex in this case (I did
not look at the others). There are two cases: tables and links.
The table case is handled by org-export-latex tables. It gets the
caption label and attributes from the corresponding text property. It
then further parses the string it gets from the 'org-attributes property
to figure out:
- whether this is a longtable (a table spanning multiple pages)
(syntax: the string "longtable" as a word)
- whether it's a table or a table* (syntax: the string itself)
- whether it's a tabular (syntax: the string "tabular" followed by a
single char - that's to catch the tabular*, tabularx and tabulary
cases I believe).
- what the width is (syntax: "width=XXX" where XXX is a sequence of
anything but white space and there is a word boundary before
"width" - i.e. " width=foo" will set the width to foo but "
linewidth=foo" will not).
- what the alignment is (syntax: same as width but with "align"
instead)
- what the placement is (syntax: "placement=XXX" - where XXX is a
string of one or more non-white-space characters.
Suvayu's method works by taking advantage of the fact that the placement
"value" (i.e. the string to the right of the equal sign) does not
contain white space and copies the whole thing as the placement value in
the correct place in the table environment. LaTeX then parses this and
breaks it up into placement and \scriptsize constructs. Since org adds
the placement info to the table environment, \scriptsize sneaks in by
the back door, so to speak.
In the case of a link (which presumably points to an image and handled by
org-export-latex-links and org-export-latex-format-image), the parsing
of the property figures out
- whether to use wrapfigure (syntax: "wrap" as a word)
- whether to use the figure env (syntax: "float" as a word)
- whether to use the figure* env (syntax: "multicolumn" as a word)
- what the placement is (syntax: same as above)
In addition, whether there is a caption or a label determines whether
the figure is floated or inlined.
</code commentary>
<soapbox> I've tried to keep a neutral tone in (most of) the rest of the
mail, but I have to say that I think clever hacks like this are too
clever for their own good - they are at best an accident of
implementation. The fact that the trick uses the placement option in
order to change the font testifies to that. They should certainly be
documented as hacks on Worg, but I'm not sure they should be documented
in the manual. Of course, it may happen that a really good hack (by some
definition of "really good") should be elevated to a standard and
documented in the manual, but IMO this one does not qualify. </soapbox>
Comments, corrections, additions are more than welcome.
Nick
Footnotes:
[fn:1] BTW, the documentation of the function says that the property is
added to the first line of the table, but unless I misread the code,
that's wrong: it gets added to the whole table.
