[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plans for ahead
From: |
Fred Kiefer |
Subject: |
Re: Plans for ahead |
Date: |
Sun, 29 Nov 2015 17:34:19 +0100 |
Greg,
>> On Sun, Nov 29, 2015 at 3:31 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:
>> 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.
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.
Apology for taking your words just as you wrote them. Next time I ask first.
>>> 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?
Fred
- Using a theme Re: Plans for ahead, (continued)
- Re: Plans for ahead, Riccardo Mottola, 2015/11/28
- Re: Plans for ahead, Svetlana A. Tkachenko, 2015/11/28
- Re: Plans for ahead, Gregory Casamento, 2015/11/29
- Re: Plans for ahead, Germán Arias, 2015/11/29
- Re: Plans for ahead, Gregory Casamento, 2015/11/29
- Re: Plans for ahead, Fred Kiefer, 2015/11/29
- Re: Plans for ahead, Gregory Casamento, 2015/11/29
- Re: Plans for ahead, Gregory Casamento, 2015/11/29
- Re: Plans for ahead,
Fred Kiefer <=
- Re: Plans for ahead, Gregory Casamento, 2015/11/29
- Re: Plans for ahead, richard, 2015/11/29
- Re: Plans for ahead, Gregory Casamento, 2015/11/29
- Re: Plans for ahead, Riccardo Mottola, 2015/11/29
- Re: Plans for ahead, Adam S, 2015/11/29
- Re: Plans for ahead, H. Nikolaus Schaller, 2015/11/29
- Re: Plans for ahead, Adam S, 2015/11/29
- Re: Plans for ahead, Alessandro Sangiuliano, 2015/11/29
- Re: Plans for ahead, Riccardo Mottola, 2015/11/29
- Re: Plans for ahead, Gregory Casamento, 2015/11/29