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

[Andre W. <wo...@us...>]

Hi,

On 29.07.04, Magnus Lie Hetland wrote:
> > Sounds like something to be build finite size canvas aka canvas with a
> > border aka boxes (in the future). I'll try to keep it in mind.
> 
> Sounds good.

Have you read this as: "Sounds like something to be build *on* *top*
*of* finite size canvas aka canvas with a ...". That's what I wanted
to say ...

> > You're free to do so. Well, its more difficult than in MetaPost I
> > guess.
> 
> I don't know; MetaPost isn't especially good here -- it just would be
> good to have some sort of automation here, if possible. Just
> fantasizing, really :]

I think there currently is a difference between MetaPost and PyX. In
MetaPost there is a picture type. Its similar to a canvas in PyX. But
AFAIK MetaPost allows to access all items in this picture. You can
fiddle along that line in PyX as well, but my current intension is,
that this would be "behind the scenes".

> 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.

Right. Its about that. And it already tells you, that we want to be
able to add support for whatever we'll need for a given output format,
although it can't be expressed in PostScript ...

> No, I didn't really mean bitmap output. I just meant thinking about
> abstracting away the core drawing stuff. Then one could plug in other
> drawing modules with very simple APIs (such as the extremely few
> Piddle methods). On the other hand, the back-end could simply
> implement a PostScript interpreter and use that as the API <wink>.

Hmmm. I think I'm looking at it the other way around: We already have
a memory representation of what we want to output. I certainly do not
want to write a PostScript interpreter. (There is one, already.) And
why should I read some strange output and try to find out, which
gsave/grestore matchs each other. We already have a canvas with local
draw attributes (colors etc.) inside. No need to worry ...

> No, I see. Does this mean that adding stuff like PDF and SVG is going
> to be Hard Work(tm)?

Not at all. You may have noticed, that you can already say
writePDFfile and it behaves quite well most of the times. You can
write whole graphs including text into pdf already. But this *is*
highly experimental. I've already started a pdfwriter, which is the
second try, which points into the right direction for the future, I
guess.

> > 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?

Sure.

> I guess it's just a matter of where the line is drawn between PyX and
> the rest of the world anyway. One could always generate other output
> formats based on what PyX outputs.

Right. And I draw the line at the native PyX output formats. Sure you
can use a PostScript interpreter afterwards. Indeed, that's always
done. It might be a RIP in a PostScript printer, but still ...

> 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...

There is some kind of transparency in pdf as well. But I'm not well
informed about it. Might come with time ...

> Anyway, PyX r teh pwnz0r! ;)

??? (I'm sorry, I don't speak that language. Seriously.)


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/