Blog vs Epub, round 1

My fairy suggested a very nice Christmas gift for my (not so lil' anymore) nephews: she owns a thermal books binder and went "oh, but you could print some story of yours and bind it in a book with my machine... My audio processors catalyzed that into "how about stripping some meaningful text out of your blog and print that on 8x8" pages?" and immediately thanked her for that marvelous idea.

Of course, that required first a major upgrade of my "blogpressing" tools. The "images scanner" got complemented with list-post.pl which extracts posts having a certain tag and formats them into an HTML document. From there, I could use Open Office to import the document, export it into ODT format and start adjusting image sizes and other formatting annoyance to fit the documents into two ~50 pages illustrated text. The fight to get that printed out of my fairy's HP all-in-one printer is for another post.

Suffice to say that I decided that I'd avoid printing for my own reading needs and try to take advantage of my cybook instead.

I had no luck with the graphical front-end of Calibre this time, so I dug a bit the web and figured out that I could use the command line approach:

ebook-convert tagtionary.html test.epub --breadth-first --max-levels=8 --margin-left=2 --margin-right=2 --verbose

Even then, calibre gave me a hard time. I guess running Lucid Lynx in 2013 is the root of all my problems, so I'll have to upgrade sooner than wished. Btw:

non-ASCII characters in URLs abort the HTML-to-epub conversion -- leading with mysterious "ascii codec can't decode" exception (and no offending URL/file mentioned), and so did %-escaping in filenames. I had to manually interrupt the conversion after it took about half an hour in conversion attempts, with 3GB resident set and taking up to 7GB of virtual address space.

 It got to the "Creating EPUB Output" stage, and most pages said "No large tree found", then "splitting on page-break". All fine. A few pages have "large tree #0", with a split point defined. (I have no idea why "Split point: {http://www.w3.org/1999/xhtml}h3 /*/*[2]/*[663]" is mentionned there). Even the largest file "english.html" got happily split into 6 parts. Then for some curious reason, "mybrew.html" enters an endless series of "splitting... split tree still too large: 464KB."
From there on, it consumed more and more memory, obviously leaking all the prior attempts.
(edit: after dropping the offending mybrew.html, I managed to get the 54MB epub file. Checking on Odyssey ASAP).
(edit++: Calibre distributed in latest LTS handled mybrew.html out of the (virutal)box =:)

read more ...

Text around figures in Latex

It gave me headaches, but finally i got it working. I discovered this morning that Computer Networks required pictures and bios of the authors, and that the elsarticle.cls latex class did not provide any standard mechanism to build these (not mentionning that my bio so far was entertaining, but absolutely not scientifical at all).

i finally used the warpfig package (preinstalled) in this way :

\begin{wrapfigure}{l}{1in}
 \includegraphics[width=1in]{SMA.eps}
 \noindent \hrulefill
\end{wrapfigure}
\input{biosylvain}

now let's see if that is understood by the editor's auto-generated pdfs ...

Indexing my Thesis

Okay. For those who have missed it so far, i'm writing down my PhD thesis ... and it's built with Latex.

Updating and completing a 1 year-old Latex document with new parts coming from conference paper, autonomic thoughts, etc. is some challenge i haven't met so far, so i'm upgrading my toolset as well.

Au cas où vous auriez loupé un épisode, je suis en train de rédiger ma thèse. Et je fais ça en Latex. Un document commencé il y a plus d'un an que je dois compléter avec des articles de conférence, etc. Bref, un des plus gros challenges auxquels j'ai eu à faire face jusqu'ici.

Le défi d'aujoud'hui ? Garder le fil de ce dont j'ai parlé, et où j'en ai parlé tandis que je fusionne et réorganise tous les bazars. En gros, construire et utiliser un index pour mon document.

Today's challenge: how to keep track of what i'm talking about in the different part and see whether merging/reorganizing things would help. In a word, building and working with an index of terms in my manuscript.

http://www.dtr.isy.liu.se/latexindex.html is a first good reference. Just adding \usepackage{makeidx}, and \makeindex \printindex to the document structure, and voilà. (oh, well, almost. I also have to make sure i properly call the makeindex command between latex calls :P)

Un petit peu de googling, et j'ai trouvé comment me servir de \usepackage{makeidx} de \makeindex et \printindex (oh, ne pas oublier d'appeler makeindex sur la ligne de commande, au passage). Reste à remplacer ici et là les \emph{protected tags} par quelque-chose comme \index{tags!protected}\emph{protected tags} ... dans près de 70,000 mots répartis sur 37 fichiers source ... de quoi devenir dingue si on ne fait pas un peu attention.

Now, i'm starting to do mass-replacement of "\emph{protected tags}" with "\index{tags!protected}\emph{protected tags}" ... in those +70000 words split in 37 source files ... Time for something to automate grep/open-file/query-replace, no?

Well, another google search pointed me at Sam teachs yourself Xemacs in 24 hours where they had a very nice explanation on regexp-query-replace and how to use the etags tool to operate on many file at a time. Roughly, all i have to do is invoking "wasp/phd> etags *.tex" to produce a condensed TAGS file for the current directory and then invoke M-x tags-query-replace to replace all the instances of the text with index-augmented text (well, i'm prompted whether i want the replacement or not ;)


Heureusement, il y a Sam, pour m'aider à comprendre le fonctionnement de etags de manière à invoquer M-x regexp-query-replace et remplacer tous ces mots l'un après l'autre en un clin d'oeil.
Allez, les windoziens. Qui dit mieux ?

edit: plein d'autres trucs latex en FAQ sur cette page

Power to XML

Okay, it's not everyday i say XML is a GoodThing(tm), so you should rather take it now before i take it back.

I'm busy merging my active networks experiments into the next chapter in my Ph.D Thesis, and being a linux-guy, i'm doing this with gnumeric for data collection and analysis, then using inkscape for converting the .svg file into a encapsulated postscript that i will later on integrate in my Latex document.

This is usually done in one command line like

inkscape ixp-collect-latency.svg --print=">eps/ixp-collect-latency.eps"

Well ... usually. This time it didn't worked. For some unknown reason gnumeric decided to include the whole dataset in the figure (rather than what can be seen through the window i defined on the axis), making weird red lines going out of the graph and stroke through the whole page.

So what's the relationship with XML you will ask? very simple. Open the .svg with inkscape (which happens to correctly hide the part of the line i don't want to see) and click in the wild where you know the line goes on. You magically captured the whole path. Pretty weird, no? Now, the good thing is that .svg files are actually XML files describing what should be drawn, where it is, etc. And inkscape features that geek-must-have "XML editor" where you can pick any item you want and have any of its properties modified (well, you could do it with a wonderful text editor too, but figuring out which of the 100+ svg:path is the red line could turn into an unpleasant thing)

So now that i have the svg:path element opened in the dialog box, i can simply pick the actual path stuff and remove the part i don't want (e.g. those lines that have negative X coordinates :P) For those who wonders, there is simply a "d" attribute of the path that consists of M <coordinates> for setting the first point followed by a collection of L <coordinates> to stroke a line to that location. Pretty easy to update, no ?

Now you might argue it doesn't matter whether that's XML and that all i'd have needed was software without bugs, but we all know there cannot be software without bugs, so the fact i can save the day by hacking data around is imho a GoodThing

Printing Faire-Parts in Linux

C'était pendant la période d'impression des faire-parts ... Réalisés avec inkscape sous linux, terrible pour de la mise en page, mais assez incomplet lorsqu'il s'agit de recoller les 2 faces d'un faire-part (ou de n'importe quelle brochure) dans un document .pdf unique.

J'ai donc ressorti ma panoplie de gourou linux (les manpages, quoi) pour chercher des "trucs postscript" pour recoller des documents à partir de petits morceaux ...

Des fois que ça servirait à quelqu'un ^_^


gs -sDEVICE=pswrite -r300 -sOutputFile=fps.ps -dNOPAUSE -dBATCH fpsa.ps fpsb.ps

the one above allows me to merge two sides of a folder into a single postscript file with no loss of resolution (thanks to the "pswrite" pseudo-device). NOPAUSE and BATCH are needed to disable all user-interaction of ghostscript.

The two sides fpsa and fpsb were individually rendered from SVG files using

inkscape fairepart-soiree-a.svg --print=">fpsa.ps"
inkscape fairepart-soiree-b.svg --print=">fpsb.ps"