Andre Wobst <wobsta@...>:
> 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.
> I.e. you calculate yourself what curves/colors occur when a partially
> transparent objects is painted on to of some existing material.
> You're free to do so. Well, its more difficult than in MetaPost I
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 :]
If you do SVG output, you could add transparency and the like, which
would only work in SVG...? (It supports animation and the like too,
off course; and filters... Hm.)
> > > I'm sorry, what's SVM?
> > Dang. It's "support vector machine", but that's not what I meant to
> > say (I'm just used to typing it).
> As I found out myself before ...
> About SVG: Its already on the TODO list (for about half a year or so).
> This means, yes, SVG support would be great. Its something we should
> try to implement to catch up with the future.
> > But I guess supporting lots of output formats isn't all that useful,
> > really, as long as there are converters out there.
> I'm not that sure. Why do you use pdftex instead of TeX+dvips+ps2pdf?
> Why is there even a market share for such a program like pdftex?
Many reasons, I guess. Shorter pipeline; very robust and nice-looking
PDF output (as opposed to, at least in the more naive versions,
dvips+ps2pdf or dvipdf). Also special-purpose PDF stuff and new
functionality with hanging punctuation and microtypography (which is
not, AFAIK, available in TeX).
In my case I guess there are two reasons; my desired output format is
PDF (PS is hardly used for docs anymore) so using pdftex seems obvious
(now that it exists already ;). And: I've used dvips + ps2pdf before,
and had some bad luck (or low skill? ;) ending up with nasty bitmapped
fonts and the like, similar to many of the horrible 'old skool' PDF
latex files you find around the Web, which don't display properly --
and display very slowly at that.
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 us=
> > command-line converter tools per default, until custom output routine=
> > 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.
OpenOffice allows you to use XSLT stylesheets as "save as"-plug-ins.
Very nifty IMO. One could, of course, invoke a separate XSLT processor
afterward. No big deal.
> > Or perhaps a simple drawing API could be used at the bottom, and
> > several back-ends could be used... (Hm. Drifting back to my old
> > project PIDDLE here, I guess ... ;)
> Well, we don't have bitmap output and PyX isn't designed that way to
> support it even in the far future.
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>.
> Our objects know themselfs what they need to do in order to be
> inserted into a vector graphics format like PostScript, PDF, etc.
> ... so it's not like PIDDLE.
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?
> Things like strokecolors and fillcolors, which PDF has, but
> PostScript doesn't. I think (J=F6rg 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,
We worked a bit at finding a really small API, and, in fact, the API
(if you use the default implementations of the various curves and arcs
in terms of polygons) consists only of the following four methods:
There is a fill parameter allowing you to fill things and the like,
Not directly applicable, I guess, but still...
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.
> In the end it's clear that PostScript, PDF and SVG are close enough to
> at least dream about support them all. In that sense we restrict
> ourself to quite a limited scope ...
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.) ;)
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.
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
Anyway, PyX r teh pwnz0r! ;)
Magnus Lie Hetland "Canned Bread: The greatest thing since sliced
http://hetland.org bread!" [from a can in Spongebob Squarepants]