Exporting to groff...

Exporting to groff...

[Luis Anaya]

Hi:

Being that groff is not available in org mode (at least by default, I 
decided to give it a try and write a driver to export Org files into 
groff with the use of the -mm macros. 

Being that I'm not familiar with many of the facilities in Org mode, 
I am modifying the org-latex.el to write groff markups. 

In its current incarnation it exports the titles, content and basic
support for tables

You can see the resultant output at:  http://ppl.ug/1_8pA3lpXWA/

Really messy code currently in http://github.com/papoanaya/emacs_utils

Regards,

-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff...

[Nick Dokos]

Luis Anaya <papoanaya@hotmail.com> wrote:

> Hi:
> 
> Being that groff is not available in org mode (at least by default, I 
> decided to give it a try and write a driver to export Org files into 
> groff with the use of the -mm macros. 
> 
> Being that I'm not familiar with many of the facilities in Org mode, 
> I am modifying the org-latex.el to write groff markups. 
> 
> In its current incarnation it exports the titles, content and basic
> support for tables
> 
> You can see the resultant output at:  http://ppl.ug/1_8pA3lpXWA/
> 
> Really messy code currently in http://github.com/papoanaya/emacs_utils
> 

If you are going to continue working on this and take it further, it
would be a good idea to change your starting point: org-latex.el is on
its way to extinction, to be replaced by Nicolas Goaziou's "new"
exporter. The code for that is in contrib/lisp/org-export.el, and the
latex/html/ascii backends are implemented in
contrib/lisp/org-e-{latex,html,ascii}.el. They are all based on a "real"
org parser in contrib/lisp/org-elements.el, as opposed to the ad-hoc
collection that the current backends use.

Nick

Re: Exporting to groff...

[Luis Anaya]

Nick Dokos <nicholas.dokos@hp.com> writes:

Hi Nick!


> would be a good idea to change your starting point: org-latex.el is on
> its way to extinction, to be replaced by Nicolas Goaziou's "new"
> exporter. The code for that is in contrib/lisp/org-export.el


Oh... ok.. good! I have no problem taking a look at it. I'll just create
a groff exporter based on that code then. I have a vested interest being
that I am more versed in ?roff than LaTeX. I worked with those macros
for a good chunk of my work life. :). 

The org-latex.el seemed like a good place to use as my base. 

Thanks!



-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff...

[Nicolas Goaziou]

Hello,

Luis Anaya <papoanaya@hotmail.com> writes:

> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> would be a good idea to change your starting point: org-latex.el is on
>> its way to extinction, to be replaced by Nicolas Goaziou's "new"
>> exporter. The code for that is in contrib/lisp/org-export.el
>
> Oh... ok.. good! I have no problem taking a look at it. I'll just create
> a groff exporter based on that code then. I have a vested interest being
> that I am more versed in ?roff than LaTeX. I worked with those macros
> for a good chunk of my work life. :). 

Also, you have some documentation for back-end developers at:

  http://orgmode.org/worg/dev/org-export-reference.html


Regards,

-- 
Nicolas Goaziou

Exporting to groff, now in org-export.el ...

[Luis Anaya]

> 
> > Nick Dokos <nicholas.dokos@hp.com> writes:
> >
> >
> > Oh... ok.. good! I have no problem taking a look at it. I'll just create
> > a groff exporter based on that code then. I have a vested interest being
> 
> Also, you have some documentation for back-end developers at:
> 
>   http://orgmode.org/worg/dev/org-export-reference.html
> 

Hi:

First release (?!) of the org-e-groff.el is available. I still need to do more testing
but it manages to export from org. 
 
The code is in the same github location, http://github.com/papoanaya/emacs_utils. 

Sample Output at http://ppl.ug/VzS3BGQjFgw/

One thing I have not managed to export are the deadlines/scheduled dates. 
The code to export and add the appropriate markup is completed, but 
that code is not running. 

I am aware that there is a flag at org-export.el to control the output,  but they are 
all "t".  Before I go all crazy on this, I need to ask if this is a feature to control its output
or am I missing something that I should take a look.

Thanks a bunch.


Luis

 		 	   		  

Re: Exporting to groff, now in org-export.el ...

[Nicolas Goaziou]

Hello,

Luis Anaya <papoanaya@hotmail.com> writes:

> First release (?!) of the org-e-groff.el is available. I still need to
> do more testing but it manages to export from org.

Thanks for that new back-end.

> The code is in the same github location,
> http://github.com/papoanaya/emacs_utils.

I see this is based on org-e-latex.el.  While this is a fast way to have
a back-end running in the short term, it adds a lot of useless code (for
example footnote handling is very specific and, as such, probably wrong
on your back-end) and I'm not sure it will be a win in the long run.

For future back-ends, I suggest to use an incremental approach, starting
from scratch and adding features and transcoders step by step.
Complexity can wait.

Also, the way e-latex handles attributes isn't an example to follow: it
uses "key=value" instead of ":key value".  If you use the latter, you
can benefit from `org-export-read-attribute' function.

Speaking of attributes, org-e-groff.el has to add "ATTR_GROFF" to both
`org-element-affiliated-keywords' and `org-element-multiple-keywords'.

> One thing I have not managed to export are the deadlines/scheduled dates. 
> The code to export and add the appropriate markup is completed, but 
> that code is not running.

By default, planning info are not exported.  See
`org-export-with-planning' variable.

> I am aware that there is a flag at org-export.el to control the
> output,  but they are all "t".  Before I go all crazy on this, I need
> to ask if this is a feature to control its output or am I missing
> something that I should take a look.

Are you talking about org-export-with-* variables?  Some of them have
a nil value (planning is an example). What do you want to know about
them?


Regards,

-- 
Nicolas Goaziou

Re: Exporting to groff, now in org-export.el ...

[Nicolas Goaziou]

Correcting myself,

> Speaking of attributes, org-e-groff.el has to add "ATTR_GROFF" to both
> `org-element-affiliated-keywords' and `org-element-multiple-keywords'.

Please scratch that.  No need to register "attr" keywords anymore since
last commit.

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

Ok, no attributes then :)

I just fixed footnotes, only automated footnotes  for now
I have to wait until I get home when I get a hold of my
UNIX MM book to get custom footnote markers added. 

(I'm on the road on holidays... before you ask, my wife's cousins
are in town. sitting down coding in Emacs LISP is a welcome break).

In terms of keywords, they all have to be revised, and many of them
are going to be removed. (Like long tables). I'll changed them from 
tag=value to :blah value, right now they're not really meaningful for
groff and many of them stubbed. 

I proposed to keep an eye on my github repository. I'll be working
on it and hopefully should be ready for prime time. 

(If I do not collapse of exhaustion taking care of them. :( )

Luis

 		 	   		  

Re: Exporting to groff, now in org-export.el ...

[Nicolas Goaziou]

Hello,

Luis Anaya <papoanaya@hotmail.com> writes:

> In terms of keywords, they all have to be revised, and many of them
> are going to be removed. (Like long tables). I'll changed them from 
> tag=value to :blah value, right now they're not really meaningful for
> groff and many of them stubbed.

Ok.

> I proposed to keep an eye on my github repository. I'll be working
> on it and hopefully should be ready for prime time. 

I can't promise to keep an eye on the repository, but if you have any
question (if possible with an example to illustrate it, as I don't know
groff syntax), do not hesitate to ask.

> (If I do not collapse of exhaustion taking care of them. :( )

There's the `sleep-for' function for that.


Regards,

-- 
Nicolas Goaziou

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> I can't promise to keep an eye on the repository, but if you have any
> question (if possible with an example to illustrate it, as I don't know
> groff syntax), do not hesitate to ask.
>

Thanks, I will. The only concern that I have is that there are times
that export hangs.  I need to figure that one out, I'll keep you
posted. 

>> (If I do not collapse of exhaustion taking care of them. :( )
>
> There's the `sleep-for' function for that.

:)

It'll execute for a looong time over the weekend 

:)

In other news I added various enhancements. Including:

1. Automated caption support. I need to figure out how to get the
caption text (via CAPTION? via ATTR ? ). Right now generic ones are
added which they show up in the table of content. 

2. EPS diagrams import support. I mostly needs it for plantuml
diagrams. Groff only supports ps and eps only. But automated plantuml
diagrams do get created and inlined (via .PSPIC) when the file is exported.

3. Quotes and Verse support.  Currently hardcoded to helvetica. I should think of
customizing fonts via defcustom, but for now, this is it.

4. Improvements on footnotes. Currently creating footnotes by taking the
value from :label. 

5. Lists (numeric and bullets). 

Sample output is here:

http://ppl.ug/xgZ7dmDq43Q/


I have a general question though. Equation and Picture creation 
support in Groff is done with the use of the "eqn" and "pic" programs. 
I've been debating if these should be included in org-babel, 
for executing these the same way plantuml is  executed through the use
of #+begin_src #+end_src 

However considering that these are Groff only I'm not sure if these
would be better served by using special attributes to add pic/eqn
code. This is because the output of these commands are Groff statements
that only make sense in Groff. 

??!!

Thanks!

-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[Nicolas Goaziou]

Hello,

Luis Anaya <papoanaya@hotmail.com> writes:

> 1. Automated caption support. I need to figure out how to get the
> caption text (via CAPTION? via ATTR ? ). Right now generic ones are
> added which they show up in the table of content.

This is done through :caption property:

  (org-element-property :caption some-element)

Note that when non nil, the value of this property is a list of two
secondary strings: CAR is the regular caption while CDR in the
(optional) short caption. Also, don't forget to send them through
`org-export-data'. Here's a snippet illustrating this:

#+begin_src emacs-lisp
(let ((caption (org-element-property :caption element)))
  ;; This how you get the long caption.
  (org-export-data (car caption) info)
  ;; This is how you get the short caption or the empty string.
  (org-export-data (cdr caption) info))
#+end_src

> I have a general question though. Equation and Picture creation 
> support in Groff is done with the use of the "eqn" and "pic" programs. 
> I've been debating if these should be included in org-babel, 
> for executing these the same way plantuml is  executed through the use
> of #+begin_src #+end_src 
>
> However considering that these are Groff only I'm not sure if these
> would be better served by using special attributes to add pic/eqn
> code. This is because the output of these commands are Groff statements
> that only make sense in Groff.

You can also write raw Groff code within #+begin_groff...#+end_groff,
provided that you modify `org-element-block-name-alist' accordingly and
define a transcoder for export blocks like the following:

#+begin_src emacs-lisp
(defun org-e-groff-export-block (export-block contents info)
  "Transcode a EXPORT-BLOCK element from Org to GROFF.
CONTENTS is nil.  INFO is a plist holding contextual information."
  (when (equal (org-element-property :type export-block) "GROFF")
    (org-remove-indentation (org-element-property :value export-block))))
#+end_src


Regards,

-- 
Nicolas Goaziou

#+CAPTION: Not being protected when they are used with #+begin_src

[Luis Anaya]

From the documentation, I know that captions work with inline images
and tables, but for some reason when then inline images are generated
through org-babel, #+CAPTION keys turns into regular text. What am I
doing wrong now? :)

-- ORG Source --

#+TITLE: Graphic Tests
#+AUTHOR: Luis R. Anaya
#+GROFF_ATTR: :alignment center
#+GROFF_CLASS: file
* PlantUML
#+CAPTION: plantuml drawing
#+begin_src plantuml :cmdline -Teps :file x.eps
[A] --> [B]
#+end_src
* Gnuplot
#+CAPTION: gnuplot drawing
#+begin_src gnuplot :file salida.pic
set term gpic
plot sin(x)
#+end_src

-- Groff Output --

.MT 1
.H 1 "PlantUML"
.P
#+CAPTION: plantuml drawing
.P
.PSPIC "x.eps"
.FG "" 
.H 1 "Gnuplot"
.P
#+CAPTION: gnuplot drawing
.P
.PS
copy "salida.pic"
.PE
.FG "" 

---

Resultant output in PDF at:  http://ppl.ug/YGVUBTwhknY/

Regards,

-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: #+CAPTION: Not being protected when they are used with #+begin_src

[Eric Schulte]

Luis Anaya <papoanaya@hotmail.com> writes:

> From the documentation, I know that captions work with inline images
> and tables, but for some reason when then inline images are generated
> through org-babel, #+CAPTION keys turns into regular text. What am I
> doing wrong now? :)
>

Instead of putting the #+Caption: line on the source block, place it on
the result.  This requires the use of named code blocks and results.
The following alternate version of your example should give the behavior
you're after.

--8<---------------cut here---------------start------------->8---
#+TITLE: Graphic Tests
#+AUTHOR: Luis R. Anaya
#+GROFF_ATTR: :alignment center
#+GROFF_CLASS: file

* PlantUML
#+name: plantuml-drawing
#+begin_src plantuml :cmdline -Teps :file x.eps
[A] --> [B]
#+end_src

#+CAPTION: plantuml drawing
#+RESULTS: plantuml-drawing
[[file:x.eps]]

* Gnuplot
#+name: gnuplot-drawing
#+begin_src gnuplot :file salida.pic
set term gpic
plot sin(x)
#+end_src

#+CAPTION: gnuplot drawing
#+RESULTS: gnuplot-drawing
[[file:salida.pic]]
--8<---------------cut here---------------end--------------->8---

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: #+CAPTION: Not being protected when they are used with #+begin_src

[Luis Anaya]

Eric Schulte <eric.schulte@gmx.com> writes:

>
> Instead of putting the #+Caption: line on the source block, place it on
> the result.  This requires the use of named code blocks and results.
> The following alternate version of your example should give the behavior
> you're after.
>
[chomp...]

Hi Eric:

Thanks for your help but not quite what I expected.  I did get the
caption now, but I am still getting the #+NAME:

See results:

.H 1 "PlantUML"
.P
#+NAME: plantuml-drawing
.P
.PSPIC "x.eps"
.FG "\fRplantuml drawing\fP" 
.H 1 "Gnuplot"
.P
#+name: gnuplot-drawing
.P
.PS
copy "salida.pic"
.PE
.FG "\fRgnuplot drawing\fP" 


I'm getting suspicious on the ".P" on my results during paragraph
generation. What I'll do is to temporary remove generating that ".P" and see
if that removes the #+NAME: tag. If that's the case, I have to add
another exception clause on the backend... 

Thanks a bunch!

-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: #+CAPTION: Not being protected when they are used with #+begin_src

[Nicolas Goaziou]

Hello,

Luis Anaya <papoanaya@hotmail.com> writes:

> Eric Schulte <eric.schulte@gmx.com> writes:
>
>>
>> Instead of putting the #+Caption: line on the source block, place it on
>> the result.  This requires the use of named code blocks and results.
>> The following alternate version of your example should give the behavior
>> you're after.
>>
> [chomp...]
>
> Hi Eric:
>
> Thanks for your help but not quite what I expected.  I did get the
> caption now, but I am still getting the #+NAME:
>
> See results:
>
> .H 1 "PlantUML"
> .P
> #+NAME: plantuml-drawing
> .P
> .PSPIC "x.eps" .FG "\fRplantuml drawing\fP" .H 1 "Gnuplot" .P
> #+name: gnuplot-drawing
> .P
> .PS
> copy "salida.pic"
> .PE
> .FG "\fRgnuplot drawing\fP" 
>
>
> I'm getting suspicious on the ".P" on my results during paragraph
> generation. What I'll do is to temporary remove generating that ".P" and see
> if that removes the #+NAME: tag. If that's the case, I have to add
> another exception clause on the backend... 

This is the known bug I told you about in another thread. It will be
fixed soon after org-element hits core.


Regards,

-- 
Nicolas Goaziou

Re: #+CAPTION: Not being protected when they are used with #+begin_src

[Luis Anaya]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

Hi:

> This is the known bug I told you about in another thread. It will be
> fixed soon after org-element hits core.

Oh... I guess I missed that email :(  At least I know that named captions are 
working for images. 

In other news...

Other things I got working today are:

1. Checklists, in Groff will be: White bullet for on, Black bullet for
off and hyphen. These map to .BL command. 
2. Descriptive lists. It maps to a .VL statement with an inch separation (2.54 cm's
for those in metric) between item and description.
3. Inline links for image types [[file:image.eps]] resolves to .PSPIC
"image.eps" while a [[file:image.pic]] link resolves to a .PS/.PE pair. 
4. Gnuplot support, embeds gpic or eps. You get better results with gpic. 
5. Direct Groff commands. Now equations can be embedded. (via EQ/EN/EC)
commands. 
6. Cleaned up some of the links output to make it look pretty :)


-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

In case you were curious how today's updates look like (if you're not,
then yeah, I'm showing up :) ),  samples of these can be found at:

Sources:

graph.org - http://ppl.ug/droqQrYmMkw/
todo.org - http://ppl.ug/W6RBCb7gNAs/

PDF results:

graph.pdf - http://ppl.ug/YGVUBTwhknY/
todo.org - http://ppl.ug/c1TZGeedv3Y/


I also added a small feature to include groff files if they are placed
in links.  The groff exporter as it stands has very minimal support for
links, these will just be printed as text. However being that groff 
can include files, I throught that it would be nice if groff files were 
included instead having their path printed out.

Hence

[[file:myfile.groff]]

Will map to an include call, namely to:

.so myfile.groff

When the org file is exported, myfile.groff will be included as part of the
export process and written in the resultant PDF file.


Regards,


-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

I should clarify that image files that are supported in groff, get
inlined when a link is written. 

Hence,

[[file:image.eps]] or
[[file:image.pic]]

Will include the image and write the image in the resultant PDF file.

Sorry if I confused anybody... :(

-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[suvayu ali]

Hi Luis,

The outputs look great. However I have a question; I see all the PDFs
have the content pages at the end instead of the front. Is there any
particular reason for that?

Keep up the good work. :)

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

suvayu ali <fatkasuvayu+linux@gmail.com> writes:

Hi Sevayu!

>
> have the content pages at the end instead of the front. Is there any
> particular reason for that?

Yes there is a reason. 

The MM implementation of table of contents collects all the headers and
captions that have read up to the point of execution of the table of
content command. 

If you want to collect all the headers, the table of content command 
must be placed at the end.  The idea was that you placed those pages in the right order
before "shipping" the document after printing. Now in the day of PDF
files, it may look weird to have it there but being that the
implementation of the macro has not changed, it still needs to be the
last command in the document.




-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[suvayu ali]

Hi Luis,

On Sun, Jul 8, 2012 at 3:49 AM, Luis Anaya <papoanaya@hotmail.com> wrote:
> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
>
> Hi Sevayu!
>
>>
>> have the content pages at the end instead of the front. Is there any
>> particular reason for that?
>
> Yes there is a reason.
>
> The MM implementation of table of contents collects all the headers and
> captions that have read up to the point of execution of the table of
> content command.
>
> If you want to collect all the headers, the table of content command
> must be placed at the end. The idea was that you placed those pages in
> the right order before "shipping" the document after printing. Now in
> the day of PDF files, it may look weird to have it there but being
> that the implementation of the macro has not changed, it still needs
> to be the last command in the document.

Ah, so it's a legacy reason. It is always great to learn about history.
:) Maybe this information would be worth mentioning in the future
documentation for the groff exporter.

Thanks,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

suvayu ali <fatkasuvayu+linux@gmail.com> writes:


>> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
>> Yes there is a reason.
>
> Ah, so it's a legacy reason. It is always great to learn about history.
> :) Maybe this information would be worth mentioning in the future
> documentation for the groff exporter.

Yeah, I would say it is more of an implementation reason, but legcy will
do as well. :).  I tried the same with the MOM and MS macros, same
results. Table of content command needs to be placed at the end of the
file and it will be printed at the end. 

I'm aware that documentation is lacking, but this code is still in quite 
active development. I have been making comments relevants as I go by
through the code. 

Today is my last day of holidays though; the rate of development will
slow down. 

(at least my wife's cousins are gone... )



-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[Suvayu Ali]

On Sun, Jul 08, 2012 at 09:14:14AM -0400, Luis Anaya wrote:
> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
> > :) Maybe this information would be worth mentioning in the future
> > documentation for the groff exporter.
> 

[...]

> I'm aware that documentation is lacking, but this code is still in quite 
> active development. I have been making comments relevants as I go by
> through the code. 
> 

I didn't mean now. :-p I meant when this backend gets included in org
core (not contrib, as org-export is now), it might be worthwhile comment
for the info manual. Just something keep in mind for the future. :)

-- 
Suvayu

Open source is the future. It sets us free.

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

Hi:

Ok, got global table control coded. I still need to figure out how to perform
column control. 

Source:      http://ppl.ug/H8mbZtyn7AQ/
PDF Output:  http://ppl.ug/tvl9DIWIABo/

Now off to put the recyclables on the curb for collection. 


-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

Hi:

Last but not least, source code highlight support. Unlike LaTeX, there
is no package for source code highlight in groff. Looking around, I
decided to use GNU source highlight as a solution. The reason being 
that the way output definitions are declared is through the use of
configuration files. In this way, I created one for groff (I should
submit it for inclusion... we'll see).  I have also saw it in use in the
WXE editor, hence I'm sort of familiar. However, most importantly, 
it supports COBOL :). 

(well, it does... its importance may be in question... )

This feature is controlled by a variable. If it is nil, it shows
the code listing using the courier font (constant width). 

Source: 
   http://ppl.ug/LN7rEdf2yS4/

PDF Output:
   http://ppl.ug/FfaTWqLLwEA/

All right... what else I need to do now? :)


-- 
Luis R. Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[suvayu ali]

Hi Luis,

On Mon, Jul 9, 2012 at 10:32 PM, Luis Anaya <papoanaya@hotmail.com> wrote:
> Hi:
>
> Last but not least, source code highlight support. Unlike LaTeX, there
> is no package for source code highlight in groff. Looking around, I
> decided to use GNU source highlight as a solution. The reason being
> that the way output definitions are declared is through the use of
> configuration files. In this way, I created one for groff (I should
> submit it for inclusion... we'll see).  I have also saw it in use in the
> WXE editor, hence I'm sort of familiar. However, most importantly,
> it supports COBOL :).
>
> (well, it does... its importance may be in question... )
>
> This feature is controlled by a variable. If it is nil, it shows
> the code listing using the courier font (constant width).
>
> Source:
>    http://ppl.ug/LN7rEdf2yS4/
>
> PDF Output:
>    http://ppl.ug/FfaTWqLLwEA/
>
> All right... what else I need to do now? :)
>

I see all the source blocks are black, but the tokens are emphasised
properly as per the syntax. Is it supposed to be like that (as in black
text not coloured as minted does for LaTeX export)?

-- 
Suvayu

Open source is the future. It sets us free.

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

suvayu ali <fatkasuvayu+linux@gmail.com> writes:

Hi:

> I see all the source blocks are black, but the tokens are emphasised

Correct.

> properly as per the syntax. Is it supposed to be like that (as in
> black

Yes.

> text not coloured as minted does for LaTeX export)?

Correct. However the reason is because of the way I wrote groff definition 
in GNU source highlight.  (i. e. black and white only). 

GNU source highlight does support colorization. It is a matter of
mapping those colors to the right code in groff. Frankly, I've never used
colorization in groff before. I just need to try it though... 

Well, I guess something else to do :)


-- 
Luis R. Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[suvayu ali]

On Mon, Jul 9, 2012 at 11:55 PM, Luis Anaya <papoanaya@hotmail.com> wrote:
> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
>
> Hi:
>
>> I see all the source blocks are black, but the tokens are emphasised
>
> Correct.
>
>> properly as per the syntax. Is it supposed to be like that (as in
>> black
>
> Yes.
>
>> text not coloured as minted does for LaTeX export)?
>
> Correct. However the reason is because of the way I wrote groff definition
> in GNU source highlight.  (i. e. black and white only).
>
> GNU source highlight does support colorization. It is a matter of
> mapping those colors to the right code in groff. Frankly, I've never used
> colorization in groff before. I just need to try it though...
>
> Well, I guess something else to do :)
>

Glad that my comments urged you. :)

-- 
Suvayu

Open source is the future. It sets us free.

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

suvayu ali <fatkasuvayu+linux@gmail.com> writes:

>> Correct. However the reason is because of the way I wrote groff definition
>> in GNU source highlight.  (i. e. black and white only).
>>
>> GNU source highlight does support colorization. It is a matter of
>> mapping those colors to the right code in groff. Frankly, I've never used
>> colorization in groff before. I just need to try it though...
>>
>> Well, I guess something else to do :)
>>
>
> Glad that my comments urged you. :)

:P

I had to read on how to put colors in groff, at least I learned 
something new today :). 

Colorized version:
Source: http://ppl.ug/LN7rEdf2yS4/
PDF Output: http://ppl.ug/wlA1QvIDNSk/

You'll notice that DUMMY refers to a #+begin_src dummy, this will
default to black and white in constant width. This will happen if the
language is not in the list of language that is stored in 
org-e-groff-listings-langs. 

Being that GNU source highlight allows for the creation of
new language colorization schemes.  This variable will need to be 
updated accordingly when a new language is added in source highlight to get it
colorized/highlighted.

Otherwise, it will default to courier, black and white. 


-- 
Luis R. Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[suvayu ali]

Hey Luis,

Looks good,

On Tue, Jul 10, 2012 at 2:00 AM, Luis Anaya <papoanaya@hotmail.com> wrote:
>
> I had to read on how to put colors in groff, at least I learned
> something new today :).
>
> Colorized version:
> Source: http://ppl.ug/LN7rEdf2yS4/
> PDF Output: http://ppl.ug/wlA1QvIDNSk/
>
> You'll notice that DUMMY refers to a #+begin_src dummy, this will
> default to black and white in constant width. This will happen if the
> language is not in the list of language that is stored in
> org-e-groff-listings-langs.
>
> Being that GNU source highlight allows for the creation of new
> language colorization schemes. This variable will need to be updated
> accordingly when a new language is added in source highlight to get it
> colorized/highlighted.
>

Does that mean a user can add any new language like this with her/his
definitions in their personal setup? If that is possible it would be
a really flexible setup.

> Otherwise, it will default to courier, black and white.

The defaults look pretty good for a fallback. :)

Sorry to nitpick, but I was wondering if it would be possible to put
some regular text in your example before or after the source blocks. It
would be good to see whether they stand out well when surrounded by
normal text.

BTW, great work. :)

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

suvayu ali <fatkasuvayu+linux@gmail.com> writes:

Hi:

> Does that mean a user can add any new language like this with her/his
> definitions in their personal setup? If that is possible it would be
> a really flexible setup.

Yes. If you sit down and create the language specification in GNU Source
Highlight, you can add any languages. I would have to do that for work
being that we used a specialized version of TCL. 

> The defaults look pretty good for a fallback. :)

Yes. I found something odd while addressing your question. For some
reason I have to force the pen back to black. I checked the groff output
and it looked ok. I had to make this change into the code. 

> would be good to see whether they stand out well when surrounded by
> normal text.

I think that it is a fair question.

For that I had to do some minor changes to make it more evident from the
last one that you saw. These are:

1. Changed from DS L to DS I. It will cause the text to be indented. 
2. Force black pen on fallback mode. This required an emacs lisp code 
change.
3. Remove the font reduction. I placed it before because of some long
code that I used for testing. I do not think that you need to do that
for writing code in org. 

Source: http://ppl.ug/R-WxCXnp_As/
PDF Output: http://ppl.ug/At07I2gFUBo/



-- 
Luis R. Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[suvayu ali]

Hey Luis,

On Tue, Jul 10, 2012 at 3:09 AM, Luis Anaya <papoanaya@hotmail.com> wrote:
> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
>
> Hi:
>
>> Does that mean a user can add any new language like this with her/his
>> definitions in their personal setup? If that is possible it would be
>> a really flexible setup.
>
> Yes. If you sit down and create the language specification in GNU Source
> Highlight, you can add any languages. I would have to do that for work
> being that we used a specialized version of TCL.
>

Great. :)

>
>> would be good to see whether they stand out well when surrounded by
>> normal text.
>
> I think that it is a fair question.
>
> For that I had to do some minor changes to make it more evident from the
> last one that you saw. These are:
>
> 1. Changed from DS L to DS I. It will cause the text to be indented.
> 2. Force black pen on fallback mode. This required an emacs lisp code
> change.
> 3. Remove the font reduction. I placed it before because of some long
> code that I used for testing. I do not think that you need to do that
> for writing code in org.
>
> Source: http://ppl.ug/R-WxCXnp_As/
> PDF Output: http://ppl.ug/At07I2gFUBo/
>

This looks beautiful! Now it's up to Nicolas to comment whether he would
like any other changes in the code. I think the backend is now looking
pretty mature, and all in a few days work!

Great work,

:)

-- 
Suvayu

Open source is the future. It sets us free.

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

suvayu ali <fatkasuvayu+linux@gmail.com> writes:

Hi
>
> This looks beautiful! Now it's up to Nicolas to comment whether he
> would

Yeah, it works! I'm amazed that it does :) 


> like any other changes in the code. I think the backend is now looking
> pretty mature, and all in a few days work!
> Great work,
>

Thanks a bunch. 

It is getting there, but I need to test the inline source and inline
TODO lists.  I have not unit tested that code yet and I'm sure that
there are uglies to squish out. 

Regards, 

-- 
Luis R. Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

Hi:

> I see this is based on org-e-latex.el. While this is a fast way to have
> a back-end running in the short term, it adds a lot of useless code (for
> example footnote handling is very specific and, as such, probably wrong
> on your back-end) and I'm not sure it will be a win in the long run.

True. I wanted to get something going to get the feel of the routine.  I know
that there is a lot of latex specific code, and I will clean it up as testing
goes on. 

In terms of foot notes. I did adjust to the way GROFF uses them, but when I

tested them nothing came out. The way it works is to insert a .FS/.FE pair

on the text to be footnoted. GROFF will place the text in the footnote

and automatically add the marker in the location that the .FS/.FE marks
where placed. 


Well, it is not working... so needs to be fixed :)

[chomp... good suggestions!]


> Speaking of attributes, org-e-groff.el has to add "ATTR_GROFF" to both
> `org-element-affiliated-keywords' and `org-element-multiple-keywords'.
>
> > One thing I have not managed to export are the deadlines/scheduled dates.
> > The code to export and add the appropriate markup is completed, but
> > that code is not running.
>
> By default, planning info are not exported. See
> `org-export-with-planning' variable.

I suspected that there was a variable that controlled it; but I was not sure, 
thanks for clarifying.
>
> Are you talking about org-export-with-* variables? Some of them have
> a nil value (planning is an example). What do you want to know about
> them?

I thought that these were used to control the export of the planning 
information. But you already answered my question.

Luis



 		 	   		  

Re: Exporting to groff, now in org-export.el ...

[Luis Anaya]

Hi:

I'm still working on this exporter, however being that my boss wants me to do
some actual productive work, I need to split the time between work and
hacking in emacs lisp.

However, during the week I performed the following coding changes to the
groff exporter:

1. Cleaned up some issues related to nested lists and special blocks.
2. Added formatting control on tables. Now the use of <l> <w> and <c>
will propagate in the exported table.
3. Added a new option for title line on tables (:title-line). It overrides the first
line to cb (centralized bold).
4. Added support to propagate column width. It will convert 5 characters
to one centimeter. It works sort of ok, but it's groff's doing, not
org-mode. Needs more testing, but what I want to export, it's being
exported fine.
5. Removed irrelevant code, more needs to be removed. This will be ongoing.

Some of these have been discovered while eating my own dog food. I have
an org file in which I store all the meeting notes. I started to export
those to PDF using the groff exporter. Things that have been found that
have resulted in bugs are being fixed and propagated. I'll do that to
make sure that the exporter is stable for daily use by... using it
daily. :)


-- 
Luis Anaya
papoanaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo