![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
On 10/24/2017 8:21 PM, Alan Braslau wrote:
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. we have a few workflows where we add color profiles to images before inclusion (in fact that's a built in option) but only for bitmap fonts
normally a press workflow is cmyk based and vector graphics are then made in cmyk too if someone knows the magic command (gm or gs) to add a color profile to an image i can also add a fixer for it (as we do for bitmaps) but it's always done with external tools Hans (We do have workflows where we manipulate graphics but often these are rather special and it doesn't pay off i.e customers don't want to pay for that and expect it to be, so it even pays off less to then make it into some built-in feature that we need to maintain and document and ...) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------