Some sparse questions

[Cyrus Harmon]

Hi Andrea,

See comments below. Thanks.

On 1/18/20 7:46 AM, Andrea De Michele wrote:
> 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.
I didn't realize this was broken, but looking forward to seeing a 
solution. Can you make a github "issue" for this?
> 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.
Why not have both? Aren't there cases where a user might want to write a 
PDF to a stream (e.g. a web server serving up a dynamic PDF)?
> 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.
Yes, I think that's what I'm suggesting.
> 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.
This sounds plausible but I would look for, e.g., jackdaniel to weigh in 
on grafts here.
> 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"
Again, sounds plausible, even nice!
> 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:
Yes, this is definitely an area that could use more testing and, likely, 
bug fixing. These sorts of things _should_ work.
> 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+

Yes, lots to discuss here. Perhaps opening up "issues" for each of the 
specific problems would be good?

Thanks for your attention to the PDF backend in specific and McCLIM in 
general. One major limitation of the PDF backend is that we currently 
don't support proper unicode fonts. It appears that this is a fair 
amount of work, but I view this as a necessity to have a truly working 
PDF backend. Do you have any experience with this?

Thanks again,

Cyrus