emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nick Dokos <ndokos@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Printable calendar?
Date: Fri, 30 May 2014 13:20:21 -0400	[thread overview]
Message-ID: <87ha47kwtm.fsf@alphaville.bos.redhat.com> (raw)
In-Reply-To: 20140530152342.GD25389@pdavismbp15.iscinternal.com

Peter Davis <pfd@pfdstudio.com> writes:

> Ok, I was able to get the column rules I want. (See below)
>
> I'm still puzzled by the right/left alignment. In the org buffer the
> columns appear correctly aligned, but in HTML output, the left (Sun)
> and right (Sat) columns are right-aligned,
> while all the others are left-aligned.
>
> Clues?
>

You can force the misbehaving columns to behave - more or less: the M
value on the 17th will cause problems (btw, I prefer
to have a non-exported "zeroth" column for things like / and !
that are basically table metadata - see (info "(org) Advanced features")
for details):


--8<---------------cut here---------------start------------->8---
#+ATTR_HTML: :border 2 :frame border
|   | Sun      | Mon     | Tue     | Wed     | Thu     | Fri     | Sat      |
|---+----------+---------+---------+---------+---------+---------+----------|
| / | <l>      | <>      | <>      | <>      | <>      | <>      | <l>      |
|---+----------+---------+---------+---------+---------+---------+----------|
|   |          |         |         |         | 1       | 2       | 3        |
|   |          |         |         |         |         |         |          |
|   |          |         |         |         | AM: 3.6 | AM: 3.6 | AM: 7.6  |
|   |          |         |         |         | PM: 3.7 | PM: 3.7 | AM: 7.6  |
|---+----------+---------+---------+---------+---------+---------+----------|
|   | 4        | 5       | 6       | 7       | 8       | 9       | 10       |
|   |          |         |         |         |         |         |          |
|   | AM: 11.4 | AM: 3.7 | AM: 3.7 | AM: 5.1 | AM: 3.6 | AM: 3.3 | AM: 5.1  |
|   |          | PM: 3.3 | PM: 3.3 |         | PM: 3.3 | PM: 3.3 |          |
|---+----------+---------+---------+---------+---------+---------+----------|
|   | 11       | 12      | 13      | 14      | 15      | 16      | 17       |
|   |          |         |         | *BIKE*  |         |         | AM: 7.6  |
|   |          | AM: 3.7 | AM: 3.7 | AM: 9.2 | AM: 3.7 | AM: 3.7 | M: 6.1   |
|   |          | PM: 3.3 | PM: 3.3 | PM: 9.7 | PM: 3.3 | PM: 3.3 | PM: 13.3 |
|---+----------+---------+---------+---------+---------+---------+----------|
|   | 18       | 19      | 20      | 21      | 22      | 23      | 24       |
|   |          |         |         |         |         |         |          |
|   |          | AM: 3.7 | AM: 3.6 | AM: 3.7 | AM: 3.7 | AM: 7.0 | AM: 5.5  |
|   |          | PM: 3.2 | PM: 3.3 | PM: 3.3 | PM: 3.3 |         |          |
|---+----------+---------+---------+---------+---------+---------+----------|
|   | 25       | 26      | 27      | 28      | 29      | 30      | 30       |
|   | *BIKE*   |         |         | *TRIKE* |         |         |          |
|   | AM: 16.2 |         | AM: 3.6 |         | AM: 3.8 | AM: 3.6 |          |
|   |          | PM: 5.1 | PM: 3.3 | PM: 7.3 | PM: 3.3 |         |          |
|---+----------+---------+---------+---------+---------+---------+----------|
--8<---------------cut here---------------end--------------->8---

The misbehaviour is caused by the heuristic used in
org-export-table-cell-alignment:

,----
| Return alignment as specified by the last alignment cookie in the
| same column as TABLE-CELL.  If no such cookie is found, a default
| alignment value will be deduced from fraction of numbers in the
| column (see `org-table-number-fraction' for more information).
`----

You can play around with org-table-number-fraction (default: 0.5) to
change the behaviour. A value of 0.25 will right-align them all, whereas
a value of 0.75 will left-align them all. But I wouldn't want to bet my
life on that: it depends on the contents of the table so it seems like a
fragile solution at best.

BTW, the 0.25 and 0.75 values above are purely trial-and-error (actually
derived from the smallest ratio I found edebugging over the columns:
6/21).

Nick

Footnotes:

[fn:1] The heuristic counts empty cells as numbers if the non-empty row
       above it is a number, so for the first column for example, there
       are 21 cells and 11 of them are "numbers".
       

  reply	other threads:[~2014-05-30 17:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-30 14:20 Printable calendar? Peter Davis
2014-05-30 15:23 ` Peter Davis
2014-05-30 17:20   ` Nick Dokos [this message]
2014-05-31 12:32     ` Peter Davis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ha47kwtm.fsf@alphaville.bos.redhat.com \
    --to=ndokos@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).