On 04/28/2017 05:26 AM, Heiko Tietze wrote:
That's really great news (and a very ambitious project). If you consider
to also touch the frontend please have a look on what the UX team did
some time ago https://pad.documentfoundation.org/p/UX-PrintDialog. Feel
free to ask in case of usability
On 04/28/2017 01:09 PM, Heiko Tietze wrote:
What a shame ;-). No idea why this didn't work, it's just an etherpad.
Perhaps the server was down for a moment. Could you please try again.
Tried it again and now it is working. Thanks.
Till
___
Hi,
as Caolán McNamara told me after presenting my problem on the
#libreoffice-dev channel on FreeNode (see log below) I am posting it here:
I am Till Kamppeter, leader of the OpenPrinting project and I am also
the packager of the printing stack in Ubuntu.
In the Google Summer of Code 2017
On 04/28/2017 05:59 AM, Caolán McNamara wrote:
The main question for me is what format/mechanism is provided by the
user of the backend as the print transport format/mechanism, e.g. if
it's simply (like cups) "give me the pdf to print" then it's relatively
easy. If it's (like GtkPrintOperation)
[ Already talked about this on IRC, #libreoffice-dev, Libera.Chat ]
I am Till Kamppeter, leader of OpenPrinting and so responsible for the
printing infrastructure in Linux and other Posix-style operating systems.
https://openprinting.github.io/about-us/
LibreOffice is one of the few
mentors being invited, joining the org
[...]
On 04/04/2023 19:33, Till Kamppeter wrote:
LibreOffice is one of the few applications which have their own print
dialog, and do not use one of the desktop environment toolkit's (GTK/Qt)
ones primarily (AFAIR one can use the GTK one option
On 06/04/2023 20:36, Till Kamppeter wrote:
To step up, please tell me your full name and e-mail address, so that I
can invite you and you can register in Google's web app. Only condition
is that you do not participate as a contributor/student in this year's
GSoC.
Please contact me by e
On 26/03/2024 15:22, Michael Weghorn wrote:
Do I understand correctly that the idea is that the new CPDB-based approach
would remain optional (for now at least), i.e. replace the previous CPDB
implementation and co-exist with the existing code directly using CUPS/PPD API,
rather than making
Michael W.,
Thanks a lot for taking our CPDB GSoC project to the meeting!
Caolan, Heiko, the UI is expected to not change, only the communication between
the dialog and the print technology (usually CUPS, with CPDB others, like cloud
printing, will also be supported) will change, so we will
On 27/03/2024 08:34, Michael Weghorn wrote:
Thanks for the detailed description. Since printing is a critical feature for
many users and the current CUPS/PPD API implementation has been used
successfully for quite a long time now, I wouldn't feel comfortable
unconditionally replacing it with
On 27/03/2024 12:55, Michael Weghorn wrote:
For CUPS 3.x support, my initial thought was that requiring the CPDB-based
implementation for that could be a way forward, while leaving LO's internal
CUPS/PPD implementation basically unchanged and around for compatibility reasons
(for CUPS 2.x
On 27/03/2024 16:22, Michael Weghorn wrote:
Are you aware of any specific reasons why distros would prefer direct use of
CUPS API over CPDB other than the usual packaging efforts needed for any new
library?
No.
It could only happen that some distros are perhaps not aware of CPDB and
On 27/03/2024 18:11, Michael Weghorn wrote:
Good, then I currently see no blocker for requiring CPDB for CUPS 3.x support.
Distros will then become aware once they're packaging any software depending on
CPDB at latest.
Would be good to tell them that for CUPS 3.x use of CPDB is required.
13 matches
Mail list logo
