[liblouis-liblouisxml] AW: Re: Python package for easy installation of liblouis - announcing Transcribo, a Braille type-setting system - feedback and help wanted
- From: "Leo" <fhaxbox66@xxxxxxxxxxxxxx>
- To: <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Sun, 19 Jul 2009 02:07:28 +0200
I haven't tried, and I hope I won't need to. If you knew how poor my
knowledge on C compilers is... but I think what you write is a very good
starting point.
Here are some further thoughts to increase confusion:
The whole thing has to be portable. So if the configure script runs on all
platforms with all compilers (eg. mingw and MSVC on Windows), there is
probably nothing to object against your distutils-free approach which is
easier to maintain as you rightly point out. A no-brainer would probably
call 'make' on Unix-like OS's and use the ready-made DLL on win32.
Perfectionists would probably use setuptools as it abstracts from all the
platform and compiler specificities. If liblouis' configure script does that
job, I don't know. I would assume that smooth compiling with mingw and MSVC
should be the perfectionist's bottom line. But others on this list are much
better placed to judge this.
Leo
-----Ursprüngliche Nachricht-----
Von: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx]Im Auftrag von Michael
Whapples
Gesendet: Sonntag, 19. Juli 2009 01:28
An: liblouis-liblouisxml@xxxxxxxxxxxxx
Betreff: [liblouis-liblouisxml] Re: Python package for easy installation
of liblouis - announcing Transcribo, a Braille type-setting system -
feedback and help wanted
Further to my thoughts yesterday, I have now managed to do what you are
asking (well not quite yet for liblouis, but for a very, and I do mean
very, basic example of a shared library). There is another solution I
could guarantee to work for liblouis but may not sit well for a python
developer, you could always have the setup script execute the configure
script and make file.
Anyway back to getting setuptools to actually perform the compile.
So taking the C file mylib.c:
#include <mylib.h>
int addNums(int val1, int val2) {
return val1 + val2;
}
and the header file mylib.h:
int addNums(int val1, int val2);
and then creating the setup.py script:
from setuptools import setup
from setuptools.extension import Library
setup(name="mylib",
version="1.0",
description="An example of compiling a library",
ext_modules=[Library("mylib", ["mylib.c"], include_dirs=["."])]
)
Now run:
python setup.py build
You should find a shared object file in the build directory (look at the
output from the setup script to get the exact file name). I checked that
the shared object file worked as a proper shared object file by using
stypes in python to load it and use the addNums function.
I don't think this makes use of the build_clib step I mentioned
yesterday, I think setuptools.extension.Library is a replacement for an
Extension object which deals with stand alone C libraries and so
compilation happens as part of the build_ext step. Whether this has any
affect on needing to be careful about order extensions/libraries are
listed I don't know.
Also I am unsure whether defining all the compilation stuff like this in
setup.py is a good idea, IE. we would have two versions of the build
system, one using make the other using setuptools, and so both would
need maintaining and could get out of sync.
Does the above help at all?
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
For a description of the software and to download it go to
http://www.jjb-software.com
Other related posts:
