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

[Nik Clayton <nik@nothing-going-on.demon.co.uk>]

On Sat, Feb 24, 2001 at 11:36:03PM -0500, Adam Di Carlo wrote:
> Nik Clayton <nik@nothing-going-on.demon.co.uk> writes:
> > On Fri, Feb 23, 2001 at 12:15:04PM -0500, Adam Di Carlo wrote:
> 
> > As far as the *author* is concerned, they should be providing images in
> > one of two formats, EPS, or PNG, depending on whichever is most
> > appropriate.
> 
> My assumptions are different, I guess, that's all.  I let people
> provide images in whatever format that I can convert out of (.fig,
> .dia just added in CVS, .jpeg, .gif, whatever).

I don't want to do that.  If I did, any one that wanted to build the
documentation for a specific output format is going to need to have the
same tools to hand as the original author -- I think this is too heavy a
burden to force on people, particularly when not everyone (myself
included) is blessed with a cable modem, DSL, or some other fast
connection.  Note, also, that someone might want to build the
documentation on a machine that is not normally used with a console
attached.  Most of these applications all require X to be installed, and
a slew of other dependencies as well.  I've inadvertently made X11 a
requirement of the documentation building on FreeBSD, which is a mistake
I'm currently fixing, but I can forward you all the indignant mail I've
received from people who want to build the documentation, but don't want
X installed (consider someone who has a FreeBSD box acting as gateway,
builds the PDF documentation on it, and then transfers it to their
Windows box to view it).

Now suppose that someone generated a network diagram in tgif, that they
might want to edit in the future.  I have no problem with the native
tgif format being committed to the CVS repository, but an EPS equivalent
must be committed as well.

> > For PDF output, we have to convert any supplied EPS files to PDF.
> 
> I actually make a similar assumption but I think I'm wrong in doing
> that.  The PDFTeX stuff can actually handle both PNG and PDF.  

Yeah, but it can't handle EPS, which is what I'm talking about here.

> I'm
> hoping to let the user either go with the stock default (PDF), set
> their own default (out of PDF or PNG), and in combination, allow
> per-figure override if they like (but I haven't worked this out in
> practice, so I don't even know if it's doable or not -- makes it a lot
> harder to auto-generate the dependancies).

As far as I know, the pdftex defaults aren't overrides, they're just a
default list of extensions to search.  So if you tell pdftex "Include
the image file with the name "figure1", it'll search for "figure1"
first, then "figure1.png", then "figure1.pdf", and so on.

All I do is change the search order, so that it'll include "figure1.pdf"
in preference to "figure1.png".

> > No.  As the first step *after* (Open)Jade has generated the .tex file we
> > prepend a line of TeX that makes sure the defaults are set to what we
> > expect them to be.
> 
> Oh, can I say "ew" to that?

Yep.  But I've learnt that expecting application defaults to change
stable between releases is a bad idea.  Better to hardcode the defaults
you want somewhere that you control, and enforce it rigorously.

N
-- 
Internet connection, $19.95 a month.  Computer, $799.95.  Modem, $149.95.
Telephone line, $24.95 a month.  Software, free.  USENET transmission,
hundreds if not thousands of dollars.  Thinking before posting, priceless.
Somethings in life you can't buy.  For everything else, there's MasterCard.
  -- Graham Reed, in the Scary Devil Monastery