Merge branch 'master' of ssh://git.ikiwiki.info

doc/bugs/UTF-16_and_UTF-32_are_unhandled.mdwn

@@ -18,3 +18,12 @@ BOMless LE and BE input is probably a lost cause.
 Optimally, UTF-16 (which is ubiquitous in the Windows world) and UTF-32 should be fully supported, probably by converting to mostly-UTF-8 and using `&#xXXXX;` or `&#DDDDD;` XML escapes where necessary.
 
 Suboptimally, UTF-16 and UTF-32 should be converted to UTF-8 where cleanly possible and a warning printed where impossible.
+
+----
+Reading the wikipedia pages about [[!wikipedia UTF-8]] and [[!wikipedia UTF-16]], all valid Unicode characters are representable in UTF-8, UTF-16 and UTF-32, and the only errors possible with UTF-16/32 -> UTF-8 translation are when there are encoding errors in the original document.
+
+Of course, it's entirely possible that not all browsers support utf-8 correctly, and we might need to support the option of encoding into [[!wikipedia CESU-8]] instead, which has the side-effect of allowing the transcription of UTF-16 or UTF-32 encoding errors into the output byte-stream, rather than pedantically removing those bytes.
+
+An interesting question would be how to determine the character set of an arbitrary new file added to the repository, unless the repository itself handles character-encoding, in which case, we can just ask the repository to hand us a UTF-8 encoded version of the file.
+
+-- [[Martin Rudat|http://www.toraboka.com/~mrudat]]

doc/forum/how_to_get_nice_pdf_from_ikiwiki_pages__63__/comment_1_332d32850c3dc0d45f5cc50434205f39._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk_MMtLPS7osC5MjX00q2ATjvvXPWqm0ik"
+ nickname="micheal"
+ subject="comment 1"
+ date="2011-11-05T09:35:40Z"
+ content="""
+I have the same question. Any ideas?
+"""]]

doc/git.mdwn

@@ -59,7 +59,7 @@ think about merging them. This is recommended. :-)
 * [[davrieb|David_Riebenbauer]] `git://git.liegesta.at/git/ikiwiki`
   ([browse](http://git.liegesta.at/?p=ikiwiki.git;a=summary))
 * [[GustafThorslund]] `http://gustaf.thorslund.org/src/ikiwiki.git`
-* [[peteg]] `git://git.hcoop.net/git/peteg/ikiwiki.git`
+* [[users/peteg]] `git://git.hcoop.net/git/peteg/ikiwiki.git`
 * [[privat]] `git://github.com/privat/ikiwiki.git`
 * [[blipvert]] `git://github.com/blipvert/ikiwiki.git`
 * [[bzed|BerndZeimetz]] `git://git.recluse.de/users/bzed/ikiwiki.git`

doc/todo/Pagination_next_prev_links.mdwn

@@ -27,4 +27,7 @@ Thank you
 > reduces the generic usefulness of typed links, though - in particular
 > you can no longer use "is part of trail A" in a PageSpec. --[[smcv]]
 
+>>> Indeed, I know the problem; I ran into the same kind of thing with my [[plugins/contrib/report]] plugin and its `trail` concept.
+>>> I simply had to declare that one couldn't use "trail" and "maketrail" options within the same report. That way, "maketrail" will add links in the "scan" pass, and "trail" will test for links in the "build" pass.  That usually works. --[[KathrynAndersen]]
+
 >> Do you have an example? --[[hendry]]

doc/todo/pdf_output.mdwn

@@ -0,0 +1,3 @@
+Some time ago there was a [[question|http://ikiwiki.info/forum/how_to_get_nice_pdf_from_ikiwiki_pages__63__/?updated#comment-05381634f89629ad26298a1af4b1d5f9]] in the forum how to get a nice pdf output from an ikiwiki page. However there were no answers. So I put it on the todo list, because I think this would be a nice feature.
+
+Note that for example dokuwiki has a [[nice plugin|http://danjer.doudouke.org/tech/dokutexit]] which converts the wiki page to latex and then to pdf and you can customize the latex-preamble.

doc/todo/web_reversion.mdwn

@@ -24,16 +24,16 @@ Implementation plan:
   and refresh site.
 
 Peter Gammie has done an initial implementation of the above.
-[[!template id=gitbranch branch=peteg/revert author="[[peteg]]"]]
+[[!template id=gitbranch branch=peteg/revert author="[[users/peteg]]"]]
 
->> It is on a separate branch now. --[[peteg]]
+>> It is on a separate branch now. --[[users/peteg]]
 
 > Review: --[[Joey]] 
 > 
 > The revert commit will not currently say what web user did the revert.
 > This could be fixed by doing a --no-commit revert first and then using
 > rcs_commit_staged.
->> Fixed, I think. --[[peteg]]
+>> Fixed, I think. --[[users/peteg]]
 >
 > So I see one thing I completly forgot about is `check_canedit`. Avoiding users
 > using reverting to make changes they would normally not be allowed to do is
@@ -45,12 +45,12 @@ Peter Gammie has done an initial implementation of the above.
 > structure that `rcs_recieve` does. This could be done by using `git revert
 > --no-commit`, and then examining the changes, and then `git reset` to drop
 > them.
->> We can use the existing `git_commit_info` with the patch ID - no need to touch the working directory. -- [[peteg]]
+>> We can use the existing `git_commit_info` with the patch ID - no need to touch the working directory. -- [[users/peteg]]
 > 
 > Then the code that is currently in IkiWiki/Receive.pm, that calls
 > `check_canedit` and `check_canremove` to test the change, can be
 > straightforwardly refactored out, and used for checking reverts too.
->> Wow, that was easy. :-) -- [[peteg]]
+>> Wow, that was easy. :-) -- [[users/peteg]]
 > 
 > (The data from `rcs_preprevert` could also be used for a confirmation
 > prompt -- it doesn't currently include enough info for diffs, but at
@@ -65,7 +65,7 @@ Peter Gammie has done an initial implementation of the above.
 >>> I agree, but have not figured out a way to make a hook work yet.
 >>> --[[Joey]] 
 >>
->> Please look it over and tell me what else needs fixing... -- [[peteg]]
+>> Please look it over and tell me what else needs fixing... -- [[users/peteg]]
 
 >>> I have made my own revert branch and put a few^Wseveral fixes in there.
 >>> All merged to master now! --[[Joey]]