Add a thin wrapper around Skia's PDF backend #775
Conversation
|
Thanks for PR! We will need some time to review it. |
|
We would love to have this functionality in Skiko! Any update on when this can be merged? |
Sorry, not yet. For now we have higher priority tasks. |
|
@LoadingByte can you include SkAnnotateRectWithURL with this PR, if possible |
|
@sgopi93 I too believe that'd be a great addition, but seeing as this PR already lingers for seven months, I think the best bet to getting it merged some day is to keep it very basic and not inflate it even further for the time being. Once the Skiko team merged it, feel free to file a follow-up PR with support for the three functions in |
|
Hi @LoadingByte , Is it possible you to merge this branch with master. As this branch is far behind master? |
|
@LoadingByte would love to see this go in. |
LoadingByte
force-pushed
the
pdf-backend
branch
8 times, most recently
from
0a56812
to
49650f1
Compare
LoadingByte
force-pushed
the
pdf-backend
branch
from
49650f1
to
b30d5a5
Compare
|
I updated this patch to be in line with master. |
|
@LoadingByte thanks I will give it a try in the morning. |
|
@eymar Could you please see about helping this get code get in? |
Skia has a convenient PDF backend that turns draw calls into PDF pages. It would be amazing to have access to that backend in Skiko too.
This changeset adds a direct wrapper around Skia's PDF API. I left out the following features:
SkPDF::Metadata::fStructureElementTreeRoottogether withSkPDF::SetNodeId, which make up an API for adding semantic annotations to elements in the PDF. I deemed this not useful enough to justify the cost of implementing it at this point.SkPDF::Metadata::fExecutor, which is an experimental API for multithreading the creation of PDFs. As Skiko doesn't support theSkExecutoryet, adding this would have incurred high cost for possibly little reward.SkPDF::Metadata::fSubsetter, which allows to choose between two font subsetters, one of which is already deprecated and will thus likely be removed by the Skia team in the near future.SkDocument::abort, which just waits for all background threads to terminate and then returns. This seems non-useful and even confusing because we don't support PDF multithreading.In contrast to my color space changeset, where I wrote POJOs to mirror the existing codebase, I now decided to employ data classes. If you for some reason want to avoid data classes in Skiko, just tell me, and I'll refactor them back to POJOs.
I'm looking forward to your comments.