Having a quick look at distutils, including a C library isn't discussed in the docs, but it does look like it should be possible. The give away seems to be the build_clib command, which seems to have a description which fits. See its docstring, launch python and enter the following:
>>> from distutils.command import build_clib >>> print build_clib.__doc__The only thing is how to add information for this in setup.py (assumeably the setup function call).
I'll have a look tomorrow when I am less tired. Michael Whapples On 17/07/09 22:36, Leo wrote:
Hello, I am new to this list. So let me briefly explain who I am, why I've joined and what I want. 1. I am using Braille in different languages and contexts, mainly English and German, simple text and music, both on refreshable displays and paper. None of the software transforming something into ready-to-emboss plain text appeals to me as it is either closed-source, costly, inflexible, inaccurate, complicated or a combination of these. Admittedly I haven't tried out liblouisxml. But here, already the name is complicated and I anticipate difficulties compiling it on Windows. 2. I like Python for its almost ideal combination of clear syntax, conciseness, user-friendliness and speed. My first project has been PyHyphen, a Python wrapper around a C library for multilingual hyphenation that is used, eg, in OpenOffice.org (see http://pypi.python.org/pypi/PyHyphen/). 3. At some point I took a look at reStructuredText (rST), a light-weight, extensible markup language that is predominantly used to write software documentation, eg. for the entire Python distribution (see http://en.wikipedia.org/wiki/ReStructuredText). reStructuredText is very easy to learn, powerful and clear to read. I am convinced it could serve as an excellent input format for high-end Braille layout. Its features include sections, bullet and enumerated lists, definition lists, tables, references such as auto-numbered footnotes, tables of contents, bibliographical information to name but a few. What's more, rST can be extended through custom directives and so-called interpreted text roles. Hence, it seemed possible to use rST to mark-up text such that the output back-end would use different Braille translators as required, eg. for text including math, music etc. 4. The reference implementation to process rST sources is Docutils (http://docutils.sourceforge.net/). It can generate HTML, LaTeX, Beamer, pdf, OpenOffice and other output formats from rST sources. Why not ready-to-emboss plain text? 5. So a few months ago I started Transcribo. (Homepage: http://transcribo.berlios.de Download daily snapshots from the Mercurial repository at: http://hg.berlios.de/repos/transcribo/archive/tip.tar.bz2 Transcribo is currently a plain text back-end for Docutils. However, its three-tier architecture makes it open to other input formats such as LaTeX, odf, RTF, xml, plain text or whatever. The core of Transcribo is a rendering package that generates a tree structure of frames. A frame can be thought of as a freely placeable, rectangular area on paper. The frames API is flexible enough to represent all kinds of lists, tables, multiple columns, centered headings, and much more. Each frame may contain objects carrying content of any type. Each content object may be given dedicated translator instances, wrappers with or without hyphenation etc. In particular, Transcribo supports liblouis as a translator for content to populate frames. Finally, the frame-tree representation of the input file is assembled to form a plain text file. The bridge between Docutils and the frame renderer (in Docutils terminology this is called a writer) supports a subset of reStructuredText. Current features include headings, paragraphs, hyperlinks, emphasized text style, multi-level bullet lists and enumerations. Adding new features is often a matter of a few lines of code. Transcribo's renderer is configured through Python dictionaries. Future versions may prefer other formats such as JSON or xml. The Docutils writer is mainly configured using the Docutils configuration system, i.e. a config file and command line options. But this is still somewhat rudimentary. However, a command line option to choose the default translator is already implemented. 6. While Transcribo works with various translators, liblouis is currently the most important one as it supports so many languages and math. 7. Transcribo might benefit from some refinement, testing and bug-fixing before the first public release. Also, I'd like to make sure that users can easily install liblouis. When I tried to install it, I had some problems: - finding the dll which is not on googlecode. John kindly pointed me to the page. - copying the dll manually into the Windows/system32 directory - downloading the liblouis sources - installing the Python bindings - copying some tables to a reasonable place 8. I'd like to see liblouis on the Python package index (pypi) so it can be installed automatically using setuptools. To this end, the dll needs to be bundled with the Python bindings, some tables and the C sources. On Unix systems, the sources would need to be compiled, on Win32, the dll needs to be installed, preferrably in the package directory rather than the windows/system32 dir as users do not always have admin privileges. It would be just great if the Python gurus on this list could make an effort. Clearly, I would help write the setup script, although I don't know off hand how to tell distutils to compile a shared library that is not a C extension module. Also, I would welcome any feedback and/or help on Transcribo. There is a mailing list (see the homepage). It is not yet in use though. So feel free to join. Warm regards Leo For a description of the software and to download it go to http://www.jjb-software.com
For a description of the software and to download it go to http://www.jjb-software.com
