On Mon, Mar 22, 2021 at 09:56:27PM +0000, Dima Pasechnik wrote:
> 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.
People implementing new hot languages? At some place you need
to call OS or existing libraries and currently portable
interface is in C (C++ is much more problematic to interface).
And "code in C" is only partly accurate: for real work you need
to call library function which is close to 1 line of code
(replicated in few places as we have few similar but not
identical binaries). You need few more lines to decide if
call is required. Rest is configure/Makefile to make sure
program links to the library.
Real work is to find right place to put library call and the
few other lines. That does not differ much from work
needed in any other language, except for fact that
some people like C and would code in C things better done
in other languages, other hate C do not want to touch it
even when it makes sense.
BTW: There are folks who are not satisfied with mainstream
GUI toolkits and code new substantial things in C (both
alternative toolkits and applications based on them).
BTW2: It would be nice to have some GUI capabilites in Spad.
However, I feel that it is wiser to put my effort in other
tasks.
> >
> > 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.
Well, if you start with .xpm then converting it to .svg have
limited sense... And Postscript produced from .xpm is not
better than .png. IIRC 'scene' (that I mention below) can
produce .svg
> > 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/20210322231215.GB7130%40math.uni.wroc.pl.
