## docutils-develop — For developer discussions of the implementation.

You can subscribe to this list here.

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 Jan Feb Mar Apr (5) May (27) Jun (22) Jul (72) Aug (82) Sep (86) Oct (138) Nov (100) Dec (62) Jan (122) Feb (147) Mar (92) Apr (82) May (101) Jun (153) Jul (37) Aug (34) Sep (46) Oct (46) Nov (6) Dec (38) Jan (64) Feb (81) Mar (36) Apr (194) May (329) Jun (272) Jul (68) Aug (74) Sep (150) Oct (57) Nov (62) Dec (63) Jan (78) Feb (30) Mar (137) Apr (78) May (54) Jun (122) Jul (72) Aug (110) Sep (80) Oct (75) Nov (125) Dec (79) Jan (100) Feb (15) Mar (41) Apr (67) May (30) Jun (11) Jul (14) Aug (22) Sep (20) Oct (14) Nov (11) Dec (15) Jan (17) Feb (16) Mar (35) Apr (21) May (33) Jun (50) Jul (12) Aug (7) Sep (2) Oct (6) Nov (5) Dec (2) Jan (14) Feb (20) Mar (35) Apr (9) May (57) Jun (21) Jul (42) Aug (4) Sep (13) Oct (76) Nov (40) Dec (55) Jan (26) Feb (15) Mar (3) Apr (67) May (32) Jun (39) Jul (59) Aug (31) Sep (59) Oct (64) Nov (21) Dec (10) Jan (21) Feb (3) Mar (116) Apr (33) May (9) Jun (28) Jul (21) Aug (23) Sep (146) Oct (70) Nov (31) Dec (57) Jan (33) Feb (22) Mar (11) Apr (21) May (51) Jun (47) Jul (35) Aug (26) Sep (25) Oct (34) Nov (61) Dec (51) Jan (75) Feb (31) Mar (26) Apr (16) May (24) Jun (24) Jul (31) Aug (46) Sep (36) Oct (28) Nov (37) Dec (21) Jan (16) Feb (56) Mar (31) Apr (44) May (45) Jun (29) Jul (38) Aug (18) Sep (12) Oct (16) Nov (21) Dec (11) Jan (13) Feb (14) Mar (28) Apr (7) May (72) Jun (33) Jul (21) Aug (1) Sep (6) Oct (14) Nov (18) Dec (22) Jan (23) Feb (108) Mar (76) Apr (114) May (60) Jun (9) Jul (8) Aug (9) Sep (42) Oct (9) Nov Dec (7) Jan (6) Feb (15) Mar (7) Apr May (33) Jun (3) Jul (19) Aug (12) Sep (6) Oct (16) Nov (17) Dec (125) Jan (46) Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
S M T W T F S

1
(7)
2
(1)
3

4
(2)
5
(2)
6
(2)
7
(2)
8
(1)
9

10
(2)
11
(1)
12

13

14
(1)
15

16
(3)
17

18
(10)
19

20
(3)
21
(3)
22
(2)
23

24

25
(2)
26
(6)
27
(10)
28
(1)
29
(5)
30
(2)
31
(2)

Showing results of 70

<< < 1 2 3 > >> (Page 2 of 3)
 [Docutils-develop] [ docutils-Bugs-3089774 ] Images in document templates are not preserved From: SourceForge.net - 2010-10-26 09:03:16 Bugs item #3089774, was opened at 2010-10-18 15:23 Message generated for change (Comment added) made by pachiburke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ODT Writer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: pachiburke (pachiburke) Assigned to: Dave Kuhlman (dkuhlman) Summary: Images in document templates are not preserved Initial Comment: Steps to reproduce the bug: 1. Create an odt template (my-template.odt) with an image in its header 2. Use the template to generate an ODT document with the --stylesheet=my-template.odt 3. Open the generated document The images in the header are not preserved. It's probably due to the Pictures subdir not being copied, and it may contain elements that are not part of contents.xml (such as headers and footers). ---------------------------------------------------------------------- >Comment By: pachiburke (pachiburke) Date: 2010-10-26 11:03 Message: It works like a charm and images show fine. Though, I had to change __init__.py in two places as ZipFile.writestr() has just grown the additional compress_type parameter in Python 2.7 and I'm using 2.6 here. So, zfile = zipfile.ZipFile(f, 'w', zipfile.ZIP_DEFLATED) -> zfile = zipfile.ZipFile(f, 'w') outzipfile.writestr(name, imageobj, zipfile.ZIP_STORED) -> outzipfile.writestr(name, imageobj) Apparently, all works fine with that change. Thanks. - Pachi ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-26 00:08 Message: I've added code to the odf-odt writer so that it copies images from the Pictures directory in the stylesheet (styles.odt) into the target .odt document. I've checked that change into the SVN repository. pachiburke, could you please try it and let me know if this fix does what you expected. Thanks. - Dave ---------------------------------------------------------------------- Comment By: pachiburke (pachiburke) Date: 2010-10-21 12:53 Message: Thank you very much, Dave! ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-21 00:48 Message: And, the usecase suggested by Matt, over on the docutils-users list is: "I could see this being used as a watermark, or any company template that has a logo in it...." Both of those seem worth addressing. So, give me a little time to look into it. Stylesheets (and styles.odt) for odf-odt writer were not originally intended for this. (How could they be when I didn't understand that need.) But, maybe it can be made to fit in smoothly. Give me a few days to look into it. And thanks much for the suggestion and guidance. - Dave ---------------------------------------------------------------------- Comment By: pachiburke (pachiburke) Date: 2010-10-20 23:50 Message: I see. I expected that, when a full odt file was provided as a template, the conversion would only replace contents.xml. My usecase is in fact very simple. I was trying to use as a template an odt file with a header with an image logo in it. I thought I could use raw::odt, but that affects, AFAICT, contents.xml, and headers are stored and defined in styles.xml so that doesn't work. The only really missing information is the picture files (stored in /Pictures) which correspond to the header images. ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-20 19:43 Message: I don't understand why we would expect images to be copied from the stylesheet into the target document. odf-odt writer supports the use of an odt document as container for *styles*. Why should images be copied? What is the use or need for doing this? - Dave ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 
 [Docutils-develop] [ docutils-Bugs-3089774 ] Images in document templates are not preserved From: SourceForge.net - 2010-10-25 22:08:05 Bugs item #3089774, was opened at 2010-10-18 06:23 Message generated for change (Comment added) made by dkuhlman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ODT Writer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: pachiburke (pachiburke) Assigned to: Dave Kuhlman (dkuhlman) Summary: Images in document templates are not preserved Initial Comment: Steps to reproduce the bug: 1. Create an odt template (my-template.odt) with an image in its header 2. Use the template to generate an ODT document with the --stylesheet=my-template.odt 3. Open the generated document The images in the header are not preserved. It's probably due to the Pictures subdir not being copied, and it may contain elements that are not part of contents.xml (such as headers and footers). ---------------------------------------------------------------------- >Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-25 15:08 Message: I've added code to the odf-odt writer so that it copies images from the Pictures directory in the stylesheet (styles.odt) into the target .odt document. I've checked that change into the SVN repository. pachiburke, could you please try it and let me know if this fix does what you expected. Thanks. - Dave ---------------------------------------------------------------------- Comment By: pachiburke (pachiburke) Date: 2010-10-21 03:53 Message: Thank you very much, Dave! ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-20 15:48 Message: And, the usecase suggested by Matt, over on the docutils-users list is: "I could see this being used as a watermark, or any company template that has a logo in it...." Both of those seem worth addressing. So, give me a little time to look into it. Stylesheets (and styles.odt) for odf-odt writer were not originally intended for this. (How could they be when I didn't understand that need.) But, maybe it can be made to fit in smoothly. Give me a few days to look into it. And thanks much for the suggestion and guidance. - Dave ---------------------------------------------------------------------- Comment By: pachiburke (pachiburke) Date: 2010-10-20 14:50 Message: I see. I expected that, when a full odt file was provided as a template, the conversion would only replace contents.xml. My usecase is in fact very simple. I was trying to use as a template an odt file with a header with an image logo in it. I thought I could use raw::odt, but that affects, AFAICT, contents.xml, and headers are stored and defined in styles.xml so that doesn't work. The only really missing information is the picture files (stored in /Pictures) which correspond to the header images. ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-20 10:43 Message: I don't understand why we would expect images to be copied from the stylesheet into the target document. odf-odt writer supports the use of an odt document as container for *styles*. Why should images be copied? What is the use or need for doing this? - Dave ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 
 [Docutils-develop] [ docutils-Bugs-3018371 ] Lithuanian language is missing From: SourceForge.net - 2010-10-25 08:02:44 Bugs item #3018371, was opened at 2010-06-19 10:15 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3018371&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Lithuanian language is missing Initial Comment: Lithuanian language file is missing. I have attached file with translation. ---------------------------------------------------------------------- >Comment By: https://www.google.com/accounts () Date: 2010-10-25 08:02 Message: I will translate it later today. I have not noticed your comment, sorry. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2010-06-19 13:37 Message: Thanks for the translation. There are actually two files for each language. Could you translate the parser file also? A copy of the English source can be found here: http://docutils.sourceforge.net/docutils/parsers/rst/languages/en.py Information about Docutils internationalization is here: http://docutils.sourceforge.net/docs/howto/i18n.html ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2010-06-19 10:16 Message: Sorry, I have not changed authorship in that file. I'm Dalius Dobravolskas my email is dalius.do...@... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3018371&group_id=38414 
 Re: [Docutils-develop] encoding of command line arguments From: David Goodger - 2010-10-22 13:46:25 On Fri, Oct 22, 2010 at 02:00, Guenter Milde wrote: > On 2010-10-21, David Goodger wrote: >> Please add one or more new tests, to test this functionality. The test >> should fail without the patch, and pass with it. Try to think of any >> corner cases or failure modes you can. > > Could you give me a hint where to add these tests? > Are there tests of command line processing already? There don't seem to be any such tests yet. There's test_functional.py (along with the test/functional/ data directory), which could provide a model. It doesn't do any command-line processing though. I suggest adding a test_command_line.py top-level test module. Check for mismatches between the encoding reported by locale.getpreferredencoding() and the actual encoding of the command line arguments. -- David Goodger ; 
 Re: [Docutils-develop] encoding of command line arguments From: Guenter Milde - 2010-10-22 06:00:55 On 2010-10-21, David Goodger wrote: > On Thu, Oct 21, 2010 at 09:49, Guenter Milde wrote: >> I ported a patch from Sphinx, that allows command line arguments to >> use high-bit chars in the encoding of the locale:: > What's the use case? rst2html.py --title=Dornröschen rst2latex.py --stylesheet=мой-стиль.sty >> OK to commit? > Does the test suite pass? Yes. > Please add one or more new tests, to test this functionality. The test > should fail without the patch, and pass with it. Try to think of any > corner cases or failure modes you can. Could you give me a hint where to add these tests? Are there tests of command line processing already? Günter 
 Re: [Docutils-develop] encoding of command line arguments From: David Goodger - 2010-10-21 17:47:33 On Thu, Oct 21, 2010 at 09:49, Guenter Milde wrote: > I ported a patch from Sphinx, that allows command line arguments to > use high-bit chars in the encoding of the locale:: What's the use case? > OK to commit? Does the test suite pass? Please add one or more new tests, to test this functionality. The test should fail without the patch, and pass with it. Try to think of any corner cases or failure modes you can. -- David Goodger ; 
 [Docutils-develop] encoding of command line arguments From: Guenter Milde - 2010-10-21 13:49:54 I ported a patch from Sphinx, that allows command line arguments to use high-bit chars in the encoding of the locale:: --- docutils/core.py (Revision 6427) +++ docutils/core.py (Arbeitskopie) @@ -22,7 +22,13 @@ from docutils.transforms import Transformer import docutils.readers.doctree +try: + import locale + argv_encoding = locale.getpreferredencoding() +except: + argv_encoding = 'ascii' + class Publisher: """ @@ -150,7 +156,7 @@ option_parser = self.setup_option_parser( usage, description, settings_spec, config_section, **defaults) if argv is None: - argv = sys.argv[1:] + argv = [a.decode(argv_encoding) for a in sys.argv[1:]] self.settings = option_parser.parse_args(argv) (The input encoding cannot be used, as it might be specified on the command line) OK to commit? Günter 
 [Docutils-develop] [ docutils-Bugs-3089774 ] Images in document templates are not preserved From: SourceForge.net - 2010-10-21 10:53:08 Bugs item #3089774, was opened at 2010-10-18 15:23 Message generated for change (Comment added) made by pachiburke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ODT Writer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: pachiburke (pachiburke) Assigned to: Dave Kuhlman (dkuhlman) Summary: Images in document templates are not preserved Initial Comment: Steps to reproduce the bug: 1. Create an odt template (my-template.odt) with an image in its header 2. Use the template to generate an ODT document with the --stylesheet=my-template.odt 3. Open the generated document The images in the header are not preserved. It's probably due to the Pictures subdir not being copied, and it may contain elements that are not part of contents.xml (such as headers and footers). ---------------------------------------------------------------------- >Comment By: pachiburke (pachiburke) Date: 2010-10-21 12:53 Message: Thank you very much, Dave! ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-21 00:48 Message: And, the usecase suggested by Matt, over on the docutils-users list is: "I could see this being used as a watermark, or any company template that has a logo in it...." Both of those seem worth addressing. So, give me a little time to look into it. Stylesheets (and styles.odt) for odf-odt writer were not originally intended for this. (How could they be when I didn't understand that need.) But, maybe it can be made to fit in smoothly. Give me a few days to look into it. And thanks much for the suggestion and guidance. - Dave ---------------------------------------------------------------------- Comment By: pachiburke (pachiburke) Date: 2010-10-20 23:50 Message: I see. I expected that, when a full odt file was provided as a template, the conversion would only replace contents.xml. My usecase is in fact very simple. I was trying to use as a template an odt file with a header with an image logo in it. I thought I could use raw::odt, but that affects, AFAICT, contents.xml, and headers are stored and defined in styles.xml so that doesn't work. The only really missing information is the picture files (stored in /Pictures) which correspond to the header images. ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-20 19:43 Message: I don't understand why we would expect images to be copied from the stylesheet into the target document. odf-odt writer supports the use of an odt document as container for *styles*. Why should images be copied? What is the use or need for doing this? - Dave ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 
 [Docutils-develop] [ docutils-Bugs-3089774 ] Images in document templates are not preserved From: SourceForge.net - 2010-10-20 22:48:59 Bugs item #3089774, was opened at 2010-10-18 06:23 Message generated for change (Comment added) made by dkuhlman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ODT Writer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: pachiburke (pachiburke) Assigned to: Dave Kuhlman (dkuhlman) Summary: Images in document templates are not preserved Initial Comment: Steps to reproduce the bug: 1. Create an odt template (my-template.odt) with an image in its header 2. Use the template to generate an ODT document with the --stylesheet=my-template.odt 3. Open the generated document The images in the header are not preserved. It's probably due to the Pictures subdir not being copied, and it may contain elements that are not part of contents.xml (such as headers and footers). ---------------------------------------------------------------------- >Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-20 15:48 Message: And, the usecase suggested by Matt, over on the docutils-users list is: "I could see this being used as a watermark, or any company template that has a logo in it...." Both of those seem worth addressing. So, give me a little time to look into it. Stylesheets (and styles.odt) for odf-odt writer were not originally intended for this. (How could they be when I didn't understand that need.) But, maybe it can be made to fit in smoothly. Give me a few days to look into it. And thanks much for the suggestion and guidance. - Dave ---------------------------------------------------------------------- Comment By: pachiburke (pachiburke) Date: 2010-10-20 14:50 Message: I see. I expected that, when a full odt file was provided as a template, the conversion would only replace contents.xml. My usecase is in fact very simple. I was trying to use as a template an odt file with a header with an image logo in it. I thought I could use raw::odt, but that affects, AFAICT, contents.xml, and headers are stored and defined in styles.xml so that doesn't work. The only really missing information is the picture files (stored in /Pictures) which correspond to the header images. ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-20 10:43 Message: I don't understand why we would expect images to be copied from the stylesheet into the target document. odf-odt writer supports the use of an odt document as container for *styles*. Why should images be copied? What is the use or need for doing this? - Dave ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 
 [Docutils-develop] [ docutils-Bugs-3089774 ] Images in document templates are not preserved From: SourceForge.net - 2010-10-20 21:50:40 Bugs item #3089774, was opened at 2010-10-18 15:23 Message generated for change (Comment added) made by pachiburke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ODT Writer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: pachiburke (pachiburke) Assigned to: Dave Kuhlman (dkuhlman) Summary: Images in document templates are not preserved Initial Comment: Steps to reproduce the bug: 1. Create an odt template (my-template.odt) with an image in its header 2. Use the template to generate an ODT document with the --stylesheet=my-template.odt 3. Open the generated document The images in the header are not preserved. It's probably due to the Pictures subdir not being copied, and it may contain elements that are not part of contents.xml (such as headers and footers). ---------------------------------------------------------------------- Comment By: pachiburke (pachiburke) Date: 2010-10-20 23:50 Message: I see. I expected that, when a full odt file was provided as a template, the conversion would only replace contents.xml. My usecase is in fact very simple. I was trying to use as a template an odt file with a header with an image logo in it. I thought I could use raw::odt, but that affects, AFAICT, contents.xml, and headers are stored and defined in styles.xml so that doesn't work. The only really missing information is the picture files (stored in /Pictures) which correspond to the header images. ---------------------------------------------------------------------- Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-20 19:43 Message: I don't understand why we would expect images to be copied from the stylesheet into the target document. odf-odt writer supports the use of an odt document as container for *styles*. Why should images be copied? What is the use or need for doing this? - Dave ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 
 [Docutils-develop] [ docutils-Bugs-3089774 ] Images in document templates are not preserved From: SourceForge.net - 2010-10-20 17:43:22 Bugs item #3089774, was opened at 2010-10-18 06:23 Message generated for change (Comment added) made by dkuhlman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ODT Writer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: pachiburke (pachiburke) Assigned to: Dave Kuhlman (dkuhlman) Summary: Images in document templates are not preserved Initial Comment: Steps to reproduce the bug: 1. Create an odt template (my-template.odt) with an image in its header 2. Use the template to generate an ODT document with the --stylesheet=my-template.odt 3. Open the generated document The images in the header are not preserved. It's probably due to the Pictures subdir not being copied, and it may contain elements that are not part of contents.xml (such as headers and footers). ---------------------------------------------------------------------- >Comment By: Dave Kuhlman (dkuhlman) Date: 2010-10-20 10:43 Message: I don't understand why we would expect images to be copied from the stylesheet into the target document. odf-odt writer supports the use of an odt document as container for *styles*. Why should images be copied? What is the use or need for doing this? - Dave ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 
 Re: [Docutils-develop] plan to add math support From: Guenter Milde - 2010-10-18 19:36:50 On 2010-10-18, David Goodger wrote: > On Mon, Oct 18, 2010 at 10:06, Alan G Isaac wrote: >> On 10/18/2010 9:45 AM, David Goodger wrote: >> But in fact Jens's rst2mathml produces very nice >> output in a broad set of circumstances. > Does it support LaTeX output? What's the input? The input is LaTeX, so it's not needed for LaTeX output. > If it's general-purpose, it's a viable candidate. Single-purpose is not. The proposed general-purpose math support uses the LaTeX math syntax for input and internal storage. LaTeX math syntax is powerfull and widely supported/used for human-edited presentational math. > I'd like to see this implemented, if only so these discussions go > away. But we need a **general-purpose** solution. I'm sorry for your > frustration. Please stop pushing for anything but general-purpose > solutions. With a LaTeX2MathML converter, we can support all Docutils standard output formats + PDF(rst2pdf_reportlab). The proposed "math" directive/role provides the framework for input and internal storage, and supports the standard output formats. However, it will not overcome intrinsic limitations of the output formats. By this, it is as *general purpose* as the "image" directive: It is up to the user to provide image files in a format understood by the presentation software. The "image" directive does no automatic image conversion, nor automatic selection of a supported graphics format. Günter 
 Re: [Docutils-develop] plan to add math support From: Guenter Milde - 2010-10-18 19:12:28 On 2010-10-18, David Goodger wrote: > On Mon, Oct 18, 2010 at 10:16, Roberto Alsina > wrote: >> David Goodger writes: >>> On Mon, Oct 18, 2010 at 09:08, Guenter Milde wrote: >> rst2pdf has math support. >> sphinx has math support (also in HTML, and yes, jsMath is a pain) > Can these approaches be ported for generalized support? Yes. >> HTML support via images and matplotlib should not be terribly hard to >> implement, I am even willing to reluctantly offer to do it ;-) > Great! This would add to the available choice of HTML output options. So we have for math in HTML: LaTeX2MathML: Jens' latex_math in the sandbox, MathJax: (HTML + JavaScript) Sphinx math extension PNGMath: (images via LaTeX) Sphinx mathplotlib: images via mathplotlib (also SVG?) Not all of them need to be supported in core Docutils, though. My preference for HTML output is LaTeX2MathML. >> The same thing happens with the code-block directive. I have in rst2pdf a >> nice code-block that only requires pygments and works for every writer that >> supports inline text roles with colors and fonts, in case someone wants it, >> too ;-) > Sure, please! There is also a generic implementation in sandbox/code-block-directive. Günter 
 Re: [Docutils-develop] plan to add math support From: Guenter Milde - 2010-10-18 18:52:54 On 2010-10-18, David Goodger wrote: > On Mon, Oct 18, 2010 at 09:08, Guenter Milde wrote: >> I [...] want to start implementing math support *now*. > If you can include reasonable HTML output, +1. Fine. > If not (and you seem to indicate not), -1. This depends on what you consider reasonable. Unfortunately, HTML has no math support. The W3C recommends MathML (http://www.w3.org/Math/), which we can support via Jens' LaTeX -> MathML converter. Browser support for MathML is mixed: * Firefox 1.0 renders PersentationMathML in HTML pages natively. See the MathML project page. (Open source, all major platforms). Since MathML rendering is part of Mozilla's layout engine, all derived browsers (Netscape 7, Galeon, Kmeleon, etc.) include it. * Although IE doesn't directly support MathML, it has the hooks that allow plug-in support, enabling the full MathML experience through plug-ins such as Mathplayer or techexplorer. http://www.w3.org/Math/Software/mathml_software_cat_browsers.html http://en.wikipedia.org/wiki/MathML#Web_browsers Could you try the examples in sandbox/jensj/latex_math/ and tell whether you would consider this reasonable? Alternatives are conversion to images (PNG or SVG) or MathJax_. As almost all math symbols are nowadays available as Unicode characters, simple formulas can also be converted to pure HTML+CSS. .. _MathJax: http://www.mathjax.org/ > If we can't improve the status quo, what's the point? LaTeX math > support exists already, via the "raw" directive at least. It's not > ideal, but it's explicit. The point is to get this started and to get a supported common RST syntax for math instead of a variety of add-ons. Even supporting all output formats that support math (LaTeX, PDF(reportlab), ODF) with a consistent input would be an advantage. > IOW, HTML output is IMO a necessary precondition for core inclusion. I agree that all standard writers should be supported. Günter 
 Re: [Docutils-develop] plan to add math support From: David Goodger - 2010-10-18 14:18:13 On Mon, Oct 18, 2010 at 10:06, Alan G Isaac wrote: > On 10/18/2010 9:45 AM, David Goodger wrote: >> If you can include reasonable HTML output, +1. >> If not (and you seem to indicate not), -1. > > Even outputting the math in a PRE element would > be better than the current situation. No, it wouldn't. That would be a mis-feature, horribly broken. -1 > But in fact Jens's rst2mathml produces very nice > output in a broad set of circumstances. Does it support LaTeX output? What's the input? If it's general-purpose, it's a viable candidate. Single-purpose is not. > Not all browsers offer good MathML support, Which ones do? Which don't? > but why not let the user decide if that is a problem! Because broken web pages don't help anybody. They'd just generate noise and siphon off the already limited resources we have (like this discussion). > PLEASE go forward with this. Not until it works. I'd like to see this implemented, if only so these discussions go away. But we need a **general-purpose** solution. I'm sorry for your frustration. Please stop pushing for anything but general-purpose solutions. -- David Goodger ; 
 Re: [Docutils-develop] plan to add math support From: Alan G Isaac - 2010-10-18 14:07:13 On 10/18/2010 9:45 AM, David Goodger wrote: > If you can include reasonable HTML output, +1. > If not (and you seem to indicate not), -1. Even outputting the math in a PRE element would be better than the current situation. This could be offered as an option. But in fact Jens's rst2mathml produces very nice output in a broad set of circumstances. Not all browsers offer good MathML support, but why not let the user decide if that is a problem! PLEASE go forward with this. Alan Isaac 
 Re: [Docutils-develop] plan to add math support From: David Goodger - 2010-10-18 14:02:18 On Mon, Oct 18, 2010 at 10:16, Roberto Alsina wrote: > David Goodger writes: > >> On Mon, Oct 18, 2010 at 09:08, Guenter Milde wrote: >>> Dear Docutils developers, >>> >>> after import this, I read >>> >>>  Simple is better than complex. >>> >>>  There should be one-- and preferably only one --obvious way to do it. >>> >>>  Now is better than never. >>> >>> and want to start implementing math support *now*. >> >> If you can include reasonable HTML output, +1. >> If not (and you seem to indicate not), -1. >> >> If we can't improve the status quo, what's the point? LaTeX math >> support exists already, via the "raw" directive at least. It's not >> ideal, but it's explicit. > > Not only is it not ideal, it's broken. Agreed. But without HTML support the proposed alternative is no less broken. > rst2pdf has math support. > sphinx has math support (also in HTML, and yes, jsMath is a pain) Can these approaches be ported for generalized support? I don't like the situation with Sphinx fragmentation/incompatibility. Core functionality should be moved into core Docutils. Unfortunately I don't have the time to drive this. I've said it before and I'll say it again: the Docutils "commit bit" is widely available to anyone willing to take the responsibility to do the job right. (See http://docutils.sourceforge.net/docs/dev/policies.html -- and that's open to modification too.) If you don't already have the commit bit, just ask! > HTML support via images and matplotlib should not be terribly hard to > implement, I am even willing to reluctantly offer to do it ;-) Great! > The same thing happens with the code-block directive. I have in rst2pdf a > nice code-block that only requires pygments and works for every writer that > supports inline text roles with colors and fonts, in case someone wants it, > too ;-) Sure, please! -- David Goodger ; 
 Re: [Docutils-develop] plan to add math support From: Roberto Alsina - 2010-10-18 13:53:19 David Goodger writes: > On Mon, Oct 18, 2010 at 09:08, Guenter Milde wrote: >> Dear Docutils developers, >> >> after import this, I read >> >>  Simple is better than complex. >> >>  There should be one-- and preferably only one --obvious way to do it. >> >>  Now is better than never. >> >> and want to start implementing math support *now*. > > If you can include reasonable HTML output, +1. > If not (and you seem to indicate not), -1. > > If we can't improve the status quo, what's the point? LaTeX math > support exists already, via the "raw" directive at least. It's not > ideal, but it's explicit. Not only is it not ideal, it's broken. rst2pdf has math support. sphinx has math support (also in HTML, and yes, jsMath is a pain) The idea that the raw latex directive is enough means that every writer that wants to provide it has two paths: 1) Implement math directive by themselves, which means the document doesn't work with other writers 2) Implement a raw directive that handles this, but then you have to duplicate, triplicate, etc. if you want to use more than one writer that supports math, HTML support via images and matplotlib should not be terribly hard to implement, I am even willing to reluctantly offer to do it ;-) The same thing happens with the code-block directive. I have in rst2pdf a nice code-block that only requires pygments and works for every writer that supports inline text roles with colors and fonts, in case someone wants it, too ;-) 
 Re: [Docutils-develop] plan to add math support From: David Goodger - 2010-10-18 13:45:22 On Mon, Oct 18, 2010 at 09:08, Guenter Milde wrote: > Dear Docutils developers, > > after import this, I read > >  Simple is better than complex. > >  There should be one-- and preferably only one --obvious way to do it. > >  Now is better than never. > > and want to start implementing math support *now*. If you can include reasonable HTML output, +1. If not (and you seem to indicate not), -1. If we can't improve the status quo, what's the point? LaTeX math support exists already, via the "raw" directive at least. It's not ideal, but it's explicit. IOW, HTML output is IMO a necessary precondition for core inclusion. ISTM that this is a case of "never is often better than *right* now." (And the Zen of Python applies best to the Python language itself. Its application to Python *code* is questionable.) -- David Goodger ; 
 [Docutils-develop] [ docutils-Bugs-3089774 ] Images in document templates are not preserved From: SourceForge.net - 2010-10-18 13:23:44 Bugs item #3089774, was opened at 2010-10-18 15:23 Message generated for change (Tracker Item Submitted) made by pachiburke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ODT Writer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: pachiburke (pachiburke) Assigned to: Dave Kuhlman (dkuhlman) Summary: Images in document templates are not preserved Initial Comment: Steps to reproduce the bug: 1. Create an odt template (my-template.odt) with an image in its header 2. Use the template to generate an ODT document with the --stylesheet=my-template.odt 3. Open the generated document The images in the header are not preserved. It's probably due to the Pictures subdir not being copied, and it may contain elements that are not part of contents.xml (such as headers and footers). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3089774&group_id=38414 
 [Docutils-develop] plan to add math support From: Guenter Milde - 2010-10-18 13:08:47 Dear Docutils developers, after import this, I read Simple is better than complex. There should be one-- and preferably only one --obvious way to do it. Now is better than never. and want to start implementing math support *now*. Plan: 1. stage: Basic support * "math" role and directive * input language "LaTeX math" * output as literal in the non-latex writers 2. stage: Improvements * support other writers (see todo.txt for existing work that we can build upon). * accept Unicode input. Directive --------- +++ rst/directives.txt (Arbeitskopie) @@ -492,6 +492,55 @@ +.. _math: + +Math Block +========== + +**NOT IMPLEMENTED YET** + +:Directive Type: "math" +:Doctree Element: math-block +:Directive Arguments: None. +:Directive Options: Possible. +:Directive Content: Becomes the body of the math block (display formula). + +The "math" directive inserts a block with mathematical content (display +formula) into the document. + +The default input format is "latex" (LaTeX math syntax without surrounding +). + +If the writer does not support math typesetting, the content will be +inserted verbatim. + +The following options are recognized: + +class : text + Set a "classes" attribute value on the block element. See the + class_ directive. Role ---- +++ rst/roles.txt (Arbeitskopie) @@ -256,6 +256,36 @@ +:math: +========== + +**NOT IMPLEMENTED YET** + +:Aliases: :inline-math:, :m: +:DTD Element: math +:Customization: + :Options: class_, input-format + :Content: None. + +The math role marks its content as mathematical notation (inline formula). + +The default input format is LaTeX math syntax without +the surrounding  ("latex"). + +See the math directive_ (producing display formulas) for more info on +mathematical notation in restructuredText. Doctree additions ----------------- +++ docutils/docs/ref/doctree.txt (Arbeitskopie) @@ -2861,7 +2862,129 @@ +math +======== + +The math element contains text in LaTeX format that will be +typeset as mathematical notation (inline formula). + +Details +------- + +:Category: + Inline Elements_ + +:Parents: + All elements employing the %inline.elements;_ parameter entities in + their content models may contain math. + +:Children: + math elements may contain text data. + +:Analogues: + math is analogous to a XHTML "math" element or + the LaTeX ($math$) mode. + +:Processing: + Rendered as mathematical notation. + +Content Model +------------- + +.. parsed-literal:: + + %text.model;_ + +:Attributes: + The math element contains the common attributes_ + (ids_, names_, dupnames_, source_, and classes_). + +To be completed_. + + +math_block +============== + +The math_block element contains a block of text in +LaTeX format that will be typeset as block of mathematical notation +(display formula). + +The math_block element is generated during the initial parse from a +"math" directive. + +If the writer does not support math typesetting, the content will be +inserted verbatim (i.e. as LaTeX source code). + +Details +------- + +:Category: + Simple Body Elements_ + +:Parents: + All elements employing the %body.elements;_ or + %structure.model;_ parameter entities in their content models + may contain math_block. + +:Children: + math_block elements may contain text data. + +:Analogues: + math_block is analogous to a LaTeX "equation*" environment or a XHTML + "math" element displayed as block-level element. + +:Processing: + Rendered in a block as mathematical notation, typically centered or with + indentation + +Content Model +------------- + +.. parsed-literal:: + + %text.model;_ + +:Attributes: + The math element contains the common attributes_ + (ids_, names_, dupnames_, source_, and classes_). Objections, Comments? Günter 
 Re: [Docutils-develop] [Docutils-users] Bug in Docutils Trunk: error: can't copy 'docutils/writers/latex2e/xelatex.tex' From: Tom Browder - 2010-10-16 20:03:27 On Sat, Oct 16, 2010 at 13:50, Guenter Milde wrote: > On 2010-10-16, engelbert gruber wrote: >> forwarded to developer >> On Fri, Oct 15, 2010 at 3:24 PM, Tom Browder wrote: >>> I just checked the trunk/docutils on Linuux.  Using Python 2.7 I ran: > ... >>> error: can't copy 'docutils/writers/latex2e/xelatex.tex': doesn't >>> exist or not a regular file > >>> Looks like it may not have been 'svn add'ed. > > Indeed. It's added now. Sorry for the inconvenience. Thanks, Günter! Regards, -Tom 
 Re: [Docutils-develop] [Docutils-users] Bug in Docutils Trunk: error: can't copy 'docutils/writers/latex2e/xelatex.tex' From: Guenter Milde - 2010-10-16 18:50:36 On 2010-10-16, engelbert gruber wrote: > forwarded to developer > On Fri, Oct 15, 2010 at 3:24 PM, Tom Browder wrote: >> I just checked the trunk/docutils on Linuux.  Using Python 2.7 I ran: >>  sudo python setup.py install >> and got: ... >> error: can't copy 'docutils/writers/latex2e/xelatex.tex': doesn't >> exist or not a regular file >> Looks like it may not have been 'svn add'ed. Indeed. It's added now. Sorry for the inconvenience. Günter 
 Re: [Docutils-develop] [Docutils-users] Bug in Docutils Trunk: error: can't copy 'docutils/writers/latex2e/xelatex.tex' From: engelbert gruber - 2010-10-16 14:56:12 forwarded to developer On Fri, Oct 15, 2010 at 3:24 PM, Tom Browder wrote: > I just checked the trunk/docutils on Linuux.  Using Python 2.7 I ran: > >  sudo python setup.py install > > and got: > > running install > running build > running build_py > running build_scripts > running build_data > error: can't copy 'docutils/writers/latex2e/xelatex.tex': doesn't > exist or not a regular file > > Looks like it may not have been 'svn add'ed. > > I don't see this error in the bug list. > > Regards, > > -Tom > > Thomas M. Browder, Jr. > Niceville, Florida > USA > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > Docutils-users mailing list > Docutils-users@... > https://lists.sourceforge.net/lists/listinfo/docutils-users > > Please use "Reply All" to reply to the list. > 
 Re: [Docutils-develop] Bug in rst2odp From: Stefan Merten - 2010-10-14 06:26:54 Attachments: application/pgp-signature Hi! Last week (13 days ago) Stefan Merten wrote: > Unfortunately rst2odp still doesn't run:: [...] > Obviously the lack of the pygments library is not cleanly supported. I patched so rst2odp now at least runs even when pygments is not installed. However, code-block directives are not rendered at all and crash. Grüße Stefan 

Showing results of 70

<< < 1 2 3 > >> (Page 2 of 3)