On 6/16/25 01:35, jbf wrote:
Thanks Pablo,
I can confirm that intent=CoatedFOGRA.icc does not work but that intent={Coated FOGRA39 (ISO 12647-2:2004)} does work, or to put it another way, the log file says profile specification 'Coated FOGRA39 (ISO 12647-2:2004)' loaded....from colorprofiles.xml.
Sorry for not having replied before, Julian.
Of course, I am still unsure why the next line in the log says 'omitting reference to profile for intent 'Coated FOGRA39 (ISO 12647-2:2004)' given that it has already told me it was loaded.
I tried to describe that (from what I saw when briefly inspecting the code from the generated PDF document). I will try to describe it again: The most obvious (missing) thing is the lack of the embedded profile (file `Coated_Fogra39L_VIGC_300.icc`). Since I was able to replicate that error and then I fixed it (landing `Coated_Fogra39L_VIGC_300.icc` embedded in the PDF document), I think your distribution isn’t being capable to find that file. But I haven’t tested whether the omission also failed to include other info (such as [so to speak] relevant tags) in a way that your printers may have problems to print your PDF documents.
My texmf-local is directly under /tex, not under /texmf
Sorry for taking that for granted. Standalone comes with `~/tex/texmf-local`. But one may create another `~/texmf/texmf-local/` (and for fonts with `~/texmf/texmf-fonts`). Which is the gain of that? If you have three different standalones on your user, such as `$HOME/production-context`, `$HOME/latest-context` and `$HOME/older-context`, the way to have a common `texmf-local` or `texmf-fonts` is under `$HOME/texmf/`. I hope it is clearer now. Of course, nothing prevents you from using `texmf-local` from each standalone, but I think the other approach may be more convenient.
[...] I have moved the *icc file into texmf.local successfully enough. I ran the link command and then the erase cache and generate commands.
If the link is working, I don’t know what is (or what I’m) missing here. But since this worked for me, I have the impression that your standalone is having issues to find the .icc file.
But if my printers are happy to make their own adjustments, then I presume I need do no more. And much like yourself, I now have other pressing demands and will have to leave the matter rest for now.
I apologize for that, I realized now that my previous looks like I’m blaming you for wasting my time. If that were the case (which wasn’t), I’m the only one responsible for wasting my time. What I should have described clearly is how I deal when replying to others who share issues they may have with ConTeXt. [Julian, what comes next is written in general, not specially related to this thread. Please, don’t read it as personally directed to you, because it isn’t at all.] My three main steps are: 1. Find out what is the experienced issue at stake. 2. Try to analyze what is going on with the issue. 3. Either compose a reply with a solution or try report the issue as a potential bug. As for 2 and 3, it is pretty straightforward to know whether I can do it or not. With 1, when the user gives no sample, everything is guesswork (at least, in my case). A sample given by the user makes testing much faster (and also the finding of an issue or a highly probable solution). [Back to you again, Julian.] With your case, I was concerned since it wasn’t clear to me that the code you might be getting wouldn’t end up being problematic for your printers (and in the end leading to money loss [no matter how big]). I also had the impression that you might be thinking that things were better than (I thought, probably) they really were. Of course, I wanted your files and profiles to go well, but I couldn’t even write that they weren’t consistent with what ConTeXt was supposed to output. In any case, I hope everything went well with the documents. Pablo