Hello, just to be clear, I had no intention either to start a flamewar or anything, and no intention to specifically advertise "my" solution (or rather, my library).
The only point of my previous message was to make clear what I could
offer, which has changed since last time I posted here. And bottom line
is I DON'T have an integration to offer anymore, though copyright
assignmnet and support offers still stand.
I answer to specific points below.
on Friday 27 April 2012 at 21:06, chris wrote:
> - server side I tried libupskirt today but it was difficult to get it
> to compile under
> win. finally I created a makefile for nmake but then header parsing
> or better
> the rendering part caused issues ("<h234523534>" header tags instead
> of "<h2>").
> The vprintbuf function has/had a problem. The I borrowed the code
> from sundown
> only for this function and it worked fine.
This is a known issue, primarily due to the lack of C99 support in
windows. I don't have access to any windows machine, so I can't make any
meaningful development or testing. However I seem to remember some
people on this ML have already solved it or worked around it. Anyway,
the whole dynamic buffer code should go IMHO.
> I did not look at the legal stuff (yet) and it's definitely a point to
> consider. If I'd still
> be a candidate for the tooth fairy my wish would be to bring libupskirt
> & sundown back
> together and use both under linux & win together with fossil
>
> I haven't dove into the details of both implementations, so there might
> be details that
> prevent this.
There isn't. The crux of the matter is the dynamic buffer code (and to a
lesser extend the dynamic array code). See below.
> Besides: I like the libupskirt approach on how to integrate the
> renderer. I want
> to createy S5 HTML slide output from some markdown files and that approach
> woulk make it quite easy to implement it.
Thanks a lot :-) (I took it as a compliment on my design)
on Friday 27 April 2012 at 22:14, chris wrote:
> Hi all,
>
> I've integrated sundown and found two problems that it shares with
> libupskirt:
> 1. both have their own buffer concept and do not allow to hand in a
> string that
> makes it necessary to copy from Fossils Blob blob_str output into
> the input
> buffer => needs twice the input docs size :-(
That's where I spent most of the time in my attempt to integrate
libupskirt into fossil. The idea was to remove libupskirt's dynamic
buffers completely and replace them with fossil blobs (which are
dynamic buffers too).
I didn't finish it, however from the part I did I'd say it's tedious but
not difficult.
> 2. discount (somewhat) supports the markdown header extension of pandoc:
> three
> % lines at the beginning of the file denote title, author and date.
> I used this
> to differentiate between real markdown (if title parsing was
> successful) and
> normal text for .txt files. That's not possible anymore.
My solution for that point was to use a dedicated extension for markdown
files (actually two, .mkd and .markdown), and then simply add them in
doc.c with text/x-markdown MIME type, along with a special handler for
text/x-markdown in doc_page() function from doc.c, besides the handling
of application/x-fossil-wiki and text/plain.
It seemed to be the least intrusive way of introducing markdown support
(but only as an embedded doc rendered into HMTL on-the-fly). That's the
only modification of fossil's current code that is needed, everything
else is integrating the markdown library into the binary.
Hoping this helps,
Natasha
pgpXUVZ5OzTmg.pgp
Description: PGP signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
