When creating a simple graphic via Cairo,
> library("Cairo")
> pdf(file="pdf1.pdf")
> plot( 1:10, 1:10, type="b")
> dev.off()
null device
1
> library("Cairo")
> CairoPDF(file="pdf1.pdf")
> plot( 1:10, 1:10, type="b")
> dev.off()
null device
1
veraPDF reports
$ verapdf --verbose --format text pdf1.pdf
FAIL ./pdf1.pdf
FAIL 6.1.3-1
FAIL 6.7.3-6
FAIL 6.3.4-1
FAIL 6.7.2-1
FAIL 6.7.3-2
FAIL 6.7.3-7
FAIL 6.1.7-2
$ verapdf --verbose --format text cairo1.pdf
FAIL ./cairo1.pdf
FAIL 6.1.3-1
FAIL 6.7.2-1
FAIL 6.2.3.3-1
FAIL 6.4-3
FAIL 6.7.3-7
Which are references to the failed requirements in https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFA-Part-1-rules. (however, veraPDF is known to have occasional bugs, too.)
In this case, I wonder if R now has an output device that produces pdf/a compliant graphics. (I noted before that all pdf files including R Cairo graphics thus lose their own pdf/a compliance.) how do other people maintain pdf/a compliant files using R graphics?
update 1: `ggsave`` does not do it, either.
update 2: kdp in particular fails content that includes transparencies. a bad crutch for Cairo output is gs -o $out -sDEVICE=pdfwrite -dCompatibilityLevel=1.3 $in
, which can fix the transparency problem [6.4-3], but adds new problems: 6.3.7-3, 6.1.8-1, 6.1.7-2; plus it explodes file sizes as it presumably rasterizes the format. An option to completely suppress transparencies in CairoPDF
would go a long way. the pdf()
device output does not add transparencies, but then requires different font and other handlings...sigh.
update 3 (best solution so far):
# gs -dPDFA -dNOPAUSE -dBATCH -sOutputFile="out.pdf" \
-sDEVICE=pdfwrite -dCompatibilityLevel=1.3 in.pdf
gets rid of most of the problems, leaving only the 6.2.3.3-1 complaint. unfortunately, some files look great, others seem rasterized and much bigger. not sure yet why.