From: Chris L. <cli...@gm...> - 2005-04-11 22:53:44
|
I've added the reST to S5 (HTML based slideshow) files to my sandbox (docutils/trunk/sandbox/cliechti). Then, i also hacked a version of Aaron Swartz' html2text__ to output reST. I can also add it to the sandbox if there is interest. (GPL license) It worked to convert my simple homepage (Text, lists, some images). But it does not yet support tables properly and it has some other quirks... The main problem is that it does not seem to be the right way to go. I guess a (docutils) XML to reST converter and XML transformations should be it. Is there some work out there for a xml2rst? My quick google search did not turn up useful results. chris __ http://www.aaronsw.com/2002/html2text/ |
From: David G. <go...@py...> - 2005-04-11 23:35:33
Attachments:
signature.asc
|
[Chris Liechti] > I've added the reST to S5 (HTML based slideshow) files to my sandbox > (docutils/trunk/sandbox/cliechti). Cool, thanks. > Then, i also hacked a version of Aaron Swartz' html2text__ to output > reST. I can also add it to the sandbox if there is interest. (GPL > license) Yes, please do! > The main problem is that it does not seem to be the right way to > go. I guess a (docutils) XML to reST converter and XML > transformations should be it. Something is better than nothing. As I've said before, an 80% solution would be fine for most uses. > Is there some work out there for a xml2rst? Not that I know of. -- David Goodger <http://python.net/~goodger> |
From: Chris L. <cli...@gm...> - 2005-04-12 00:46:46
|
David Goodger wrote: > [Chris Liechti] > > Then, i also hacked a version of Aaron Swartz' html2text__ to output > > reST. I can also add it to the sandbox if there is interest. (GPL > > license) > > Yes, please do! ok, done, in sandbox/cliechti/html2rst > > Is there some work out there for a xml2rst? > > Not that I know of. i have some ideas how to render the document tree in reST, but then i'm not the XML professional which doesn't make it easier ;-) chris |
From: Felix W. <Fel...@gm...> - 2005-04-12 10:34:25
|
Chris Liechti wrote: > David Goodger wrote: > >> Chris Liechti wrote: >> >>> Is there some work out there for a xml2rst? >> >> Not that I know of. > > i have some ideas how to render the document tree in reST, but then > i'm not the XML professional which doesn't make it easier ;-) You don't need to touch XML. Just use Docutils' internal node tree (which bears resemblance to XML though). -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2005-04-11 23:44:01
Attachments:
signature.asc
|
[replying to a message sent off-list, quoting with permission] [Chris Liechti] > the themes are under the "Creative Commons" license. i'm not sure if > that's compatible with the docutils license. Most of Docutils is in the public domain, but some included parts are copyrighted and licensed. The details are in the COPYING.txt file (http://docutils.sf.net/COPYING.html#exceptions). > my files can be placed in the public domain/same license as > docutils. Cool, thanks! It's always best if the author checks in files; helps with provenance. > that probably means that there cannot be a complete example in > docutils - the user has to grab some S5 presentation and copy the > theme from there... That would be fine. But we can include S5's materials in Docutils with a copy of their license, no problem. Packagers and redistributors of Docutils may have to separate out the copyrighted parts, but that's not our problem. >> I heard about S5 last fall and thought about hooking it up with >> Docutils, but never got around to it. Separately, I had been >> working on some ideas for a Docutils slideshow writer. I've added >> my previously-unpublished ideas-in-progress to the to-do list: >> http://docutils.sf.net/docs/dev/todo.html#html-slideshow-writer > > - ``Incremental slides``: seems to be implemented in S1.1 which is > in beta state at the moment. one just needs to put the bullet list > in the "incremental" class (``<UL class="incremental"> ... > </UL>``). the ``.. class::`` directive seems to work for that. > > see http://meyerweb.com/eric/tools/s5/testbed/ > > - ``Speaker's notes.`` > comments seem to make some sense to me. it would fit well in the > reST source document. a command line option in the rst2s5 > converter could then be used switch from true HTML comments to > visible text in the printed version (something like the > ``.. handout::`` directive?) or maybe some admonition type, that > is rendered with a good visible border (would be good if you print > the master) on the other hand, something like the sidebar could be > useful too... > > - ``One layout for all slides, or allow some variation?`` while S5 > seems to support only one style per HTML file, it's pretty easy to > split a presentation in different files and insert a hyperlink to > the last slide of the first part and load the second part by a > click on it I have updated the to-do list with your feedback. > while i was checking out the ``.. class::`` directive, i noticed > that > > .. class:: handout > .. compound:: > > or > > .. compound:: :class: handout > > and > > .. sidebar:: Title > : class: handout > > can be used to replace my own ``.. handout::`` directive, which > would make the slideshow source more compatible to other writers. > > but then, most slideshow docs will contain short sections, not too > many levels of titles/subtitles etc. which means such a document > isn't very well suited for other things than a slideshow anyway. If a document can be used in multiple ways, it will be, so it would be better to keep compatibility. We may be able to co-opt another construct for this purpose. It requires some thought; ideas are welcome. -- David Goodger <http://python.net/~goodger> |
From: Aahz <aa...@py...> - 2005-04-12 00:47:37
|
On Mon, Apr 11, 2005, David Goodger wrote: > > Most of Docutils is in the public domain, [...] No, it isn't. Have you been paying attention to the license/copyright threads on psf-members? Please explicitly put Docutils as a whole under a standard Open Source license. Everyone will thank you. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR |
From: David G. <go...@py...> - 2005-04-12 02:33:29
Attachments:
signature.asc
|
[Aahz] > On Mon, Apr 11, 2005, David Goodger wrote: >> Most of Docutils is in the public domain, [...] > > No, it isn't. IANAL or a philosopher, and esoteric arguments about the validity of the public domain don't really interest me. The Creative Commons and Lawrence Lessig (who *is* a lawyer, who specializes in this stuff) seem to think dedicating a work to the public domain is perfectly valid, and that's good enough for me. > Have you been paying attention to the license/copyright threads on > psf-members? Yes, but I don't see how they apply here. Care to elaborate? > Please explicitly put Docutils as a whole under a standard Open > Source license. Everyone will thank you. The PSF is gathering signed licenses from contributors. I'm not prepared to do that at this point, so I don't really see what practical difference it would make at this point to switch from our current public domain declaration to a statement of copyright with license. Whenever anyone is given write access to the Docutils repository, they are directed to the project policy document (http://docutils.sf.net/docs/dev/policies.html), where the "Copyrights and Licensing" section sets out our intentions quite clearly. At the top of every source file in the docutils package there is a comment line like this: # Copyright: This module has been placed in the public domain. It seems to me that we're well covered. I'm not at all worried, and don't intend to spend any more time on it. If there's a concrete issue here, please elaborate with specifics. -- David Goodger <http://python.net/~goodger> |
From: Aahz <aa...@py...> - 2005-04-12 03:30:20
|
On Mon, Apr 11, 2005, David Goodger wrote: > [Aahz] >> On Mon, Apr 11, 2005, David Goodger wrote: >>> >>> Most of Docutils is in the public domain, [...] >> >> No, it isn't. > > IANAL or a philosopher, and esoteric arguments about the validity of > the public domain don't really interest me. The Creative Commons and > Lawrence Lessig (who *is* a lawyer, who specializes in this stuff) > seem to think dedicating a work to the public domain is perfectly > valid, and that's good enough for me. Larry Rosen disagrees: http://www.rosenlaw.com/lj16.htm Because Rosen is the PSF's lawyer, I'm more inclined to listen to him than Lessig on this subject. (I've been a fan of Lessig for years, back to the Cyberlaw mailing list in the early 90s -- it's not that I think he should be ignored.) Note that Lessig is overall less of a specialist in this area than Rosen; Lessig's specialty is constitutional law, though he certainly has a great deal of expertise in IP law. >> Have you been paying attention to the license/copyright threads on >> psf-members? > > Yes, but I don't see how they apply here. Care to elaborate? You won't be able to contribute Docutils to Python as long as you're claming it's in the public domain. Given that one of the goals of Docutils is to migrate into the Python core eventually, my opinion is that it's much simpler to keep the licensing issues straight now. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR |
From: Felix W. <Fel...@gm...> - 2005-04-12 10:29:55
|
Aahz wrote: > David Goodger wrote: > >> The Creative Commons and Lawrence Lessig (who *is* a lawyer, who >> specializes in this stuff) seem to think dedicating a work to the >> public domain is perfectly valid, and that's good enough for me. > > Larry Rosen disagrees: http://www.rosenlaw.com/lj16.htm He basically says that it's impossible to place software in the public domain. I don't know if that's correct, but I think the *intent* of the copyright notice (that anyone is allowed to do anything with it) is quite clear, so that's OK, I suppose. (IANAL, though.) The article furthermore says: "This 'Give-It-Away' license provides no protection for anyone if the donated software causes harm." I'm wondering how easily you can really get sued for that? -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Florian S. <flo...@gm...> - 2005-04-12 11:49:28
|
On Tue, 12 Apr 2005 12:28:09 +0200, Felix Wiemann <Fel...@gm...> wrote: > Aahz wrote: > >> David Goodger wrote: >> >>> The Creative Commons and Lawrence Lessig (who *is* a lawyer, who >>> specializes in this stuff) seem to think dedicating a work to the >>> public domain is perfectly valid, and that's good enough for me. >> >> Larry Rosen disagrees: http://www.rosenlaw.com/lj16.htm > > He basically says that it's impossible to place software in the public > domain. I don't know if that's correct, but I think the *intent* of the > copyright notice (that anyone is allowed to do anything with it) is > quite clear, so that's OK, I suppose. (IANAL, though.) > > The article furthermore says: "This 'Give-It-Away' license provides no > protection for anyone if the donated software causes harm." I'm > wondering how easily you can really get sued for that? > Why don't you guys just use something like the BSD License (without the advertising clause). Those are the most simple ones and basically say it's public domain, but you deny any responsibility if it causes any harm. They are widely used (but not yet proven in court I think) and accepted. Regards, Florian Schulze |
From: Alan G I. <ai...@am...> - 2005-04-12 12:40:17
|
How about referencing a more careful statement e.g. http://creativecommons.org/licenses/publicdomain/ fwiw, Alan Isaac |
From: Aahz <aa...@py...> - 2005-04-13 17:18:05
|
On Tue, Apr 12, 2005, Alan G Isaac wrote: > > How about referencing a more careful statement e.g. > http://creativecommons.org/licenses/publicdomain/ http://www.python.org/psf/contrib.html If you're contributing to the Python project, the preferred licenses are Academic Free License v. 2.1 http://opensource.org/licenses/afl-2.1.php Apache License, Version 2.0 http://opensource.org/licenses/apache2.0.php -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR |
From: Chad W. <ch...@ze...> - 2005-06-01 01:43:45
|
Dear All, I found this thread while Googling, and thought I would share a resource I just put together on the subject of "Software and the Public Domain." In preparing this doc I talked to both Lawrence Lessig and Lawrence Rosen, so I'm hoping that this will help clarify comments they've made elsewhere. http://www.zetadev.com/misc/software-public-domain/ The bottom line seems to be that software probably *can* be put in the public domain (if you're American, at least), but that it's probably not a good idea to do so because of liability. I'm not a PSF member so I don't have access to that discussion, although I'd certainly be interested in it if anyone can share (and you're welcome to repost this there if you think it'd be helpful). Ok, thanks! Chad Whitacre http://www.zetadev.com/ |
From: Felix W. <Fel...@gm...> - 2005-04-12 09:30:17
|
> Chris Liechti wrote: > >> - ``Incremental slides``: seems to be implemented in S1.1 which is >> in beta state at the moment. one just needs to put the bullet list >> in the "incremental" class (``<UL class="incremental"> ... >> </UL>``). the ``.. class::`` directive seems to work for that. Maybe there could be an option to make section-level (i.e. non-nested) bullet lists automatically incremental. It seems to be a common construct; the example slide show in todo.txt has a ".. pause::" at the end of every bullet list item. >> while i was checking out the ``.. class::`` directive, i noticed >> that >> >> .. class:: handout >> .. compound:: Why would you want to use compound here? I'd rather write:: .. class:: handout This is a paragraph. >> .. compound:: :class: handout Mmmh. David, is it intended that this works? I think normally the options should start at the next line. -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2005-04-12 19:05:34
Attachments:
signature.asc
|
> Would you like to have the account password for docutilsupdate? If > yes, I'll send you an encrypted mail with the password. Yes, please. I had an interesting issue yesterday. After some check-ins, I ran docutils-update remotely, but it stopped for some reason (lost connection or closed my laptop, I don't know). Running it again, I got SVN lock errors. I logged in to berlios, ran "svn cleanup", and ran docutils-update again, but the changes weren't propagated to SourceForge. Somehow, and I don't know how, the tarball on berlios got updated but not propagated to SF. The -u option didn't help. I ended up zeroing the htdocs.tar file which updated everything. Perhaps we need to add an option to docutils-update for such cases (e.g., "force an update"). Ideas? -- David Goodger <http://python.net/~goodger> |
From: David G. <go...@py...> - 2005-04-12 19:13:19
Attachments:
signature.asc
|
Please ignore my last post. I pasted to the wrong window! -- David Goodger <http://python.net/~goodger> |
From: David G. <go...@py...> - 2005-04-12 19:17:21
Attachments:
signature.asc
|
[Felix Wiemann] > Maybe there could be an option to make section-level > (i.e. non-nested) bullet lists automatically incremental. Perhaps, but I don't think it's sufficient. > It seems to be a common construct; the example slide show in > todo.txt has a ".. pause::" at the end of every bullet list item. That's was just my preference; shouldn't be taken as evidence of anything. >>> .. class:: handout >>> .. compound:: > > Why would you want to use compound here? I'd rather write:: > > .. class:: handout > > This is a paragraph. I think I see the reason for it. If the "handout" text consists of several paragraphs, it would be tedious to have to declare ".. class:: handout" before each one. But the above is an abuse of the "compound" construct. A "handout" directive would be the most direct solution. The problem is that "handout" is SlideShow-specific, and would cause problems when processing the text in other contexts. How can we allow specialized directives, while retaining compatibility with contexts lacking those directives? Perhaps a declaration of ignorable directives? Or is this a non-issue? >>> .. compound:: :class: handout > > Mmmh. David, is it intended that this works? I think normally the > options should start at the next line. Yes, that syntax is intended to work. It's meant to be flexible. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-04-21 19:13:37
|
David Goodger wrote: > Felix Wiemann wrote: > >> Maybe there could be an option to make section-level >> (i.e. non-nested) bullet lists automatically incremental. > > Perhaps, but I don't think it's sufficient. No, of course not. >>>> .. class:: handout >>>> .. compound:: >> >> Why would you want to use compound here? [...] > > I think I see the reason for it. If the "handout" text consists of > several paragraphs, it would be tedious to have to declare ".. class:: > handout" before each one. But the above is an abuse of the "compound" > construct. I added a note to the docs. > How can we allow specialized directives, while retaining compatibility > with contexts lacking those directives? Perhaps a declaration of > ignorable directives? Ignoring directives is a Bad Thing, IMO. It's probably best to implement the whole slideshow support in a plugin, which adds the "handout" directive and writer support. -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Chris L. <cli...@gm...> - 2005-04-22 01:44:58
|
Felix Wiemann wrote: > David Goodger wrote: > >>How can we allow specialized directives, while retaining compatibility >>with contexts lacking those directives? Perhaps a declaration of >>ignorable directives? > > Ignoring directives is a Bad Thing, IMO. It's probably best to > implement the whole slideshow support in a plugin, which adds the > "handout" directive and writer support. not that bad if there is a warning, but i agree, i'd prefer if there was a less error prone way. do we have plugin support in docutils? if so, i'l like to learn about it, so that i can rewrite my s5 writer. chris |
From: David G. <go...@py...> - 2005-04-23 15:49:50
Attachments:
signature.asc
|
> David Goodger wrote: >> How can we allow specialized directives, while retaining >> compatibility with contexts lacking those directives? Perhaps a >> declaration of ignorable directives? [Felix Wiemann] > Ignoring directives is a Bad Thing, IMO. It's probably best to > implement the whole slideshow support in a plugin, which adds the > "handout" directive and writer support. That doesn't solve the problem though. I'll explain with an example. Say we have a document that we want to multipurpose, as both a slideshow and an ordinary standalone document. It needs to use a specialized directive like "handout" for the slideshow, but the standalone context doesn't support "handout". How can we use a single source document in both contexts without generating an error? -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-04-30 16:26:21
|
David Goodger wrote: > I'll explain with an example. > Say we have a document that we want to multipurpose, as both a > slideshow and an ordinary standalone document. It needs to use a > specialized directive like "handout" for the slideshow, but the > standalone context doesn't support "handout". How can we use a single > source document in both contexts without generating an error? I think there shouldn't be any implicit way to handle directives which are unsupported in a given context. Being able to use (parts of) a slideshow document as a standalone document is not a necessity, IMO. However, it would be possible to have a slideshow mode which just inserts the contents of "handout" directives into the document. E.g., if we have ".. slideshow:: presentation" and ".. slideshow:: handout", ".. slideshow:: passthrough" might cause any slideshow-specific directives to pass through their contents to the document, and ".. slideshow:: drop" might cause the contents to be dropped. -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2005-05-02 13:02:29
Attachments:
signature.asc
|
[Felix Wiemann] > I think there shouldn't be any implicit way to handle directives which > are unsupported in a given context. I agree. I'm saying there could be an *explicit* way to handle unsupported directives. Perhaps something like this: .. require-directive:: handout :unsupported: ignore The "unsupported" option could also have "error" and "parse content" values. The latter could parse the directive's content as if it were not contained in a directive . > Being able to use (parts of) a > slideshow document as a standalone document is not a necessity, IMO. I think it would be a common use case. > However, it would be possible to have a slideshow mode which just > inserts the contents of "handout" directives into the document. > > E.g., if we have ".. slideshow:: presentation" and ".. slideshow:: > handout", ".. slideshow:: passthrough" might cause any > slideshow-specific directives to pass through their contents to the > document, and ".. slideshow:: drop" might cause the contents to be > dropped. Such commands could be part of the Slideshow writer, but as runtime settings, not in the document. But this just side-steps the real issue. The problem remains, and I think it needs a solution. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-04-22 10:20:47
|
Chris Liechti wrote: > do we have plugin support in docutils? Not currently, but it's high on my to-do list. I was planning to have some basic plugin support running by now, but the need for a new LaTeX writer got in the way. :-( -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Felix W. <Fel...@gm...> - 2005-06-04 16:56:44
|
Chad Whitacre wrote: > I found this thread while Googling, and thought I would share a > resource I just put together on the subject of "Software and the > Public Domain." In preparing this doc I talked to both Lawrence Lessig > and Lawrence Rosen, so I'm hoping that this will help clarify comments > they've made elsewhere. > > http://www.zetadev.com/misc/software-public-domain/ > > The bottom line seems to be that software probably *can* be put in the > public domain (if you're American, at least), but that it's probably > not a good idea to do so because of liability. Thanks for the information; the article is quite interesting to read. I prefer public domain nonetheless for several reasons: * I don't want more text at the top of files. Large headers are annoying to paste in, and they are distracting to read. * It's a very bad thing to have relicensing problems. With public domain, I can be *absolutely* sure that the code is always usable without legal obstacles. * I don't want to spend time thinking and discussing about which license to use. * I don't consider the risk of being sued for errors in Docutils very high. The home page says it's highly experimental, so it's OK to have some errors in there. David's reasons for favoring public domain are similar, I assume. -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Steve H. <st...@ho...> - 2005-04-12 07:17:41
|
David Goodger wrote: > [Aahz] > > On Mon, Apr 11, 2005, David Goodger wrote: > >> Most of Docutils is in the public domain, [...] > > > > No, it isn't. > Yes, it is. > IANAL or a philosopher, and esoteric arguments about the validity of > the public domain don't really interest me. The Creative Commons and > Lawrence Lessig (who *is* a lawyer, who specializes in this stuff) > seem to think dedicating a work to the public domain is perfectly > valid, and that's good enough for me. > And you're in charge of docutils and that's good enough for me :-) > > Have you been paying attention to the license/copyright threads on > > psf-members? > > Yes, but I don't see how they apply here. Care to elaborate? > > > Please explicitly put Docutils as a whole under a standard Open > > Source license. Everyone will thank you. > > The PSF is gathering signed licenses from contributors. I'm not > prepared to do that at this point, so I don't really see what > practical difference it would make at this point to switch from our > current public domain declaration to a statement of copyright with > license. > If you don't feel you need a license then not having one *would* appear to be the simplest solution, notwithstanding concerns about the validity of such a stance. > Whenever anyone is given write access to the Docutils repository, they > are directed to the project policy document > (http://docutils.sf.net/docs/dev/policies.html), where the "Copyrights > and Licensing" section sets out our intentions quite clearly. At the > top of every source file in the docutils package there is a comment > line like this: > > # Copyright: This module has been placed in the public domain. > Presumably this includes everyone who has commit privileges. I certainly remember asking myself was this something I could live with. > It seems to me that we're well covered. I'm not at all worried, and > don't intend to spend any more time on it. If there's a concrete > issue here, please elaborate with specifics. > The prospect of shying away from using someone's software because they are trying to give it away does appear nonsensical, and yet there are lawyerly arguments on both sides of this discussion. The existence of docutils is the best argument for leaving the lawyerly arguments to lawyers (who will please start *their* posts with "I am not a developer"...). [obreStructured Text: I *am* now using reStructured Text and docutils to generate portions of the Holden Web site -- see http://www.holdenweb.com/blogs/2005/04/versioned-reviews-implemented-post.html for more information. Thanks for your help at PyCon, David]. regards Steve -- Steve Holden +1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ |