Geany Newsletter #2 -------------------
Contents ========
About Geany Geany Development Update to Scintilla 2.25 Real-time tag parsing Automatic indentation width detection Fixes to template encoding Plugins New plugins geanycfp GeanyNumberedBookmarks GeanyMacro Other features Significant updates on Split Window Plugin A view onto GeanyVC usage Let us introduce you... Plugin Focus Save Actions Auto Save Instant Save Backup Copy Feature Focus Append Toolbar to the Menu Other screen-space-saving tips Geany local Geany at Chemnitzer LinuxTage (March, 19th-20th) About this newsletter
About Geany ===========
Geany is a small and lightweight Integrated Development Environment. It was developed to provide a small and fast IDE, which has only a few dependencies from other packages. Another goal was to be as independent as possible from a special Desktop Environment like KDE or GNOME - Geany only requires the GTK2 runtime libraries.
More information about Geany can be found at geany.org http://www.geany.org/.
Geany Development =================
Update to Scintilla 2.25 ^^^^^^^^^^^^^^^^^^^^^^^^
With Subversion revision 5682 another update to Scintilla has been done so Geany's development version is now powered by Scintilla 2.25 in favor of the version previously used: 2.22.
As with every update of Scintilla there have been a lot of improvements. This includes changes to Scintilla itself, for example: fixing an issue with marking of a word when double clicking or fixing some memory leaks and unneeded redraws of editor window as well on used lexer e.g. for SQL.
A detailed list of changes done with Scintilla can be found at Scintilla ChangeLog http://www.scintilla.org/ScintillaHistory.html.
Real-time tag parsing ^^^^^^^^^^^^^^^^^^^^^
Parsing of symbols (also known as tags) in the file currently being edited can now be done directly in memory. This change means that tag parsing for the current document happens in real time when the content changes; so the symbol list reflects the actual content of the document rather than the state when it was last saved.
This can be configured (and disabled) in the preferences by the `Symbol list update frequency` option under `Editor -> Completions`.
Automatic indentation width detection ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Geany now has the ability to detect the indentation width used by a file when opening it, making it easier to work with files which use different indentation widths. The auto-detection, however, doesn't yet work if the file uses a tabs-only indentation type.
To enable automatic detection of indentation width, open the Preferences dialog and check `Detect width from file` in the `Editor->Indentation` section.
Fixes to template encoding ^^^^^^^^^^^^^^^^^^^^^^^^^^
The encoding of template files is now properly auto-detected, fixing loading of any template using an encoding incompatible with UTF-8.
Plugins =======
New plugins ^^^^^^^^^^^
geanycfp ********
Back in January, William Fraser add the geanycfp plugin which adds a couple of interesting new functions to Geany's plugin pool.
After some time this plugin has been split up into GeanyNumberedBookmarks and GeanyMacro, but this process is not yet finished.
GeanyNumberedBookmarks ######################
The plugin adds an option to store bookmarks in files and directly access them via a keybinding.
To set a numbered bookmark press Ctrl+Shift+(a number from 0 to 9). You will see a marker appear next to the line number. If you press Ctrl+Shift+(a number) on a line that already has that bookmark number then it removes the bookmark, otherwise it will move the bookmark there if it was set on a different line, or create it if it had not already been set.
GeanyMacro ##########
Macros are well known from other tools. Users of Photoshop are always saying how amazing the batch processing is for manipulating images. However, this plugin adds something similar to Geany with its macro feature: the plugin can record small actions and rerun them after pressing e.g. a keybinding. This could be very helpful for example if you need to remove the last two letters of a line and search & replace or rectangle selection are not able to solve the request.
Other features ##############
Remembering fold states:
By default, Geany does not remember the status of folding when reloading a file e.g. on startup. This can be annoying when you have a huge number of nested structures e.g. inside an XML-document. This feature helps you to remember those states so you don't have to fold again after loading.
Significant updates on Split Window Plugin ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There have been quite a few improvements and bug fixes done in the Split Window plugin that ships with Geany which allows viewing two documents at the same time.
Code folding is now supported in the split editor as of revision 5626.
Since revision 5633, the terminology used in the Split Window menu under the Tools menu has been improved to avoid ambiguity regarding the direction in which the split will take place. Rather than using the word Horizontal for when the editors are laid out horizontally (the splitter is vertical), the words "Side by Side" are now used. Likewise, when the editors are laid out vertically (the splitter is horizontal), the words "Top and Bottom" are now used.
Previously, when the Split Window was active and the document currently being viewed in it was closed in the main documents notebook, the Split Window plugin would unsplit, even if there were other documents which could be viewed instead. As of revision 5634, when this happens, the Split Window plugin will switch to view the current document in the main documents notebook instead. If there are no more documents open, the Split Window plugin will unsplit.
Probably the most significant improvement to the Split Window plugin is that it will now work on Microsoft Windows. Previously, the plugin was using a trick to work around a bug in the Scintilla widget Geany uses as editing component. A side effect of this workaround was that it caused serious issues on Windows and so the plugin was disabled for the Windows build. Matthew Brush fixed the bug in Scintilla and sent the fix to the Scintilla project where it was merged upstream. Geany is no longer required to use the previously mentioned trick, and so the plugin was re-enabled for the Windows build, with equivalent functionality as it has on other platforms.
A view onto GeanyVC usage ^^^^^^^^^^^^^^^^^^^^^^^^^
GeanyVC is one of the oldest plugins of Geany and adds bindings for some popular version control systems to Geany such as Subversion and GIT. To get a feeling which bindings are being used we started a little Doodle poll a couple of weeks ago. The output was interesting and a little surprising: Until the end of April 2011, 33 people took part in the poll and the first surprise was that none of these are using GeanyVC for working with either CVS or SVK. In terms of CVS this has been a real surprise as it was one of the most popular version control systems during the last decades. SVK always took place a role inside 2nd row as its trying to add some offline functionality to Subversion but keeping Subversion inside core. With the introduction of GIT and a number of new features being added to Subversion with version 1.6, the biggest advantages were also went away.
However, most users do use the plugin for working with GIT (~90%) followed by Subversion as you can see from the tiny chart at <newsletter.geany.org>
Bazaar and Mercurial are also getting used, but only seem to have a minor role in GeanyVC's universe.
Let us introduce you... =======================
This section is intended to introduce particular plugins or features on a regular basis.
Plugin Focus ^^^^^^^^^^^^
Save Actions ************
The Save Actions plugin adds options available to you when saving files, including: Auto Save, Instant Save and Backup Copy. Each of the options can be enabled independently but they can be even more powerful when used in combination. Read on, discover their functions, and judge for yourself if this plugin might make your use of Geany easier and more productive.
Auto Save #########
Auto Save provides an option to automatically save either the current file or all open files at a defined interval. It can be very useful if you tend to forget to save because it works in the background. The default interval is 300 seconds, which is 5 minutes, but you might prefer to set a longer or shorter interval.
Instant Save ############
Instant Save aims to make it easier to make use of Geany's file-specific features with newly-created files. With this plugin activated you can specify what file type new files are to be treated as. If you often work with Python for example, and are testing code snippets, you can activate the plugin, configure new files to be treated as Python and Geany's full Python support is available when the file's created.
Backup Copy ###########
Backup Copy will keep backup copies of files as you save them. Instead of cluttering the file's own directory, the backups are stored in a specific directory. So that you can identify when each backup was created, the backup files have the current date and time added to the end of their names, with the date and time format being configurable. To make finding your backups even easier there is even an option to recreate the directory structure in which the current file is stored.
When combined with the Auto Save option, the Backup Copy option can provide a basic form of versioning with a backup copy of your file(s) every time they were saved. A version control system such as GIT, Subversion or Mercurial is definitely recommended instead when possible.
Feature Focus ^^^^^^^^^^^^^
Append Toolbar to the Menu **************************
The popularity of the netbook means that many people are looking at screens which are less than the desktop PC sizes of 15 inch and above. A netbook's screen format is usually widescreen, so vertical space is more limited than horizontal space. If you navigate to Edit -> Preferences you'll find an option titled "Append Toolbar to the Menu". Checking this option will result in the toolbar being moved from below the menu bar to beside it, resulting in more vertical space being available.
Other screen-space-saving tips ******************************
Geany has several other options which increase the amount of room available for the editing pane. In the View menu you'll find an option titled "Toggle all Additional Widgets" which hides all elements of the user interface except for the menu bar and scrollbars. Also in the View menu is an option titled "Fullscreen" which maximizes the Geany window to take up the entire screen, also turning off the window's titlebar and borders. This view can be especially useful if you want to minimize distractions from other applications.
Geany local ===========
Geany at Chemnitzer LinuxTage (March, 19th-20th) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Together with the guys of Xfce, Geany was presented with a booth at the annual Chemnitzer LinuxTage event in March, a convention about all topics around Linux, BSD and free software in general. The booth was well visited and people came not only to ask questions or report a bug but also to tell us what they are using Geany for. So Dominic, Enrico and Frank had a lot of questions to answer and a lot of feedback to respond to.
About this newsletter =====================
This newsletter has been created in cooperation by people from Geany's international community. Contributors to this newsletter and the infrastructure behind it, ordered by alphabet:
Colomban Wendling, Dominic Hopf, Enrico Tröger, Frank Lanitz, Matthew Brush, Nicholas Manea, Russell Dickenson
On Sun, May 22, 2011 at 1:25 PM, Frank Lanitz frank@frank.uvena.de wrote:
Geany Newsletter #2
Contents
{snip}
Great newsletter!
Would be helpful if there were a link at the top of the newsletter email pointing to the online html version: http://newsletter.geany.org/vol_2/newsletter_2.html
At the top of that online html page, it would be helpful if there were a link back to http://newsletter.geany.org/ to make it easier to take a peek at previous versions.
Also, the navigation menus on the left hand side at http://www.geany.org/ could use a link to newsletter.geany.org. Maybe in the Documentation section?
Finally, I found the newsletter easier to follow when the sections were numbered, as with the first newsletter.
Thanks! ---John
Am 23.05.2011 04:13, schrieb John Gabriele:
On Sun, May 22, 2011 at 1:25 PM, Frank Lanitz frank@frank.uvena.de wrote:
Geany Newsletter #2
Contents
{snip}
Great newsletter!
Would be helpful if there were a link at the top of the newsletter email pointing to the online html version: http://newsletter.geany.org/vol_2/newsletter_2.html
At the top of that online html page, it would be helpful if there were a link back to http://newsletter.geany.org/ to make it easier to take a peek at previous versions.
Good point. Will be added with next release ;)
Also, the navigation menus on the left hand side at http://www.geany.org/ could use a link to newsletter.geany.org. Maybe in the Documentation section?
Yepp, maybe useful.
Finally, I found the newsletter easier to follow when the sections were numbered, as with the first newsletter.
Me too. Unfortunately I wasn't able to create this by using RST but failed. Input is welcome.
Cheers, Frank
Me too. Unfortunately I wasn't able to create this by using RST but failed. Input is welcome.
Replace the h1 and h2 CSS definitions with the following:
body { counter-reset: counter1; counter-reset: counter2; } h1:before { content: counter(counter1) " "; } h1.title:before { content: ""; } h1 { counter-increment: counter1; counter-reset: counter2; font-size: 1.4em } h2:before { content: counter(counter1) "." counter(counter2) " "; } h2 { counter-increment: counter2; font-size: 1.3em }
Cheers Lex
Cheers, Frank _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Am 23.05.2011 10:08, schrieb Lex Trotman:
Me too. Unfortunately I wasn't able to create this by using RST but failed. Input is welcome.
Replace the h1 and h2 CSS definitions with the following:
body { counter-reset: counter1; counter-reset: counter2; } h1:before { content: counter(counter1) " "; } h1.title:before { content: ""; } h1 { counter-increment: counter1; counter-reset: counter2; font-size: 1.4em } h2:before { content: counter(counter1) "." counter(counter2) " "; } h2 { counter-increment: counter2; font-size: 1.3em }
Its not only about the html, but also the generated PDF as well as the plain text version.
Cheers, Frank
On 23 May 2011 18:33, Frank Lanitz frank@frank.uvena.de wrote:
Am 23.05.2011 10:08, schrieb Lex Trotman:
Me too. Unfortunately I wasn't able to create this by using RST but failed. Input is welcome.
Replace the h1 and h2 CSS definitions with the following:
body { counter-reset: counter1; counter-reset: counter2; } h1:before { content: counter(counter1) " "; } h1.title:before { content: ""; } h1 { counter-increment: counter1; counter-reset: counter2; font-size: 1.4em } h2:before { content: counter(counter1) "." counter(counter2) " "; } h2 { counter-increment: counter2; font-size: 1.3em }
Its not only about the html, but also the generated PDF as well as the plain text version.
I'm just following the Rest documentation which said to number HTML with CSS, don't know how to do plain text.
I thought PDF was generated via latex and I wasn't about to try to tell *you* how to get Latex to do the numbering :-)
And like a great man once said: "all interesting programs have at least one counter, at least one loop and at least one bug", so the first line should read
body { counter-reset: counter1 -1 counter2; }
otherwise the heading counts as 1.
Cheers Lex
Cheers, Frank _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Am 23.05.2011 10:50, schrieb Lex Trotman:
I thought PDF was generated via latex and I wasn't about to try to tell *you* how to get Latex to do the numbering :-)
With change to ReST this has been changed as the TeX export is causing nightmares to me in current state.
Cheers, Frank
Hey,
Le 23/05/2011 11:05, Frank Lanitz a écrit :
Am 23.05.2011 10:50, schrieb Lex Trotman:
I thought PDF was generated via latex and I wasn't about to try to tell *you* how to get Latex to do the numbering :-)
With change to ReST this has been changed as the TeX export is causing nightmares to me in current state.
I tuned a bit PDF (and LaTeX) generation and pushed on branch pdf-from-latex [1] if anyone want to take a look. OK it's a little ugly to postprocess LaTeX output, but at least it looks almost OK. Feel free to tune, I'm a LaTeX noob, just collected some infos to get this working.
About switching to another lightweight markup format, just make sure the output is flexible enough not to need this kind of things to tune the output. Even if the default output "looks good".
Cheers, Colomban
Am 24.05.2011 15:58, schrieb Colomban Wendling:
Hey,
Le 23/05/2011 11:05, Frank Lanitz a écrit :
Am 23.05.2011 10:50, schrieb Lex Trotman:
I thought PDF was generated via latex and I wasn't about to try to tell *you* how to get Latex to do the numbering :-)
With change to ReST this has been changed as the TeX export is causing nightmares to me in current state.
I tuned a bit PDF (and LaTeX) generation and pushed on branch pdf-from-latex [1] if anyone want to take a look. OK it's a little ugly to postprocess LaTeX output, but at least it looks almost OK. Feel free to tune, I'm a LaTeX noob, just collected some infos to get this working.
About switching to another lightweight markup format, just make sure the output is flexible enough not to need this kind of things to tune the output. Even if the default output "looks good".
Not sure what I'm doing wrong, but not working:
frlan@ubuntu:~/git/newsletter$ LANG=C vol=2 make pdf maxpasses=5; \ file=`basename vol_2/newsletter_2.tex .tex`; \ cd `dirname vol_2/newsletter_2.tex` && \ pdflatex -interaction batchmode "$file.tex" > /dev/null && \ while test $maxpasses -gt 0 && grep -q -i 'rerun' $file.log; do \ pdflatex -interaction batchmode "$file.tex" >/dev/null || exit 1; \ maxpasses=`expr $maxpasses - 1`; \ done; \ rm "$file.log" "$file.toc" "$file.out" "$file.aux" rm: cannot remove `newsletter_2.toc': No such file or directory rm: cannot remove `newsletter_2.out': No such file or directory rm: cannot remove `newsletter_2.aux': No such file or directory make: *** [vol_2/newsletter_2.pdf] Error 1
Cheers, Frank
Le 24/05/2011 16:14, Frank Lanitz a écrit :
Not sure what I'm doing wrong, but not working:
frlan@ubuntu:~/git/newsletter$ LANG=C vol=2 make pdf maxpasses=5; \ file=`basename vol_2/newsletter_2.tex .tex`; \ cd `dirname vol_2/newsletter_2.tex` && \ pdflatex -interaction batchmode "$file.tex" > /dev/null && \ while test $maxpasses -gt 0 && grep -q -i 'rerun' $file.log; do \ pdflatex -interaction batchmode "$file.tex" >/dev/null || exit 1; \ maxpasses=`expr $maxpasses - 1`; \ done; \ rm "$file.log" "$file.toc" "$file.out" "$file.aux" rm: cannot remove `newsletter_2.toc': No such file or directory rm: cannot remove `newsletter_2.out': No such file or directory rm: cannot remove `newsletter_2.aux': No such file or directory make: *** [vol_2/newsletter_2.pdf] Error 1
Seems your pdflatex don't generate .toc, .out and .aux... no idea if it's normal behavior (mine does output them), but I pushed a fix not to fail if one of these files don't exist, so it should be fixed.
Cheers, Colomban
On Tue, 24 May 2011 17:07:52 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 24/05/2011 16:14, Frank Lanitz a écrit :
Not sure what I'm doing wrong, but not working:
frlan@ubuntu:~/git/newsletter$ LANG=C vol=2 make pdf maxpasses=5; \ file=`basename vol_2/newsletter_2.tex .tex`; \ cd `dirname vol_2/newsletter_2.tex` && \ pdflatex -interaction batchmode "$file.tex" > /dev/null && \ while test $maxpasses -gt 0 && grep -q -i 'rerun' $file.log; do \ pdflatex -interaction batchmode "$file.tex"
/dev/null || exit 1; \ maxpasses=`expr $maxpasses - 1`; \
done; \ rm "$file.log" "$file.toc" "$file.out" "$file.aux" rm: cannot remove `newsletter_2.toc': No such file or directory rm: cannot remove `newsletter_2.out': No such file or directory rm: cannot remove `newsletter_2.aux': No such file or directory make: *** [vol_2/newsletter_2.pdf] Error 1
Seems your pdflatex don't generate .toc, .out and .aux... no idea if it's normal behavior (mine does output them), but I pushed a fix not to fail if one of these files don't exist, so it should be fixed.
Well, it seems there has been an error before which prevented pdflatex from running correctly as when I commented the rm out for testing, it also failed. And its not normal behavior ;)
However, after the change its running on my Debian unstable box. Will try it tomorrow with 'ancient' Ubuntu 10.04 where I originally experienced the issue.
Cheers, Frank
Am 24.05.2011 23:33, schrieb Frank Lanitz:
On Tue, 24 May 2011 17:07:52 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 24/05/2011 16:14, Frank Lanitz a écrit :
Not sure what I'm doing wrong, but not working:
frlan@ubuntu:~/git/newsletter$ LANG=C vol=2 make pdf maxpasses=5; \ file=`basename vol_2/newsletter_2.tex .tex`; \ cd `dirname vol_2/newsletter_2.tex` && \ pdflatex -interaction batchmode "$file.tex" > /dev/null && \ while test $maxpasses -gt 0 && grep -q -i 'rerun' $file.log; do \ pdflatex -interaction batchmode "$file.tex"
/dev/null || exit 1; \ maxpasses=`expr $maxpasses - 1`; \
done; \ rm "$file.log" "$file.toc" "$file.out" "$file.aux" rm: cannot remove `newsletter_2.toc': No such file or directory rm: cannot remove `newsletter_2.out': No such file or directory rm: cannot remove `newsletter_2.aux': No such file or directory make: *** [vol_2/newsletter_2.pdf] Error 1
Seems your pdflatex don't generate .toc, .out and .aux... no idea if it's normal behavior (mine does output them), but I pushed a fix not to fail if one of these files don't exist, so it should be fixed.
Well, it seems there has been an error before which prevented pdflatex from running correctly as when I commented the rm out for testing, it also failed. And its not normal behavior ;)
However, after the change its running on my Debian unstable box. Will try it tomorrow with 'ancient' Ubuntu 10.04 where I originally experienced the issue.
I'm afraid still not working on Xubuntu 10.4 :( and I don't have a clue why.
Cheers, Frank
Le 25/05/2011 15:45, Frank Lanitz a écrit :
Am 24.05.2011 23:33, schrieb Frank Lanitz:
On Tue, 24 May 2011 17:07:52 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 24/05/2011 16:14, Frank Lanitz a écrit :
Not sure what I'm doing wrong, but not working:
frlan@ubuntu:~/git/newsletter$ LANG=C vol=2 make pdf maxpasses=5; \ file=`basename vol_2/newsletter_2.tex .tex`; \ cd `dirname vol_2/newsletter_2.tex` && \ pdflatex -interaction batchmode "$file.tex" > /dev/null && \ while test $maxpasses -gt 0 && grep -q -i 'rerun' $file.log; do \ pdflatex -interaction batchmode "$file.tex"
/dev/null || exit 1; \ maxpasses=`expr $maxpasses - 1`; \
done; \ rm "$file.log" "$file.toc" "$file.out" "$file.aux" rm: cannot remove `newsletter_2.toc': No such file or directory rm: cannot remove `newsletter_2.out': No such file or directory rm: cannot remove `newsletter_2.aux': No such file or directory make: *** [vol_2/newsletter_2.pdf] Error 1
Seems your pdflatex don't generate .toc, .out and .aux... no idea if it's normal behavior (mine does output them), but I pushed a fix not to fail if one of these files don't exist, so it should be fixed.
Well, it seems there has been an error before which prevented pdflatex from running correctly as when I commented the rm out for testing, it also failed. And its not normal behavior ;)
However, after the change its running on my Debian unstable box. Will try it tomorrow with 'ancient' Ubuntu 10.04 where I originally experienced the issue.
I'm afraid still not working on Xubuntu 10.4 :( and I don't have a clue why.
With the help of a 10.4 user, I fixed it. Actually, it's because 10.4 has Docutils 0.6 and it seems it don't know about --latex-preamble. I then dropped it (anyway I didn't actually used it), it should now work.
Cheers, Colomban
On Wed, 25 May 2011 18:11:16 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 25/05/2011 15:45, Frank Lanitz a écrit :
Am 24.05.2011 23:33, schrieb Frank Lanitz:
On Tue, 24 May 2011 17:07:52 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 24/05/2011 16:14, Frank Lanitz a écrit :
Not sure what I'm doing wrong, but not working:
frlan@ubuntu:~/git/newsletter$ LANG=C vol=2 make pdf maxpasses=5; \ file=`basename vol_2/newsletter_2.tex .tex`; \ cd `dirname vol_2/newsletter_2.tex` && \ pdflatex -interaction batchmode "$file.tex" > /dev/null && \ while test $maxpasses -gt 0 && grep -q -i 'rerun' $file.log; do \ pdflatex -interaction batchmode "$file.tex"
/dev/null || exit 1; \ maxpasses=`expr $maxpasses - 1`; \
done; \ rm "$file.log" "$file.toc" "$file.out" "$file.aux" rm: cannot remove `newsletter_2.toc': No such file or directory rm: cannot remove `newsletter_2.out': No such file or directory rm: cannot remove `newsletter_2.aux': No such file or directory make: *** [vol_2/newsletter_2.pdf] Error 1
Seems your pdflatex don't generate .toc, .out and .aux... no idea if it's normal behavior (mine does output them), but I pushed a fix not to fail if one of these files don't exist, so it should be fixed.
Well, it seems there has been an error before which prevented pdflatex from running correctly as when I commented the rm out for testing, it also failed. And its not normal behavior ;)
However, after the change its running on my Debian unstable box. Will try it tomorrow with 'ancient' Ubuntu 10.04 where I originally experienced the issue.
I'm afraid still not working on Xubuntu 10.4 :( and I don't have a clue why.
With the help of a 10.4 user, I fixed it. Actually, it's because 10.4 has Docutils 0.6 and it seems it don't know about --latex-preamble. I then dropped it (anyway I didn't actually used it), it should now work.
Sound good ;) I will give it a try tomorrow. BUT: PDF already looks very well. Huge Thanks!
Cheers, Frank
Le 25/05/2011 18:27, Frank Lanitz a écrit :
Sound good ;) I will give it a try tomorrow. BUT: PDF already looks very well. Huge Thanks!
No problem :) The point I think that should be improved is image sizing/placement, but I can't tell how to fix this without adding one more sed replacement, but as I'm a LaTeX noob, maybe you'll have a solution :)
Cheers, Colomban
PS: I currently played with this addition to the sed replacement (thanks to a friend of mine for most of the LaTeX part):
s/(.*)(\includegraphics)(.*)/\centerline{\1\2[width=\textwidth,height=0.25\textheight,keepaspectratio=true]\3}/
Hi All,
I made a version of the newsletter using asciidoc and generated HTML, PDF and text.
See:
https://github.com/elextr/geany_stuff/commit/d094fb77d37bd00c4172041ea95be08...
The HTML has the images embedded just to make it a single file, they link by default.
Commands used:
For html:
asciidoc -a stylesdir=/home/lex/projects/zzz/newsletter/content -a toc -a toclevels=3 -a data-uri -n newsletter_2.asciidoc
For PDF (a2x is a wrapper that comes with asciidoc that runs dblatex or other toolchains for you and avoids all the problems poor Frank has been having when he was left with Latex and didn't know what options to use)
a2x newsletter_2.asciidoc
For text
a2x --format=text newsletter_2.asciidoc
I have done no formatting to either PDF or text. The HTML of course needed the css changed since the ids and classes had different names, the xhtml11.css is the source used.
Cheers Lex
Le 26/05/2011 04:10, Lex Trotman a écrit :
Hi All,
I made a version of the newsletter using asciidoc and generated HTML, PDF and text.
Don't look too different from ReST, good.
See:
https://github.com/elextr/geany_stuff/commit/d094fb77d37bd00c4172041ea95be08...
The HTML has the images embedded just to make it a single file, they link by default.
Commands used:
For html:
asciidoc -a stylesdir=/home/lex/projects/zzz/newsletter/content -a toc -a toclevels=3 -a data-uri -n newsletter_2.asciidoc
For PDF (a2x is a wrapper that comes with asciidoc that runs dblatex or other toolchains for you and avoids all the problems poor Frank has been having when he was left with Latex and didn't know what options to use)
a2x newsletter_2.asciidoc
For text
a2x --format=text newsletter_2.asciidoc
I have done no formatting to either PDF or text. The HTML of course needed the css changed since the ids and classes had different names, the xhtml11.css is the source used.
The default PDF output looks good apart the two first pages... is it easily to tune everything or is this just a chance that the default "looks better"?
Cheers, Colomban
On 27 May 2011 03:04, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 26/05/2011 04:10, Lex Trotman a écrit :
Hi All,
I made a version of the newsletter using asciidoc and generated HTML, PDF and text.
Don't look too different from ReST, good.
That was the point :-) (for HTML anyway)
I have done no formatting to either PDF or text. The HTML of course needed the css changed since the ids and classes had different names, the xhtml11.css is the source used.
The default PDF output looks good apart the two first pages... is it easily to tune everything or is this just a chance that the default "looks better"?
Well as I said above, I didn't touch the tuning so yes it is "chance" that it "looks better". With separation of content markup and formatting there is nothing that defines what a particular document should look like, it depends on what the particular toolchain's defaults are, as an example I committed the default output from the fop toolchain, really very bland :-) (Note for example that as the document type is "article" fop doesn't create title pages etc, whereas it does if the document type is "book", but dblatex does for both, neither is "right" just different)
Both have numbers of options, see [1] and [2]
And beyond that dblatex uses xsl stylesheets to generate the latex and latex stylesheets which can be infinitely tuned (insert usual reference to guru Frank :-) see [3]
fop uses xsl stylesheets to generate the fo and that can also be infinitely tuned (insert reference to xslt guru, not me but I found it easier than latex :-) see [4]
Cheers Lex
[1] http://dblatex.sourceforge.net/doc/manual/sec-params.html [2] http://sagehill.net/docbookxsl/OptionsPart.html [3] http://dblatex.sourceforge.net/doc/manual/sec-custom-latex.html [4] http://sagehill.net/docbookxsl/CustomizingPart.html
On Wed, May 25, 2011 at 10:10 PM, Lex Trotman elextr@gmail.com wrote:
Hi All,
I made a version of the newsletter using asciidoc and generated HTML, PDF and text.
See: {snip}
Given that:
* the various markup formats and their tools can all easily produce nice-looking html, pdf, and text output * people have their own preferences regarding doc markup formats * different people at different times may produce a given newsletter * no one ever has to go back and edit old newsletters
I don't think it makes much sense to debate which format to use. Whomever is producing the current newsletter should decide which markup format and tools they want to use. [The markup-languages page] should simply provide requirements for the output (as it already does) and provide guidance on how to produce a newsletter using the various tools for those writers who don't have a favorite.
[The markup-languages page]: http://wiki.geany.org/newsletter/markuplanguages
That page might also provide some default newsletter css source for those wanting to make their output look like one or another newsletter (though, variety is the spice of life :) ).
If someone wants to contribute to a given newsletter but is unfamiliar with the markup format that the producer is using, they should just send in their content in whatever format they know and the producer should do the conversion.
---John
Given that:
* the various markup formats and their tools can all easily produce nice-looking html, pdf, and text output * people have their own preferences regarding doc markup formats * different people at different times may produce a given newsletter * no one ever has to go back and edit old newsletters
Agree
I don't think it makes much sense to debate which format to use. Whomever is producing the current newsletter should decide which markup format and tools they want to use. [The markup-languages page] should simply provide requirements for the output (as it already does) and provide guidance on how to produce a newsletter using the various tools for those writers who don't have a favorite.
Good idea.
That page might also provide some default newsletter css source for those wanting to make their output look like one or another newsletter (though, variety is the spice of life :) ).
But I suspect that it might get annoying if every newsletter looked different, too spicey :-)
The css would have to be per markup and tool since the tools don't use the same class and id names for the things we want to style (why should they, there is no standard).
If someone wants to contribute to a given newsletter but is unfamiliar with the markup format that the producer is using, they should just send in their content in whatever format they know and the producer should do the conversion.
Yes, so long as the formats are all lightweight markup languages and stick to sections, images and very simple tables then the conversions should be simple, eg asciidoc paragraphs and sections are valid rst but not markdown and links images and tables are all slightly different. Kinda annoying for the newsletter producer, as I said before wish there were more converters.
Cheers Lex
Am 27.05.2011 04:01, schrieb Lex Trotman:
Given that:
- the various markup formats and their tools can all easily produce
nice-looking html, pdf, and text output
- people have their own preferences regarding doc markup formats
- different people at different times may produce a given newsletter
- no one ever has to go back and edit old newsletters
Agree
I don't think it makes much sense to debate which format to use. Whomever is producing the current newsletter should decide which markup format and tools they want to use. [The markup-languages page] should simply provide requirements for the output (as it already does) and provide guidance on how to produce a newsletter using the various tools for those writers who don't have a favorite.
Good idea.
That page might also provide some default newsletter css source for those wanting to make their output look like one or another newsletter (though, variety is the spice of life :) ).
But I suspect that it might get annoying if every newsletter looked different, too spicey :-)
I agree. So at latest with with issue 3 I will not change anything on markup language as in the end its a useless discussion. All that counts is the content.
The css would have to be per markup and tool since the tools don't use the same class and id names for the things we want to style (why should they, there is no standard).
Ia gree.
If someone wants to contribute to a given newsletter but is unfamiliar with the markup format that the producer is using, they should just send in their content in whatever format they know and the producer should do the conversion.
Yes, so long as the formats are all lightweight markup languages and stick to sections, images and very simple tables then the conversions should be simple, eg asciidoc paragraphs and sections are valid rst but not markdown and links images and tables are all slightly different. Kinda annoying for the newsletter producer, as I said before wish there were more converters.
Please fill in the wikipage by using the feature list I provided.
There will be a poll in maybe 1 week and we will do the decission. No big further discussion here please.
To be honest I'm really sick of this discussion, as changing to ReST wasn't to complicated for me (and shouldn't be for anybody else) but as I still prefer LaTeX for doing such work it was a compromise I wanted to do. So everybody, please be so kind and think about whether you are able to do a compromise too on the first hand and think about whether you ever will contribute to the newsletter or just discussing here to discuss anything. And if you want to write some content for the newsletter and you are sick of language being used for markup, I'm happy to receive a odt, doc, pdf or whatever and convert it to the correct format.
Sorry... a bit pissed, Frank
On 27 May 2011 19:12, Frank Lanitz frank@frank.uvena.de wrote:
Am 27.05.2011 04:01, schrieb Lex Trotman:
Given that:
* the various markup formats and their tools can all easily produce nice-looking html, pdf, and text output * people have their own preferences regarding doc markup formats * different people at different times may produce a given newsletter * no one ever has to go back and edit old newsletters
Agree
I don't think it makes much sense to debate which format to use. Whomever is producing the current newsletter should decide which markup format and tools they want to use. [The markup-languages page] should simply provide requirements for the output (as it already does) and provide guidance on how to produce a newsletter using the various tools for those writers who don't have a favorite.
Good idea.
That page might also provide some default newsletter css source for those wanting to make their output look like one or another newsletter (though, variety is the spice of life :) ).
But I suspect that it might get annoying if every newsletter looked different, too spicey :-)
I agree. So at latest with with issue 3 I will not change anything on markup language as in the end its a useless discussion. All that counts is the content.
I also agree. The focus of the newsletter should first be on the content.
The css would have to be per markup and tool since the tools don't use the same class and id names for the things we want to style (why should they, there is no standard).
Ia gree.
If someone wants to contribute to a given newsletter but is unfamiliar with the markup format that the producer is using, they should just send in their content in whatever format they know and the producer should do the conversion.
Yes, so long as the formats are all lightweight markup languages and stick to sections, images and very simple tables then the conversions should be simple, eg asciidoc paragraphs and sections are valid rst but not markdown and links images and tables are all slightly different. Kinda annoying for the newsletter producer, as I said before wish there were more converters.
Please fill in the wikipage by using the feature list I provided.
Again - I agree. Listing our requirements of a markup method and associated tools is best done in the wiki. When we have agreed that we can easily review what's available and choose from them according to the list.
There will be a poll in maybe 1 week and we will do the decission. No big further discussion here please.
OK. Doodle (poll) here we come. :)
To be honest I'm really sick of this discussion, as changing to ReST wasn't to complicated for me (and shouldn't be for anybody else) but as I still prefer LaTeX for doing such work it was a compromise I wanted to do.
I can understand your view and frustrations, Frank. You compromised in moving the markup from LateX to ReST and I appreciate your willingness in doing this.
So everybody, please be so kind and think about whether you are able to do a compromise too on the first hand and think about whether you ever will contribute to the newsletter or just discussing here to discuss anything. And if you want to write some content for the newsletter and you are sick of language being used for markup, I'm happy to receive a odt, doc, pdf or whatever and convert it to the correct format.
Agreed. Let's get on with focusing first on the content. Perhaps it will take a while for us as a community to get the newsletter's markup and layout right but that's usually how it is when you start something new. Too many changes with markup etc right now is distracting us from our main goal.
Sorry... a bit pissed, Frank
Understood, and I hope I haven't offended by giving my responses. I sincerely respect you and your views.
Please fill in the wikipage by using the feature list I provided.
There will be a poll in maybe 1 week and we will do the decission. No big further discussion here please.
Well thats one way of doing it, maybe...
To be honest I'm really sick of this discussion, as changing to ReST wasn't to complicated for me (and shouldn't be for anybody else) but as I still prefer LaTeX for doing such work it was a compromise I wanted to do. So everybody, please be so kind and think about whether you are able to do a compromise too on the first hand and think about whether you ever will contribute to the newsletter or just discussing here to discuss anything. And if you want to write some content for the newsletter and you are sick of language being used for markup, I'm happy to receive a odt, doc, pdf or whatever and convert it to the correct format.
Hi Frank,
I think you might be overreacting a bit to people who are just trying to help you with something that appears to be causing problems.
It is the nature of open source development that you get lots of different suggestions from people, each of whom is convinced that their approach will solve your problem. I see that as a good thing rather than something to be annoyed at, that people are willing to be involved and to put in effort to show how their suggestion helps. At least they are interested in the Newsletter and its production.
Of course the content is the most important, but that wasn't the problem you asked about, nor was the markup, it was the toolset that was causing problems and thats why you got suggestions of alternate toolsets. That they happened to be based on slightly differing markup was noted in several previous posts to be unimportant.
Nobody is trying to force you to use anything, they are offering things they think will help, but as editor in chief the decision is still yours. If you are happy with Latex and are happy to convert contributions in other formats then you shouldn't listen to us, and you should go right on using Latex. IIRC originally ReST was suggested as a way of capturing most of the input without giving you the effort of conversion, but if it gives you too much heartache elsewhere don't use it.
Everyone should add their two cents worth to the Wiki page, but Frank, if you are willing to mastermind the production of the newsletter then you should get to decide on what works best for you, based on the capabilities and effort you and your team need to convert contributions and to produce the output.
Cheers Lex
Hi,
Please don't me wrong.
Am 27.05.2011 14:22, schrieb Lex Trotman:
I think you might be overreacting a bit to people who are just trying to help you with something that appears to be causing problems.
It is the nature of open source development that you get lots of different suggestions from people, each of whom is convinced that their approach will solve your problem. I see that as a good thing rather than something to be annoyed at, that people are willing to be involved and to put in effort to show how their suggestion helps. At least they are interested in the Newsletter and its production.
Of course the content is the most important, but that wasn't the problem you asked about, nor was the markup, it was the toolset that was causing problems and thats why you got suggestions of alternate toolsets. That they happened to be based on slightly differing markup was noted in several previous posts to be unimportant.
Nobody is trying to force you to use anything, they are offering things they think will help, but as editor in chief the decision is still yours. If you are happy with Latex and are happy to convert contributions in other formats then you shouldn't listen to us, and you should go right on using Latex. IIRC originally ReST was suggested as a way of capturing most of the input without giving you the effort of conversion, but if it gives you too much heartache elsewhere don't use it.
Everyone should add their two cents worth to the Wiki page, but Frank, if you are willing to mastermind the production of the newsletter then you should get to decide on what works best for you, based on the capabilities and effort you and your team need to convert contributions and to produce the output.
I had the feeling that nearly every suggestion wasn't searching for a compromise we as contributors to the newsletter can work with but pointing the mentioned solution as the only one - which is a valid way, but well.... you know. We talked about sphinx, docbook, asciidoc, rest, latex, pandoc (and mabye I missed one in my list) which is pretty much (I apologize) the same crap. None of them is perfect. However, lets put a line onto that.
This is my suggestion: Everybody, please put information together as mentioned on http://wiki.geany.org/newsletter/markuplanguages I extended the list of things I'd like to see inside the 'system' with some points. Upcoming weekend (June, 4th) I will start a doodle for a week (so closing at latest June, 11th) with all suggestions on the page hitting the minimal criteria and we decide together* which system we are using.
After this decision has been made we will adjust the build system and maybe convert all issues to the new system. None further discussion about which markup language/system we are using until there are real good reasons.
Sorry for being maybe a bit rude.
Cheers, Frank
* In some special case I will take over the rule as galactic imperator and will tell you, what your decision will be ....
I had the feeling that nearly every suggestion wasn't searching for a compromise we as contributors to the newsletter can work with but pointing the mentioned solution as the only one - which is a valid way, but well.... you know.
Ah well, nobody is going to bother to put forward something they are not enthusiastic about, so I guess it can sound a bit evangelical :-)
We talked about sphinx, docbook, asciidoc, rest, latex, pandoc (and mabye I missed one in my list) which is pretty much (I apologize) the same crap. None of them is perfect. However, lets put a line onto that.
With free software sometimes you gets what you pays for :-)
[...]
Cheers, Frank
- In some special case I will take over the rule as galactic imperator
and will tell you, what your decision will be ....
I'm afraid *I'm* ruler of the universe, but you can be universal editor in chief :-D
Cheers Lex
Am 25.05.2011 19:07, schrieb Colomban Wendling:
Le 25/05/2011 18:27, Frank Lanitz a écrit :
Sound good ;) I will give it a try tomorrow. BUT: PDF already looks very well. Huge Thanks!
No problem :) The point I think that should be improved is image sizing/placement, but I can't tell how to fix this without adding one more sed replacement, but as I'm a LaTeX noob, maybe you'll have a solution :)
;) Will need to have a deeper look.
PS: I currently played with this addition to the sed replacement (thanks to a friend of mine for most of the LaTeX part):
s/(.*)(\includegraphics)(.*)/\centerline{\1\2[width=\textwidth,height=0.25\textheight,keepaspectratio=true]\3}/
Can you commit this to the git... and maybe its worth of thinking to merge it into master.... and go on with styling over there. What do you think?
Cheers, Frank
Le 26/05/2011 10:46, Frank Lanitz a écrit :
Am 25.05.2011 19:07, schrieb Colomban Wendling:
Le 25/05/2011 18:27, Frank Lanitz a écrit :
Sound good ;) I will give it a try tomorrow. BUT: PDF already looks very well. Huge Thanks!
No problem :) The point I think that should be improved is image sizing/placement, but I can't tell how to fix this without adding one more sed replacement, but as I'm a LaTeX noob, maybe you'll have a solution :)
;) Will need to have a deeper look.
PS: I currently played with this addition to the sed replacement (thanks to a friend of mine for most of the LaTeX part):
s/(.*)(\includegraphics)(.*)/\centerline{\1\2[width=\textwidth,height=0.25\textheight,keepaspectratio=true]\3}/
Can you commit this to the git...
Pushed. Actually I pushed 2 versions, the original from the friend of mine (45faa66) and a change inspired by a2x output (f1901c8).
I prefer the look of the second, but it has the drawback that the preceding "title" (actually it's a paragraph) may not be on the same page than the image if the sizes don't suggest it.
and maybe its worth of thinking to merge it into master.... and go on with styling over there. What do you think?
As you want, I'll leave you to chose whether this is good enough for your taste or not ;)
Cheers, Colomban
Am 23.05.2011 10:50, schrieb Lex Trotman:
And like a great man once said: "all interesting programs have at least one counter, at least one loop and at least one bug", so the first line should read
body { counter-reset: counter1 -1 counter2; }
otherwise the heading counts as 1.
Hehe. When reading documentation of e.g. rst2pdf there is an option but this didn't work on my end and I have no clue why and what I was doing wrong. So maybe somebody of ReST experts here could take a look and fix the Makefile or tell me what to do inside ReST code. ;)
Cheers, Frank
On Mon, May 23, 2011 at 2:59 AM, Frank Lanitz frank@frank.uvena.de wrote:
Am 23.05.2011 04:13, schrieb John Gabriele:
Finally, I found the newsletter easier to follow when the sections were numbered, as with the first newsletter.
Me too. Unfortunately I wasn't able to create this by using RST but failed. Input is welcome.
I don't know how to do this with the docutils tools.
However, in case it's of any interest, here's Newsletter 2 in markdown source format: http://www.unexpected-vortices.com/temp/geany/newsletter_2.txt
Here it is as html http://www.unexpected-vortices.com/temp/geany/newsletter_2.html , produced using [Pandoc] via the following command: `pandoc -s --toc -N --css=styles.css -o newsletter_2.html newsletter_2.txt` (and using bits of your geany newsletter stylesheet).
[Pandoc]: http://johnmacfarlane.net/pandoc/
Here it is as a pdf: http://www.unexpected-vortices.com/temp/geany/newsletter_2.pdf , produced using the following commands:
pandoc -s --toc -N --css=styles.css -o newsletter_2.tex newsletter_2.txt pdflatex newsletter_2.tex
---John
Hi John,
Yeah pandoc is a useful tool, but everytime I have used it in the past it does nearly everything not quite perfectly :-)
Here it is as html http://www.unexpected-vortices.com/temp/geany/newsletter_2.html , produced using [Pandoc] via the following command: `pandoc -s --toc -N --css=styles.css -o newsletter_2.html newsletter_2.txt` (and using bits of your geany newsletter stylesheet).
As I said, not quite the same as the original, but not bad.
Here it is as a pdf: http://www.unexpected-vortices.com/temp/geany/newsletter_2.pdf ,
Sadly this still has no toc, I see from the command below you asked for it, did you paste the right output?
produced using the following commands:
pandoc -s --toc -N --css=styles.css -o newsletter_2.tex newsletter_2.txt pdflatex newsletter_2.tex
Cheers Lex
On Mon, May 23, 2011 at 7:43 PM, Lex Trotman elextr@gmail.com wrote:
Hi John,
Yeah pandoc is a useful tool, but everytime I have used it in the past it does nearly everything not quite perfectly :-)
I like it because the markup is pretty (and easy and fast to type), and it's easy to process into multiple formats.
Also, you can tweak pandoc to use a custom html header if you like, but I generally am pretty happy with the default output.
Here it is as html http://www.unexpected-vortices.com/temp/geany/newsletter_2.html , produced using [Pandoc] via the following command: `pandoc -s --toc -N --css=styles.css -o newsletter_2.html newsletter_2.txt` (and using bits of your geany newsletter stylesheet).
As I said, not quite the same as the original, but not bad.
Here it is as a pdf: http://www.unexpected-vortices.com/temp/geany/newsletter_2.pdf ,
Sadly this still has no toc, I see from the command below you asked for it, did you paste the right output?
Yup. Interesting. Here's the intermediate .tex file: http://www.unexpected-vortices.com/temp/geany/newsletter_2.tex . There's a `\tableofcontents` directive in there. Maybe if there's a texpert here they can comment on why there's no ToC in the resulting pdf.
One nice thing though about having an intermediate .tex file is that you can tweak it if want something specific and know your way around LaTeX.
---John
produced using the following commands:
pandoc -s --toc -N --css=styles.css -o newsletter_2.tex newsletter_2.txt pdflatex newsletter_2.tex
Cheers Lex
I like it because the markup is pretty (and easy and fast to type), and it's easy to process into multiple formats.
I presume you mean markdown markup, pun intended I'm sure. Its just another lightweight markup language, not much between any of them, my personal favorite is Asciidoc but more because the tools are better.
Also, you can tweak pandoc to use a custom html header if you like, but I generally am pretty happy with the default output.
Sure, just doesn't match the Newsletter format thats all.
Sadly this still has no toc, I see from the command below you asked for it, did you paste the right output?
Yup. Interesting. Here's the intermediate .tex file: http://www.unexpected-vortices.com/temp/geany/newsletter_2.tex . There's a `\tableofcontents` directive in there. Maybe if there's a texpert here they can comment on why there's no ToC in the resulting pdf.
Hmmmm, thats the problem we were having with rst2pdf, it eventually started working but not sure why??
Actually now I do, same as your problem, you need to run pdflatex several times for it to work, but nothing says how many times. And thats only one of the reasons I don't like latex. :-)
One nice thing though about having an intermediate .tex file is that you can tweak it if want something specific and know your way around LaTeX.
Thats Franks speciality :-)
I don't know how receptive the guys will be to yet another tool, its up to them.
Cheers Lex
On 24 May 2011 11:21, Lex Trotman elextr@gmail.com wrote:
I like it because the markup is pretty (and easy and fast to type), and it's easy to process into multiple formats.
I presume you mean markdown markup, pun intended I'm sure. Its just another lightweight markup language, not much between any of them, my personal favorite is Asciidoc but more because the tools are better.
Also, you can tweak pandoc to use a custom html header if you like, but I generally am pretty happy with the default output.
Sure, just doesn't match the Newsletter format thats all.
Sadly this still has no toc, I see from the command below you asked for it, did you paste the right output?
Yup. Interesting. Here's the intermediate .tex file: http://www.unexpected-vortices.com/temp/geany/newsletter_2.tex . There's a `\tableofcontents` directive in there. Maybe if there's a texpert here they can comment on why there's no ToC in the resulting pdf.
Hmmmm, thats the problem we were having with rst2pdf, it eventually started working but not sure why??
Actually now I do, same as your problem, you need to run pdflatex several times for it to work, but nothing says how many times. And thats only one of the reasons I don't like latex. :-)
One nice thing though about having an intermediate .tex file is that you can tweak it if want something specific and know your way around LaTeX.
Thats Franks speciality :-)
I don't know how receptive the guys will be to yet another tool, its up to them.
Cheers Lex
Is anyone open to idea of switching to AsciiDoc markup and set of tools? It can definitely output plain text, HTML and PDF, with and without Table Of Contents.
If there are no loud objections I'll put together samples of the newsletter's source file in AsciiDoc markup converted into plain text, HTML and PDF output formats.
Is anyone open to idea of switching to AsciiDoc markup and set of tools? It can definitely output plain text, HTML and PDF, with and without Table Of Contents.
If there are no loud objections I'll put together samples of the newsletter's source file in AsciiDoc markup converted into plain text, HTML and PDF output formats.
Well, I'm biased of course.
OTOH if the Rest tools are too fragile it isn't worth sticking to them so I guess any options are open. In fact IIUC Python itself has now moved to a new toolset called sphinx, don't know any more though.
Asciidoc might be worth the example if you've got time since John already has a markdown example.
Cheers Lex
On Mon, May 23, 2011 at 9:34 PM, Lex Trotman elextr@gmail.com wrote:
Is anyone open to idea of switching to AsciiDoc markup and set of tools? It can definitely output plain text, HTML and PDF, with and without Table Of Contents.
If there are no loud objections I'll put together samples of the newsletter's source file in AsciiDoc markup converted into plain text, HTML and PDF output formats.
Well, I'm biased of course.
OTOH if the Rest tools are too fragile it isn't worth sticking to them so I guess any options are open. In fact IIUC Python itself has now moved to a new toolset called sphinx, don't know any more though.
Asciidoc might be worth the example if you've got time since John already has a markdown example.
Sphinx utilizes reST and the docutils tools under the covers. BTW, all the [official Python docs] are written in reST and processed using [Sphinx].
[official Python docs]: http://docs.python.org/ [Sphinx]: http://sphinx.pocoo.org/
Asciidoc seems to have a pretty nice default html output style (looks like [git uses it] for some of their docs). Sphinx has [some themes] available. With Pandoc, you'd have to come up with some basic styling of your own.
[git uses it]: http://www.kernel.org/pub/software/scm/git/docs/everyday.html [some themes]: http://sphinx.pocoo.org/theming.html
These days, I find Markdown (with the Pandoc enhancements) to be the nicest looking and easiest to use markup of everything I've seen (ex., reST, moin-style, Textile, asciidoc, not to mention Perl Pod, LaTeX, Texinfo, and others). IMO, the easier it is to write and read as plain text, the less trouble you'll have finding people to write and update content, and the more you yourself will enjoy writing.
---John
Hi John,
Let me declare at the outset that I have contributed a few minor patches to Asciidoc and respond to some mailing list queries and I am using it within a Python project, so I am not an unbiased observer. :-)
Sphinx utilizes reST and the docutils tools under the covers. BTW, all the [official Python docs] are written in reST and processed using [Sphinx].
Yes, thats where I saw it but didn't investigate further
Asciidoc seems to have a pretty nice default html output style (looks like [git uses it] for some of their docs). Sphinx has [some themes] available. With Pandoc, you'd have to come up with some basic styling of your own.
Yes, and see also http://www.methods.co.nz/asciidoc/index.html#X6
That list includes whole books, in fact Asciidoc is one of the formats O'Reilly (you know, publishers of slim volumes on computing topics) accepts.
Git, Waf, Pacman, Cherokee are some users that list members might know about. Asciidoc was designed for documents, not extracting docstrings from code so the focus and toolset is different. The newsletter is a document not code.
These days, I find Markdown (with the Pandoc enhancements) to be the nicest looking and easiest to use markup of everything I've seen (ex., reST, moin-style, Textile, asciidoc, not to mention Perl Pod, LaTeX, Texinfo, and others). IMO, the easier it is to write and read as plain text, the less trouble you'll have finding people to write and update content, and the more you yourself will enjoy writing.
And of course I say all that about Asciidoc markup :-).
In the end there isn't that much in the source formats of all the lightweight markup languages, it comes to personal taste. I just wish there were more converters, the concepts are mostly the same but the syntaxes always differ in details. And hand conversion is a pain.
The thing that differentiates for me is documentation and tools.
Asciidoc is reasonably well documented, many queries get answers including pointers to the manual. I got turned off markdown when the website displayed as a 100mm strip down the centre of my widescreen monitor, poor advertisement.
Since Asciidoc goes through docbook it has the benefit of two PDF backends, dblatex and fop and all the well tested XSLT to generate other XML forms, eg XHTML, HTML epub, manpages etc. and Asciidoc provides the a2x wrapper that runs the whole chain rather than dumping you with an intermediate file and leaving it all up to you.
And I happen to like the way its implemented as a parser driven by config files and backends driven by config files all of which cascade like CSS, so you only have to write the one line you want to change, not copy the whole config file.
But as I am not likely to contribute a lot to the newsletter I won't try to influence (much ;-) the guys who do.
Cheers Lex
Am 24.05.2011 03:28, schrieb Russell Dickenson:
On 24 May 2011 11:21, Lex Trotman elextr@gmail.com wrote:
I like it because the markup is pretty (and easy and fast to type), and it's easy to process into multiple formats.
I presume you mean markdown markup, pun intended I'm sure. Its just another lightweight markup language, not much between any of them, my personal favorite is Asciidoc but more because the tools are better.
Also, you can tweak pandoc to use a custom html header if you like, but I generally am pretty happy with the default output.
Sure, just doesn't match the Newsletter format thats all.
Sadly this still has no toc, I see from the command below you asked for it, did you paste the right output?
Yup. Interesting. Here's the intermediate .tex file: http://www.unexpected-vortices.com/temp/geany/newsletter_2.tex . There's a `\tableofcontents` directive in there. Maybe if there's a texpert here they can comment on why there's no ToC in the resulting pdf.
Hmmmm, thats the problem we were having with rst2pdf, it eventually started working but not sure why??
Actually now I do, same as your problem, you need to run pdflatex several times for it to work, but nothing says how many times. And thats only one of the reasons I don't like latex. :-)
One nice thing though about having an intermediate .tex file is that you can tweak it if want something specific and know your way around LaTeX.
Thats Franks speciality :-)
I don't know how receptive the guys will be to yet another tool, its up to them.
Cheers Lex
Is anyone open to idea of switching to AsciiDoc markup and set of tools? It can definitely output plain text, HTML and PDF, with and without Table Of Contents.
If there are no loud objections I'll put together samples of the newsletter's source file in AsciiDoc markup converted into plain text, HTML and PDF output formats.
To be honest, I don't care much (my preference for LaTeX I already mentioned). There are only a few points the language/format should offer: - Output in plain text, HTML and PDF (show stopper) - Table of Content (show stopper) - Table of figures, tables (would be cool but no show stopper) - Automatic section numbering (show stopper) - Useable way on style PDF and HTML
I started a wiki page where we maybe can collect better the pro and contras and other informations.
-> http://wiki.geany.org/newsletter/markuplanguages
Cheers, Frank
Le 24/05/2011 03:28, Russell Dickenson a écrit :
Is anyone open to idea of switching to AsciiDoc markup and set of tools? It can definitely output plain text, HTML and PDF, with and without Table Of Contents.
I don't really mind, but:
1) is AsciiDoc really more flexible or does it only have "better defaults"? I mean, as said in another mail, I tuned the ReST PDF output, and even though there is some configuration possible, not everything can be configured (e.g. adding a \newpage after the TOC). Switching to something that have similar flaws don't seem sensible to me.
2) Geany uses ReST in general, so sticking to it might have advantages, like users being used to it, etc.
...perhaps others, but I don't think of them now -- and I don't care so much, I guess AsciiDoc is not hard to write.
Cheers, Colomban
Am 24.05.2011 03:21, schrieb Lex Trotman:
Actually now I do, same as your problem, you need to run pdflatex several times for it to work, but nothing says how many times. And thats only one of the reasons I don't like latex.
In most cases running 2 times is enough. But there are also build systems available taking over this task ;)
Cheers, Frank