Status of XPS backend?
137 views
Skip to first unread message
Luboš Luňák
Jun 16, 2020, 6:10:33 AM6/16/20
to skia-d...@googlegroups.com
Hello,
I know that SkXPS is "still experimental", but I'd like to know what that
means in practice and if there are plans to make it not experimental.
I have made LibreOffice use Skia on Windows, with one of the benefits being
the possibility of phasing out GDI use, and I'd like to do the same for
printing, but I'm unsure if it would be a good idea to rely on SkXPS for it.
After some testing, there are some unexpected problems like
SkCanvas::drawLine() not doing anything at all, with the relevant SkXPSDevice
function containing merely "// TODO", but actually it mostly seems to work
and I think there could be all the functionality I'd need. I've also checked
Chromium sources and while it uses XPS it seems it doesn't use SkXPS.
Is SkXPS meant to be usable for "real" use, or is that not a good idea?
--
Luboš Luňák
l.l...@collabora.com
Matthew Leibowitz
Jun 16, 2020, 6:53:05 AM6/16/20
to skia-discuss
Just coming in here to say that PDF is possibly better since it can create files on both Windows, mac and Linux - and then that files works all over. XPS is very Windows-specific.
And, I think the PDF implementation is more complete?
Mike Reed
Jun 16, 2020, 10:59:23 AM6/16/20
to skia-d...@googlegroups.com
The XPS backend has never shipped (in a google product), so it is definitely "experimental" from our perspective.
We started it at a time when PDF support on Windows machines was questionable, and we thought native printing on Windows would be valuable to Chrome. That hasn't really materialized, so the code has been idle for years.
Do you see real value in XPS -vs- PDF for Windows? If so, we'd like to understand that.
--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/144a53f1-47d4-47e5-a6ab-c275fc5049d1o%40googlegroups.com.
Ben Wagner
Jun 16, 2020, 10:59:28 AM6/16/20
to skia-d...@googlegroups.com
Part of the history of the XPS backend was to have more than one
non-bitmap backend so that we could figure out what the SkDocument
interface might look like, as well as helping influence the design of
the SkPDF back-end, which was originally written quite differently.
Also, it was written before Pdfium and the XPS backend was one
possible way to improve printing in Chrome which Chrome could have
some influence on. Since then Pdfium happened and Chrome can do pretty
well with just PDFs. Since printing generally doesn't get a high
priority and isn't a particularly popular thing to work on it just
hasn't had the time put into it. That being said, the XPS backend
still mostly works for common things (though isn't well tested), and
if it were a priority many missing bits could be implemented
(somethings like font subsetting could really be updated as well). So
the answer to your question is that it's probably not a great idea to
use it in production, but it probably could be made usable with a bit
of work.
non-bitmap backend so that we could figure out what the SkDocument
interface might look like, as well as helping influence the design of
the SkPDF back-end, which was originally written quite differently.
Also, it was written before Pdfium and the XPS backend was one
possible way to improve printing in Chrome which Chrome could have
some influence on. Since then Pdfium happened and Chrome can do pretty
well with just PDFs. Since printing generally doesn't get a high
priority and isn't a particularly popular thing to work on it just
hasn't had the time put into it. That being said, the XPS backend
still mostly works for common things (though isn't well tested), and
if it were a priority many missing bits could be implemented
(somethings like font subsetting could really be updated as well). So
the answer to your question is that it's probably not a great idea to
use it in production, but it probably could be made usable with a bit
of work.
Luboš Luňák
Jun 18, 2020, 5:14:26 AM6/18/20
to skia-d...@googlegroups.com
On Tuesday 16 of June 2020, 'Mike Reed' via skia-discuss wrote:
> The XPS backend has never shipped (in a google product), so it is
> definitely "experimental" from our perspective.
>
> We started it at a time when PDF support on Windows machines was
> questionable, and we thought native printing on Windows would be valuable
> to Chrome. That hasn't really materialized, so the code has been idle for
> years.
>
> Do you see real value in XPS -vs- PDF for Windows? If so, we'd like to
> understand that.
Not really, I was just considering options. If PDF is the preferred way,
> The XPS backend has never shipped (in a google product), so it is
> definitely "experimental" from our perspective.
>
> We started it at a time when PDF support on Windows machines was
> questionable, and we thought native printing on Windows would be valuable
> to Chrome. That hasn't really materialized, so the code has been idle for
> years.
>
> Do you see real value in XPS -vs- PDF for Windows? If so, we'd like to
> understand that.
it'll do for me too.
Thank you for the answers.
--
Luboš Luňák
l.l...@collabora.com
wst wst
Apr 23, 2021, 3:47:49 AM4/23/21
to skia-discuss
"
Do you see real value in XPS -vs- PDF for Windows? If so, we'd like to understand that. "
We are using SkiaSharp XPS, as printing in Windows works with XPS, so do V4 drivers and devices/multi-functionals of major brands accept XPS documents directly for printing. We've seen a major increase in XPS lately.
Op dinsdag 16 juni 2020 om 16:59:23 UTC+2 schreef Mike Reed:
Reply all
Reply to author
Forward
0 new messages