Fred, On Sun, Nov 29, 2015 at 11:34 AM, Fred Kiefer <[email protected]> wrote: > Greg, > <content from previous message removed for brevity... please see previous replies> > > So you were talking about MS Windows? Why didn't you say so? While I am > myself not interested in this platform it should be very simple to package up > cairo_win32_printing_surface_create (HDC hdc) in a cairo backend surface and > use that directly while printing. I am sure you can do that in just a few > hours.
With respect to Windows, which I know you don't care about, but that doesn't make it unimportant, it is, as I said before, impossible to send a PS file to a non-PS printer without using ghostscript. I guess this wouldn't be a BAD thing since this is not to dissimilar to how it was done on OSE as DPS was present on that system and did the translation for you in a similar way. My current approach streams the file, as is, to the printer. This is okay for me since I have a PS printer and it will recognize the postscript coming in... at least in theory. There are issues talking to the Windows spooling mechanism using the existing code in Printing for Windows printing. > Apology for taking your words just as you wrote them. Next time I ask first. Ummm, thanks, I think, for your rather disingenuous and apology such as it is. I have, nevertheless, found that it is beyond your capacity to politely correct people either if you misunderstand or if a mistake is made. I don't mind it as I have a pretty thick skin, but it is unfortunate, however, that it's cost us potential developers in the past. Just being honest. >>>> 6) Lack of support for Wayland. While this is not high on the list >>>> (it is #6 guys) it is something that, if we had taken the initiative >>>> in the beginning, we would have been one of the first adopters of it >>>> and that in and of itself would have gotten us some attention. >>> >>> For years now I have suggested to work on a Wayland backend as soon as >>> somebody takes over normal development and support on gui and back. Getting >>> an initial implementation working should be a matter of just a few days, >>> getting all functionality fully correct takes much longer. >>> This is similar to the opal backend, which I am actually working on in the >>> moment, in that we have something basic there, but nobody would want to use >>> it in that state. >> >> My point was that this should have been something we jumped on from >> the beginning. I fully understand what is involved and that it is >> far from simple. >> >> I am not making any of these points as a matter of blame. I'm simply >> pointing out observations that I have made and facts that I know about >> things we need to address in GNUstep. > > "would have", "should have", maybe I am missing your point here as well. Is > this just reflection about the past or is there something for the present and > the future as well? I will re-iterate more simply so you can understand: I'm only enumerating a list of things which need attention and our current state on some things, nothing more. I'm not sure how I can be any clearer than that. While we "Should have" jumped on Wayland, and there is still time for us to do so. GC -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/ _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
