ICC profiles for \externalfigure
Dear Luigi and Hans, I have the following sample: \setupbackend [format=PDF/A-3a, intent=sRGB IEC61966-2.1, profile={sRGB.icc,default_gray.icc}, level=0] \setuptagging[state=start] \setupcolors[cmyk=no, pagecolormodel=auto] \setupexternalfigure[location=default] \startTEXpage[offset=1em, align=center] \dontleavehmode \externalfigure[cow-black] \dontleavehmode \externalfigure[cow-brown] \dontleavehmode \externalfigure[basic-figures.pdf][scale=200] \stopTEXpage \stoptext The third external figure is found at http://pdf.ousia.tk/basic-figures.pdf. I included it, since it adds a transparency group (and I guess this might be relevant). PDF/A-3a validation (http://verapdf.org) warns about XObjects not having any ICC profile. Would it be possible to add the "profile" key to \externalfigure, so that each figure may have its own profile (or the reference to the profile) added? Many thanks for your help, Pablo -- http://www.ousia.tk
On 10/8/2017 11:09 AM, Pablo Rodriguez wrote:
Dear Luigi and Hans,
I have the following sample:
\setupbackend [format=PDF/A-3a, intent=sRGB IEC61966-2.1, profile={sRGB.icc,default_gray.icc}, level=0]
\setuptagging[state=start]
\setupcolors[cmyk=no, pagecolormodel=auto]
\setupexternalfigure[location=default]
\startTEXpage[offset=1em, align=center] \dontleavehmode \externalfigure[cow-black]
\dontleavehmode \externalfigure[cow-brown]
\dontleavehmode \externalfigure[basic-figures.pdf][scale=200] \stopTEXpage \stoptext
The third external figure is found at http://pdf.ousia.tk/basic-figures.pdf. I included it, since it adds a transparency group (and I guess this might be relevant).
PDF/A-3a validation (http://verapdf.org) warns about XObjects not having any ICC profile.
Would it be possible to add the "profile" key to \externalfigure, so that each figure may have its own profile (or the reference to the profile) added?
i looked into it and it's not going to happen (1) we don't interpret the included images (2) and even if we could mess with the either or not present resource getting the resource from someplace (main document, upstream object) is dubious and fragile too so .. fix the included images ... (bitmap images can be autoconverted into profiled ones runtime but i didn't figure out a call to whatever program for pdf yet) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 10/09/2017 08:16 PM, Hans Hagen wrote:
On 10/8/2017 11:09 AM, Pablo Rodriguez wrote:
[...] PDF/A-3a validation (http://verapdf.org) warns about XObjects not having any ICC profile.
Would it be possible to add the "profile" key to \externalfigure, so that each figure may have its own profile (or the reference to the profile) added?
i looked into it and it's not going to happen
(1) we don't interpret the included images
(2) and even if we could mess with the either or not present resource getting the resource from someplace (main document, upstream object) is dubious and fragile too
Many thanks for your reply and for analyzing the issue, Hans. I know this is a compromise solution. Of course, I cannot expect from ConTeXt to assign the right profile to the image. The user is the one that might mess the final PDF document by selecting the wrong color profile for \externalfigure. But this possibility is already there with the profile key in \setupbackend. Choosing the right profiles is up to the user. Wrong attribution causes unvalid documents, but attribution is a user task. Explaining this information in the wiki is essential to clarify that “feature”. (I can do that myself.) Having this in mind, could you reconsider the implementation of the profile key implemented for \externalfigure? Many thanks for your help, Pablo -- http://www.ousia.tk
On 10/9/2017 9:55 PM, Pablo Rodriguez wrote:
Having this in mind, could you reconsider the implementation of the profile key implemented for \externalfigure?
as said, it will not be an engine supported features as it's technically impossible without messing up the backend (and we don't want to mess up stable code with fragile hacks) if there is a command (gs, graphicmagic, ...) that can convert the image then we can add a converter directive (as we have for jpg and png) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Am 2017-10-10 um 01:02 schrieb Hans Hagen
On 10/9/2017 9:55 PM, Pablo Rodriguez wrote:
Having this in mind, could you reconsider the implementation of the profile key implemented for \externalfigure? as said, it will not be an engine supported features as it's technically impossible without messing up the backend (and we don't want to mess up stable code with fragile hacks)
if there is a command (gs, graphicmagic, ...) that can convert the image then we can add a converter directive (as we have for jpg and png)
http://www.graphicsmagick.org/GraphicsMagick.html#details-profile gm convert -profile profile.icm picture.jpg (didn’t try, on my way to Frankfurt book fair...) Greetlings, Hraban --- http://www.fiee.net http://wiki.contextgarden.net GPG Key ID 1C9B22FD
On 10/10/2017 11:27 AM, Henning Hraban Ramm wrote:
Am 2017-10-10 um 01:02 schrieb Hans Hagen:
if there is a command (gs, graphicmagic, ...) that can convert the image then we can add a converter directive (as we have for jpg and png)
http://www.graphicsmagick.org/GraphicsMagick.html#details-profile
gm convert -profile profile.icm picture.jpg (didn’t try, on my way to Frankfurt book fair...)
Many thanks for your reply, Hraban. I’m afraid that only gs adds the profile without converting the vectors to bitmaps. Enjoy the book fair, Pablo -- http://www.ousia.tk
On 10/10/2017 01:02 AM, Hans Hagen wrote:
as said, it will not be an engine supported features as it's technically impossible without messing up the backend (and we don't want to mess up stable code with fragile hacks)
Many thanks for the reply, Hans. I understand the problem now with fragile hacks. Sorry for having insisted in my proposal. I fixed the external PDF figure (http://pdf.ousia.tk/icc-vector.pdf) and I used with in the following sample: \setupbackend [format=PDF/A-3a, intent=sRGB IEC61966-2.1, profile={sRGB.icc,default_gray.icc}, level=0] \setuptagging[state=start] \setupcolors[cmyk=no, pagecolormodel=auto] \startTEXpage[offset=1em] \externalfigure[icc-vector.pdf] \stopTEXpage \stoptext http://pdf.ousia.tk/icc-vector.pdf is the same graphic as http://pdf.ousia.tk/basic-figures.pdf, but with an ICC profile. The veraPDF validator (http://verapdf.org) says it’s a valid PDF/A-1b document. But the output from the sample above (http://pdf.ousia.tk/xobject-noicc.pdf) isn’t a valid PDF/A document. The external figure has no ICC profile. The uncompressed PDF document reveals that the XObject has no reference to any ICC profile. I’m afraid this might be a bug. Many thanks for your help, Pablo -- http://www.ousia.tk
participants (3)
-
Hans Hagen -
Henning Hraban Ramm -
Pablo Rodriguez