From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Price Subject: Re: org->odt/html table export: adjusting default behaviour? Date: Fri, 26 Aug 2011 10:24:38 -0400 Message-ID: References: <81pqjtqife.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=90e6ba6e86ea373e0804ab694e4e Return-path: Received: from eggs.gnu.org ([140.186.70.92]:43151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwxKr-0000hh-Ij for emacs-orgmode@gnu.org; Fri, 26 Aug 2011 10:24:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QwxKq-0003XG-1t for emacs-orgmode@gnu.org; Fri, 26 Aug 2011 10:24:41 -0400 Received: from mail-qy0-f169.google.com ([209.85.216.169]:43381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwxKp-0003XC-UF for emacs-orgmode@gnu.org; Fri, 26 Aug 2011 10:24:40 -0400 Received: by qyk27 with SMTP id 27so448719qyk.0 for ; Fri, 26 Aug 2011 07:24:39 -0700 (PDT) In-Reply-To: <81pqjtqife.fsf@gmail.com> 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: Matt Price , Org Mode --90e6ba6e86ea373e0804ab694e4e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 25, 2011 at 5:40 PM, Jambunathan K wrote: > Matt Price writes: > >> The attached test file shows an org file with tables whose columns >> include substantial amounts of text. The default export to odt is >> pretty ugly in this case, and even in html (where things work to some >> extent) I would rather be able to control to some extent the way that >> long fields wrap. is there a recommended way to do set values like >> table and column width for these two exports? I guess I am >> particularly concerned with the odt export -- can I e.g. adjust a >> default value somewhere in the styles.xml file? I doubt the problem >> will be easily solved but if someone can point me in the right >> direction I'd really appreciate it. > > The issue is not that fields don't wrap well but that the table is big > for the width of the paper and columns are as a result getting > congested. yes, that's a better description. > > I have pushed a fix whereby tables now occupy bigger space [1]. > > I also noticed that columns are unevenly spaced. Now I have updated the > styles so that columns are equally spaced [2]. > > Orgmode exporters can never be layout engines. They are also typically > useful for personal (as opposed to professional) production. In some > sense they are good for handouts, pamphlets and drafts etc. So some > amount of hand fixing and finer adjustments would always be required. That makes sense, of course. My issue in this case is that I update this particular file quite frequently & store it online in a repository. It would be nice if I could code the table formatting into the org file so that I don't have to hand-fix the formatting on each iteration. But on the other hand, maybe a table isn't really the right tool in such a case -- as you suggest, a spreadsheet (or perhaps a structured outline, which org excels at) might be better. > > You choose a smaller font for text in the table with: > > F11->Paragraph Styles->OrgTableContents->Choose a smaller (say 10 pt) > font. that's helpful, and I can presumably save this change to my styles.xml file for future use. > > This will affect the text in all the tables. > > For the sake of documentation, > > Vertical and horizontal grid lines in the exported table correspond to > colgroups (specified in table cookie lines) and by horizontal rulers in > the org table [3]. You can use these grid lines in the Org file and > automatically the exporter will create the grid lines for you. > > If you need really prettier tables you can rely on Table->Autoformat. > > Footnotes: > [1] So there is now a reverse problem of tables with less number of > columns and not having copious text looking too big. But big is better > even if it is ugly. > > The workaround is to rely on Table Properties->Table->Width > > [2] Pre-processor in org-exp.el groks l, r, c cookies but ignores the > colwidth directives. With some changes these colwidth directives could > be used for controlling the relative width of columns on a per-table > basis. This has to wait. If there is sufficient demand I can consider > adding this support. > > The workaround is to rely on Table Properties->Columns->Column Width > > [3] The exporter wouldn't still create vertical lines on the extreme > ends. I believe the default style of tables is so selected based on some > standard styling manual. In my view the problem here is that Openoffie is difficult to work with for some of these formatting tasks -- so really this is an issue that's hard for you to fix. But for instance, I have had a lot of difficulty trying to change the colour of the timestamps -- in fact for now I've given up! But I think the issue might just be that LibreOffice/Openoffice doesn't redraw the document properly after certain style changes, so I can't actually tell whether my style changes (to OrgTimestamp and ORgTimestampWrapper character styles in the style manager, F11) have been effective. sorry that was a digression. Thanks so much for your help on this issue. matt --90e6ba6e86ea373e0804ab694e4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 25, 2011 at 5:40 PM, Jambunathan K <kjambunathan@gmail.com> wrote:
> Matt Price = <moptop99@gmail.com> writes= :
>
>> The attached test file shows =A0an org file with tables wh= ose columns
>> include substantial amounts of text. =A0The default= export to odt is
>> pretty ugly in this case, and even in html (w= here things work to some
>> extent) I would rather be able to control to some extent the way t= hat
>> long fields wrap. =A0is there a recommended way to do set v= alues like
>> table and column width for these two exports? I gues= s I am
>> particularly concerned with the odt export -- can I e.g. adjust a<= br>>> default value somewhere in the styles.xml file? I doubt the pro= blem
>> will be easily solved but if someone can point me in the r= ight
>> direction I'd really appreciate it.
>
> The issue = is not that fields don't wrap well but that the table is big
> fo= r the width of the paper and columns are as a result getting
> conges= ted.

yes, that's a better description.

>
> I have pushed= a fix whereby tables now occupy bigger space [1].
>
> I also n= oticed that columns are unevenly spaced. Now I have updated the
> sty= les so that columns are equally spaced [2].
>
> Orgmode exporters can never be layout engines. They are also t= ypically
> useful for personal (as opposed to professional) productio= n. In some
> sense they are good for handouts, pamphlets and drafts e= tc. So some
> amount of hand fixing and finer adjustments would always be required.<= br>That makes sense, of course. My issue in this case is that I update this= particular file quite frequently & store it online in a repository. It= would be nice if I could code the table formatting into the org file so th= at I don't have to hand-fix the formatting on each iteration.=A0 But on= the other hand, maybe a table isn't really the right tool in such a ca= se -- as you suggest, a spreadsheet (or perhaps a structured outline, which= org excels at) might be better.=A0

>
> You choose a smaller font for text in the table with:
&= gt;
> F11->Paragraph Styles->OrgTableContents->Choose a smal= ler (say 10 pt)
> =A0 font.
that's helpful, and I can presumab= ly save this change to my styles.xml file for future use.
>
> This will affect the text in all the tables.
>
> F= or the sake of documentation,
>
> Vertical and horizontal grid = lines in the exported table correspond to
> colgroups (specified in t= able cookie lines) and by horizontal rulers in
> the org table [3]. You can use these grid lines in the Org file and> automatically the exporter will create the grid lines for you.
>= ;
> If you need really prettier tables you can rely on Table->Auto= format.
>
> Footnotes:
> [1] So there is now a reverse problem of ta= bles with less number of
> columns and not having copious text lookin= g too big. But big is better
> even if it is ugly.
>
> Th= e workaround is to rely on Table Properties->Table->Width
>
> [2] Pre-processor in org-exp.el groks l, r, c cookies but igno= res the
> colwidth directives. With some changes these colwidth direc= tives could
> be used for controlling the relative width of columns o= n a per-table
> basis. This has to wait. If there is sufficient demand I can consider<= br>> adding this support.
>
> The workaround is to rely on T= able Properties->Columns->Column Width
>
> [3] The export= er wouldn't still create vertical lines on the extreme
> ends. I believe the default style of tables is so selected based on so= me
> standard styling manual.

In my view the problem here is t= hat Openoffie is difficult to work with for some of these formatting tasks = -- so really this is an issue that's hard for you to fix.=A0 But for in= stance, I have had a lot of difficulty trying to change the colour of the t= imestamps -- in fact for now I've given up! But I think the issue might= just be that LibreOffice/Openoffice doesn't redraw the document proper= ly after certain style changes, so I can't actually tell whether my sty= le changes (to OrgTimestamp and ORgTimestampWrapper character styles in the= style manager, F11) have been effective.=A0

sorry that was a digression.=A0 Thanks so much for your help on this is= sue.
matt


--90e6ba6e86ea373e0804ab694e4e--