better quality image in book.pdf

[Qian Yun]

Hi Ralf,

I noticed that in the creation process of book.pdf,
you convert .xpm (bitmap) image to .ps format.

But "draw" in FriCAS can create ".ps" (vector) image directly.

I'm trying to use this better quality for the book.

So I'm asking there's no particular reason to choose
bitmap image over vector image, right?

- Best,
- Qian

[Waldek Hebisch]

There is a trouble: currently our 2D Postscript output is black and
white only (no colors). So there is some extra work to do,
either use Postscript only for 3D, or modify Postscript output
so that it can handle colors also for 2D.

BTW. There is long standing issue that our 3D Postscript output
needs connection to X server. It would be good to make it work
independently of X.

--
Waldek Hebisch

[Ralf Hemmecke]

Hi Qian,

No. I think there is no reason to convert .xpm for the book.
Any way to produce the final picture that is included in the book is fine.
As far as I know, .xpm might be needed for HyperDoc.
Otherwise, I would be super-happy, if we can generate the pictures for
the book without X.

Let me know what you are doing. It would be possible to inject code that
while generating the .xmp, some other code generates .ps.

Ralf

[Tim Daly]

I have printed versions of the original pictures in the book.

I'm not sure if scanning them would be useful though.

[Ralf Hemmecke]

> I have printed versions of the original pictures in the book.
> I'm not sure if scanning them would be useful though.

Not useful (for me, at least). We are not selling a super-duper product.
So if the FriCAS book just shows graphics the way that FriCAS is
currently able to produce, then I think that is just being honest to the
users and leaves some motivation for someone to improve the situation.

Looking forward to contributors. ;-)

Ralf

[Qian Yun]

To Waldek:

Does HyperDoc use the generated .xpm image from "draw" commands?

To Ralf:

This is my current progress. The ps image looks much better that
xpm image, I have not realized this before.

Some problems other than black-and-white 2D image:

1. Title not shown in .ps format.
2. Image size needs adjustment in *.tex. (Currently too big.
I guess a new tex package is required for auto resizing.)
3. "smooth" style image is not shown.

- Qian

diff --git a/src/doc/ugepsf.awk b/src/doc/ugepsf.awk
index e39ddde9..a53d6c9c 100644
--- a/src/doc/ugepsf.awk
+++ b/src/doc/ugepsf.awk
@@ -18,7 +18,7 @@
} else {
print "no-pics: " $0
}
- print $0 ": " view n ".VIEW/image.xpm"
- print "\tconvert $< $@"
+ print $0 ": " view n ".VIEW/image.ps"
+ print "\tcp $< $@"
spadgraph=0
}
diff --git a/src/graph/view2D/write2d.c b/src/graph/view2D/write2d.c
index 05bbf62e..d9126b53 100644
--- a/src/graph/view2D/write2d.c
+++ b/src/graph/view2D/write2d.c
@@ -186,7 +186,7 @@ writeViewport(int thingsToWrite)
case Postscript:
/*** Create postscript output for viewport (in
fricas2D.ps) ***/
fricas_sprintf_to_buf2(PSfilename, "%s%s", viewDirName,
- "/fricas2D.ps");
+ "/image.ps");
if (PSInit(viewport->viewWindow,viewport->titleWindow) ==
psError)
return (-1);
drawViewport(PSoption); /* write new script file in /tmp */
diff --git a/src/graph/view3D/write3d.c b/src/graph/view3D/write3d.c
index ac5a1210..990b0fb5 100644
--- a/src/graph/view3D/write3d.c
+++ b/src/graph/view3D/write3d.c
@@ -196,7 +196,7 @@ writeViewport (int thingsToWrite)
case Postscript:
/*** Create postscript output for viewport (in
fricas3D.ps) ***/
fricas_sprintf_to_buf2(PSfilename, "%s%s", viewDirName,
- "/fricas3D.ps");
+ "/image.ps");
if (PSInit(viewport->viewWindow,viewport->titleWindow) ==
psError)
return(-1);
drawViewport(PSoption); /* write new script file in /tmp */
diff --git a/src/hyper/htinp.c b/src/hyper/htinp.c
index 5174ec69..f8014829 100644
--- a/src/hyper/htinp.c
+++ b/src/hyper/htinp.c
@@ -366,7 +366,7 @@ get_graph_output(char *command,char *pagename,int
com_type)
for (i = 0; i < n; i++) {
get_string_buf(spad_socket, buf, 1024);
}
- sprintf(buf, "(|processInteractive| '(|write| |%s| \"%s%d\"
\"image\") NIL)", "%",
+ sprintf(buf, "(|processInteractive| '(|write| |%s| \"%s%d\"
\"postscript\") NIL)", "%",
pagename, example_number);
send_lisp_command(buf);
send_lisp_command("(|setViewportProcess|)");

[Qian Yun]

I checked your bookvol0.pdf and bookvol0.pamphlet.

There's a section "Axiom Images" includes ps/v0page1.eps to
ps/v0page8.eps.

They are in very low quality. A higher resolution scan of them
would be nice. But having the source code to generate them
would be nicer. Does anyone know if the input file to generate
those images exist in somewhere?

- Qian

[Ralf Hemmecke]

> This is my current progress.  The ps image looks much better that
> xpm image, I have not realized this before.

I have not looked at the code so sorry if I say something wrong here.

Do you mean "better" after conversion xpm -> ps happened?

> Some problems other than black-and-white 2D image:
>
> 1. Title not shown in .ps format.

Oh yes, I think that was one of the problems when I experimented with it.

> 2. Image size needs adjustment in *.tex. (Currently too big.
> I guess a new tex package is required for auto resizing.)

Yep. I also remember that. The problem for me was that the .ps has no
size and the .tex file does not say in which size it wants the picture.
So even an auto-resizing does not help much. I think the best would be
to add some size information into the .tex file. But that was too much
for me at that time.

> 3. "smooth" style image is not shown.

What exactly does that mean?

BTW, can be perhaps work on a branch of your github repo. I do not so
much like patches in emails when we have git already.

Eventually, the .ps image creation must be fixed.

Ralf

[Qian Yun]

On 2/4/24 08:20, Ralf Hemmecke wrote:
>> This is my current progress.  The ps image looks much better that
>> xpm image, I have not realized this before.
>
> I have not looked at the code so sorry if I say something wrong here.
>
> Do you mean "better" after conversion xpm -> ps happened?

No. I mean the ps image directly generated by FriCAS is much better
than the xpm image or the xpm converted ps image.

I'm attaching the first image in the book for comparison.

>> Some problems other than black-and-white 2D image:
>>
>> 1. Title not shown in .ps format.
>
> Oh yes, I think that was one of the problems when I experimented with it.
>
>> 2. Image size needs adjustment in *.tex. (Currently too big.
>> I guess a new tex package is required for auto resizing.)
>
> Yep. I also remember that. The problem for me was that the .ps has no
> size and the .tex file does not say in which size it wants the picture.
> So even an auto-resizing does not help much. I think the best would be
> to add some size information into the .tex file. But that was too much
> for me at that time.
>
>> 3. "smooth" style image is not shown.
>
> What exactly does that mean?

In the "Graphics" chapter, there's this example:
draw(cos(x*y),x=-3..3,y=-3..3, style=="smooth", title=="Smooth Option")
The exported ps image only shows axis.

> BTW, can be perhaps work on a branch of your github repo. I do not so
> much like patches in emails when we have git already.

Sure.

- Qian

[Waldek Hebisch]

On Sun, Feb 04, 2024 at 08:18:21AM +0800, Qian Yun wrote:
> I checked your bookvol0.pdf and bookvol0.pamphlet.
>
> There's a section "Axiom Images" includes ps/v0page1.eps to
> ps/v0page8.eps.
>
> They are in very low quality. A higher resolution scan of them
> would be nice. But having the source code to generate them
> would be nicer. Does anyone know if the input file to generate
> those images exist in somewhere?

AFAIK we have source files for all "math" images from Axiom book.
There was also bunch of screen dumps showing parts of user
interface. Currently to re-create those dump one need to run
FriCAS and use a screen dumper utility, so this is manual
process.

Coming back to math images, I believe they were all included
in early FriCAS release. Files were moved after that, but I
think they are still there.

Note: "the same" image may be used in multiple places. I tried
to "de-dupe" them, so there is only one source file.

--
Waldek Hebisch

[Ralf Hemmecke]

> There's a section "Axiom Images" includes ps/v0page1.eps to
> ps/v0page8.eps.

https://github.com/daly/axiom/blob/master/books/ps/v0page1.eps

Oh. You have found something. I left out those pictures that appear
somewhere in the middle of the orginal Axiom book in high quality.
I could scan it from my version, but won't, because I rather want to
have a way to generate them with the FriCAS graphics system and tell the
user how to achieve it. Otherwise it's just showing off while actually
lying.

> Does anyone know if the input file to generate
> those images exist in somewhere?

Tim perhaps knows the person who generated those pictures. ;-)

Ralf

[Qian Yun]

Hi Ralf,

A new scan is still useful -- otherwise I can't see clearly the
sentences describing those graphs.

With a new scan, maybe we can recreate those pages in tex.

About the source files to regenerate those graphs, see Waldek's
post. I'm guessing src/input/image*.input and some other input
files are the sources. Checking.

- Qian

[Waldek Hebisch]

On Sun, Feb 04, 2024 at 08:29:49AM +0800, Qian Yun wrote:
> On 2/4/24 08:20, Ralf Hemmecke wrote:
> >
> > > 3. "smooth" style image is not shown.
> >
> > What exactly does that mean?
>
> In the "Graphics" chapter, there's this example:
> draw(cos(x*y),x=-3..3,y=-3..3, style=="smooth", title=="Smooth Option")
> The exported ps image only shows axis.

Actually, I get a grayish background, white contour and black dots.
I would say that image is recognizable, but colors are gone.
That could be related to use of X: AFAIR X was used to do convertion
between color spaces.

--
Waldek Hebisch

[Waldek Hebisch]

On Sun, Feb 04, 2024 at 08:10:34AM +0800, Qian Yun wrote:
> To Waldek:
>
> Does HyperDoc use the generated .xpm image from "draw" commands?

Yes. HyperDoc and 'viewAlone' use .xpm files. 'FRICASsys' transfers
data which are written to .data files. Graphics program connected
tp FriCAS can render images from .data files. In principle
HyperDoc could be changed to also use .data files, but currently
uses .xpm.

> Some problems other than black-and-white 2D image:
>
> 1. Title not shown in .ps format.

That should not be hard to add. OTOH in printed form or in .pdf
file images normally have captions, so embedded title is not
needed.

> 2. Image size needs adjustment in *.tex. (Currently too big.
> I guess a new tex package is required for auto resizing.)

There is Postscript convention about including information about
bounding box. In fact, it would be good to be able to get
proper .eps for easier embedding.

--
Waldek Hebisch

[Tim Daly]

I believe that the images with bounding box information (.eps) are at:

https://github.com/daly/axiom/tree/master/books/ps

[Camm Maguire]

Greetings!

1) What do you use for standard benchmarking?

2) I have some GCL specific build commits to make. Would you prefer
these to go in master or a separate branch?

Take care,
--
Camm Maguire ca...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

[Camm Maguire]

Greetings!

Unfortunately, there is some 'common' common lisp code that cannot be
compiled twice in the same image, i.e (load (compile-file ...))(load
(compile-file ...)), most notably pcl. Typically this is due to
eval-when :compile-toplevel statements setting global state variables,
etc. Where does fricas stand here?

GCL has a facility to iterate over all its loaded functions at the end
of a build to recalculate all function signatures consistently, and then
to recompile any needed original source files. This is in place a
building twice from scratch after writing a sys-proclaims.lisp file.
The older mechanism will continue to be supported. Is this something
that might be used in fricas?

[Waldek Hebisch]

On Sun, Feb 04, 2024 at 10:19:16AM -0500, Camm Maguire wrote:
> Greetings!
>
> Unfortunately, there is some 'common' common lisp code that cannot be
> compiled twice in the same image, i.e (load (compile-file ...))(load
> (compile-file ...)), most notably pcl. Typically this is due to
> eval-when :compile-toplevel statements setting global state variables,
> etc. Where does fricas stand here?

I am not aware of any problem of this sort with FriCAS code.

> GCL has a facility to iterate over all its loaded functions at the end
> of a build to recalculate all function signatures consistently, and then
> to recompile any needed original source files. This is in place a
> building twice from scratch after writing a sys-proclaims.lisp file.
> The older mechanism will continue to be supported. Is this something
> that might be used in fricas?

Mathematical functionality of FriCAS is implemented almost entirely
in Spad code. Currently there are _no_ direct calls between different
Spad files: either call is inlined and there is no call in generated
Lisp or (main case) there is an indirect call. There are direct
calls inside a single file. OTOH FriCAS tries to emit Lisp
declarations, so Lisp compiler should be able to optimize based
on declarations.

Due to the above determiantion of function signatures by GCL should
have little (if any) effect on mathematical functionality of FriCAS.

Determiantion of function signatures may be significant for code
written in Lisp and Boot, that is FriCAS "interpreter" and Spad
compiler. However, here measurement may be tricky.

--
Waldek Hebisch

[Waldek Hebisch]

On Sun, Feb 04, 2024 at 10:07:37AM -0500, Camm Maguire wrote:
> Greetings!
>
> 1) What do you use for standard benchmarking?

I regularly look at time taken by the testsuite, that it:

time make all-input

I have bunch of specific tests, but they are targeted,
that is each is relevant to some specific issue.

> 2) I have some GCL specific build commits to make. Would you prefer
> these to go in master or a separate branch?

Normally I prefer commits to go into master, unless there is
high risk of breaking things.

--
Waldek Hebisch

[Camm Maguire]

Greetings! i-map.clisp contains three instances of

'

What is intended by this?

[Waldek Hebisch]

On Sun, Feb 04, 2024 at 04:24:38PM -0500, Camm Maguire wrote:
> Greetings! i-map.clisp contains three instances of
>
> '
>
> What is intended by this?

It is a symbol with a strange name. It is used as a kind of
"error mark". AFAICS the name is intended to reduce probability
of clash with user identifiers.

--
Waldek Hebisch

[Qian Yun]

I find this as well when porting to Allegro CL.

I take a look at open-axiom, found that it is fixed by
https://github.com/GabrielDosReis/open-axiom/commit/9584120cc4fd35f1ae0639430e07d5936f1ac39b

My fix is in attachment.

- Qian

[Qian Yun]

One minor correction: remove extra single quote, should be:

DEFPARAMETER($ClearBodyToken, GENSYM('"^L"))

instead of

DEFPARAMETER($ClearBodyToken, GENSYM('"^L"'))

- Qian

[Waldek Hebisch]

On Fri, Feb 09, 2024 at 11:29:20AM +0800, Qian Yun wrote:
> One minor correction: remove extra single quote, should be:
>
> DEFPARAMETER($ClearBodyToken, GENSYM('"^L"))
>
> instead of
>
> DEFPARAMETER($ClearBodyToken, GENSYM('"^L"'))

One litte thing: 'GENSYM' produces unique symbls, so we can use a
informative name, like:

DEFPARAMETER($ClearBodyToken, GENSYM('"ClearBodyToken"))

> - Qian
>
> On 2/5/24 08:31, Qian Yun wrote:
> > I find this as well when porting to Allegro CL.
> >
> > I take a look at open-axiom, found that it is fixed by
> > https://github.com/GabrielDosReis/open-axiom/commit/9584120cc4fd35f1ae0639430e07d5936f1ac39b
> >
> > My fix is in attachment.
> >
> > - Qian
> >
> > On 2/5/24 06:50, Waldek Hebisch wrote:
> > > On Sun, Feb 04, 2024 at 04:24:38PM -0500, Camm Maguire wrote:
> > > > Greetings!  i-map.clisp contains three instances of
> > > >
> > > > '
> > > >
> > > > What is intended by this?
> > >
> > > It is a symbol with a strange name.  It is used as a kind of
> > > "error mark".  AFAICS the name is intended to reduce probability
> > > of clash with user identifiers.
> > >
>

> --
> 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 fricas-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/5824f823-74db-45f7-9b12-b50d3c804e20%40gmail.com.

--
Waldek Hebisch