From: Magnus L. H. <ma...@he...> - 2004-07-28 21:49:55
|
... while we're on the topic (sort of): - Constructive area geometry - Transparency/alpha levels (has been done using MetaPost; could perhaps be ported) - SVM output Oh, wait -- that's three things... <wink> -- Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] |
From: Andre W. <wo...@us...> - 2004-07-29 07:21:49
|
Hi, On 28.07.04, Magnus Lie Hetland wrote: > ... while we're on the topic (sort of): > > - Constructive area geometry What do you want? Please explain in a few words ... > - Transparency/alpha levels (has been done using MetaPost; could > perhaps be ported) Transparency in PostScript? Have to take a look at it. I know that there are some tricks, but those are quite problematic. > - SVM output I'm sorry, what's SVM? > Oh, wait -- that's three things... <wink> As soon as you want to take one of it yourself ... ;-) André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Magnus L. H. <ma...@he...> - 2004-07-29 08:14:09
|
Andre Wobst <wo...@us...>: > > Hi, >=20 > On 28.07.04, Magnus Lie Hetland wrote: > > ... while we're on the topic (sort of): > >=20 > > - Constructive area geometry >=20 > What do you want? Please explain in a few words ... CAG is a 2D-version of constructive solid geometry. Basically the use of set operations on areas (or closed (or, perhaps, even open?) paths). The Java 2D API has it (although I've never really used that much). Basically you can do stuff like "take this circle here, remove the part that overlaps with this other circle here, and then use the union of that and this rectangle here" and so forth. Can make it quite easy to build up complex paths. > > - Transparency/alpha levels (has been done using MetaPost; could > > perhaps be ported) >=20 > Transparency in PostScript? Have to take a look at it. I know that > there are some tricks, but those are quite problematic. Sure. Here's some material on faking transparency with MetaPost, though: http://www-math.univ-poitiers.fr/~phan/metalpha.html > > - SVM output >=20 > 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). What I *did* mean was SVG. (SVG, of course, has support for nice things like transparency already...) But I guess supporting lots of output formats isn't all that useful, really, as long as there are converters out there. 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? 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 ... ;) > > Oh, wait -- that's three things... <wink> >=20 > As soon as you want to take one of it yourself ... ;-) Right. :] > Andr=E9 --=20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] |
From: Andre W. <wo...@us...> - 2004-07-29 08:58:46
|
Hi, On 29.07.04, Magnus Lie Hetland wrote: > CAG is a 2D-version of constructive solid geometry. Basically the use > of set operations on areas (or closed (or, perhaps, even open?) > paths). The Java 2D API has it (although I've never really used that > much). > > Basically you can do stuff like "take this circle here, remove the > part that overlaps with this other circle here, and then use the union > of that and this rectangle here" and so forth. Can make it quite easy > to build up complex paths. 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. > > > - Transparency/alpha levels (has been done using MetaPost; could > > > perhaps be ported) > > > > Transparency in PostScript? Have to take a look at it. I know that > > there are some tricks, but those are quite problematic. > > Sure. Here's some material on faking transparency with MetaPost, > though: > > http://www-math.univ-poitiers.fr/~phan/metalpha.html 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 guess. > > 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? > 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. > 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. 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. 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. 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 ... 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 ... André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Magnus L. H. <ma...@he...> - 2004-07-29 10:57:23
|
Andre Wobst <wo...@us...>: > [snip] > 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. [snip] >=20 > I.e. you calculate yourself what curves/colors occur when a partially > transparent objects is painted on to of some existing material. Yes. > 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 :] 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? > >=20 > > Dang. It's "support vector machine", but that's not what I meant to > > say (I'm just used to typing it). >=20 > 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. Excellent. > > But I guess supporting lots of output formats isn't all that useful, > > really, as long as there are converters out there. >=20 > 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= e > > command-line converter tools per default, until custom output routine= s > > were produced? >=20 > 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 ... ;) >=20 > 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, anyway. 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: drawLine drawPolygon drawImage drawString There is a fill parameter allowing you to fill things and the like, though. 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 PDF... Anyway, PyX r teh pwnz0r! ;) --=20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] |
From: Joerg L. <jo...@us...> - 2004-07-29 11:40:37
|
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 |
From: Magnus L. H. <ma...@he...> - 2004-07-29 11:57:46
|
Joerg Lehmann <jo...@us...>: > > 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. Sure, sure! I'm definitely *not* arguing against native support. This was more like a temporary (or additional) feature. If PyX could do SVG, that would be *excellent*. Imagine real tex layout, transparency and filters in one and the same figure... Wooo. :) [snip] > 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. Yep; sounds very reasonable (as I also said elsewhere). > But lowest common denominator would exclude things like transpacerency. You are right. (It would have to be a "sliding scale" sort of thing, I guess -- but that would also have to be the case with PyX supporting SVG alongside PS, for example.) > [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.) ;) >=20 > Well said. The more I've learnt about PDF and SVG there more I've becom= e > a PostScript fan. Yes. PostScript is one of my favourite languages -- and not just graphics languages. It's a pretty little programming language too. The other two just really suck in that department (and the aren't even Turing complete... Bah! ;) [snipped about extra SVG features] > 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. ;-) Of course. After all, SVG has *lots* of features :) > > Anyway, PyX r teh pwnz0r! ;) >=20 > I'll bite. What does it mean? Heh. Just an attempt at l33t sp33k. "r teh" as in "are the" as in "is the". "pwn" as in "own"; "pwnz0r" as in "ownzor" as in "owner" as in "the coolest" (or something; as in "i pwn u" or "I own you" from online gaming and the like). IOW, PyX rulez -- it's kewl :) Seriously, I think it's a serious contender as one of the de facto standard graphics packages for Python. I've been using ReportLab a bit (it is in some areas sort of similar to Piddle/Sping, and, I think, inspired by them) but the support for typography (through TeX and the like) is, of course, completely missing. And PyX is just so much cooler in many other ways too, so... ;) Oh, enough, already... I've got to get out into the sun while I still have some holiday left. > J=F6rg --=20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] |
From: Andre W. <wo...@us...> - 2004-07-29 11:52:52
|
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/ |
From: Magnus L. H. <ma...@he...> - 2004-07-29 12:04:09
|
Andre Wobst <wo...@us...>: > > Hi, >=20 > On 29.07.04, Magnus Lie Hetland wrote: > > > Sounds like something to be build finite size canvas aka canvas wit= h a > > > border aka boxes (in the future). I'll try to keep it in mind. > >=20 > > Sounds good. >=20 > 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 ... OK. Didn't read it that thoroughly, really -- I just thought it looked good that something was possible here. [snip] > 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. No, no -- this was slightly humorous, I guess... That if you didn't want to use a back-end API I could still pretend the EPS output was front-end-to-back-end communication and use a PS interpreter in my own back-end code, to convert things to my own memory representation. :) > (There is one, already.) Of course. [snip] > > No, I see. Does this mean that adding stuff like PDF and SVG is going > > to be Hard Work(tm)? >=20 > 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. Excellent :) [snip] > 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 ... Well... If you have pdfwriter objects and the line, couldn't I write an (external) antigrainwriter (or something) for example? Just thinking here... As long as you output (say) SVG, interpreting this and using it for (say) display graphics should be easy anyway. PS, PDF and SVG is a nice trio. [snip] > There is some kind of transparency in pdf as well. Hm. Right. > But I'm not well informed about it. Me neither. > Might come with time ... >=20 > > Anyway, PyX r teh pwnz0r! ;) >=20 > ??? (I'm sorry, I don't speak that language. Seriously.) Heh. See explanation in my previous posting. > Andr=E9 --=20 Magnus Lie Hetland "Canned Bread: The greatest thing since sliced http://hetland.org bread!" [from a can in Spongebob Squarepants] |