TeX/LaTeX: tex to txt

Since a .tex file is already essentially compatible with all text editors, you may be wondering why anyone would need to do any sort of conversion to .txt format. I would also have wondered at why such a task would need to be done--that is, until I ran into the need myself.

But I did run into such a need. The issue was that I had a nicely formatted .tex document--an article, actually, that I had translated with the aid of my computer, into a foreign language. I had one fairly competent translator check the machine translation over and do some corrections and thought I was ready to go. Then, another translator had a look and offered to do further improvements, to which I gladly assented. This is where I ran into a problem with the nicely-formatted file.

This translator, although quite well-qualified and fairly capable in matters technical, was nonetheless not at all familiar with Tex/LaTeX formatting. So I couldn't really give him the document in the most optimum format for me (.tex) for correcting. And at the same time getting from him the corrected text in a format like .pdf or .doc would further complicate my task of getting it back to its nicely-formatted .tex state. Thus, I decided that .txt would be the most neutral format to use for providing the translator with the computer-translated text for further revision. But how to do that?

Well, I had already created a pdf of the document, so I had that to work from. Using sed or awk to strip out all the TeX formatting codes would be an option for someone far better versed in those utilities that I am. But even that might prove a fairly involved and time-consuming task.

Some on-line searching revealed another possible solution: it involved using the utility pdftotext. It seemed worth a try.

Sure enough, running pdftotext file.pdf file.txt actually gave quite good results. There were a few anomalies I needed to clean up, but they were actually fairly few in number. I'd say the whole process took about 15 minutes total, after which, I had a .txt version of this 5k-word file that I could submit to the translator.

So, in the unlikely event that you may need to convert your .tex file to .txt, I can recommend the routine of first converting it to .pdf, then the resulting file to .txt. I should probably mention that this file didn't contain graphics, a table, or any sort of chart. So I can't vouch for how it would work on files containing comparatively more complex elements such as that. So, probably the less complex the document is, the more successfully it will convert using this method. So, there you have it, a method for converting .tex to .pdf to .txt

Addendum to 12th installment: watermarks with copyright notice using LaTeX

So, it's been awhile. And there's been plenty I could have blogged about on the tech front. Like when I copied my Arch install to another hard drive, making it bootable. But I didn't. And now I've forgotten important details of how I did it. Oh well.

I can blog about this next item, though, which is still fresh in memory. I've got to write up  some articles and am sending them out for proofreading. So I wanted to mark them as drafts, something I already know how to do and have blogged about previously.

I decided to modify things a bit for the current task, though. This time I'm using only one utility to do the watermarking--LaTeX--and I'm tweaking things a bit further.

The challenge this time is making a watermark with a line break, as well as one that contains text with differing font sizes in the two lines. I want a really large font for the first line, which marks the document as a draft--as in my previous installment--but I want a really small font for the second line this time. That second line is where a copyright notice will be located.

Without further ado, here's the MWE (TeX-speak for minimum working example) I've come up with for accomplishing this:

\documentclass{article} \usepackage{fullpage} \usepackage[margin=1.0in]{geometry} \usepackage{hyperref} \usepackage[utf8]{inputenc} \usepackage[english]{babel} \usepackage{graphicx} \usepackage{type1cm} \usepackage{eso-pic} \usepackage{color} \makeatletter \newcommand{\the\year} \makeatother \SetWatermarkText{\rotatebox{15}{\parbox{16cm}{% DRAFT \\ \small{\textbf{Unless otherwise attributed, content of this document \textcopyright Yours Truly, \the\year}}}} }} \SetWatermarkScale{1.4} \SetWatermarkColor[gray]{0.90}% \title{Lorem ipsum} \begin{document} \maketitle Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. \end{document} }

This will place, diagonally across each page of the document, a notice in light gray font and in very large letters, with the word DRAFT. Underneath that, there will be text in much smaller font alerting that the material is under copyright claim of the document's author. It's also got a nice little feature that auto-inserts the year, so it's something that can be reused in varying documents over a period of time, relieving the composer of having to fiddle with minor details like dates.

So, that's about it for this installment!

LATE ADDITION: Just today I ran across a new means of watermarking that can be done on already-existing .pdf files. It involves using the program pdftk and is quite simple. You simply create an empty--except for your desired watermark--.pdf, then use the program to add the watermark to the already-existing .pdf. Something like the following:

pdftk in.pdf background back.pdf output out.pdf

(I ran across that here). I used LibreOffice Draw to create such a background watermark and easily added that to an existing .pdf. It worked great, though it should be noted that the watermark won't cover graphics; I assume there must be a way to make it do so, however.

12th installment: adding watermarks to documents

In this twelfth installment, I'll describe my recent success with adding watermarks to a document. As often happens when I want to do a quick document or need to work on a .doc file, I turned to LibreOffice for this task. The major part of this post, then, will be occupied with how to add watermarks to documents created in or edited with LibreOffice/OpenOffice. I decided, just out of curiosity, to look into how watermarks can be added to TeX/LaTeX documents as well, so I'll share as well a bit of information that I gleaned about that from another site.

First, though, a bit about watermarks. As the wikipedia article on the topic tells us "[a] watermark is a recognizable image or pattern in paper that appears as various shades of lightness/darkness when viewed by transmitted light (or when viewed by reflected light, atop a dark background), caused by thickness or density variations in the paper."

Watermarks proper are actually added into the paper itself during manufacture, and the text was later printed over the watermark. With the advent of modern computer printing, however, it has become possible to print "watermarks"--actually it might be better to refer to these as pseudo-watermarks--onto standard, clean paper and so to add them, page by page, to a document. This is the sort of watermarking I will be discussing.

This pseudo-watermarking might be added to a document for a number of reasons: a background image--such as a business logo--might be wanted in a document; a copyright notice might be added to a document in this way; or a document might need to be identified as a draft, as opposed to a final revision. The latter of these scenarios applied to me and was why I wanted to learn how to do pseudo-watermarking.

I was pretty certain I could readily find instructions for how this is done using LibreOffice, and a quick search proved my supposition correct. That search furthermore proved that it is a fairly trivial task, so long as one feels comfortable with using some image editing or creating software. I used GIMP for creating my image, though I decided as well to experiment with LibreOffice Draw and had success with it as well. The image created is simply selected as a background for the document. The steps I used were as follows.

First, open GIMP and select File > New. In the resulting dialog, I changed the increments for image size to inches, so as to create an image that will fit within an 8.5x11 inch sheet.

Once I'd selected the size I wanted and created the file, I next went to the GIMP toolbar and selected the Text Tool. I printed in the resulting window the text I wanted to appear, selected a light gray color for the font, changed the font increment to point, then increased the font size substantially (as you'll see in the screenshot, I went with 213 point type).

The somewhat tricky part after having done that was to rotate the text such that it would run across the page at an angle. This I accomplished by selecting Layer > Transform > Arbitrary Rotation. Doing this raises a window with a slider that allows you to rotate the image to the desired angle--in my case -57.66 degrees. As will be evident in the screenshot, the text can be better centered in the image using this dialog as well (x and y axes).

Thus, the final product (not very well centered here):

I exported that image to a .png file as the final step. From here, it's a simple matter of opening your LibreOffice document and clicking on Format > Page, selecting the "Background" tab, selecting "Graphic" from the "As" drop-down menu, and finding and selecting the file you just created using GIMP. Once that's done, all pages in that file will have a pseudo-watermark with the text "Draft" on them.

The initial video I found described making the watermark using LibreOffice's Draw program, so I decided I should have a try with it as well. That process was almost as simple as GIMP's, but it had the limitation that the largest font size I could select was 96 point--a bit on the small side. I will nonetheless outline the steps here.

First, I opened up Draw and selected the "T" (for text insertion) from the toolbar at the bottom of the page.

Next, I selected a light gray font color and the largest possible font size from the menu, and printed the text "Draft" in the page. The text ends up being in a horizontal orientation, of course, as can be seen in the screenshot.

In order to make the text run at an angle across the page, it is next necessary to choose the "Effects" tool from the bottom toolbar (the symbol has two blue boxes off kilter from one another and is situated fourth from the right side on my toolbar). Once that's done the highlights of the text box just created turn red, and if the cursor is moved over the top right corner of that text box, the box can be dragged such that it is oriented on the page at the desired angle.

Once the text box is satisfactorily oriented and centered, the file can be exported. Once again, I chose the .png format. The resulting image can then be added to the background of a document using the same process followed above to add the GIMP image.

Finally, though I did not try out this last method, I wanted to see how difficult or easy it might be, using TeX/LaTex, to add a pseudo-watermark to a document. I easily found some directions here. That author describes three different methods, the simplest of which--since it is one on which pdflatex can be run directly, is quite easy with use of the graphicx, eso-pic, and type1cm packages, as demonstrated in the code below:
search() \documentclass{article} \usepackage{graphicx} \usepackage{type1cm} \usepackage{eso-pic} \usepackage{color} \makeatletter \AddToShipoutPicture{% \setlength{\@tempdimb}{.5\paperwidth}% \setlength{\@tempdimc}{.5\paperheight}% \setlength{\unitlength}{1pt}% \put(\strip@pt\@tempdimb,\strip@pt\@tempdimc){% \makebox(0,0){\rotatebox{45}{\textcolor[gray]{0.75}% {\fontsize{6cm}{6cm}\selectfont{DRAFT}}}}% }% } \makeatother \title{Lorem ipsum} \begin{document} \maketitle Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. \end{document} }

Here's how the resulting page looks:

That's it for this installment.

Fourth installment: How to write a business letter using TeX/LaTeX

I continue my experiments with TeX/LaTeX. There's just something I like about working with mark-up. I suppose that for most people, the mark-up would hopelessly complicate things. But I find the opposite to be the case for me.

That dates back probably at least as far as the first word processor I used with regularity--WordPerfect (WP hereafter) 4.0. It was also a console application, one that I managed to learn my way around fairly easily. It ran on a 286 with a whopping 20 megabytes of hard drive space and probably not more than 2 megabytes of RAM.

One of the great things about that version of WP was a feature it had called "reveal codes." If some aspect of the document you were working on looked weird and you couldn't correct by selecting various canned options, you could use the "reveal codes" feature to examine the situation behind the scenes. Despite the fact that my computer knowledge was extremely paltry back then, I don't think I ever confronted a situation where, by revealing those codes, I wasn't able to straighten things out.

Skip forward about a year to when I had finally gotten rid of the old computer and was using a "modern" word processor--Word 6.0. Imagine my surprise and dismay when, having issues with documents I was creating with that version of Word, I discovered that the program had no "reveal codes" feature. I was stuck with whatever Word wanted to give me, and that was that (a more technical explanation of the matters at issue can be read here).

So, my interest in TeX/LaTeX perhaps traces, ultimately, to the frustrations I encountered long ago with using more "modern" word processing applications. Whatever the motivations, I continue to experiment--and am now even having modest successes--with TeX/LaTeX.

Recently, I had another opportunity to continue my experimentation with  TeX/LaTeX. I needed to write an official, business-type letter and decided to try writing it with TeX/LaTeX.

I must admit there were also other motivating factors--not least of which was that, since I write so few of these types of letters, I can never remember the proper format and need, each time I write one, to do some web research aimed at refreshing my memory about that prior to composing the letter. TeX/LaTeX could be of assistance here since, I assumed, the letter document class should already be set to output the proper format--which did, indeed, turn out to be the case.

The down side was that it took me an inordinately long time to compose this fairly short letter: but that was, in part, because I wasted a lot of time in a largely fruitless attempt to utilize what was supposed to be a new-and-improved letter class, something called scrlttr2, a component of what is called the "KOMA bundle." Had I just used the old letter document class and not spent so much time trying to get scrlttr2 to do what I wanted, it probably would have taken me about half as long. A long time to write just one letter but, given that it was my first try using this application and that I had some spare time to spend on it, not too bad.

I was successful in the end. Below I'll paste a template for the letter I wrote, one that contains a nice tweak that causes a scanned signature to be printed.

Without further ado, here's the template I used (some explanation below):

\documentclass[12pt]{letter}
\usepackage{fullpage}
\usepackage[english]{babel}
\usepackage{graphicx} %so that signature graphic can be included
%\signature{Name Surname}
\address{My Street \\ My City zip \\ Phone: 555-555-5555 \\ e-mail: me@mydomain.whrvr}
\begin{document}
\begin{letter}{Recipient \\ Recipient's street \\ Recipient's city zip\\ country}
\opening{To whom it may concern:}
This letter is written for the purpose of \ldots

If you have any questions, or would like to see some additional documentation, please do not hesitate to contact me.
\closing{Sincerely,\\
\fromsig{\includegraphics[width=55mm]{Mysig.jpeg}}\\
\fromname{My Name}
}
% \ps{P.S. Here goes your ps.}
% \encl{Enclosures.}
\end{letter}
\end{document}

The first thing I'd like to explain is the use of the graphicx package, which is what allows for the graphic of the signature file to be included. Simply scan your signature and save it as a jpg file (other image formats may work, though jpg is the only one I tested). It will need to be saved within the directory from which you're compiling your letter. Stipulate the size you want for the signature, and pdflatex will include it once you compile.

The other fields in the template should be self-explanatory. I've commented out some of them (the percentage sign is the comment character in TeX/LaTeX), either because they did not apply to the letter I was writing--for example, the PS and enclosure options at the end--or perhaps because it was something that I tried but that didn't have the desired result (the "signature" option in the preamble).

The template should work as is. Just save it as a .tex file, enter your values in place of the generic information, scan your signature and save it to the same directory, then run pdflatex on the .tex file. You should end up with a nicely-formatted business letter.

EDIT: Thanks to those commenters who pointed out the the missing \end{document} tag at the letter's end--not sure how I left that out but it's now been added.

Addendum to second installment: a TeX/LaTeX template for outlines

As a follow-up to the last installment regarding creating outlines with nano, I've done some further experimentation with LaTeX and wanted to post here a template I created. The template contains the mark-up that, when appropriately applied, can turn a nano outline into one that prints nicely on a page. After running pdflatex on the created file (which should be given a *.tex extension first), a nice pdf can be output for sending to the printer.

Without further ado, the code:

\documentclass[14pt]{extarticle}
\usepackage{cjwoutl}
\usepackage[top=1in,bottom=1in,left=1in,right=1in]{geometry}
\usepackage{underlin}
\setlength{\headsep}{12pt}
\pagestyle{myheadings}
\markright{\today {\hfill ***Header*title*here***\hfill}}
\linespread{1.3} % gives 1.5 line spacing
\pagestyle{underline}
\begin{document}
\begin{outline}[new]
%\outl{1}
%       \outl{2}
%               \outl{3}
%                       \outl{4}
%                               \outl{5}
%                                       \outl{6}
%                                               \outl{7}
%                                                       \outl{8}
%                                                               \outl{9}
%                                                                       \outl{10}
\end{outline}
\end{document}

Now, for a bit of an explanation. I've increased the font size (see the \begin \end{Large} stipulations) due to my deteriorating vision: the standard 10 pt. font used for the document class just is not going to work for me. For the same reason, I needed to increase line spacing (the \linespread stipulation).

Of course the \outl{#} comments indicate the levels of the outline and how far from the left margin the text gets spaced. The spaces in the template are not, of course needed, but I find them to be a visual aid when looking at this mark-up, so I left them in the template.

The key package I'm using, as may be evident to those of you who've learned a bit about TeX/LaTeX, and the one that allows more than four outline levels, is the cjwoutl package. I also wanted to fiddle with page margins, since the default article class margins seem terribly wasteful of paper. So I set them to be one inch all around.

The final printed product looks pretty nice. Truth be told, I'd like to see greater indentation increments for the outline levels, but I think that might actually be tweakable. I'm not up for attempting that at the moment though, since this looks like it should suit my needs fine.

So, what remains to be done is to find some way to apply that code to the outlines I create in nano. For the time being, I'm content to just edit the files manually, adding mark-up where needed. But there is surely a way to automate that task--a way, unfortunately, shrouded in mystery for uninitiated plebians like myself.

What would need to be done first of all is probably to add at least some special marking to the outline file itself. For example, if each outline level entry were to begin with a unique character unlikely to appear anywhere else in the document as the first character in a new line--say, an equals sign--processing the file could probably be simplified. A program could then be written to look for every new line that begins, either with the equals sign, or with one or more tab spaces followed by an equals sign. Depending on the presence of the equals sign at the beginning of new lines, or after one or more spaces from the newline, the program could be told to replace the equals sign with the \outl{#} mark-up, appropriately incremented.

Then, of course, the preamble and ending would need to be added to the file. Finally, the file would need to be saved with a new extension, namely the .tex extension, so that pdflatex could process it.

For better reference, here are some screenshots of the stages of creating this sort of outline using nano. First, some dummy text entered into a test.outl file open in nano:

In the next phase, the mark-up is added and the file is saved with a new extension (note how the color highlighting changes when the file's extension is modified)(LATER EDIT; you may also note that the prepended and appended lines do not match exactly the mark-up from my template--that because I edited those parts slightly, having found a better way to increase font size for the document):

Finally, pdflatex is run on the file that had the mark-up added and its extension changed appropriately. The pdf produced looks like this:

To give some concrete examples, using regular expressions as they are understood by nano, of the way the nano outline file would have to be processed, the following. Every instance of ^= (new line followed by equals sign) should be replaced by ^\outl{1} (new line followed by first-outline-level mark-up). Next, every instance of ^[[:blank:]]= (new line followed by tab space, followed by equals sign) should be replaced by ^[[:blank:]]\outl{2}. And so on for the various outline levels.

Then, the mark-up

\documentclass[14pt]{extarticle}
\usepackage{cjwoutl}
\usepackage[top=1in,bottom=1in,left=1in,right=1in]{geometry}
\usepackage{underlin}
\setlength{\headsep}{12pt}
\pagestyle{myheadings}
\markright{\today{\hfill ***Header*title*here***\hfill}}
\linespread{1.3} % gives 1.5 line spacing
\pagestyle{underline}
\begin{document}
\begin{outline}[new]

should be prepended to the beginning of the file, and

\end{outline}
\end{document}

should be appended to the file's end. Finally, the extension of the file to which all the mark-up has been added should be changed to .tex. After this, the file is ready for processing by pdflatex.

That's how far I've gotten with it to date. Next, I'll be looking for the aid of someone who might be able to give pointers on how the file could be processed as described. I note that Steve Litt's conversion program for making vimoutliner files into something LyX can handle is done using awk. So, perhaps this could be done in the same way. If I discover a way of doing it, I'll post the results in a further addendum to second installment in this series.

NOTE: I made a later edit to the TeX/LaTeX code so that the date, rather than the author's name, appears at the left margin in the header. I also increased the font size for the header title. So the screenshots no longer correspond precisely with the code.

ANOTHER LATER NOTE: here, by the way, is the modified entry from .nanorc that both makes the color highlighting possible, as well as designates the equals sign as a sort of pseudo-bullet (note that levels that do not start with the equals sign do not get color highlighted on this scheme):

syntax "outl" "\.outl$"
color brightwhite "(^)=.*$"
color brightred "(^[[:blank:]])=.*$"
color brightgreen "(^[[:blank:]]{2})=.*$"
color magenta "(^[[:blank:]]{3})=.*$"
color brightblue "(^[[:blank:]]{4})=.*$"
color brightyellow "(^[[:blank:]]{5})=.*$"
color cyan "(^[[:blank:]]{6})=.*$"
color brightred "(^[[:blank:]]{7})=.*$"
color brightgreen "(^[[:blank:]]{8})=.*$"
color magenta "(^[[:blank:]]{9})=.*$"
color brightblue "(^[[:blank:]]{10})=.*$"
color brightyellow "(^[[:blank:]]{11})=.*$"
color cyan "(^[[:blank:]]{12})=.*$"

Second installment: Outlining with nano

nano, the old stand-by, low-resource console editor, is probably most often used for quickly editing computer configuration files. It seems also sometimes to be used by programmers for writing programs or editing code. Some of us non-programmers can think of other uses it might serve, such as writing documents or creating outlines. This article will discuss some of the uses I've tried to make of it and some ideas I have for further deploying it.

My history with nano

I'm a long-time user of the nano text editor, it having been from the beginning for me a far more approachable tool for editing configuration and other text files in GNU/Linux than the other popular option, vi. My experiences with nano began in the days when GNU/Linux operating system installations were command-line affairs, and when most initial configuration of the system was done from the terminal. But even after operating system installations developed into a thing of graphical wonder (Knoppix was sort of a trailblazer in this realm, as I recall), I continued to use nano for many tasks owing, not in small part, to the fact that I'm a trailing-edge technologist (read; I re-purpose cast-off or firesale equipment), and so gravitate toward low-resource computing applications.

When I needed to create a very long and complex document a few years ago, I was even hoping at that point that I could learn enough TeX mark-up in order to be able to write most of it using nano. In the end, however, I found myself too intimidated by the prospect of both learning TeX mark-up and planning and executing the complex document, to make the attempt. I chose instead to use a WYSIWYG word processor for the task--but that's another story.

I've since maintained my interest in TeX and LaTeX, and, in the last year or so, actually managed some modest successes with it. Needless to say, I've been using nano right along, and have combined the two in those successful tests. But what got me started thinking about a possible new way of using nano in combination with TeX/LaTeX was actually a tweaked version of vim--vimoutliner with which I was experimenting. And my initial experiments were not TeX/LaTeX related, but were actually focused on finding a text-mode outliner.

vimoutliner

Ok, I know that's a rather convoluted introduction to this story but, hey, life is like that. I all the time stumble onto new and unexpected variations, both in my technical endeavors as well as in other areas of life. So, please bear with me as I recount some of the convolutions, and be comforted by the fact that I'm not rehearsing them all. :)

Now, as a pre-emptive nod to all you emacs lovers out there who are just hopping at the prospect of putting in your pitch for emacs org-mode here, know that I'm aware of and interested in that project. In fact, I already attempted to install it. But once I saw the outrageous size of emacs and associated files, I got cold feet. vim was far smaller, and the vimoutliner package that causes vim to function as a nice outliner doesn't add much beyond that. So, off I went for some experimentation with vimoutliner.

One of the interesting things vimoultiner does is to cause varying outline levels to appear in different colors. For example, the leftmost level will, in a terminal with a dark background, appear in a white font, while the next level--one tab space from the left margin--will be in a red font. The next level--two tab spaces from the left margin--will appear in a green font. And so forth. So, vimoutliner enables vim to use both a particular type of formatting, where tabs at the left margin determine outline levels, as well as applying font coloring to go with those levels.

That's a nice little trick in that the colors allow the eye more readily to distinguish between outline levels--something that, in more ponderous applications such as Libre Office Writer (LOWriter hereafter) is accomplished by both indentation from the margin and the use of varying symbols or letter/number combinations for the differing levels.

Which brings up another factor in my quest for a lightweight outliner: LOWriter's outlining mode is absolutely horrendous. It keeps popping up some tool bar as you move through outline levels, which steals focus from the cursor, forcing you to do a mouse click at the point where you desire to enter text. Not to mention the fact that it's severe overkill to use such a gigantic application for creating an outline.

As I found out from my experimentation with vimoutliner however, both the lightweight and heavyweight applications have their advantages and drawbacks, depending on what is the final goal. And speaking of final goals, this provides occasion for highlighting a wonderful discovery I made with respect to TeX/LaTeX: the author of vimoutliner (Steve Litt) has created a conversion program that turns his outline files into the chapter, section, and sub-section headings of a book to which can then be added all the remaining text. Incidentally, he uses LyX for entering in the additional text.

I created a few outlines using vimoutliner--not for any book publishing projects, my more immediate need being the creation of notes to be used during lecture delivery. Though it did work well for me for the most part, things were still wanting in certain respects when it came to lecture note creation. For example in a text editor like vim (nano has the same shortcoming, you'll doubtless understand) there is no simple way to render something that will render well in printed form, such as WYSIWYG word processors allow and such as is needed for something like lecture notes, that need to be as legible as possible and to contain various visual cues.

vimoutliner

For example, for use in the lecture hall, a larger font might be wanted--perhaps 14-point--and wider line-spacing. The varying symbols WYSIWYG editors can insert at differing outline levels also provide extra visual cues. Certainly page numbering, and perhaps even a header, would be desirable in the final, printed product as well. So, while the coloring vimoutliner provides on-screen for various levels is an aid to creating the outline, when it comes time to print the outline for use from the podium, it falls seriously short.

As a stop-gap measure, I imported the outline files I had made into LOWriter and performed some of the needed manipulations there. Not a very satisfactory solution but one that got me by at the beginning. The real solution to this issue, i.e., to creating from a file that works well on the computer to one that prints well onto a page, is to come up with some sort of conversion program, as Steve Litt did for his book outlines. That task--despite Steve's short-lived but well-intentioned efforts to teach me a little python (I got as far as creating hello.py)--remains at the moment beyond my capabilities.

Can I do something like this with nano?

But I've not given up altogether. One avenue I've begun exploring as a possible resolution to the issues--owing to being once again faced with the prospect of learning simultaneously two new systems (vimoutliner and whatever programming technique I'd need to use in order to convert my outlines)--is whether I might be able to employ my old friend nano in place of the less familiar vim in this scheme somehow. Oh yeah, this article is supposed to be about nano, isn't it?

My initial question was, then, whether I could get nano to function as well on-screen as vimoultiner. Could I make it do the same sort of indentation of levels, and possibly even cause it to assign differing colors to the varying outline levels? Well, that part of the equation turns out to have been quite trivial: with just a couple of simple tweaks to the configuration file .nanorc, nano can be made to do those same outlining features.

Here's how it's done. First, we'll need to locate nano's configuration file, .nanorc, or else create one. To do the latter, you would simply issue from the command line touch ~/.nanorc. That, of course, creates an empty .nanorc file in your home directory.

To invoke the outlining magic, two entries need to be made in that file. The first entry, which causes tabs made at the left margin to create persistent outline levels, is set autoindent. With just this entry in your .nanorc, nano will begin to treat all tabs that start at the left margin as level indentations--meaning that after each wrapped line or each hard return, the cursor returns to that same level on subsequent lines. To get the cursor back to the left margin, it's necessary to use the backspace key or the left arrow key.

The other way to get a .nanorc file in your home directory, or to perhaps create a nano configuration file that obtains system-wide, is to use the sample file found--on my Ubuntu computer--in /usr/share/doc/nano/examples, a file which, with proper editing, can implement nearly any tweak you might want to make to nano. For that file to be valid system-wide, it should, I believe, be renamed to nanorc (no leading period) and copied to the /etc directory.

In that sample file, for example, the line set autoindent is already included and you need only to uncomment it to activate that feature in nano. Likewise, you'll see toward the end of that file that a number of alternate nanorc files can be invoked as well. What are these?

If you inspect those alternate files--on my system located in the /usr/share/nano directory--you may note that they are pre-configured to apply color highlighting to certain types of files. For example, the html.nanorc configuration file stipulates that all files ending in .html, when opened with nano, are to have angle-brackets highlighted in blue, while other elements are to appear in red. This is all accomplished through the agency of regular expressions, which nano identifies as you type and so highlights with the defined colors in real-time.

I've worked a little in the past with regular expressions--mainly when I need to do "power searches" within LOWriter documents. I'm quite far from being conversant with the system, though, and need to consult some sort of documentation each time I want to do something involving regular expressions. Nonetheless, once I had read about these color-highlighting capabilities and understood that they relied on regular expressions, I suspected I might be able to get nano to do something very like the color highlighting vimoutliner does.

I had to experiment for a few hours, all the while trying to find any relevant snippets of information I might dig up on the internet, but I did finally find a way of causing nano to apply color highlighting to the differing levels that can be achieved by placing set autoindent into .nanorc.

That's done by, first of all, defining the extension of files to which the color highlighting should be applied. I decided to define my own extension: all files with the extension .outl should have the color highlighting applied to them. Then, I defined a set of regular expressions which cause color highlighting to apply to varying levels, as follows: white is applied to the first, left-most level; red is applied to the second level; green is applied to the third level; magenta is applied to the fourth level; blue is applied to the fifth level; yellow as applied to the sixth level; cyan is applied to the seventh level; and then the color scheme starts over again with red. I doubt I would ever create and outline that would go beyond seven levels, but it was trivial to add the capability to continue the coloration, so I did it.

Below is the entry I placed in .nanorc that causes the coloration to be applied:

syntax "outl" "\.outl$"
color brightwhite "(^).*$"
color brightred "(^[[:blank:]]).*$"
color brightgreen "(^[[:blank:]]{2}).*$"
color magenta "(^[[:blank:]]{3}).*$"
color brightblue "(^[[:blank:]]{4}).*$"
color brightyellow "(^[[:blank:]]{5}).*$"
color cyan "(^[[:blank:]]{6}).*$"
color brightred "(^[[:blank:]]{7}).*$"
color brightgreen "(^[[:blank:]]{8}).*$"
color magenta "(^[[:blank:]]{9}).*$"
color brightblue "(^[[:blank:]]{10}).*$"
color brightyellow "(^[[:blank:]]{11}).*$"
color cyan "(^[[:blank:]]{12}).*$"

The regular expressions stipulate that, in every file with the extension .outl, each new line that begins with a blank or series of blanks is to have all characters tinted with the appropriate shade to the end of the line. In this form, an outline can have a color-highlighting scheme that goes to thirteen levels. With those fairly simple modifications I was able to cause nano to mimic some of the chief characteristics of vimoutliner.

nano with my highlighting tweak

The difference, at least on the technical level, in how vimoutliner and nano handle the differing levels is not very clear to me. On the surface they differ in that my nano solution seems to treat all white space at the left margin as indicative of an outline level. So, either a space or a tab at the left margin indicates the second outline level, while either two tabs or two spaces indicate the third outline level. I believe there is no regular expression that differentiates a tab from a single space so, at my current level of understanding, it seems what I've come up with is the best possible solution for making nano do outline levels. In vimoutliner, on the other hand, only tabs at the left margin indicate outline levels.

What remains to be done: export outlines as can be done with vimoutliner

As I hinted earlier, however, my ultimate aims have not yet been accomplished. What I've managed to do thus far is to enable a console editor with which I am familiar to apply color highlighting to my outline files. This answers to two important considerations for me: it allows me to 1) utilize an easy-to-use and low-resource application to create outlines that 2) look good on the screen. But it does leave one very important consideration unanswered, namely how to get the created outline into a form that looks good on paper?

That's an issue on which I continue to work and I'm not really even sure where to begin. It seems that converting these outlines into a form that can be handled by LyX or even straight TeX/LaTeX, and from there into a nice printed form, should be possible--as certain vimoutliner add-ons that apparently utilize python for this, indicate. Since my capability with python has not progressed beyond creating hello.py, I'm certainly in no position to attempt to create that sort of converter.

A more congenial place for me to start, since I have slightly more experience with it, would be to use bash somehow. The little I know about it leads me to wonder whether, by bringing to bear something like awk or sed, a sort of search-and-replace could be done on the .outl files in order to add the relevant mark-up to them. But to be honest, I lack even the rudimentary knowledge to know whether bash might even be a viable option for this task.

Another alternative might be to create some macro in LOWriter that could import and apply formatting to these files. I don't have much more experience with macros than I do with bash scripting, though I have become quite familiar over the years with the LOWriter interface and the program's capabilities. Of course TeX/LaTeX printed output looks superior by far to what any office suite can produce. But I would be satisfied with a somewhat aesthetically inferior product for these lecture outlines if I could more readily accomplish the task with LOWriter.

If you have suggestions for any of the issues raised above, please offer them. Specifically, if you know of a way to distinguish, using regular expressions, tabs from spaces, please offer your input. Also, if you know whether the conversion of which I speak might be accomplished using bash and related utilities, please let me know: that would involve essentially searching for end of lines together with tabs/spaces and followed by any character, then replacing those instances with the same end of line, number of tabs/spaces, a TeX/LaTeX mark-up string, then the same character with which the line initially began (incidentally, the mark-up can be found at this site). Likewise, if you have any Libre/Open Office solution for importing these files into a list or outline, please say your piece.