On 10/24/2017 8:21 PM, Alan Braslau wrote:
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.
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
-----------------------------------------------------------------
_______________________________________________
dev-context mailing list
dev-context@ntg.nl
https://mailman.ntg.nl/mailman/listinfo/dev-context
