| | <<<Back 1 day (to 2019/04/11) | 20190412 |
| i3v | @kens : | 00:00.05 |
| | > I believe you can indeed use a different profile, that's the default. You can supply a different DefaultCMYKProfile I think. | 00:00.10 |
| | Hm... Do you mean adding `-sDefaultCMYKProfile=cmyk_des_renderintent.icc` should change the output result in that experiment? | 00:00.16 |
| | I've just tried the following: | 00:00.21 |
| | > gswin64c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dHaveTransparency=false -r20 -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -sOutputFile=colorbar_cmyk1.pdf colorbar.pdf | 00:00.29 |
| | > gswin64c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dHaveTransparency=false -r20 -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -I. -sDefaultCMYKProfile=cmyk_des_renderintent.icc -sOutputFile=colorbar_cmyk2.pdf colorbar.pdf | 00:00.39 |
| | > gswin64c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dHaveTransparency=false -r20 -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -I. -sDefaultCMYKProfile=cmyk_src_renderintent.icc -sOutputFile=colorbar_cmyk3.pdf colorbar.pdf | 00:00.45 |
| | Using this pdf as an input: https://1drv.ms/b/s!Anqmq2Ex7NSPnVw3deN9weZNHvcm , source tex : https://www.overleaf.com/read/bvkfbwhqzbtp , input & output & scripts: https://1drv.ms/f/s!Anqmq2Ex7NSPnVcnWHYD9QGNzrpj . | 00:00.55 |
| | And in all 3 cases, output colors are exaclty the same on the 1st page (let's only consider the 1st page for now). | 00:01.11 |
| | It looks like, `sDefaultCMYKProfile` is meant to only affect input_CMYK->DeviceIndependent conversion. And, since the input_CMYK->DeviceIndependent->output_CMYK does not happen at all for `pdfwrite`, nothing happens. The color profile is ignored. | 00:01.30 |
| | Meanwhile, `tiff32nc` do perform the "input_CMYK->DeviceIndependent->output_CMYK" conversion. Thus the following commands produce different results: | 00:01.37 |
| | > gswin64c -dBATCH -dNOPAUSE -sDEVICE=tiff32nc -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -sOutputICCProfile=default_cmyk.icc -dRenderIntent=1 -sOutputFile=colorbar_cmyk1.tiff colorbar.pdf | 00:01.51 |
| | > gswin64c -dBATCH -dNOPAUSE -sDEVICE=tiff32nc -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -sOutputICCProfile=default_cmyk.icc -I. -sDefaultCMYKProfile=cmyk_des_renderintent.icc -dRenderIntent=1 -sOutputFile=colorbar_cmyk2.tiff colorbar.pdf | 00:01.58 |
| | > gswin64c -dBATCH -dNOPAUSE -sDEVICE=tiff32nc -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -sOutputICCProfile=default_cmyk.icc -I. -sDefaultCMYKProfile=cmyk_src_renderintent.icc -dRenderIntent=1 -sOutputFile=colorbar_cmyk3.tiff colorbar.pdf | 00:02.03 |
| | So, it looks like, after all, I cannot use a different profile here. Or, am I missing something? | 00:02.11 |
| | Finally, concerning the second page in those test pdf. It is rasterized (due to transparency), and the resulting colors look much like the `tiff32nc` output. | 00:02.23 |
| | Thus, colors are now different from the first page (while they were equal before in the input). | 00:02.29 |
| kens2 | i3v I think we've reached the point where you need to talk to Michael, not me. The colour management is his code, I can really only comment on how the pdfwrite device makes use of it; essentially where parts of it are not implemented when using pdfwrite. | 08:01.00 |
| | It would probably help if you were to explain what it is you are trying to achieve, rather than asking lots of apparently unconnected questions. | 08:01.37 |
| | As I think I explained earlier, pdfwrite generally tries to preserve everythign it can unchanged. If you specifically disable transparency preservation and then run a transparent PDF file then it has no choice but to render teh page. Rendering, unlike PDF creation, uses the rules for rendering. | 08:02.49 |
| | BTW there's absolutley no point in giing me TeX files or bash scripts, I'm runningon Windows and can't use any of those. | 08:03.51 |
| i3v | kens: | 19:44.26 |
| | > I can really only comment on how the pdfwrite device makes use of it; essentially where parts of it are not implemented when using pdfwrite. | 19:44.30 |
| | Actually, I think, this is exactly the case. My point is mainly that pdfwrite does not allow user to select output CMYK profile, for RGB->CMYK conversion. | 19:44.35 |
| | (Which was a bit surprising, provided that it is possible to specify default input profiles.) | 19:44.41 |
| | AFAIU, you've suggested to check if "-sDefaultCMYKProfile" can help. However, as demonstrated in my yesterday's experiments, this parameter does not work like that. Its value is only used as input profile. Thus, it only affects rasterized elements (that are CMYK in orig pdf), if we consider CMYK output. | 19:44.47 |
| | The tiff32nc works as expected. It allows user to select output CMYK profile via `-sOutputICCProfile`. So, I doubt this is a general color management issue. | 19:44.54 |
| | > It would probably help if you were to explain what it is you are trying to achieve, rather than asking lots of apparently unconnected questions. | 19:45.00 |
| | My purpose was to convert any input pdf to a pdf v1.3 with CMYK colors. Using "proper" color management (and a specific output icc profile), if possible. | 19:45.06 |
| | > As I think I explained earlier, pdfwrite generally tries to preserve everything it can unchanged. | 19:45.12 |
| | I understand that this is the best possible default behavior. But that's hardly apply to RGB->CMYK conversion case. | 19:45.18 |
| | > BTW there's absolutley no point in giing me TeX files or bash scripts, I'm runningon Windows and can't use any of those. | 19:45.25 |
| | OK. But scripts I've sent are ".bat", and those ".tex" is "just for reference" (cause the compiled pdf is there as well), to explain the pdf contents. | 19:45.30 |
| | Forward 1 day (to 2019/04/13)>>> | |
Log of #ghostscript at irc.freenode.net.