From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Passing font size to exported LaTeX table Date: Wed, 01 Jun 2011 14:50:34 -0400 Message-ID: <8988.1306954234@alphaville.dokosmarshall.org> References: <80oc2s3v6k.fsf@somewhere.org> <5180.1306265114@alphaville.americas.hpqcorp.net> <6073.1306269772@alphaville.americas.hpqcorp.net> <6564.1306271566@alphaville.americas.hpqcorp.net> <6636.1306271949@alphaville.americas.hpqcorp.net> <20110527095013.385082e0@bhishma.homelinux.net> <20110527113013.253f79d9@bhishma.homelinux.net> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([140.186.70.92]:33617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRqVP-0007yf-Cr for emacs-orgmode@gnu.org; Wed, 01 Jun 2011 14:51:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRqVN-0000cz-5J for emacs-orgmode@gnu.org; Wed, 01 Jun 2011 14:50:59 -0400 Received: from vms173017pub.verizon.net ([206.46.173.17]:54564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRqVM-0000ch-R5 for emacs-orgmode@gnu.org; Wed, 01 Jun 2011 14:50:56 -0400 Received: from alphaville.dokosmarshall.org ([unknown] [173.76.32.106]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LM400CZ0KCAFFA0@vms173017.mailsrvcs.net> for emacs-orgmode@gnu.org; Wed, 01 Jun 2011 13:50:40 -0500 (CDT) In-reply-to: Message from tsd@tsdye.com (Thomas S. Dye) of "Fri, 27 May 2011 11:25:05 -1000." List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Thomas S. Dye" Cc: Sebastien Vauban , emacs-orgmode@gnu.org, nicholas.dokos@hp.com Thomas S. Dye wrote: > Suvayu Ali 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): 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. 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. 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.