From: Oliver R. <ol...@ru...> - 2002-10-24 04:00:50
Attachments:
hthtml.py
rest2ht.py
|
Hi David, I've written a Writer for .ht (HTML Template?) files used by ht2html_. .. _ht2html: http://ht2html.sourceforge.net/ Basically it writes the body of an HTML page with some optional RFC-2822 headers at the top. The writer, as you can see, is a very thin wrapper of html4css1. As this is kind of a specialized writer, I didn't know whether you or anyone would have any interest in it for Docutils, so I figured I'd check and see. If you don't want it for Docutils proper, I can just plunk it into the sandbox. On an unrelated note, what do you think of adding the front end scripts in "tools" as scripts in docutils setup.py file? That way when someone installed docutils they had scripts to do conversions ready to go. However, if they were installed by default, it might be more intuitive if they were named something like rest2html, rest2xml, etc... I've done that with the attached front end script, so I didn't have 2 files with the same name attached. Lastly, I'm hoping the get the DocBook writer a little more polished before long. I got caught up with a move, new job, etc... and haven't gotten around to getting the last few bits going and remaining kinks worked out. Regards, -Ollie Ollie Rutherfurd ol...@ru... |
From: David G. <go...@us...> - 2002-10-24 05:29:57
|
Oliver Rutherfurd wrote: > I've written a Writer for .ht (HTML Template?) files used by ht2html_. Cool! I've been thinking of doing something like that for a while. One reason being that the Docutils home page is too long and boring, and could use some sprucing up. > As this is kind of a specialized writer, I didn't know whether you or anyone > would have any interest in it for Docutils, so I figured I'd check and see. > If you don't want it for Docutils proper, I can just plunk it into the > sandbox. I am definitely interested. We'll have to think about where the best place should be (opinions?). If we can get the code really bulletproof (could be already; I haven't looked at it yet and may not get a chance for a couple of days), I don't see why it can't live in the docutils package. I would love to see a slew of specialized writers in there, tempting users. > On an unrelated note, what do you think of adding the front end scripts in > "tools" as scripts in docutils setup.py file? Good idea. But how would that work? Does Distutils put scripts on the shell's path? Is it cross-platform? (Where does it put scripts on my ancient Mac?) > However, if they were installed by default, it might be more intuitive if > they were named something like rest2html, rest2xml, etc... Perhaps, although I'd prefer "rst" to "rest". Opinions? > Lastly, I'm hoping the get the DocBook writer a little more polished before > long. More good news! I'll sleep well tonight. And with that: good night. -- David Goodger <go...@us...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: Julien T. L. <me...@fr...> - 2002-10-24 09:35:20
|
On Oct 24, 2002, at 01:30, David Goodger was heard saying: > Oliver Rutherfurd wrote: > Cool! I've been thinking of doing something like that for a while. One > reason being that the Docutils home page is too long and boring, and could > use some sprucing up. Another application is (as far as I'm concerned) including docutils-generated HTML into page templates (e.g. in a PHP website). For now I'm manually extracting HTML bodies and including them into my page templates (on solarpack.sf.net) > Perhaps, although I'd prefer "rst" to "rest". Opinions? I vote 'rst' (I already use rst2latex :) ) Cheers, -- Julien T. Letessier aim: JLetessier Post-graduate ENSIMAG Student web: http://www.mezis.net IMAG IVR Master Student email: co...@me... --------------------------------------------------------------- SourceForge projects: Solarpack: Distributing free software for Solaris Docutils: Python documentation framework DocbookX: software suite for MacOS X Docbook XML processing --------------------------------------------------------------- |
From: David G. <go...@us...> - 2002-10-24 21:55:14
|
Julien T. Letessier wrote: > Another application is (as far as I'm concerned) including > docutils-generated HTML into page templates (e.g. in a PHP > website). For now I'm manually extracting HTML bodies and including > them into my page templates (on solarpack.sf.net) So your preferred output is the same as .ht files, but without the RFC 822 headers? Should it include <body> & </body> tags, or just their contents? Any other requirements? -- David Goodger <go...@us...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: Julien T. L. <me...@fr...> - 2002-10-25 15:04:47
|
On Oct 24, 2002, at 17:55, David Goodger was heard saying: > Julien T. Letessier wrote: > > Another application is (as far as I'm concerned) including > > docutils-generated HTML into page templates (e.g. in a PHP > > website). For now I'm manually extracting HTML bodies and including > > them into my page templates (on solarpack.sf.net) > > So your preferred output is the same as .ht files, but without the RFC > 822 headers? Should it include <body> & </body> tags, or just their > contents? Any other requirements? Well, ideally, yes: a plain HTML body, without header and without <body> tags. But this could be made optionnal, hmm :) Anyways, even with headers, my processing chain could easily become automatic: reST source ----> .ht file .ht file ----> HTML content header + HTML content + footer ----> final HTML document (for instance) Cheers, -- Julien T. Letessier aim: JLetessier Post-graduate ENSIMAG Student web: http://www.mezis.net IMAG IVR Master Student email: co...@me... --------------------------------------------------------------- SourceForge projects: Solarpack: Distributing free software for Solaris Docutils: Python documentation framework DocbookX: software suite for MacOS X Docbook XML processing --------------------------------------------------------------- |
From: <gr...@us...> - 2002-12-12 09:03:42
|
somehow complete (for my reasons/usage overcomplete) open issues * blanks in line blocks * more visible admonitions * a latex error on centering the abstract title without visible effect, but annoying. * the multirow/column problem: deferred the tables are problematic anyway. * tabularx (used for docinfo and option list) is only for single page tables. * table width is always full page width: possibly to try: assume rst-pagewidth of 80 get tablewidth and make same ratio in latex. cheers -- BINGO: change the basis of competition --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: <pf...@ar...> - 2002-12-12 11:00:39
|
Hi, gr...@us... schrieb: [...] > open issues [...] > the tables are problematic anyway. > * tabularx (used for docinfo and option list) is only for > single page tables. > * table width is always full page width: > possibly to try: assume rst-pagewidth of 80 get tablewidth > and make same ratio in latex. Have you considered to use the 'supertab' package instead? Do you have example tables long enough to be suitable for testing? Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen, Germany) |
From: <gr...@us...> - 2002-12-12 14:03:50
|
On Thu, 12 Dec 2002, Peter Funk wrote: > Hi, > > gr...@us... schrieb: > [...] > > open issues > [...] > > the tables are problematic anyway. > > * tabularx (used for docinfo and option list) is only for > > single page tables. > > * table width is always full page width: > > possibly to try: assume rst-pagewidth of 80 get tablewidth > > and make same ratio in latex. > > Have you considered to use the 'supertab' package instead? we are using longtable for tables, but for docinfo and option-list i am thinking about a special list environment, with a minimal term width. this should do it also or even better, as these are no tables. > Do you have example tables long enough to be suitable for testing? we use test.txt, but docinfo or option-list donot exceed a page. anyway i want to drive away from tables. -- BINGO: continually leverage existing value-added solutions --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: David G. <go...@py...> - 2002-12-17 03:01:45
|
Peter Funk wrote: > Do you have example tables long enough to be suitable for testing? There's a nice long table in docs/tools.txt (http://docutils.sf.net/docs/tools.html#configuration-file-entries). -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: <gr...@us...> - 2002-12-17 08:21:07
|
On Mon, 16 Dec 2002, David Goodger wrote: > Peter Funk wrote: > > Do you have example tables long enough to be suitable for testing? > > There's a nice long table in docs/tools.txt > (http://docutils.sf.net/docs/tools.html#configuration-file-entries). the generated pdf: http://docutils.sourceforge.net/sandbox/grubert/tools.pdf already handles this long table. the long tables i am talking of are document information and option-list. * docinfo still uses tabularx, therefore it is limited to one page. * option-list now uses a latex list environment, therefore is no longer limited to one page. this will be used for the docinfo too. anyway due to limited interest in the public, i will proceed at my pace. cheers and have a nice day. -- BINGO: Das muessen wir noch kommunizieren --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: David G. <go...@py...> - 2002-12-18 00:57:59
|
gr...@us... wrote: > the generated pdf: > http://docutils.sourceforge.net/sandbox/grubert/tools.pdf Looking good! There are two things I notice though: 1. There's no vertical space between paragraphs in table cells. 2. Near the end of the table, there's a cell that spans both columns. It doesn't have any border in the PDF file. It should. In this particular case it looks OK (it's a pseudo-title), but it's still wrong. > anyway due to limited interest in the public, i will proceed at my > pace. Of course, by all means. It's all about scratching your *own* itch, after all! -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: Richard J. <rj...@ek...> - 2002-12-18 04:00:45
|
On Wed, 18 Dec 2002 11:58 am, David Goodger wrote: > gr...@us... wrote: > > the generated pdf: > > http://docutils.sourceforge.net/sandbox/grubert/tools.pdf > > Looking good! I agree - great stuff. I've just run latex.py over the Roundup documentation - and it's come out looking really good (see http://roundup.sf.net/doc-0.5/). I can't run it over the cusomtizing.txt file because of the number of heading levels - it ends up generating a \subsubsubsection which there's no handler for. My other random comments: 1. There seems to be a missing line break in definition lists after the term, possibly only when the definition is a list - for an example, see http://roundup.sf.net/doc-0.5/features.pdf 2. I'd like to be able to turn off the table of contents - it's not much use in most (if not all) of the pdfs generated for the Roundup documentation. The result looks great though! > There are two things I notice though: > > 1. There's no vertical space between paragraphs in table cells. I'm not sure I have a problem with this. I think it looks OK as it is... Richard |
From: David G. <go...@py...> - 2002-12-18 04:21:03
|
[David Goodger] >> 1. There's no vertical space between paragraphs in table cells. [Richard Jones] > I'm not sure I have a problem with this. I think it looks OK as it is... In this particular case, one paragraph or two doesn't matter much. But in the general case of table cells containing multiple paragraphs (or other objects, like lists etc.), there has to be some indication of separation. If now way can be found for TeX tables to handle multiple paragraphs, it's a documentation issue (at least until a way *is* found). But I have to believe that TeX can handle just about anything. But without any concrete TeX knowledge I can't contribute to that code. All I can do is point out issues, and hope for the best. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: <gr...@us...> - 2002-12-19 08:03:50
|
On Tue, 17 Dec 2002, David Goodger wrote: > [David Goodger] > >> 1. There's no vertical space between paragraphs in table cells. > > [Richard Jones] > > I'm not sure I have a problem with this. I think it looks OK as it is... > > In this particular case, one paragraph or two doesn't matter much. But in > the general case of table cells containing multiple paragraphs (or other > objects, like lists etc.), there has to be some indication of separation. > If now way can be found for TeX tables to handle multiple paragraphs, it's a > documentation issue (at least until a way *is* found). But I have to > believe that TeX can handle just about anything. yes of course but not everything can be fetched from the rst. but i think the paragraph separation should work. currently i have turned off first line intendation and use paragraph separation seams to fail inside longtable. tables are an itch and used far to often the configuration files entries might be done by a description environment as the option-list, but this might need another markup, if we donot use field-lists. e.g.:: _destination -- Path to output destination, set from positional arguments. Default: stdout (None). No command-line options. _source -- Path to input source, set from positional arguments. Default: stdin (None). No command-line options. would be easier to type (in fact we could still make it a table as a field list (are not set correct up to now IMHO):: :_destination: Path to output destination, set from positional arguments. Default: stdout (None). No command-line options. :_source: Path to input source, set from positional arguments. Default: stdin (None). No command-line options. cheers -- BINGO: Einpflegen --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: David G. <go...@py...> - 2002-12-20 01:49:39
|
[David Goodger] >> 2. Near the end of the table, there's a cell that spans both >> columns. It doesn't have any border in the PDF file. It >> should. In this particular case it looks OK (it's a >> pseudo-title), but it's >> still wrong. [Engelbert Gruber] > in the html version there is no border at all. is this because the > table was without vertical lines or because of me. Are you referring to the markup in the source file being a simple table, without "|" characters between columns? That doesn't get stored in the doctree, and doesn't influence the output. A grid table produces the exact same doctree as an equivalent simple table. I suspect it may be a browser/stylesheet issue. In Mozilla and IE I see the table with full borders and row/column separators. > should i make no border too. There should be a border by default. > tables are an itch and used far to often Not following you here. > the configuration files entries might be done by a description > environment as the option-list, but this might need another markup, > if we donot use field-lists. That's just avoiding the real issue. If there's a bug in table processing, you can't say "use feature X instead", unless tables (or some aspect of tables) are not supported at all, in which case the docs and help (and even the code) should say so explicitly. -- David Goodger <go...@py...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: <gr...@us...> - 2002-12-20 14:08:10
|
On Thu, 19 Dec 2002, David Goodger wrote: > > tables are an itch and used far to often > > Not following you here. > > > the configuration files entries might be done by a description > > environment as the option-list, but this might need another markup, > > if we donot use field-lists. > > That's just avoiding the real issue. If there's a bug in table i agree on that a bug needs a fix, but an argument is an argument and just because in html historically tables where the means to place items on the page does not mean everything is a table. cheers -- BINGO: empower strategic product evolution --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: <gr...@us...> - 2002-12-19 08:03:52
|
On Wed, 18 Dec 2002, Richard Jones wrote: > I agree - great stuff. I've just run latex.py over the Roundup documentation - > and it's come out looking really good (see http://roundup.sf.net/doc-0.5/). I > can't run it over the cusomtizing.txt file because of the number of heading > levels - it ends up generating a \subsubsubsection which there's no handler > for. i limited too subsubsection. from latex documentation, next headings should be paragraph and subparagraph but it did not work here, the heading looks the same as the following paragraph (obviously). section numbering is done by docutils, so this should work, but we might limit it sometime to avoid section 1.3.2.4.3.5 ... pdfbookmark are only four levels. (more might be possible, there is something lurking in my head that i read ... but i think this should do). > My other random comments: > > 1. There seems to be a missing line break in definition lists after the term, > possibly only when the definition is a list - for an example, see > http://roundup.sf.net/doc-0.5/features.pdf > > 2. I'd like to be able to turn off the table of contents - it's not much use > in most (if not all) of the pdfs generated for the Roundup documentation. you mean a switch --suppress-latex-toc ? -- BINGO: Das lassen wir aussen vor --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: Richard J. <rj...@ek...> - 2002-12-19 09:39:59
|
On Thu, 19 Dec 2002 6:06 pm, gr...@us... wrote: > On Wed, 18 Dec 2002, Richard Jones wrote: > > 2. I'd like to be able to turn off the table of contents - it's not much > > use in most (if not all) of the pdfs generated for the Roundup > > documentation. > > you mean a switch --suppress-latex-toc ? That sounds good to me. Are you intending to provide page numbers in the LaTeX TOC at some stage? Richard |
From: <gr...@us...> - 2002-12-19 15:04:03
|
On Thu, 19 Dec 2002, Richard Jones wrote: > On Thu, 19 Dec 2002 6:06 pm, gr...@us... wrote: > > On Wed, 18 Dec 2002, Richard Jones wrote: > > > 2. I'd like to be able to turn off the table of contents - it's not much > > > use in most (if not all) of the pdfs generated for the Roundup > > > documentation. > > > > you mean a switch --suppress-latex-toc ? > > That sounds good to me. Are you intending to provide page numbers in the LaTeX > TOC at some stage? in the one you do want to switch off with the above command ?-) i will place it in the todo, but somehow this could make for another switch --use-latex-toc. i did use it for test.txt because there are two tocs the test.txt toc and a toc of a sample document. where should the options go: commandline, conf file, rst document ? cheers -- BINGO: Testing! Testing! Testing! Testing! This is your nine o'clock alarm call! --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: <gr...@us...> - 2002-12-27 15:32:35
|
On Thu, 19 Dec 2002, Richard Jones wrote: > On Thu, 19 Dec 2002 6:06 pm, gr...@us... wrote: > > On Wed, 18 Dec 2002, Richard Jones wrote: > > > 2. I'd like to be able to turn off the table of contents - it's not much > > > use in most (if not all) of the pdfs generated for the Roundup > > > documentation. > > > > you mean a switch --suppress-latex-toc ? this was a wrong understanding on my side (i guess). > That sounds good to me. Are you intending to provide page numbers in the LaTeX > TOC at some stage? option "--use-latex-toc 1" -- BINGO: authoritatively engineer scalable materials --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: <gr...@us...> - 2003-01-09 08:17:12
|
On Wed, 18 Dec 2002, Richard Jones wrote: > On Wed, 18 Dec 2002 11:58 am, David Goodger wrote: > > gr...@us... wrote: > > > the generated pdf: > > > http://docutils.sourceforge.net/sandbox/grubert/tools.pdf > > > > Looking good! > > I agree - great stuff. I've just run latex.py over the Roundup documentation - > and it's come out looking really good (see http://roundup.sf.net/doc-0.5/). I > can't run it over the cusomtizing.txt file because of the number of heading > levels - it ends up generating a \subsubsubsection which there's no handler > for. > > My other random comments: > > 1. There seems to be a missing line break in definition lists after the term, > possibly only when the definition is a list - for an example, see > http://roundup.sf.net/doc-0.5/features.pdf this is a feature not a bug. i think of definition and option lists as latex-description not as a table and the description allows to continue on the same line. i like this more for short texts for longer definitions it does no harm to have an extra line break. must think about it. > > There are two things I notice though: > > > > 1. There's no vertical space between paragraphs in table cells. > > I'm not sure I have a problem with this. I think it looks OK as it is... > this seams to be a generic latex problem, i tried several directions but without luck up to now. -- BINGO: a commitment to serving customer --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: <gr...@us...> - 2002-12-19 07:03:53
|
On Tue, 17 Dec 2002, David Goodger wrote: > gr...@us... wrote: > > the generated pdf: > > http://docutils.sourceforge.net/sandbox/grubert/tools.pdf > > Looking good! There are two things I notice though: > > 1. There's no vertical space between paragraphs in table cells. still itching. > 2. Near the end of the table, there's a cell that spans both columns. > It doesn't have any border in the PDF file. It should. In this > particular case it looks OK (it's a pseudo-title), but it's still > wrong. in the html version there is no border at all. is this because the table was without vertical lines or because of me. should i make no border too. > > anyway due to limited interest in the public, i will proceed at my > > pace. > > Of course, by all means. It's all about scratching your *own* itch, > after all! -- BINGO: --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |
From: Oliver R. <ol...@ru...> - 2002-10-24 19:16:17
|
----- Original Message ----- From: "David Goodger" <go...@us...> To: "Oliver Rutherfurd" <ol...@ru...> Cc: <doc...@li...> Sent: Thursday, October 24, 2002 12:30 AM Subject: [Docutils-develop] Re: Writer for .ht (HTML Template?) files > Oliver Rutherfurd wrote: > > I've written a Writer for .ht (HTML Template?) files used by ht2html_. > > Cool! I've been thinking of doing something like that for a while. One > reason being that the Docutils home page is too long and boring, and could > use some sprucing up. > > > As this is kind of a specialized writer, I didn't know whether you or anyone > > would have any interest in it for Docutils, so I figured I'd check and see. > > If you don't want it for Docutils proper, I can just plunk it into the > > sandbox. > > I am definitely interested. Ok, great. > We'll have to think about where the best place should be (opinions?). > If we can get the code really bulletproof (could be already; I haven't > looked at it yet and may not get a chance for a couple of days), I don't > see why it can't live in the docutils package. I would love to see a slew > of specialized writers in there, tempting users. As far as the bulletproof part goes, I might have sent a broken version :-(. When I tried it this morning I got an error. I've fixed the break and added stylesheet handling and will upload an updated version into the sandbox as soon as my sf key lets me (just uploaded a key since I seem to need that on windows). > > On an unrelated note, what do you think of adding the front end scripts in > > "tools" as scripts in docutils setup.py file? > > Good idea. But how would that work? Does Distutils put scripts on the > shell's path? Is it cross-platform? (Where does it put scripts on my > ancient Mac?) Good question, so after suggesting it I'm embarrased to say that it might not. I could have sworn that 'Scripts' was in my PATH, but I just checked and it's not. Maybe ActivePython's version does that, but Python.org's installer doesn't? I updated from ActivePython 2.2.1 to Python 2.2.2 and it's not in my PATH now. > > However, if they were installed by default, it might be more intuitive if > > they were named something like rest2html, rest2xml, etc... > > Perhaps, although I'd prefer "rst" to "rest". Opinions? "rst" sounds good. -Ollie ol...@ru... |
From: David G. <go...@us...> - 2002-10-24 22:13:29
|
I think this effort (and I, personally!) could benefit greatly from a short README or quick-start guide, giving straightforward instructions how to set up HT2HTML and how to use the HT2HTML and Docutils tools to build a web page or site. HT2HTML comes with a bunch of "generators"; which one to use at first? Or do we have to customize our own? A quick-start guide answering these questions could also be fed back to the HT2HTML project. Could someone write one? Oliver Rutherford wrote: > As far as the bulletproof part goes, I might have sent a broken > version :-(. When I tried it this morning I got an error. It happens. No biggie. > I've fixed the break and added stylesheet handling and will upload > an updated version into the sandbox Having taken a look at the code, I noticed that the ``settings_spec`` attribute is being partially duplicated. With the addition of stylesheet handling, the duplication is complete (or close). Perhaps it would be best to make the generation of .ht files (and body-contents-only files, as Julien proposed) part of the html4css1.py writer. Something like "--form=ht" or "--partial-ht" (can't think of anything good today; brain's a bit fuzzy). The "HTTranslator" class could live in the same module as "HTMLTranslator", and the option would trigger its use (the visitor/translator class is already parameterized in the "Writer" class). Or should they be separate writers, but inherit most or all settings? See writers/pep_html.py for an example. >>> On an unrelated note, what do you think of adding the front end >>> scripts in "tools" as scripts in docutils setup.py file? >> >> Good idea. But how would that work? Does Distutils put scripts on >> the shell's path? Is it cross-platform? (Where does it put >> scripts on my ancient Mac?) > > Good question, so after suggesting it I'm embarrased to say that it > might not. I could have sworn that 'Scripts' was in my PATH, but I > just checked and it's not. That's not really *our* problem though. We can ask users to add to their PATH, and petition PythonLabs to fix their installer (if it's a bug). Any user competent enough to use the command line ought to be able to set their PATH. For those not competent to use the command line, there's DocFactory, a Docutils GUI front end using wxPython (http://docutils.sf.net/sandbox/gschwant/docfactory/README.html; anybody interested, *please* help out with this -- could be great). I experimented on different OSes: * On Win2K, scripts are installed into the "Scripts" subdirectory of the Python install directory (``sys.prefix``). * On GNU/Linux (I agree with RMS's views on naming :-), scripts are installed into the "bin" subdirectory of the installation prefix (``sys.prefix``), typically /usr/bin or /usr/local/bin. These should be on every user's PATH. * On MacOS 8.6 (my home machine; hardware contributions welcome! :-) it's the same as Windows: scripts are installed into the "Scripts" subdirectory of the Python install directory (``sys.prefix``). On my machine, that subdirectory didn't exist -- Distutils created it. There is no PATH on MacOS (pre-X), only Python's ``sys.path``. But there's also no command line, so any Docutils use would have to be programmatic or have a GUI. Don't know where scripts get installed on MacOS X, but since it's FreeBSD-based, it's probably the same as GNU/Linux. Distutils (setup.py) has an option for the scripts install directory: "--install-scripts". See all the options with:: python setup.py install --help -- David Goodger <go...@us...> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/ |
From: Oliver R. <ol...@ru...> - 2002-10-25 04:11:34
|
----- Original Message ----- From: "David Goodger" <go...@us...> To: "Oliver Rutherfurd" <ol...@ru...> Cc: <doc...@li...> Sent: Thursday, October 24, 2002 5:13 PM Subject: Re: [Docutils-develop] Re: Writer for .ht (HTML Template?) files > David Goodger wrote: > I think this effort (and I, personally!) could benefit greatly from a > short README or quick-start guide, giving straightforward instructions > how to set up HT2HTML and how to use the HT2HTML and Docutils tools to > build a web page or site. HT2HTML comes with a bunch of "generators"; > which one to use at first? Or do we have to customize our own? A > quick-start guide answering these questions could also be fed back to > the HT2HTML project. > > Could someone write one? I've just started playing around with it this past week, so I'll try to put a little something together over the next couple of days as I check it out a little more. I'm going to be travelling, but I should have some time. > David Goodger wrote: > Having taken a look at the code, I noticed that the ``settings_spec`` > attribute is being partially duplicated. With the addition of > stylesheet handling, the duplication is complete (or close). Perhaps > it would be best to make the generation of .ht files (and > body-contents-only files, as Julien proposed) part of the html4css1.py > writer. Something like "--form=ht" or "--partial-ht" (can't think of > anything good today; brain's a bit fuzzy). The "HTTranslator" class > could live in the same module as "HTMLTranslator", and the option > would trigger its use (the visitor/translator class is already > parameterized in the "Writer" class). > > Or should they be separate writers, but inherit most or all settings? > See writers/pep_html.py for an example. I duplicated all the settings because I didn't think the 'embed stylesheet' option would work for the writer. From what I can see, if you want to embed styles in your generated html, you must put it in the Python generator class. This is one hangup that I see about making '.ht' output an option for the html4.css1 writer. Maybe it's just me, but it might start getting a little confusing if some options work or don't work depding on the "form" of the output from the same writer -- though maybe I'm making a bigger deal about that than it really is. How would people suggest dealing with these types of differences? -Ollie ol...@ru... |