Re: [O] Exporting to groff, now in org-export.el ...
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
Re: [O] Exporting to groff, now in org-export.el ...
suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el ...
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: [O] Exporting to groff, now in org-export.el ...
Hi Luis, On Mon, Jul 9, 2012 at 10:32 PM, Luis Anaya papoan...@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: [O] Exporting to groff, now in org-export.el ...
suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el ...
On Mon, Jul 9, 2012 at 11:55 PM, Luis Anaya papoan...@hotmail.com wrote: suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el ...
suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el ...
Hey Luis, Looks good, On Tue, Jul 10, 2012 at 2:00 AM, Luis Anaya papoan...@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: [O] Exporting to groff, now in org-export.el ...
suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el ...
Hey Luis, On Tue, Jul 10, 2012 at 3:09 AM, Luis Anaya papoan...@hotmail.com wrote: suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el ...
suvayu ali fatkasuvayu+li...@gmail.com writes: suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el ...
On Sun, Jul 08, 2012 at 09:14:14AM -0400, Luis Anaya wrote: suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el
Hi: I added the ability to modify positioning for EPS images. It maps to the parameters for .PSPIC calls. It only works with EPS images being that groff PIC images are self contained. Source: http://ppl.ug/v-RtLdtfM2E/ PDF Output: http://ppl.ug/wbx7AVcI_Ak/ Tables might take some doing, but that'll be the next thing to work on. -- Luis Anaya papo anaya aroba hot mail punto com Do not use 100 words if you can say it in 10 - Yamamoto Tsunetomo
Re: [O] Exporting to groff, now in org-export.el ...
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: [O] Exporting to groff, now in org-export.el ...
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: [O] Exporting to groff, now in org-export.el ...
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: [O] Exporting to groff, now in org-export.el ...
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: [O] Exporting to groff, now in org-export.el ...
suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el ...
Hi Luis, On Sun, Jul 8, 2012 at 3:49 AM, Luis Anaya papoan...@hotmail.com wrote: suvayu ali fatkasuvayu+li...@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: [O] Exporting to groff, now in org-export.el ...
Hello, Luis Anaya papoan...@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
Re: [O] Exporting to groff, now in org-export.el ...
Nicolas Goaziou n.goaz...@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: [O] Exporting to groff, now in org-export.el ...
Hello, Luis Anaya papoan...@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: [O] Exporting to groff, now in org-export.el ...
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: [O] Exporting to groff, now in org-export.el ...
Hello, Luis Anaya papoan...@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: [O] Exporting to groff, now in org-export.el ...
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: [O] Exporting to groff, now in org-export.el ...
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
