OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: DOCBOOK-APPS: Problem converting DB to PDF...

Nik Clayton <nik@nothing-going-on.demon.co.uk> writes:

> On Tue, Feb 20, 2001 at 04:04:27AM -0500, Adam Di Carlo wrote:
> > I have an unreleased but I think pretty decent system, 'preheat'.
> > This is a scheme-based system.  You specify a little scheme file with
> > the local stuff to build and customization, for instance:
> Oh God.  Just as soon as I think I've cleared some free time, something
> new and interesting comes along.
> :-)
> We should really try and get together at some point and go through this
> stuff in more detail.  I get the feeling there are several groups all
> working towards similar goals, and there are just too many mailing lists
> to keep track of.

Absolutely.  I am personally more swamped than can be imagined (work
and Debian stuff).   It would be nice to move preheat over to a
general team of like-minded folks rather than having these separate,
specialized, and not generally useful tools.

The bottom line is that dealing with the whole SGML/XML -> output tool
chain (DSSSL or XSL0 is a pain in the butt.  Nik and I share the
intuition that make already solves half this problem, and the db2*
scripts that are currently availble (from the simple cygnus ones to
even the more complex, python based SGMLtools one) are fundamentally
flawed in that they are not customizable and solve too few of the
actual problems of formatting SGML/XML.

In some ways, your needs seem pretty specific to what you are doing.
I mean, there's a lot of talk about library images and repository
images and stuff, based on your CVS structure (or at least it seemed
on a glance).

You guys use BSD make and we use GNU make.  If we standardized, I
would think it would be reasonable to standardize on SYSV make, but
you guys might not find that acceptable.  OTOH, if we went with a
makefile-maker system like preheat uses, I could see us being able to
support either SYSV or BSD make without too much problems.

You guys also rely on a more specific problem of docbook DSSSL
processing.  My system, god help it, models jade building in general,
among other things.  The docbook layer is a customizatino of that. I
use it for non-docbook Jade processing, and also it supports a lot of
TeX building and such.

It would be wonderful if we could merge our efforts, but I'm not sure
if we can or not.

Even if we can't, I would like to be sure that we are at least
consistent between each other in the jade -V and -i switches that we
pass to indicate the output format.

> I discovered that if I convert PNG images to EPS files and then run them
> through TeX they appear about twice the size they should do.  For
> example, an 80x24 xterm takes up almost half the page.

Is this some sort of TeX problem?  'convert' problem?  Is the EPS
itself that large?

> Then redefine the Graphic handling in the stylesheet, like so;
>     (define ($graphic$ fileref


See, in preheat I can't do things like this since I can't rely on
specific DSSSL customizations.

> What's the best way to make sure that you guys are informed when changes
> are committed?

Can you have the CVS commitlog for just that file email to me ?

.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC