On Tue, 24 Oct 2017 19:46:21 +0200 luigi scarso <luigi.sca...@gmail.com> wrote:
> On Tue, Oct 24, 2017 at 7:27 PM, Alan Braslau > <braslau.l...@comcast.net> wrote: > > On Tue, 24 Oct 2017 19:06:51 +0200 > > luigi scarso <luigi.sca...@gmail.com> wrote: > > > >> is this > >> \externalfigure[cow] > >> a pdf ? > >> As said previously , including pdf can break the rules of > >> format=PDF/A-3a. > >> Simply include bitmap images, it's way more robust. > > > > Isn't that non-optimal, using bitmap images rather than vector > > graphics? Must there not be a way to correctly include PDF > > graphics, perhaps modifying the included file to make it > > conforming? > Forgetting for the moment that a generic pdf could not have the right > structure (and fix it can be quite complicate) > you can have a "guest" pdf file that is valid pdf/a but once included > with \externalfigure can conflicts with the "host" pdf, because the > host specifies a different color spaces, for example. > On the other side, if you include it as bitmap, you are safe on the > color spaces and the structure. > Of course This sound not ok if the pdf is only text --- but even in > this case the situation is not so simple: > the fonts must be correct (it's known that we have math fonts that are > not ok ), the tounicode also.. > so also in this case a high res bitmap can be the only solution., "Let the buyer beware". Given that bitmap graphics are NOT OK (think bloat, an MS/Office specialty), there must be a better solution. Perhaps simply detecting a conflict between an included PDF and the "host" PDF and printing a warning! Then it could be up to the user to "fix" the included PDF so not to break the host PDF. Alan _______________________________________________ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context
