Re: [dev-context] fix output intent subtype

On Tue, 24 Oct 2017 19:46:21 +0200 luigi scarso wrote:

On Tue, Oct 24, 2017 at 7:27 PM, Alan Braslau wrote:

...

On Tue, 24 Oct 2017 19:06:51 +0200 luigi scarso 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