[Scribus] Docbook XML import
Tue Apr 5 15:19:14 CEST 2005
On Tue, Apr 05, 2005 at 10:40:53AM +0800, Craig Ringer wrote:
> On Tue, 2005-04-05 at 00:54 +0000, Riku Leino wrote:
> > There's a new file format coming for 1.3.x at some point and for that we will
> > need to write a new file loader for what I've planned to write a universal
> > easy to use api to build custom file importers as well (will also include an
> > exporter api). This is pretty much the next step from the Get Text
> > implementation that is already in use but will extend the behaviour to page
> > creation, object placement and all that is involved in creating a document.
> ... and hopefully as part of the core code, so I can do some wrappers to
> expose it to Python without too much pain. Now that could be rather
> handy indeed, especially if it exposed some sort of text and font
> > Currently the best way would probably be exactly this until the new file
> > loader api is available. To make it fully automatic one will need to create
> > text frames needed and then use all those gt* classes to do the formatted
> > text importing. This is best implemented with a custom made c++ plugin. I'm
> > not sure how up there the scripter is for that. You'll need to wait for an
> > answer from the scripter guys.
> Paragraph style creation in the scripter isn't written yet - it's been
> on my TODO list for so long it's embarrassing (I _did_ say I'd do
> You can, however, import paragraph styles from another document that you
> use as a template, so if you have a reasonably stable set of styles you
> could probably do a pretty good job of scripting your layout from
> DocBook XML. The main limitations you're likely to face are the lack of
> text metrics ("how wide would this text be at this font", etc) and
> inability to create paragraph styles from Python.
Stable as in probably haven't changed in years so this should be fine.
I don't see text metrics as a problem. We aren't trying to totally
automate the process. (Someday, this will be a good article to write
for Linux Journal, I guess.)
We just want to get the layout person out of the business of having to
make decisions that require knowing what the article is about. Well,
we also wanted to be able to use vi to create stuff--we don't have the
time to use Windoze systems. :-) Docbook XML is semi-new. We actually
used to just hand-tag (using vi key maps) for Quark. We then had a
totally disgusting (I can say that as I wrote it--it didn't start out
disgusting but eight years of "let's add this" made it that way)
script that used sed and awk to convert the quark format to troff to
print a proof copy before stuff was sent to layout. (Hope I didn't
make anyone sick but this was done over 10 years ago.)
We use a special tag for instructions to the layout person for such
things as placement of graphics. Because Linux Journal has ads in it,
we really need a human to deal with graphics placement, whether an ad,
a pull quote or a tip would be the best to fill a page and such. We
also have multiple page templates (in particular, two and three column)
that the layout person selects based on the size of a graphic or need
to include a block of text, for example.
> The gettext interface will most likely be much easier for styled text
> import, while using Python would let you do image placement etc too.
> Neither is perfect for your needs I suspect, but both should be
> improving over time. I'd *really* like to get text metrics and para
> style creation into scripter some time. I'm also hoping it'll be
> possible to call the gettext API from Python and/or call out to gettext
> plugins in future. That's not something I'll be able to tackle any time
> soon I suspect, as I'm swamped with uni and work, and I don't think
> anybody else has plans to work on any of those points.
> If you decide to go the Python route, I'd be happy to help out in
> whatever small ways I can.
Thanks. You guys have been great. My hope is that we can build
something that will be useful to others. There is a lot of stuff in
Docbook XML and it just seems that being able to directly import it
into Scribus would be a big win.
Phil Hughes, fyl at a42.com Phone: 505-713-5675
Aptdo. Postal 201, Esteli, Esteli, NICARAGUA
More information about the scribus