Some sparse questions

Andrea De Michele andrea.demichele at gmail.com
Sat Jan 18 15:46:22 UTC 2020


Dear all,

I'm working on CLIM-PDF backend and I solved some problems like the
text direction in landscape orientation, but I don't like the solution
so I didn't submit any PR. 

Instead I write here to have some feedback from you about some issues that I
have found, some very PDF specific other in the very core of McCLIM.

I'm start from the more pdf specific (and easier) to the more general one (and harder):

1) WITH-OUTPUT-TO-PDF-STREAM  macro:

The PDF backend is used through WITH-OUTPUT-TO-PDF-STREAM that is
based on the analogous macro for Postscript backend defined in the
Spec.

I think it is better to define for PDF backend a
WITH-OUTPUT-TO-PDF-FILE with a string or a pathname as argument
instead of a stream. In this way the user don't have to open the file
stream (the user needs also to known that the stream must be open with
keyword :element-type '(unsigned-byte 8)). If we remove the
WITH-OUTPUT-TO-PDF-STREAM McCLIM can remove the dependency to
FLEXI-STREM system.

The difference from PDF to Postscript is giustified because PDF is a
file format so the output is ever a file, instead the Postscript
output can be send on a stream directly atttached to a postscript
printer.

We can also add a WITH-OUTPUT-TO-POSTSCRIPT-FILE macro without remove
the WITH-OUTPUT-TO-POSTSCRIPT-STREAM defined in the Specification.

2) GRAFT in PDF and Postscript Backend

PDF and Postscript Backend define their GRAFT but then never use
it. The stream sheet where the output is drawn is not a child of a
graft. I think this is not correct. 

3) GRAFT in general

Now each backend define its GRAFT. I think that the backend could only
initialize a standard-graft with the right information (in MAKE-GRAFT
generic) like: mirror, width, height, device-millimiter-density,
backend-transformation, and leave all the other stuff in the common
graft module "Core/clim-basic/windowing/grafts.lisp"

4) transformation and region machinery

Is it the transformation and region machinery correct? Or it is works
only in some standard situaions? For example I think that we could
obtain a Zoom effect simply by: (setf (sheet-transformation
some-sheet) (make-scaling-transformation 1.5 1.5)) but this doesn't
work on McCLIM (I try it in the listener demo of clim-tos and there it
works). Follow some more specific topics:

4a) Setting sheet-native-transformation: 

McCLIM set directly the SHEET-NATIVE-TRANSFORMATION with
%%SET-SHEET-NATIVE-TRANSFORMATION. I think this is not correct the
sheet-native-transformation must be computated and only cached never
set directly, otherwise you can lost the parent trasformation.

4b) sheet-native-transformation for basic-sheet:

(defmethod sheet-native-transformation ((sheet basic-sheet))
  (with-slots (native-transformation) sheet
    (unless native-transformation
      (setf native-transformation
	    (if-let ((parent (sheet-parent sheet)))
	      (compose-transformations
               (sheet-native-transformation parent)
               (sheet-transformation sheet))
              +identity-transformation+)))
    native-transformation))

it's not correct because didn't take in account the mirror
transformation if the mirror of sheet it is not the same of the
parent.  So we need to correct this or to add a method for
mirrored-sheet-mixin.  Of course we didn't see the error because often
McCLIM set directly sheet-native-transform as written before in 4a)

4c) What is sheet-native-region?

>From the spec: "Returns the region for the sheet sheet in native
coordinates". This is not clear. The first time that I read it I
understood that it is the sheet-region of the sheet transformed in
native coordinates, that means for examples that a sheet with a region
+everywhere+ have a native-region +everywhere+. Instead for McCLIM,
and clim-tos too, it is the region of the mirror "for" the sheet
i.e. the sheet-region of the sheet transformed in native coordinates
clipped by the mirror region.  This interpretation maybe is correct
because the spec said about sheet-device-region:

"Returns the actual clipping region to be used when drawing on the
mirror. This is the intersection of the user's clipping region
(transformed by the device transformation) with the sheet's native
region."

Anyway, in this case, the sheet-native-region for the graft in Mcclim
is wrong: it is +everywhere+

-- 
Andrea De Michele




More information about the mcclim-devel mailing list