Some sparse questions

[Andrea De Michele]

Hello Cyrus,

thanks for your answers. As you suggested I will open some issues on github.

For the unicode font, I'm sorry but I don't have any experience.

Cyrus Harmon <ch-mcclim at bobobeach.com> writes:

> 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
>
>
>
>

-- 
Andrea De Michele