Re: [O] Enhancing table cell alignments and commenting columns (was Re: Orthogonality of blocks)

[Jambunathan K]

 I am wrong, the issue is not with the LibreOffice but with my memory.

 The srcblocks are actually aligned centrally (along the vertical axis)
 within the table cell. Since the two blocks are of different
 sizes/lengths the top border gets staggered.

 Changing the alignment to top will fix the issue.

I have pushed a fix to this effect. Table cells will now be
top-aligned by default in ODT export.
-- 

[O] Enhancing table cell alignments and commenting columns (was Re: Orthogonality of blocks)

[Jambunathan K]

Jambunathan K kjambunat...@gmail.com writes:

 Charles Turner chtu...@gmail.com writes:

 @Jambunathan: Your examples render the blocks with sizes proportional
 to the contained text, rather than aligning as a table. I find that
 aesthetically displeasing :-(

 I am unable to understand what sizes proportional to the contained
 text means. What viewer are you using?

 I am using a fairly recent version of LibreOffice (v3.4.4) and I see
 that the positions of the blocks are a bit staggered (See portions
 marked red in the attached png)

 Furthermore, the srcline where the cursor is - marked with an ellipse -
 uses OrgSrcBlockLastLine style. If the style were modified to
 OrgSrcBlock style, I see that the above staggering gets less
 accentuated. A plausible explanation for this behaviour is that the
 space below paragraph introduced by OrgSrcBlockLastLine spills over
 to the next paragraph which is in the second table column.

 One of the reasons that the staggering persists is because of the change
 in space settings between Text_20_body and OrgSrcBlock styles (Note
 that the Say Hello in ... lines and the src block lines use different
  fonts and font sizes and different paragraph styles)

 AFAIK, there is nothing amiss with the XML that the ODT exporter dumps
 and I am inclined to think that the issue is with LibreOffice rendering
 engine.

I am wrong, the issue is not with the LibreOffice but with my memory.

The srcblocks are actually aligned centrally (along the vertical axis)
within the table cell. Since the two blocks are of different
sizes/lengths the top border gets staggered.

Changing the alignment to top will fix the issue.

#+begin_src nxml :see OrgOdtContentTemplate.xml
style:style style:name=OrgTblCell style:family=table-cell
 @@@   
  style:table-cell-properties style:vertical-align=middle 
fo:padding=0.159cm fo:border-top=none fo:border-bottom=none 
fo:border-left=none fo:border-right=none/
/style:style
#+end_src

There colcookies that specify how a table column has to be
aligned. Currently there are specifiers only for left and right
alignment.

, (info (org) Column width and alignment)
|If you would like to overrule the automatic alignment of number-rich
| columns to the right and of string-rich column to the left, you can use
| `r', `c'(2) or `l' in a similar fashion.  You may also combine
| alignment and field width like this: `l10'.
`

I think it would be useful to specify a top alignment specifier. There
is also a recent interest in commenting out certain Org-table columns
[1].

I think the colcookie lines could be enhnaced to also support t and
/ characters. IMNSHO, using #+ATTR_ODT: lines for commenting out
columns will not only be cumbersome but also error-prone.

 ps: I am not much concerned xhtml exporter as it is mostly a museum
 piece cherished just by me.

Footnotes: 
[1]  http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00691.html

-- 

Re: [O] Enhancing table cell alignments and commenting columns (was Re: Orthogonality of blocks)

[Jambunathan K]

 I think the colcookie lines could be enhnaced to also support t and
 / characters. IMNSHO, using #+ATTR_ODT: lines for commenting out
 columns will not only be cumbersome but also error-prone.

A random thought:

I think there will be more flexibility if the colcookies characters -
l and r - were actually style strings (of length  1). The backend
can use their own discretion on how they apply these styles.

There was some interest to mark certain columns specially - for example,
mark automatically computed derived columns specially (both in Org and
may be in the different backends). The colcookie could line could be put
to some use here. (Question: Is there a way to fontify a rectangle in
Emacs?)

On a related note:

From ODT perspective and taking a cue from the way LibreOffice does
autoformatting of tables, I was thinking of introducing template
tables whose only job is to specify the styles to be associated with
each of the different categories of table cells.

OpenDocument talks of following types of columns and LibreOffice's
autoformatting is much richer and recognizes, I believe, as much as 16
categories of table cells.

, C-h v org-export-odt-table-styles
| TABLE-CELL-TYPE   := FirstRow   | LastColumn |
|  FirstRow   | LastRow|
|  EvenRow| OddRow |
|  EvenColumn | OddColumn  | 
| 
`

#+ATTR_ODT: template-table
| red | green | yellow |
|-+---+|
| |   ||

ps: I don't have time to implement the above features. I am just
capturing my thoughts so that it is archived.

--