Hey everybody!
--------------
webgen 0.5.11 has just been released! If you don''t know what webgen is,
read the "What''s webgen?" section down below.
This announcement is also available at
http://webgen.rubyforge.org/news/release_0_5_11.html
In this release there are two big changes regarding the internals of
webgen:
1. The dependency on facets has been removed since it was only used in
two or three places and since the facets project is not very stable
regarding its API.
2. The default markup language used by the webgen is Markdown and the
default processor for converting Markdown to HTML has been Maruku
for a long time. However, Maruku has some bugs that need to be
fixed and although it runs under Ruby 1.9 there are some issues.
Therefore the new default processor for Markdown will be
[kramdown][2] from now on. Aside from being actively maintained, it
is about 5x faster than Maruku and runs on Ruby 1.9 without
problems.
This means that if you used the default configuration, you will
automatically use kramdown from now on. If you still want to use
Maruku, just change the default processing pipeline for page files:
default_processing_pipeline:
Page: erb,tags,maruku,blocks,fragments
The short name `markdown` now also refers to kramdown instead of
Maruku.
Aside from the new content processor [kramdown][2], another content
processor for [LESS][3] has been added and the content processor
[head][4] has been updated to handle arbitrary `link` tags. Many bugs
have been fixed in this release as well.
*Note*: All deprecated methods have been removed in this release!
Changes
-------
* Major changes:
- Added content processor [kramdown][2] (faster Markdown parser)
- Added content processor [less][3] (extends CSS with variables,
mixins, operations, ...)
- Updated content processor [head][4] to allow the specification of
arbitrary `link` tags and links to javascript and CSS files by the
user
* Minor changes:
- Added a CSS class to the HTML tag of the currently selected
language of [Tag::Langbar][1] (requested by Damien Robert)
- Removed dependency on facets
- All deprecated methods have been removed
* Bug fixes:
- Fixed atom feed template to produce completely valid feeds
- Fixed order of feed entries (now sorted from most recent to oldest)
(reported by Tuomo Valkonen)
- Fixed error in `SourceHandler::Virtual` when creating virtual
directories (reported by Tuomo Valkonen)
- Fixed bug in `ContentProcessor::Blocks`: `context.dest_node` was
not correctly set when `#render_block` was called via the context
object
- Fixed bug in `Sourcehandler::Main`: an error was raised when the
configuration option `output.do_deletion` was set to `true`
(reported by Thomas Deselaers)
- Fixed RF#27075: Typo in webgen documentation (reported by Luis
Parravicini)
- Fixed bug which occured when archive-tar-minitar was not installed
- Fixed CSS bug with sub directories in style bundle
''andreas07'' (reported by Thomas Deselaers)
- Fixed a bug with path patterns not matching correctly (reported by
Damien Robert)
- Fixed bug in `ContentProcessor::Tags` with regard to parsing
strings/files with a multi-byte encoding under Ruby 1.9 (reported
by Stefano Crocco)
- Fixed bug in terminal size detection (webgen CLI now works in Emacs
shell buffer) (reported by Bob Dobbs)
[1]: http://webgen.rubyforge.org/documentation/tag/langbar.html
[2]: http://webgen.rubyforge.org/documentation/contentprocessor/kramdown.html
[3]: http://webgen.rubyforge.org/documentation/contentprocessor/less.html
[4]: http://webgen.rubyforge.org/documentation/contentprocessor/head.html
What''s webgen?
--------------
webgen is a tool to generate static websites by combining content
with template files. You create one or more template files in which
you define the layout of your page and where the content should go.
After that you create page files in which you only define the
content. You can use a variety of markup languages like Textile or
Markdown or Haml to define your content and you can add dynamic parts
via ERB or by using webgen tags. This allows the automatic generation
of menus, breadcrumb trails and much more!
Installation
------------
gem install webgen
Usage
-----
See http://webgen.rubyforge.org/documentation/
Hi Thomas, On 2/15/2010 5:01 AM, Thomas Leitner wrote:> webgen 0.5.11 has just been released!Would it be possible to improve diagnostic output? Present error messages are not especially useful. For instance: "Error in <#<Webgen::Node:0x3577c40>> while rendering <#<Webgen::Node:0x3577c40>> with Webgen::Tag::Relocatable:" -- ES
Hi Thomas, On 2/15/2010 5:01 AM, Thomas Leitner wrote:> webgen 0.5.11 has just been released!Would it make sense for Webgen::ContentProcessor::KramdownHtmlConverter#convert_a() to be a bit smarter about handling non-URI links. For instance, with default configuration "contentprocessor.kramdown.handle_links=true", compilation crashes with: Error in...while rendering...with Webgen::Tag::Relocatable: Error while parsing path ''mailto:[person at example.com] (mailto:person at example.com)'': bad URI(is not URI?): mailto:[person at example.com](mailto:person at example.com) Perhaps convert_a() should avoid invoking Webgen::Tag::Relocatable for links which clearly are not URI''s, yet which nevertheless may validly appear within "href". -- ES
On Mon, Feb 15, 2010 at 11:01, Thomas Leitner <t_leitner at gmx.at> wrote:> webgen 0.5.11 has just been released! If you don''t know what webgen is, > read the "What''s webgen?" section down below.Just a quick post-upgrade report and testing?> This announcement is also available at > ? ?http://webgen.rubyforge.org/news/release_0_5_11.html404 not found> 2. The default markup language used by the webgen is Markdown and the > ? default processor for converting Markdown to HTML has been Maruku > ? for a long time. However, Maruku has some bugs that need to be > ? fixed and although it runs under Ruby 1.9 there are some issues. > ? Therefore the new default processor for Markdown will be > ? [kramdown][2] from now on. Aside from being actively maintained, it > ? is about 5x faster than Maruku and runs on Ruby 1.9 without > ? problems.Ok. I replaced maruku with kramdown in my pipeline and ran on 1.9 to avoid the bug I get with the current ruby 1.8.7, but I get a couple blockers: - acronyms don''t seem to work (the *[ABC]: Aaa Bbbb Ccc notation) - I have markdown links defined in a common file that I include at the beginning of many pages using {include_file: src/links.markdown}, but kramdown does not see them (I get a bunch of "No link definition for link ID foo found" complaints). I do have the tags handler before kramdown in the pipeline, and this was working before. I will fiddle around that to see what I can do? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On 2/15/2010 7:56 AM, Damien Pollet wrote:> Just a quick post-upgrade report and testing? > Ok. I replaced maruku with kramdown in my pipeline and ran on 1.9 to > avoid the bug I get with the current ruby 1.8.7, but I get a couple > blockers: > - acronyms don''t seem to work (the *[ABC]: Aaa Bbbb Ccc notation)kramdown does not implement this facility. Perhaps Thomas can add it.> - I have markdown links defined in a common file that I include at the > beginning of many pages using {include_file: src/links.markdown}, but > kramdown does not see them (I get a bunch of "No link definition for > link ID foo found" complaints). I do have the tags handler before > kramdown in the pipeline, and this was working before.I also ran into a similar problem with one of my link identifiers since kramdown is more strict about which characters can compose a link identifier. In my case, I had an identifier such as "foo/bar", which worked fine in Maruku with a link definition of the same name. With kramdown, however, the ''/'' is stripped (as documented), so it expects a link definition named "foobar" when encountering link identifier "foo/bar". -- ES
On Mon, Feb 15, 2010 at 14:07, Eric Sunshine <sunshine at sunshineco.com> wrote:> kramdown does not implement this facility. Perhaps Thomas can add it.I think it''s a nice extension, it allows to write jargon and not bother too much about defining things :)>> - I have markdown links defined in a common file that I include at the >> beginning of many pages using {include_file: src/links.markdown}, but >> kramdown does not see them > I also ran into a similar problem with one of my link identifiers since > kramdown is more strict about which characters can compose a link > identifier.I doubt that''s the case, all my link identifiers (at least those concerned here) are camelcase identifiers (just letters/numbers, no space) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On Mon, 15 Feb 2010 05:45:35 -0500, Eric Sunshine wrote:> Hi Thomas, > > On 2/15/2010 5:01 AM, Thomas Leitner wrote: > > webgen 0.5.11 has just been released! > > Would it be possible to improve diagnostic output? Present error > messages are not especially useful. For instance: > > "Error in <#<Webgen::Node:0x3577c40>> while rendering > <#<Webgen::Node:0x3577c40>> with Webgen::Tag::Relocatable:"Thanks for spotting this - added this to the TODO list! -- Thomas
> Would it make sense for > Webgen::ContentProcessor::KramdownHtmlConverter#convert_a() to be a > bit smarter about handling non-URI links. For instance, with default > configuration "contentprocessor.kramdown.handle_links=true", > compilation crashes with: > > Error in...while rendering...with Webgen::Tag::Relocatable: > Error while parsing path ''mailto:[person at example.com] > (mailto:person at example.com)'': bad URI(is not URI?): > mailto:[person at example.com](mailto:person at example.com) > > Perhaps convert_a() should avoid invoking Webgen::Tag::Relocatable > for links which clearly are not URI''s, yet which nevertheless may > validly appear within "href".Will have a look at this! Can you post the source text which raises the error? This would help a lot! -- Thomas
> Just a quick post-upgrade report and testing? > > > This announcement is also available at > > ? ?http://webgen.rubyforge.org/news/release_0_5_11.html > > 404 not foundIs fixed now! I have forgotten to execute the announce task since I released a new version of kramdown directly before webgen and the Rakefile there is better organized and doesn''t need a separate call to announce ;-) Will port the changes to the webgen Rakefile so that this won''t happen again.> > 2. The default markup language used by the webgen is Markdown and > > the default processor for converting Markdown to HTML has been > > Maruku for a long time. However, Maruku has some bugs that need to > > be fixed and although it runs under Ruby 1.9 there are some issues. > > ? Therefore the new default processor for Markdown will be > > ? [kramdown][2] from now on. Aside from being actively maintained, > > it is about 5x faster than Maruku and runs on Ruby 1.9 without > > ? problems. > > Ok. I replaced maruku with kramdown in my pipeline and ran on 1.9 to > avoid the bug I get with the current ruby 1.8.7, but I get a couple > blockers: > - acronyms don''t seem to work (the *[ABC]: Aaa Bbbb Ccc notation) > - I have markdown links defined in a common file that I include at the > beginning of many pages using {include_file: src/links.markdown}, but > kramdown does not see them (I get a bunch of "No link definition for > link ID foo found" complaints). I do have the tags handler before > kramdown in the pipeline, and this was working before.Acronyms are currently not supported by kramdown, however, I have them on my TODO list. So they will probably make it into one of the next releases of kramdown. The error with include file is strange - I will try to reproduce it here and report again! -- Thomas
On 2/15/2010 8:57 AM, Damien Pollet wrote:> On Mon, Feb 15, 2010 at 14:07, Eric Sunshine<sunshine at sunshineco.com> wrote: >> I also ran into a similar problem with one of my link identifiers since >> kramdown is more strict about which characters can compose a link >> identifier. > I doubt that''s the case, all my link identifiers (at least those > concerned here) are camelcase identifiers (just letters/numbers, no > space)Did your normalize the link definitions in your include file to lowercase? kramdown expects this. For instance, when you reference the link "fooBar", kramdown will look for a definition named "foobar". -- ES
Hi Thomas,> webgen 0.5.11 has just been released! If you don''t know what webgen is, > read the "What''s webgen?" section down below.Great! Thanks a lot. I just tested it and also have some feedback: 1. I have reverted to the maruku processor, because there are some problems with links, if a) umlauts are contained. b) email addresses are contained (the @ is lost?) c) other characters like ? or / are contained d) Third level headlines do not work. Maybe I got this wrong and kramdown is meant for another markup language than maruku, but I thought they should do about the same, right? 2. The problem I reported in November is still in: [I just noticed that in the default style (andreas07?) the selected-class ( webgen-menu-item-selected) is only set correctly for pages that are not in subdirectories. i.e. I have src/index.page where title is set to: home a/index.page A b/index.page B and the menu looks like home A B then the menuitem is marked correctly (webgen-menu-item-selected) only for the home page and for none of the others. Is this intentional, can I change this? ] you can see this at my homepage http://thomas.deselaers.de: if "home" is selected, this is clearly shown if you select any of the other items (e.g. publications) it is not highlighted in the menu on the left hand side. Otherwise it works as smooth as the old one for me. Thanks, thomas On Mon, Feb 15, 2010 at 11:01, Thomas Leitner <t_leitner at gmx.at> wrote:> Hey everybody! > -------------- > > This announcement is also available at > ? ?http://webgen.rubyforge.org/news/release_0_5_11.html > > In this release there are two big changes regarding the internals of > webgen: > > 1. The dependency on facets has been removed since it was only used in > ? two or three places and since the facets project is not very stable > ? regarding its API. > > 2. The default markup language used by the webgen is Markdown and the > ? default processor for converting Markdown to HTML has been Maruku > ? for a long time. However, Maruku has some bugs that need to be > ? fixed and although it runs under Ruby 1.9 there are some issues. > ? Therefore the new default processor for Markdown will be > ? [kramdown][2] from now on. Aside from being actively maintained, it > ? is about 5x faster than Maruku and runs on Ruby 1.9 without > ? problems. > > ? This means that if you used the default configuration, you will > ? automatically use kramdown from now on. If you still want to use > ? Maruku, just change the default processing pipeline for page files: > > ? ? ? default_processing_pipeline: > ? ? ? ? Page: erb,tags,maruku,blocks,fragments > > ? The short name `markdown` now also refers to kramdown instead of > ? Maruku. > > Aside from the new content processor [kramdown][2], another content > processor for [LESS][3] has been added and the content processor > [head][4] has been updated to handle arbitrary `link` tags. Many bugs > have been fixed in this release as well. > > *Note*: All deprecated methods have been removed in this release! > Changes > ------- > > * Major changes: > > ?- Added content processor [kramdown][2] (faster Markdown parser) > ?- Added content processor [less][3] (extends CSS with variables, > ? ?mixins, operations, ...) > ?- Updated content processor [head][4] to allow the specification of > ? ?arbitrary `link` tags and links to javascript and CSS files by the > ? ?user > > * Minor changes: > > ?- Added a CSS class to the HTML tag of the currently selected > ? ?language of [Tag::Langbar][1] (requested by Damien Robert) > ?- Removed dependency on facets > ?- All deprecated methods have been removed > > * Bug fixes: > > ?- Fixed atom feed template to produce completely valid feeds > ?- Fixed order of feed entries (now sorted from most recent to oldest) > ? ?(reported by Tuomo Valkonen) > ?- Fixed error in `SourceHandler::Virtual` when creating virtual > ? ?directories (reported by Tuomo Valkonen) > ?- Fixed bug in `ContentProcessor::Blocks`: `context.dest_node` was > ? ?not correctly set when `#render_block` was called via the context > ? ?object > ?- Fixed bug in `Sourcehandler::Main`: an error was raised when the > ? ?configuration option `output.do_deletion` was set to `true` > ? ?(reported by Thomas Deselaers) > ?- Fixed RF#27075: Typo in webgen documentation (reported by Luis > ? ?Parravicini) > ?- Fixed bug which occured when archive-tar-minitar was not installed > ?- Fixed CSS bug with sub directories in style bundle > ? ?''andreas07'' (reported by Thomas Deselaers) > ?- Fixed a bug with path patterns not matching correctly (reported by > ? ?Damien Robert) > ?- Fixed bug in `ContentProcessor::Tags` with regard to parsing > ? ?strings/files with a multi-byte encoding under Ruby 1.9 (reported > ? ?by Stefano Crocco) > ?- Fixed bug in terminal size detection (webgen CLI now works in Emacs > ? ?shell buffer) (reported by Bob Dobbs) > > [1]: http://webgen.rubyforge.org/documentation/tag/langbar.html > [2]: http://webgen.rubyforge.org/documentation/contentprocessor/kramdown.html > [3]: http://webgen.rubyforge.org/documentation/contentprocessor/less.html > [4]: http://webgen.rubyforge.org/documentation/contentprocessor/head.html > > > What''s webgen? > -------------- > > webgen is a tool to generate static websites by combining content > with template files. You create one or more template files in which > you define the layout of your page and where the content should go. > After that you create page files in which you only define the > content. You can use a variety of markup languages like Textile or > Markdown or Haml to define your content and you can add dynamic parts > via ERB or by using webgen tags. This allows the automatic generation > of menus, breadcrumb trails and much more! > > Installation > ------------ > > gem install webgen > > > Usage > ----- > > See http://webgen.rubyforge.org/documentation/ > _______________________________________________ > webgen-users mailing list > webgen-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/webgen-users >-- http://thomas.deselaers.de
On Mon, Feb 15, 2010 at 21:00, Thomas Deselaers <thomas at deselaers.de> wrote:> Hi Thomas, > > >> webgen 0.5.11 has just been released! If you don''t know what webgen is, >> read the "What''s webgen?" section down below.> 2. The problem I reported ?in November is still in: > > > [I just noticed that in the default style (andreas07?) the > selected-class ( webgen-menu-item-selected) is only set correctly for > pages that are not in subdirectories. > > i.e. > > I have > src/index.page ? where title is set to: home > a/index.page ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?A > b/index.page ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?B > > and the menu looks like > home > A > B > > then the menuitem is marked correctly (webgen-menu-item-selected) only > for the home page and for none of the others. > > Is this intentional, can I change this? > ] > > you can see this at my homepage http://thomas.deselaers.de: > if "home" is selected, this is clearly shown > if you select any of the other items (e.g. publications) it is not > highlighted in the menu on the left hand side.>> ?- Fixed CSS bug with sub directories in style bundle >> ? ?''andreas07'' (reported by Thomas Deselaers)I only now saw this... and retried again. I deleted the out directory and the webgen cache, but the bug really seems to be still in. Cheers, thomas -- http://thomas.deselaers.de
> I only now saw this... and retried again. > I deleted the out directory and the webgen cache, but the bug really > seems to be still in.Hi, me again ;-) I kept trying... Finally I figured out that of course I should replace my default.template and default.css by the new versions. Now I did this, but the problem seems to persist. Cheers, thomas -- http://thomas.deselaers.de
On 2/15/2010 10:31 AM, Thomas Leitner wrote:>> Perhaps convert_a() should avoid invoking Webgen::Tag::Relocatable >> for links which clearly are not URI''s, yet which nevertheless may >> validly appear within "href". > Will have a look at this! Can you post the source text which raises the > error? This would help a lot!This may not have been a valid use-case, or at least not well defined/documented. With Maruku, I had been formatting an email address, such as <me at example.com> where the text within the ''<'' and ''>'' is clickable. It was formatted as such: <[me at example.com](mailto:me at example.com)> Although Maruku supports autolink, it may have noted that the content of ''<'' and ''>'' was not suitable autolink material, and consequently merely encoded the ''<'' and ''>'' and then processed the inner [foo](bar) link as usual. kramdown, on the other hand, apparently applies autolink behavior to the content of ''<'' and ''>'' regardless. The generated (weird) link was then passed to Webgen::Tag::Relocatable. It is not clear that either behavior is "correct" or meaningful. I resolved it by encoding ''<'' and ''>'' manually as HTML character references and then applied normal autolink behavior: <<me at example.com>gt; -- ES
On Mon, Feb 15, 2010 at 20:45, Eric Sunshine <sunshine at sunshineco.com> wrote:> Did your normalize the link definitions in your include file to lowercase? > kramdown expects this. For instance, when you reference the link "fooBar", > kramdown will look for a definition named "foobar".No, but most of the definitions that fail are still full lowercase. It really looks like the include_file tag does not process its output, whatever the state of tag.includefile.process_output. (it''s supposed to be true by default but I also tried to set it so explicitly in config.yaml) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On Feb 16, 2010, at 7:02 AM, Damien Pollet wrote:> On Mon, Feb 15, 2010 at 20:45, Eric Sunshine > <sunshine at sunshineco.com> wrote: >> Did your normalize the link definitions in your include file to >> lowercase? >> kramdown expects this. For instance, when you reference the link >> "fooBar", >> kramdown will look for a definition named "foobar". > No, but most of the definitions that fail are still full lowercase.My mistake. I allowed my own stylistic preference for lowercasing the link identifier to shade my recollection of the kramdown documentation. In fact, kramdown ignores case of the link identifier. -- ES
> This may not have been a valid use-case, or at least not well > defined/documented. With Maruku, I had been formatting an email > address, such as <me at example.com> where the text within the ''<'' and > ''>'' is clickable. It was formatted as such: > > <[me at example.com](mailto:me at example.com)> > > Although Maruku supports autolink, it may have noted that the content > of ''<'' and ''>'' was not suitable autolink material, and consequently > merely encoded the ''<'' and ''>'' and then processed the inner > [foo](bar) link as usual. > > kramdown, on the other hand, apparently applies autolink behavior to > the content of ''<'' and ''>'' regardless. The generated (weird) link was > then passed to Webgen::Tag::Relocatable. > > It is not clear that either behavior is "correct" or meaningful. I > resolved it by encoding ''<'' and ''>'' manually as HTML character > references and then applied normal autolink behavior:Thanks for the information - I will think about this. -- Thomas
On Tue, 16 Feb 2010 13:02:31 +0100, Damien Pollet wrote:> On Mon, Feb 15, 2010 at 20:45, Eric Sunshine > <sunshine at sunshineco.com> wrote: > > Did your normalize the link definitions in your include file to > > lowercase? kramdown expects this. For instance, when you reference > > the link "fooBar", kramdown will look for a definition named > > "foobar". > > No, but most of the definitions that fail are still full lowercase. > It really looks like the include_file tag does not process its output, > whatever the state of tag.includefile.process_output. (it''s supposed > to be true by default but I also tried to set it so explicitly in > config.yaml)I have tried to reproduce this but was not successful. Could you extract the parts that cause the error from your website and post them? -- Thomas
> 1. I have reverted to the maruku processor, because there are some > problems with links, if > a) umlauts are contained. > b) email addresses are contained (the @ is lost?) > c) other characters like ? or / are contained > d) Third level headlines do not work. > > Maybe I got this wrong and kramdown is meant for another markup > language than maruku, but I thought they should do about the same, > right?Yes, they should do about the same. Can you provide separate test cases for points a) - c)? Regarding d) As far as I know third level headlines in Markdown can only be created using atx style headers (i.e. `### headline`) since setext style headers support only `=` and `-` as header underline markers. Since you seem to use setext style headers, which character do you use for underlining third level headings?> 2. The problem I reported in November is still in: > > <SNIP/> > > you can see this at my homepage http://thomas.deselaers.de: > if "home" is selected, this is clearly shown > if you select any of the other items (e.g. publications) it is not > highlighted in the menu on the left hand side.Replying to this and the other two mails in one go: I will have a look at this, however, when creating a new website with `webgen create SITE` it seems to work fine. -- Thomas
On Mon, 15 Feb 2010 21:45:36 +0100, Thomas Deselaers wrote:> > I only now saw this... and retried again. > > I deleted the out directory and the webgen cache, but the bug really > > seems to be still in. > > Hi, > > me again ;-) > > I kept trying... > > Finally I figured out that of course I should replace my > default.template and default.css by the new versions. > > Now I did this, but the problem seems to persist.Yep, I know where the problem is now: your directory links don''t link to an index page but to the directory itself. Therefore the links don''t output span elements and I have forgotten to include the styling on the a elements. Just replace the following lines in default.css #menu li.webgen-menu-item-selected a, #menu li.webgen-menu-item-selected span, #menu li.webgen-menu-submenu-inhierarchy span {padding:5px 18px 5px 0; background:#fafafa; border-top:2px solid #c0c0c0; border-bottom:2px solid #c0c0c0;} #menu li.webgen-menu-item-selected a:hover, #menu li.webgen-menu-item-selected span:hover, #menu li.webgen-menu-submenu-inhierarchy span:hover {color:#505050; background:#fafafa;} with these lines: #menu li.webgen-menu-item-selected a, #menu li.webgen-menu-item-selected span, #menu li.webgen-menu-submenu-inhierarchy span, #menu li.webgen-menu-submenu-inhierarchy a {padding:5px 18px 5px 0; background:#fafafa; border-top:2px solid #c0c0c0; border-bottom:2px solid #c0c0c0;} #menu li.webgen-menu-item-selected a:hover, #menu li.webgen-menu-item-selected span:hover, #menu li.webgen-menu-submenu-inhierarchy span:hover, #menu li.webgen-menu-submenu-inhierarchy a:hover {color:#505050; background:#fafafa;} -- Thomas
> Just replace the following lines in default.css >Thanks. works perfectly. Just one thing I noticed (I am not a css expert ;-) the default.css contains a ">"-character at one spot. To mee it looks odd, becuse it is nowhere else in the file. Is it supposed to be there, or should it be removed? t. -- http://thomas.deselaers.de
On Tue, 16 Feb 2010 18:12:10 +0100, Thomas Deselaers wrote:> > Just replace the following lines in default.css > > > Thanks. > > works perfectly. > > Just one thing I noticed (I am not a css expert ;-) > > the default.css contains a ">"-character at one spot. To mee it looks > odd, becuse it is nowhere else in the file. > > Is it supposed to be there, or should it be removed?That''s okay. If you use "a > b" as CSS selector, it means that you only want to apply the following rule to <b> elements that are directly below an <a> element. For example, the following <b> element would be matched: <a>Hello<b>du</b></a> Whereas the following wouldn''t be matched: <a>Hello<span>du<b>hello</b></span></a> -- Thomas
On Tue, Feb 16, 2010 at 15:48, Thomas Leitner <t_leitner at gmx.at> wrote:> I have tried to reproduce this but was not successful. Could you > extract the parts that cause the error from your website and post them?The code is readable at http://code.untyped.org/gitweb/gitweb.cgi?p=website.git;a=tree;f=src For instance, files links.markdown and index.page (the include_file tag is at the top). I''m not sure you can clone it but I can send you a tarball of you need. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On Wed, 17 Feb 2010 10:36:00 +0100, Damien Pollet wrote:> On Tue, Feb 16, 2010 at 15:48, Thomas Leitner <t_leitner at gmx.at> > wrote: > > I have tried to reproduce this but was not successful. Could you > > extract the parts that cause the error from your website and post > > them? > > The code is readable at > http://code.untyped.org/gitweb/gitweb.cgi?p=website.git;a=tree;f=src > For instance, files links.markdown and index.page (the include_file > tag is at the top). > I''m not sure you can clone it but I can send you a tarball of you > need.I found the problem: Since you don''t specify the `escape_html` option in the include_file tag, it uses the default value of `true` and turns the quotes in the link defs to " and therefore kramdown doesn''r recognize the link defs anymore. Just specify `escape_html: false` in your include_file tags or set the global option and everything should be fine. -- Thomas
On Wed, Feb 17, 2010 at 19:00, Thomas Leitner <t_leitner at gmx.at> wrote:> I found the problem: Since you don''t specify the `escape_html` option > in the include_file tag, it uses the default value of `true` and turns > the quotes in the link defs to " and therefore kramdown doesn''r > recognize the link defs anymore.Indeed, that fixed most of the broken links, thanks! Some do remain, e.g.: ERROR -- Could not resolve path ''curriculum.html'' in </index.fr.html> but I guess those are due to localizations or the way I put links in the source? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On Thu, Feb 18, 2010 at 12:57, Damien Pollet <damien.pollet at gmail.com> wrote:> Some do remain, e.g.: > ? ?ERROR -- Could not resolve path ''curriculum.html'' in </index.fr.html> > but I guess those are due to localizations or the way I put links in the source?OK that was a localization problem (there is only the english version of this page. However, I have a couple links that have targets and do not resolve. e.g. [agenda](contact.html#agenda) The target IDs are generated correctly in contact.html, and only this couple of links with #targets does not work. I''ve tried using the link tag instead of the kramdown syntax but it makes no difference? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
> However, I have a couple links that have targets and do not resolve. > e.g. [agenda](contact.html#agenda) > The target IDs are generated correctly in contact.html, and only this > couple of links with #targets does not work. > > I''ve tried using the link tag instead of the kramdown syntax but it > makes no difference?contact.html#map can''t be found because it is an ID on a non-header element. webgen only converts HTML header tags with IDs to fragment nodes that can be linked to. You will need to create a virtual node so that the error message disappears. The problem with contact.html#agenda disappears if you add the fragments processor back to the end of the pipeline for page files. And the problem with the mailto tag (and the others) not being recognized can be solved by using `load` instead of `require` in ext/init.rb (note that you need to add the extension to the loaded files, i.e. use `load "ext/mailto.rb"`). -- Thomas
On Mon, Feb 22, 2010 at 14:16, Thomas Leitner <t_leitner at gmx.at> wrote:> contact.html#map can''t be found because it is an ID on a non-header > element. webgen only converts HTML header tags with IDs to fragment > nodes that can be linked to. You will need to create a virtual node > so that the error message disappears. > > The problem with contact.html#agenda disappears if you add the > fragments processor back to the end of the pipeline for page files.Ok. I actually just did that and moved #map to a header too. Thanks!> And the problem with the mailto tag (and the others) not being > recognized can be solved by using `load` instead of `require` in > ext/init.rb (note that you need to add the extension to the loaded > files, i.e. use `load "ext/mailto.rb"`).This seems to work fine with ''require''? why would load be different? Isn''t there a risk of initializing things several times with an explicit load? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
> > And the problem with the mailto tag (and the others) not being > > recognized can be solved by using `load` instead of `require` in > > ext/init.rb (note that you need to add the extension to the loaded > > files, i.e. use `load "ext/mailto.rb"`). > > This seems to work fine with ''require''? why would load be different? > Isn''t there a risk of initializing things several times with an > explicit load?You can use ''require'', however, all things done with the `website.config` object have to be done each time ext/init.rb is loaded (webgen really `load`s it instead of `require''ing it). Otherwise the necessary information may not be set. -- Thomas
On Mon, 15 Feb 2010 21:00:18 +0100, Thomas Deselaers wrote:> Hi Thomas, > > > > webgen 0.5.11 has just been released! If you don''t know what webgen > > is, read the "What''s webgen?" section down below. > > Great! Thanks a lot. > > I just tested it and also have some feedback: > > 1. I have reverted to the maruku processor, because there are some > problems with links, if > a) umlauts are contained. > b) email addresses are contained (the @ is lost?) > c) other characters like ? or / are contained > d) Third level headlines do not work. > > Maybe I got this wrong and kramdown is meant for another markup > language than maruku, but I thought they should do about the same, > right?Do you still have the above problems with newer version of kramdown? If yes, could you provide test cases? Best regards, Thomas