It's blogpress time again

French journalists have a word for that seasonal topic that comes up again in newspapers when every high-end interviewers are on holiday and things are up to interns: "Le marronnier de l'été" ... and it may feel that doing some blog-to-printable/epub conversions pops up every summer here, but hopefully not for the same reason.

The motion started with the late-night idea that "tiled" engine discussions could be a chapter 1 if the blog ever had to be converted into a book, but also that editions could use their own tag, like "ch1" for that chapter 1. On the next day, I was dusting off repositories and working directories for the next "blogpress" round, motivated by the fact that I'll have up to early August before the next automated snapshot/takeout.

I wrote a small introduction to that chapter (french only, atm) and then grew surprised by how little preparation there was on that "tiled" tag. Reader would just be thrown stuff at their eyes, and they'd better understand things. Sure, I introduced it rather late, not as I was writing those posts... I discovered a bit sadly that most of the tutorial I had used by the time are now offline (and even their archive.org copy are firewalled T_T by "my" most powerful computer).

I edited some of the early posts in "tiled" following the idea that "Many posts contain parts that would be useful for a chapter (say, one about tiled game engines) but also parts that don't quite fit. So how about having <span> or <div> tags assigning those items a "no-ch1" (or no-ch5 when I'll be at chapter 5) and let the simple.css make them display: none ?"

Finally, 4 days ago, I managed to get all the issues fixed in my scripts and re-generate a good-looking page that I can use in calibre to export an epub file. And because each issue involved a good deal of html snippets and that I'd rather have a clipboard to compare them when that happens, I decided to use codeberg's issue tracking system for that. 

script output, as uploaded on codeberg	what it looks like on the blog
what it looks like copy-pasted in office	what I had from older (2025) script output

We're not fully done, but it's getting in good shape. I couldn't get it printable, though, as the browser seems to ignore the CSS instructions that make it neat and stylish on screen. 
Next points would be

• recognized purple-colored-text as English
• if a picture is large enough to cover most of the column width, don't try to make it floating.

A sad discovery while working at all this was that the 72x72 thumbs are no longer automatically provided by the takeout. They might have annoyed me when doing the last conversion back in 2025, but no more than I month later I had figured out that they could be a "magical portal" to posts and uploaded them to neocities.

And now I have another project for those thumbs. I had included the "milestone" tag together with "tiled" to get a bit of reminder of what had already happened and what not between two "tiled" posts, but many of the milestones are too large and distracting compared to what I want. The first paragraph (?), the date, title and the thumbnail would likely be sufficient. Hopefully, I can recontruct some thumbs URIs from regular picture URIs, but I'll need to resort on my drive-archived blogthumbs.zip for the missing ones...  

There's one line of all that that I'd like to bring here. It's the incarnation of "make the possible easy" part of Perl:

$post=~s/src=\"([^"]+)"/src="$larger{$pix{$1}}$escaped{$1}" alt="$1 ; $pix{$1}"/sg; 

In that single line, we iterate through (thanks, g modifier) all the image URLs of a single post and patch them using the hash tables that we constructed by parsing "temporary" files that other scripts produced. No need for split-patch-join sort of loop. 

edit: Some commands used to generate the latest version:

THUMBS=../thumbs/thumbz.html perl ../git/list-atoms.pl ../bilou/feed.atom <(cat ../pictures3.lst ../morepix.lst ../pictures2.lst) tiled '(milestone)' > tm3t.html

where "thumbz.html" is the page featuring a link & thumbnail for every post, which list-atom will look for contents. It needs so many .lst files because I worked on list-

grep '<!-- all images' -A9999 tm3t.html | grep ^i | fe - "cp % /d/local/pages/geds/attach_files/ -v"

I added a flat list of filenames with the pictures at the tail of the HTML file so you can "more easily" cherry-pick the files you need (save-as-html in web browser is doing too weird things)

BLOG=https://sylvainhb.blogspot.com perl ../git/thumbify.pl <(perl ../git/summarize-atoms.pl ../bilou/feed.atom) > thumbz.html

Above: how the thumbs page is generated, below, how I got some -0- thumbs from files that had more normal identifiers. (applied in the folder where I unziped blogthumbs.zip I got from that-time-where-thumbs-appeared-in-exported-data.

ls i* | sed -e 's/\(i[0-9][0-9]*\)-\([^0]\)-\(.*\)/mv \1-\2-\3 \1-0-\3/' | grep -v '^i' > renamethumbs.sh

edit+: fine-tuning keeps going on mastodon

Signets et attach

J'ai pour la SchoolZone l'intention d'introduire des signets/marque-pages qui pendouillent... on pourrait s'y accrocher (indispensable), grimper, descendre (sympa) et ils réagiraient comme des cordes plutôt que comme des barres.

J'ai appris dernièrement qu'il fallait que je prototype ce genre de choses dans l'environnement des "three rooms" sous peine d'être démoralisé par le côté "nu et inintéressant" d'un niveau à peine commencé. Et coup de bol, il y a un coin de la salle "école" qui conviendrait bien : le haut. On pourrait atteindre les signets en utilisant la gomme et s'en servir pour rejoindre l'éponge, un peu compliquée à utiliser pour l'instant.

Hanging to a rope-like bookmark, using it to swing around and hop to the next ... that's clearly something I'd like to bring into the school zone and I may have just found the right way to introduce it first in the "three rooms" demo. Yes, I could use one of the levels in which they are featured, but recent development on the green zone shown that a rushed large level doesn't motivate me as much as a small polished screen can. They would be there, in the top corner and providing an alternate way to reach the swinging Spongebop.

Avant de permettre de s'y accrocher et de se balancer, je voulais voir comment m'y prendre pour une interaction plus simple: juste laisser Bilou bousculer le signet et qu'il ondule un peu en reprenant sa place. J'ai le comportement "circular" qui pourrait être pas mal pour ça.

Before I'll let Bilou grab them and swing, I'll have to start with something easier, like just having Bilou disturb them and make them swing stronger when passing nearby. It should be a mere matter of attaching segments to one another with the "circular" controller... except that once Bilou pushes the bottom part of the "rope", segments now need to lookup two objects instead of just one. And that's a bit more tricky to handle for my engine that only allow one object pointer per object.  

Sauf que on tombe dans le cas de figure compliqué où les mouvements d'un segment dépendent à la fois de la position du segment au-dessus et en-dessous de lui, ce qui pose trois questions:

• Est-ce qu'il faut que j'ajoute une zone "solide" à Bilou ?
• Quels flags (pour les collisions) sont disponibles pour ajuster les comportements (j'ai oublié ^^") ?
• de quelles infos est-ce que je dispose après une collision entre deux segments ? Est-ce suffisant ? 

J'avais pensé relire le tag "attach" pour me rafraîchir la mémoire, et j'ai eu la désagréable surprise de le trouver confus, avec quelque malheureuses infos pratiques perdues au milieu du "gamedev story". Il est devenu mon "tag de la semaine", mais j'ai dû reconnaître que ça ne suffisait pas. Je me suis retrouvé à essayer de l'extraire avec les outils "blogpress" et lui appliquer une feuille de style avant de l'utiliser pour tester les "pages web codeberg".

So, that was the idea back on 11/11 when I sat down with my notebook and collected the questions that needed answers before I could get to the coding stage. I thought unrolling the "attach" tag of the thread would give me answers, but it turned out the useful information was somehow lost into trivias, screenshots and other progress reports. And the code documentation wasn't much better, so I ended up restoring a setup for blogpress and tutogit at the same time, uploading them all on codeberg and see whether I could apply simple.css etc.

ça m'a donné le déclic pour reprendre le travail sur le repository "tutogit", en plan depuis 7 ans, vu que maintenant le nouveau système de gestion des propriétés du niveau est arrivé à maturité. Je pense que ce serait là le bon emplacement pour des pages thématiques présentant chaque élément du moteur de jeu ... qui puisse au final s'intégrer à la documentation doxygen. Voilà déjà celle pour attach.

blogpress 0.3

Combinez les scripts de traitement "blogpress" (blogger-vers-epub) et le service d'impression utilisé par Rodrigo Copetti et vous aurez le "side-project" qui me distrait actuellement... Alimenté en plus par une page de recherche sur l'utilisation de XPath pour "travailler plus proprement" ... Sauf que XPath, pour traiter une requête sur le blog, il met 8 secondes. Mes expressions régulières, 1/8ème de seconde.

Ça fait un peu suite à des travaux de septembre dernier pour essayer de voir ce que les "takeout" de photos google ont vraiment dans le ventre, et l'idée serait de "rassembler tout ce qui peut parler de Qui est Bilou, plutôt en Français à destination de la génération suivante.

I have PERL scripts to process the XML data exported from this blog and fetch pictures to get something that could be printed or converted into epub. So far, it had a drawback: if you got an updated version of the xml (i.e. a later backup), all implied filenames for the pictures would change and almost everything would have to be re-downloaded. A shame in a context where some pictures may get lost.

So I opened them again and started replacing "line number" by "uuid generated by blogger", which gives them stable filenames. A curious idea, when you know I was almost stunned by fatigue. I guess I was just too tired to resist the idea of working on a printable book around the idea of "who is Bilou?" that could be printed like the work of Rodrigo Copetti.

Things haven't been all fine, though. One annoyance was those "new" (vs. 2019) 72x72 pixels thumbs that broke some assumptions I made about multiple URLs pointing to the same file in the same post... Then I've tried to use symlinks to refer to contents previously downloaded, but accidentally forgot to tell the "get-pictures" script that it should skip symlinks when they're around, so it tried to overwrite those pictures I already had and I had to plug my backup HDD and enter data recovery mode ... (I mentioned I was tired, right ?)

Plus tôt dans le mois, j'avais passé en revue tous les posts avec le tag "Bilou", donc, pour en retenir à peu près la moitié. 16 Mo de fichier XML, 106 posts retenus (plus les drafts ^^ ) ... des soucis avec les miniatures 72x72 qui essaient de se faire passer pour les images "grand format" ... des soucis avec les fichiers 1600-h qui font semblant d'être des images mais sont en réalité des pages HTML présentant l'image ... des soucis avec les fichiers tirés de screenshots dans firefox qui à force de conversions / -> %2f finissent par produire des noms de fichiers trop long ... les joyeusetés du scripting quoi. Mais au final, j'ai pu avoir un fichier HTML d'à peu près 1Mo référençant la majorité des images voulues convertible en 115 pages de pdf mal fichu (entendez, avec tout de même des images tronquées ou coupées sur deux pages ^^") qui m'a donné envie de voir malgré l'heure avancée "ce que ça donnerait avec la sélection définitive"

Je me prépare donc à télécharger blog-05-07-2025.xml mais à la place ... me voilà débarqué dans le portail "takeout" de google ...  

By late Saturday, I had collected everything again and was ready to apply the scripts on the latest .xml file, the one where I'd have processed all posts with #bilou and assigned some of them to #firstDemo (because they really weren't quite about Bilou himself, but about trees, applemen, scripting ... or something totally unrelated but featuring a small illustration from the 2001 comics). Only to realize that Google has now decided that Blogger export should be managed by the Google Takeout portal. That means waiting for several hours (up to 2 days, but hopefully not in my case), checking boxes and finally receiving a link to a 2GB archive containing .... (drumroll) ... the whole set of pictures uploaded to the blog.

Il me faut donc patienter plusieurs heures pour avoir le nouveau .xml qui est entre-temps devenu un .atom, a laissé tomber certaines informations, regroupé d'autres autrement et est maintenant accompagné ... de l'ensemble (?) des images du blog. Je m'autorise un point d'interrogation, parce que si j'ai finalement pu produire le bilou.html.pdf que je voulais, j'ai quand-même conservé le listing URL->fichiers construit avec blog-28-06-2025.xml et pas avec le nouveau feed.atom ...

Tout ça pour passer le témoin aux p'tits jeunes ? Bah, quand j'ai montré pour la 2eme fois à J.L.N les feuilles qui étaient malgré tout sorties de l'imprimante, il n'y a pour ainsi dire pas regardé et m'a demandé si j'avais fait des progrès avec les cascades, le bug de Bilou-ballerine et tout ça  ^^"

edit: j'ai finalement un petit script thumbify.pl qui rassemble toutes les images 72x72 un peu mieux qu'un oneliner bash et y ajoute les liens vers les posts du blog. ça nous fait 26MiB d'html+png (probablement inutilisable vu le nombre de requêtes HTTP qui seraient nécessaires -- comptez 30' sur le wifi local) ou 11 pages A4 (pas beaucoup plus utiles vu qu'on ne sait pas y faire de recherche ou cliquer sur les liens ^^"). A découvrir sur neocities...

edit++: capturer l'attention de J.L.N avec la page: check ^_^

e-book gets colors!

I decided to pick the expensive-but-easy road and to give the Nova 3 Color a try. It's been too long I'm trying to 'repair' web access on my N96 boox.

 Since the device comes with Chinese manuals, I've took some time to review

The personal note data will never be shared to any third party or internal staff 

[we] may collect info about installed applications, SDK version, system update settings

There are a good deal of things I've had to do to get the device in a usable state.

First, the device is initially couldn't use Google services. I had no "Play Store" around, but even the few google applications that were available through Boox's "Application store" (containing mostly alternate ebook viewers and book collections) -- like Google Drive -- wouldn't work because "the device was not certified". 

Bon, c'est pas la voie de l'économie, mais je jette l'éponge: je ne crois plus au fait de remettre en service le navigateur web de ma liseuse Boox N96 et je prends une Nova 3 Color à la place. Les conditions d'utilisations m'ont l'air ok, mais je resterai quand-même à l'écart du booxcloud, vu que l'appareil nous arrive de Chine.

Activer le PlayStore à travers l'application store du constructeur en entrant un GSF ID, désactiver la fonction "blanchir le fond" pour avoir des polices de caractères utilisables, c'est à peu près tout ce qu'il m'aura fallu faire pour arriver à me servir correctement de l'appareil. Je regrette qu'il n'ait pas de slot micro-SD ni de prise jack, mais un affichage 300dpi capable de me montrer quand les choses sont en couleurs avec une reconnaissance des traîts sans faille ... ça mérite quelques compromis.

Fixing that one wasn't too hard. Just below 'Enable Google Play', there was a cryptic 'GSF ID' box and tapping it (as suggested) took me through the process of telling google I trust the device and so should they (if I understood things correctly). I guess I couldn't expect more from a Chinese device right now.

Second, many of the 3rd-party applications I installed once this was fixed rendered weirdly. They seemed to believe that, as soon as text is large enough, it should be shown with outlined white characters.

I couldn't find any settings menu to change the system font or whatever and I started to get worried. Hopefully, this is tweakable, but not just with a system-wide configuration as I expected (or were told). 

Instead, we can tweak this application-by-application by means of the '°¨_o_' button of the ring-menu. The thing I had to disable was 'whiten the background', something that is certainly a good feature in many places but for some reason leads to weird-looking text.

I can also lie to applications about the device's resolution (actually 1872×1404 at 300dpi, which is über-amaZing) so that it doesn't throw huge fonts at me. That made Wordpress and Twitter back to normal rendering (with the stunning handscript recognition added ^_^)

As far as the device is concerned, my last regret is the lack of a micro SD card support and of an audio jack. So far the over-provisioned 32GB of internal flash sounds enough, but I don't like having to rely solely on some soldered, fated-to-fail storage on my device.

Now, I'll have to understand why the device cannot render my code-in-epub properly, and why it seems to be unable to browse completely my (huge, I must confess) epub files.

Until then, I think I'll populate '#booxread' on twitter ...

Thanks, ::Twig

On y est presque. Un mois après l'arrivée du Boox comme remplaçant du Cybook, j'ai réussi à faire un petit script Perl convertissant la sortie de Doxygen pour que le e-pub reader le plus puissant de l'appareil (point de vue navigation) parvienne à afficher correctement les extraits de code. Et ce grâce à l'aide d'un petit module plutôt bien foutu -- XML::Twig -- permettant d'écrire dès règles du style "si tu rencontres
<div class="line">...</div>, remplace par <tt>...</tt>".

Yo! One month later, I finally have a nice Perl script for converting stylesheet-heavy doxygen output for the super-navigating (but style-agnostic) reader application embedded on my Boox device.
The XML::Twig package I used for the job seems pretty powerful -- and much easier to use than XmlStylesheetsTransformationLanguage, as far as I am concerned.

I can't help but dreaming about pushing it further and have blog excerpts integrated with code snippets on an enlightening document that would progressively turns the readers into code writers that would contribute to dsgametools ...

Il serait très tentant d'utiliser ça pour faire aussi un peu de fusion blog/doxygen, d'ailleurs. histoire de reprendre les schémas UML dans le code navigable.

Doxygen on Onyx

I don't exactly know what I have changed, but using the "Neo Reader" application on the Boox today, my doxygen-to-epub-through-calibre file now renders as expected. I thought that could be linked to the disabling of "cache reflow bitmap" cryptic option in the advanced settings (see the small icon pointed by the stylus on the picture), but re-enabling it doesn't change anything (or it only has an effect when restarting the application ?)

Qu'est-ce que j'ai changé ? Je n'en sais plus trop rien. J'ai "torturé" le morceau de code qui apparaissait dans la version e-pub de mon blog pour essayer de trouver ce qui faisait la différence entre un rendu correct (white-space: pre-wrap ? utilisation de
<pre>plutôt que <div>? de <tt> plutôt que <span>?

Rien n'a semblé avoir d'effet. Puis ce midi, en jetant un coup d'oeil à mon code converti par doxygen et calibre, surprise! tout est impecablement rendu.

Plus de numéro de lignes indésirables, changements de polices, traitement correct des espaces ... tout y est.

Est-ce que ça vient du réglage "cache reflow bitmap" que j'avais changé ? difficile à dire. Le désactiver ne semble pas avoir d'effet immédiat, mais ils auraient pu omettre de dire qu'il fallait redémarrer l'application ...

One major drawback, though: Neo Reader application is the only one for which I find no way to hop back to the place I was before following a link in the epub document. And that will make navigation extremely annoying, I'm afraid.
Neo Reader v2.0 had nice backtracking feature, and that one gets interesting behaviour on my test epub document.

• When using <span> or <div> with the CSS classes associated with working 'code-style' elements, nothing happens
• When using <pre> or <tt> with the same elements, code is rendered as it should (as printed on dot-matrix ;-)
• The style applied to "English section" (using <en>) doesn't go italic, while emphasis directly using <i> in the French part goes italic.
• skipping CSS classes altogether has no impact (given that you're using
  
  pre/tt tags)
• embedding the whole stuff in "blockquote" doesn't seem to have much effect
• trying to use tables with colspan and some cells containing only a few whitespaces failed miserably. I think all cells are just sitting in a vertical list, not laid out on a table at all. 

I got a Boox

J'ai reçu mon nouveau gadget à base d'encre électronique, donc. Même si au prix où il était, j'espère qu'il sera plus proche d'un ordi que d'un gadget, évidemment. Il s'agit d'un Onyx Boox 9.6" combinant un stylet magnétique et un écran capacitif.

I jumped completely out of my comfort zone and ordered online a device I never had in hands before at a price well over that of a Nintendo DS: the Onyx Boox N96, combining magnetic stylus (afaik), capacitive screen and e-ink display for roughly the size of a A5 sketchpad.

Malgré une boîte tout-en-chinois un peu intimidante, l'appareil a des menus en bon Anglais et la prise en main s'est faite assez facilement. Ma grande inquiétude, évidemment, c'était de savoir si je pourrai m'en servir pour mes documents "doxygen" si utile pour faire du développement intermittent.

The device feels right in hand, is quite a hybrid between an androïd tablet (unfortunately only 4.0, making applications for twitter, picasa and blogger unusable >_<), but what was really stressing me was to know whether I could use it for epub+doxygen code browsing I've been usiing sooo much for the last years to progress on my pet projects. And unfortunately, out of the 4 embedded readers, none of them got the layout right. No indentation, useless line numbers, incoherent spacing ... all of the issues I had fixed earlier this summer -- and some I never heard of before -- were back to haunt me.

Ce n'est pas gagné: sur les quatre lecteurs e-pubs embarqué, aucun n'a un système "styles de l'éditeur" comme mon regretté Cybook. Et sur chacun d'eux, le code produit a tous les défauts d'une mauvaise conversion: pas d'indentation, numéro de ligne inutiles, tailles incohérentes, etc.

J'avais compté sur l'installation de FBReader, testé avec succès sur la tablette de ma fée, mais c'était compter sans une dernière roublardise d'androïd: Il y a en réalité une version plus ancienne de FBReader dans le pack d'applications préinstallées, ce qui m'empèche d'installer une version plus récente pour cause d'erreur -104. (j'aurai peut-être plus de chances après une recompilation ?)

My plan was to use the open-source FBReader if such thing occured, but unfortunately, I couldn't install it from Google Play: interference between the pre-installed FBReader (older version) in the firmware makes it fail with error -104.

I was hesitating between sending it back and switching to some pure html-based doxygen crawling when a post in one of my blog-on-epub conversion caught my attention.

Bref, je m'apprétais à devoir me rabattre sur une utilisation de pages webs moins pratiques (pas d'annotations, pas de marqueur 'vous êtes ici' d'une lecture à l'autre, etc.) lorsqu'au détour d'un post de ce blog converti en fichier e-pub, je constate que l'un des lecteurs par défaut (je ne me souviens pas duquel il s'agit :P) que les styles sont tout à fais satisfaisants pour mes besoins:

• le bloc de code est en police monospace alors que le texte du post est en police classique,
• les indentations ont fonctionné correctement,
• (bin y'a pas denuméro de ligne, forcément, vu que je n'en ai pas mis. Haha.)

Le jeu, ça va être maintenant de comprendre la différence entre ce bloc-là et ce que j'avais dans mon document doxygen pour faire des doxygens qui marchent mieux.

See ? It's all there. Indentation, font switching... The CSS reading is there. The rendering works. It's all a matter of making the doxygen stuff damn simple enough so that it couldn't possibly fail. That's something I can handle. The boox may stay here.

cyblog de retour.

Voilà ... quelques retouches à mon projet "blogpress" puisque je m'étais fait exiler sur le vieux PC bruyant où je l'avais développé. Et j'en extrait un livre de 600 mini-pages avec les posts sur le thème "quel jeu ?"

Bien sympa. En Français exclusivement (puisque je filtre le contenu des balises "<en>" au moment de l'export pour le format .epub), et perfectible:

• j'approche les 50Mo pour un thème (une dizaine de tags sur le blog)
• trop d'images dupliquées. Il faudra les identifier (fdupes) et n'en garder qu'une de chaque
• la construction d'un chapitre par tag est plus intéressante parce qu'elle permet de cibler la lecture (en tout cas pour moi)
• Tous les liens page-à-page sont pour l'instant perdus (si on clique dessus, la liseuse essaiera d'aller se connecter sur le blog)

Enfin, je serai prêt à affronter les plages et les plaines de jeu ^_^

Updating Doxyfile

Depuis 2014, je n'utilise apparemment plus que d'anciennes versions de mon code sur ma liseuse Cybook. Du coup, l'utilité s'en trouve assez bien réduite. En cause ? le comportement du nouveau doxygen (1.8.11 contre le 1.7.6 qui avait donné des résultats plus satisfaisants à force de bricole).

Pendant un moment, je me suis dit que je ferais mieux de passer par DocBook (dont je ne sais pas grand-chose excepté le fait qu'il s'agit d'xml). En fait, ce ne serait pas la bonne approche:

1. le générateur de documentation DocBook de doxygen ne fournit pas les "fragments de code" qui sont essentiels pour mon utilisation
2. s'il existe des epub-tools pour faire la conversion docbook->epub, le contenu même du format e-pub c'est ... de l'HTML.

It looks like the last time I updated code shown on my cybook e-ink reader was in 2014. The reason is the newer doxygen that came with with ubuntu since then produces HTML code that makes much less usable epubs.

I realize that CSS support on cybook is picky on what works and what doesn't. Plus there are now 'tooltip' additional information that calibre unrolls between each function. And line numbers, which I don't need in this context either and impede readability.

J'ai donc repris point par point les choses qui posent problème dans la sortie de doxygen 1.8.11

• les modifications pour que le code ressemble à du code et ne soit pas trop grand ne marchent plus. La faute à un nouveau jeu de règles CSS. Mais en réalité, les modifications que j'avais apportées à ces règles sont assez peu nombreuses, et je devrais donc pouvoir faire l'équivalent sur le nouvea fichier CSS.
• les blocs indésirables en fin de fragment de code sont en réalité les tooltips, rendus visibles soit par calibre (le logiciel que j'utilise pour la conversion HTML->epub), soit par mon remplacement sauvage du .css de doxygen 1.8 par un .css modifé venant de doxygen 1.7 ... quoi qu'il en soit, définir SOURCE_TOOLTIPS=NO permet de les évincer du code HTML sans devoir y aller à coup d'expressions régulières. Et si rien ne m'indiquait que c'était possible dans mon DoxyFile, c'est tout simplement que je travaillais dans un fichier 1.7 où la fonction était indisponible ^^"
• les indentations déviantes s'expliquent par une largeur de tabulations de 3 dans les règlages de Doxygen alors qu'elles sont définies à 8 caractères dans mon éditeur. Et que malheureusement il y a toujours dans le code un mélange d'espaces et de tabulations pour indenter le code >_<
• Enfin, pour les numéros de lignes, je n'ai rien trouvé pouvant les supprimer, mais ils ont heureusement une structure très prévisible dans le code HTML. Un sed -ie "s:[ 0-9]*::g" *.html, et on en sera quitte.

Et je préparais un commentaire désobligeant sur la lenteur de conversion à laquelle calibre m'avait habitué, mais il semble que la version présente sur Ubuntu 16.04 a réglé ça. Voyons donc ...

Verdict : il y a encore du travail. Lors de la conversion, je me farcis un retour à la ligne chaque fois qu'on passe à un autre type d'élément syntaxique connue (un mot-clé, un type de donnée, une variable reconnue, une chaîne littérale, etc.)

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 ...

Doxygen & Cybook : round 2

That's for sure: doxygen output on a cybook is a great thing to plan the next update on my tools. I can do that any time while commuting, take simple notes and then just commit the changes into code when I get to a keyboard-enabled computer :)

Still, that requires a bit of tweaking of my Doxyfile configuration:

COLS_IN_ALPHA_INDEX    = 3
ALPHABETICAL_INDEX     = YES
REFERENCES_LINK_SOURCE = NO
REFERENCED_BY_RELATION = YES
FULL_PATH_NAMES        = NO

Au fil des mois, mon cybook odyssey se révèle de plus en plus un puissant allié pour la programmation de projets-hobby. Toujours en poche (ou presque), il me permet de planifier les évolutions de mon projet à tête reposée, dans mon fauteuil, sans nécessiter de réimprimer à chaque fois la dernière version du code. Il a évidemment fallu un peu chipoter pour avoir des documents "pratiques" sur cet écran 600x800, en enlevant les numéros de ligne ici, changeant la structure du document là, etc. Mais le résultat est plutôt satisfaisant.

J'aimerais juste que l'Odyssey soit capable de détecter les "clics" sur les schémas en mode "image map" (cf. p. 1629, par exemple) et que doxgen propose un mode "epub" natif qui m'éviterait de faire tourner "calibre" pendant près de 10 minutes pour la conversion html->epub.

Once the doxygen files have been created, I need to post-process them to strip out line numbers in the code. There's unfortunately no configuration setting to do that *in doxygen* itself, and I lost the patch that forced doxygen to avoid generating them altogether.
fe class*.html "mv % /tmp/% ; sed /tmp/% -e 's:/a>0[0-9]*:/a>:g;' > % ; echo % stripped"

Last step is to get rid of <namespace>:: prefix in some classes name (in the class index) so that it actually fits 3 columns.
mv classes.html /tmp/ ; sed /tmp/classes.html -e "s/>[A-Z][a-zA-Z]*::/>/g;" > classes.html

Unfortunately, calibre is still über-slow processing this, and it looks like the Cybook Odyssey doesn't support clickable image maps. Anyway, if you want to give it a try (and have the hardware as well), here's the file.

cybook + doxygen = long

Le Sprite Editor est en rade, mon fichier d'images pour la school zone de plus en plus mal en point ... et pourtant je "perds mon temps" à essayer d'avoir du contenu 'bilou' sur mon nouveau gadget: le Cybook Odyssey. Encre électronique, écran tactile, ce n'est pas la noteslate que j'espérais, mais au moins il existe ... et avec un peu de chance, il me permettra d'avoir les yeux moins fatigués en fin de journée, au boulot.

L'appareil supporte les fichiers HTML en natif, donc les choses auraient dû être assez simples ... Sauf qu'en mode "lecture de fichier offline", les liens sont ignorés dans le mode HTML. Il me faut donc passer au format dédié "epub".

Je me suis perdu dans des tentatives de conversion doxygen xml -> docbook -> epub en passant par les feuilles de styles XSL de la bibliothèque boost ... alors qu'il suffisait de prendre un fichier HTML et de le passer à calibre pour qu'il me fasse un "joli" epub prêt à l'emploi (en près de 5 minutes quand-même :P), récupérant lui-même les pages inter-dépendantes, etc.

I wasn't much into amazon library, but I managed to purchase a french e-ink device to get some publications shown without having to print things all over the time: the Cybook Odyssey. It has a touchscreen (that was a must for me) and WiFi, and while it is not the NoteSlate I hoped to purchase, it should help me avoiding eye strain at the end of the day.

Since it natively supports HTML content, showing bilou-ish things on it should have been trivial, but unfortunately, if you check some HTML in offline mode, many things don't work. Hyperlink, for a start. And annotations. If I want to have some doxygen on it, I'll have to convert it to the dedicated e-book file format: epub.

Et là-dessus, je n'ai toujours pas corrigé plus SEDS ... et il est temps d'aller souhaiter bonne fête à mon papa ^^"

EDIT: note pour les autres utilisateurs de cybook: il y a malgré tout moyen d'avoir les annotations, surlignage et signets pour les fichiers PDF même si ça n'apparaît pas directement dans le menu contextuel. Tapottez un coup dans le coin supérieur droit de votre cybook (comme vous pouvez d'ailleurs le faire sur les .epub) pour avoir directement le menu "annotations" qui apparaît. C'est un peu hésitant (toucher/relâcher ne marchera pas, ni un petit glissement. Il faut vraiment une petite touche du bout du doigt comme si vous vouliez vérifier que la casserole n'est pas trop chaude sans risquer de vous brûler. Par contre, si votre pdf est un vieux document numérisé sans reconnaissance de caractères (au hasard, un mode d'emploi de C64 ? :P), oubliez tout ce qui nécessiterait un surlignage pour l'instant: le cybook prend vraiment trop longtemps à essayer de trouver le texte à surligner dans ce cas-là.

After some aborted attempts to go through docbook format, I realised that there was a tool (calibre) that could do straight HTML->epub conversion, producing some decent output. It takes a while to process the file, though. Easily up to 5 minutes. 

Oh, and you could have annotations and 'highlighting' with PDF files too, although it doesn't show up in the contextual menu. Just double-tap the upper-right corner to get the annotations menu showing up.