Vladimir,

Some specific comments I had on the current draft:

(1) "The scope of this SRFI is not to implement the whole drawing
library..." If the SRFI implementation doesn't provide the actual
drawing routines, and also doesn't provide an extensive drawing
library, it seems too limited to be useful--the bottom and top
"layers" are both missing, and much of what it does provide is
unspecified.  Since procedures for image-rendering would probably be
far outside the scope of the SRFI, it would be useful to specify a
full high-level picture language--for example, the frame, segment,
"vector", and painter-constructor procedures (which the Racket library
provides) might be included; this way, useful drawing operations can
be done with this library without having to build a dozen procedures
on top.

(2) Renaming canvas-reset and canvas-cleanup with !s is a good idea.
(But, as has been noted, it's quite true that most of the drawing
procedures are called only for their effects.  This isn't optimal, in
my opinion--see (4) below.)  It should also be stated what these
procedures return (presumably, unspecified values).

(3) canvas-refresh needs to be clarified.  "A Scheme object which can
be used for drawing operations" might be clearer phrasing than "a
system-dependent identifier".  What does "the canvas may not exist
unless it has been drawn on" mean?

(4) Implicit state: All of the procedures in this library operate on a
canvas which seems to be mutable data visible in the calling
environment.  More needs to be said about this state.  What do drawing
procedures do if no canvas has been created, or if there are multiple
canvases?

More generally, it seems like it would be easy to create a version of
the language with no global state (canvases are passed and returned).
Perhaps the SICP language could be offered as a layer on top of this.

(5) `rogers' seems far too specific to be useful.  Maybe it's best to
just describe the general behavior of painters here, or to provide
more painter constructors.  Providing image-file->painter and showing
an example with "rogers.jpg" or the like is probably all that's needed
to show how to implement `rogers'.

(8) jpeg-file->painter: This is, in my opinion, too specific and
should just be image-file->painter.  Or, better, perhaps it should
take the same kind of opaque object returned by canvas-refresh.

(9) The "Issues" section mentions canvas-name and canvas-size.
Are these supposed to be included in the SRFI, or are they internal
to the sample implementation?

To develop on (1), I think it would greatly increase the usefulness
of this SRFI if it provided a general-purpose picture language, with
the SICP language offered as a compatibility layer.  While what we
have may be useful for readers of SICP, it's a very limited core which
would need significant extension to be used for any other purpose.

Best regards,

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Eventually, I decided that thinking was not getting me very far and
it was time to try building." --Rob Pike