discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plans for ahead


From: Gregory Casamento
Subject: Re: Plans for ahead
Date: Sun, 29 Nov 2015 03:58:54 -0500

Fred,

On Sun, Nov 29, 2015 at 3:31 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:
> Hi Greg,
>
> I prefer to stay out of such discussions normally, but have to reply to two 
> of your points. If you reply, please don't add me as a recipient, reply to 
> list should do.

Done.

> On the road
>
> Am 29.11.2015 um 07:53 schrieb Gregory Casamento <greg.casamento@gmail.com>:
>
>> 5) Missing features in GNUstep itself: Printing, after 20 years, is
>> still not complete.  This is something various people, including
>> myself, have worked on in the past to make it somewhat passable.
>> Issues with this are partly related to the backend.   We currently
>> generate postscript directly.   I am wondering if it would not be
>> possible to sidestep this approach and write directly to a Cairo
>> surface.... discussion should open on this as I will not cover the
>> complete topic here.
>
> On cairo we actually use a PDF surface and I am a bit frustrated that you 
> don't know this and don't check before posting. The positioning and splitting 
> into separate pages still needs to be done in GNUstep code and there seem to 
> be some inconsistencies. Feel welcome to address them.
>

I am aware that we are using a Cairo surface.... to generate
POSTSCRIPT output. :)  If you would like me to upload an example file
to prove this I can do so.   GNUstep's backend spits out a PS file
which is generated by the backend and, yes, I am aware that we use a
Cairo surface to generate this file.   My point is... perhaps we
should use Cairo to print *directly*, if at all possible directly
rather than using it to create a PS file and then stream that to the
printer.   Not being an expert on Cairo I am not certain if printing
directly with it is supported.  I only know that what we are doing at
the moment is not a perfect solution.

As for feeling free to address them... I am at the moment working on
getting printing working properly on Linux (registration is way off
and so is pagination as you pointed out) and Windows.  Working on
Linux with the PS file is easy, doing it on Windows is not.  If we had
a printing backend that didn't generate postscript and talked directly
to the GDI+ interface for printing, then it would be MUCH easier to
make it work there as well.

While I could have been more clear, prior to assuming I don't know
what I'm talking about, perhaps it would be easier to ask me to
clarify my points.

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

> Cheers
> Fred
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


Greg
-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]