Some sparse questions
Andrea De Michele
andrea.demichele at gmail.com
Sat Jan 18 20:55:24 UTC 2020
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
>> 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
>> 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)))
>> (sheet-native-transformation parent)
>> (sheet-transformation sheet))
>> 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
>> 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,
Andrea De Michele
More information about the mcclim-devel