Re: [PyX-devel] Two other things that might be nice...

[Joerg L. <jo...@us...>]

On 29.07.04, Magnus Lie Hetland wrote:
> Andre Wobst <wo...@us...>:
[snip]
> Now... If your point was: "Of course one needs pdftex. This
> illustrates why PyX should output the relevant formats itstelf instead
> of using external converters" I agree with that.
> 
> > > Perhaps one could add a back-end for different output formats, and use
> > > command-line converter tools per default, until custom output routines
> > > were produced?
> > 
> > Personally I'm not convinsed to make use of external programs to claim
> > to support pdf, png, gif, jpeg etc. output. It's just a lie.
> 
> Sure. But if you're open about it, and call it a utility framework
> (so people don't have to write external shell scripts to do this sort
> of thing) it's not lying. You could just describe what it really is.
> Using external programs as output plug-ins.

While I'm not necessarily against doing so, I still think that having
native support for some of the more popular vector formats is really a
good idea. Consider for instance the transparency support, which does
not exist in PostScript. How would you like to do that with
a converter.

[snip]
> No, I see. Does this mean that adding stuff like PDF and SVG is going
> to be Hard Work(tm)?
> 
> > Anyway, we need to extract, what special features are in those
> > different vector graphic formats we want to support and try to fit
> > it into a unique API.
> 
> Yeah, I guess that's exactly what I was thinking about. Then, if
> someone would like to write, say, an Antigrain object (or whatever)
> using that API, it would (or might?) work. Or not?

I think that we should focus on vector graphic formats which are built
according to the PostScript model, which has already been quite well
abstracted in PyX.

> > Things like strokecolors and fillcolors, which PDF has, but
> > PostScript doesn't. I think (Jörg and I discussed it), we want only
> > one color for both, stroking and filling. Just to give you an idea,
> > what we're thinking about and what our problems are ...
> 
> Sure. Lowest common denominator is fine. That's what Piddle does,
> anyway.

But lowest common denominator would exclude things like transpacerency.

[snip]
> Sure. PostScript, PDF and SVG are all part of the same happy family.
> PDF is a dumbing down of PostScript with a more ugly syntax, and SVG
> wraps that the PDF syntax in XML attributes... (And adds lots of
> stuff, of course.) ;)

Well said. The more I've learnt about PDF and SVG there more I've become
a PostScript fan.

> I don't know of any other formats that are as closely related to these
> as they are to each other; restricting yourselves to this threesome
> seems like a reasonable decision.

Yes, indeed.

> And just to repeate a thought from before: I think it would be very
> nice if you allowed the use of some of the extra features in SVG even
> if they won't work with PostScript and PDF. If I know I want SVG
> output I won't care if (say) transparency isn't supported in PS and
> PDF...

As I said above, this should be possible. Realistically, this will also
mean that some features are not supported by a specific backend,
although they are supported by the output format, just because nobody
has written the code. ;-)

> Anyway, PyX r teh pwnz0r! ;)

I'll bite. What does it mean?

        Jörg