On Mon, Mar 22, 2021 at 9:43 PM Waldek Hebisch <[email protected]> wrote: > > On Mon, Mar 22, 2021 at 10:03:09PM +0100, Ralf Hemmecke wrote: > > > Our graphics routines can create Postscript. > > > > I actually thought so, but never looked deeper to find out how this can > > be done. > > Click PS button in graphics menu. Draw has options giving output > format. To avoid explicit options in drawing commands we would > have to include Postscript in default output format. Crude > way is to modify .spad file defining default. I am not sure > if there is nicer way. When generationg .pht files HyperDoc > sends some inital setup commands, it would be natural to > change output format there. > > > > ATM you need access to X server for this, but you also need access > > > to X server to create .xpm, so this really is not extra requirement. > > > > Hmmm... in fact, I don't know what .xpm is really used for other than > > being converted into .ps. Maybe HyperDoc pics it up, but I never looked > > at what HyperDoc wants. > > Well, 'draw' sends data to C side. This is used for display. > When you store image C program save requested data formats > (which in case of viewport includes .data which is essentially > copy of data sent from FRICASsys to C side). However, when > you clik on image in HyperDoc, then viewer uses .xpm (presumably > the idea was to save time needed to render data).
I don't know who would code such things in C in 2021, though. This is 25 years too late. > > BTW1: 2D Postscript output ATM is black and white. So > you may prefer .xpm due to color. OTOH, .xpm is just pixel > data, so Web-friendly convertion would go to .png Rather, to svg (scalable vector graphics). Png (or xpm) isn't optimal at all, as they are raster image/bitmap formats. And it is ideologically closer to postscript images, also very small in size. > > BTW2: Long ago I was thinking about replacing use of .xpm > by .png. However, to my surprize compressed .xpm was > smaller than corresponding .png. So with .png our > compressed tarball would be slightly bigger. So it looked > that .png gave us no advantage and I did not look how > much effort would be needed to generate .png > > BTW3: 'scene' framework can generate other formats, but it > is not clear how to connect it to 'draw' so that the > whole thing operate as a whole (ATM you need completely > different commands to get output from 'scene' framework). > > -- > Waldek Hebisch > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/20210322214330.GA7130%40math.uni.wroc.pl. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq0VG1Nqu7s9iAMdOrV7oD9BtPG-L7cGx-uDNBrg2Wzy0A%40mail.gmail.com.
