Open maltoe opened 1 year ago
PDFA_def_ext.ps.eex
or so)info
snippet in the GhostscriptWorker.join/2
functionGhostscriptWorker.convert/2
With the limited knowledge I have about the code base, I tried to come up with a (high level) plan about how to "smoothly" introduce a unified/smart print_to_pdf/3
that allows to print both pdf
or pdfa
files.
ChromicPDF::API
lib/chromic_pdf/api/v1/
behaviour.ex
specifying its behaviourimpl.ex
(or a better name if you can think of one) and move the code from ChromicPDF::API
here.ChromicPDF::API
to delegate function calls to ChromicPDF::API::V1::Impl
The goal of the second version is to have a unified/smart print_to_pdf/3
, capable to print both pdf
and pdfa
files based on the given function parameters. This version is also smart enough to know when to use Ghoshscript
.
Add lib/chromic_pdf/api/v2/
Add behaviour.ex
specifying its behaviour
Add impl.ex
(or a better name if you can think of one) and move the code from ChromicPDF::API
here.
print_to_pdf
looks like?The key is to have a well defined type for the opts
that can be passed.
For example:
pdfa
files could be passed through a archival
key. annotations
key.The presence of one (or a combination) of the top level key of the opts
map suffice to determine wether a pdf
or
a pdfa
file should be printed and wether goshscript
should be used or not.
@type opts :: {
archival: map() | true,
annotations: { title: atom() ... }
}
Update ChromicPDF::API
to delegate function calls to ChromicPDF::API::V2::Impl
.
Now that we're calling Ghostscript from
print_to_pdf/2
(optionally, for multiple sources), we may as well benefit from it.GhostscriptWorker/Interface/Impl
messinfo_option
topdf_option
and add it as optional flag toprint_to_pdf/2