| | <<<Back 1 day (to 2017/07/25) | 20170726 |
| icem | Robin_Watts, can someone let me know if the bug I submitted has been fixed? | 00:43.45 |
| | https://bugs.ghostscript.com/show_bug.cgi?id=698274 | 00:44.16 |
| | it wasn't very clear from what Andersson said... | 00:44.40 |
| | at least I didn't understand it | 00:45.37 |
| | and if it is fixed do you think someone could give me the link for the updated version? | 00:46.53 |
| | I kind of depend on it for my ebook collection.. | 00:48.42 |
| sig__ | hello? | 02:57.53 |
| | how to add javascript to a pdf file? | 02:58.11 |
| Robin_Watts | gah. what a fool. | 09:21.43 |
| | balls balls balls balls balls balls balls. | 13:06.04 |
| | My cunning plan for doing overprint won't work :( | 13:06.19 |
| | I had hoped to come up with a number, z, say, which I could pass into the plotting functions so that instead of doing | 13:07.08 |
| | d = d (+) color[k] | 13:07.18 |
| | I'd do if (k <= x || color[k]) d = d (+) color[k] | 13:07.50 |
| | and that works fine in most cases. | 13:07.58 |
| | but if you are plotting from a device N space, you can't guarantee that the components line up into non-overprint, followed by overprint. | 13:10.04 |
| | I'm going to need to pass a bitmap of which components to overprint. | 13:10.19 |
| kens | Hmmm | 13:10.44 |
| | The normalkle this is that either all the components are present in teh device, in which case you overprint, or at least one is missing in which case you don't. Am I missing something ? | 13:11.14 |
| Robin_Watts | kens: The example I have here is the altona file. It has CMYK + MyRed + MyBlue | 13:11.56 |
| | Suppose I plot a path on top of that which has a color 1,2,3,4,0,0 with OP=false,OPM=0 | 13:13.05 |
| | That's a simple matter of setting all the color components, including the zero ones. | 13:13.21 |
| kens | Yes.... | 13:13.35 |
| Robin_Watts | Damn. Bad example. Let's start again. | 13:13.44 |
| | color 1,2,0,4,0,0,0 | 13:13.54 |
| | OP = false, OPM=0 - just set all the components. | 13:14.09 |
| kens | Yes | 13:14.15 |
| Robin_Watts | OP = true, OPM=0, set components 0 to 3, 4 and 5 unchanged. | 13:14.32 |
| | OP = true, OPM=1, set componets 0,1,3 and leave the rest alone. | 13:14.57 |
| | That all works out nicely in my scheme. | 13:15.09 |
| | But if you have the colorspace as being /DeviceN [/Magenta /Key] and the color as being 1,2 | 13:15.45 |
| | or better... /DeviceN [/Magenta /MyBlue] with color 1,2 | 13:16.28 |
| kens | assumes that by /Key you mean /Black | 13:16.39 |
| Robin_Watts | oops, yes. | 13:16.50 |
| kens | Hmm, OverprintMode keeps on talking about a DeviceCMYK colour space | 13:18.11 |
| Robin_Watts | The easiest example is to look at Altona_Technical_1v1_x3.pdf | 13:18.15 |
| | and look at cell C5 | 13:18.23 |
| kens | Oh but the example uses a DeviceN | 13:18.24 |
| Robin_Watts | You can see that we overprint the K, but not the CMY, because the image is specified as being a /Separation /Black one. | 13:19.25 |
| kens | Yes that's correct. The inks specified in DeviceN overprint the others remain unchanged | 13:19.59 |
| Robin_Watts | If I did the same thing with the image being /Separation /Magenta, then I'd have to apply the "is it 0?" logic to components 0,1, and 3. | 13:20.02 |
| kens | The 'is it 0' logic opnly applies to colours specified in DeviceCMYK | 13:20.20 |
| | Not to DeviceN | 13:20.25 |
| | Overprint Mode only works with CMYK colours | 13:20.42 |
| Robin_Watts | kens: Suppose I have a duotone image, that uses a /DeviceN [/Cyan /Black] | 13:21.11 |
| kens | THen you only print Cyan and Black, all other inks are untouched | 13:21.44 |
| Robin_Watts | Exactly. | 13:21.53 |
| | And my current scheme doesn't allow for that. | 13:22.06 |
| kens | And you don't care about overprint, you can ignore it | 13:22.07 |
| | DeviceN specifies the inks exactly so you don't have to worry about the 'untouched' inks, they are untouched | 13:22.36 |
| Robin_Watts | kens: the plotting routines need to know which colors to set. | 13:22.43 |
| kens | Ah well, details of the way MuPDF rendering works, I don't know about | 13:23.15 |
| Robin_Watts | Until now, the plotting routines just set all the components according to the colors they are given. | 13:23.17 |
| | yeah, this is all implementation. | 13:23.25 |
| kens | So you need an ink% and a 'do not touch' flag or value | 13:23.43 |
| | But you need that for DeviceN regardless | 13:23.57 |
| Robin_Watts | right. The "do not touch" flag is the bitmap I am talking about. | 13:24.03 |
| kens | But how do you handle DeviceN right now ? | 13:24.17 |
| Robin_Watts | DeviceN in the absence of overprint is easy to deal with. | 13:24.33 |
| kens | You If you send, and plot, 0 for the untouched inks, you'll get the wrong answer | 13:24.34 |
| | DeviceN doesn't care baoput overprint | 13:24.44 |
| | I don't think I'm helping here :-( | 13:25.13 |
| Robin_Watts | We always hold pixmaps in chunky format. | 13:25.35 |
| | for each pixel we hold 1 byte each for the process colorants, 1 byte each for each spot, and then 1 (optional) byte for alpha | 13:26.06 |
| | So on each drawing routine the first thing we do is to 'resolve' the color into a set of values, one per component, in the same order as the pixmap. | 13:26.46 |
| | So DeviceN colors end up with a lot of zeros, and just non-zeros in the appropriate places. | 13:27.02 |
| kens | And how do you know not to plot 0 for those inks ? | 13:27.17 |
| | ie not to erase any existing colours | 13:27.33 |
| Robin_Watts | kens: When OP=false, and OPM=0, you DO set those inks. | 13:27.36 |
| | When OP=true, then you do not. | 13:27.48 |
| kens | You don't set them to 0 for DeviceN if they are not specified | 13:28.06 |
| Robin_Watts | OPM says whether to extend that same "do not" down to process inks too. | 13:28.07 |
| | kens: That's not my reading of the PDF spec. | 13:28.26 |
| kens | For DeviceN in the absence of overprint, you only set the inks you are given, untouched inks are untouched | 13:28.31 |
| Robin_Watts | kens: If that were true, then what is the point of the OP flag? :) | 13:28.50 |
| kens | Hmm, maybe I need to go reread the spec.... | 13:28.53 |
| | Overprint is used for DeviceCMYK, not for DeviceN | 13:29.07 |
| | You can get the same effect with DeviceN, but DeviceN is a level 3 feature (PostScriprt) whereas overprint is a level 1.5 /2 feature | 13:29.36 |
| | I'm going to go reaqd the spec on DeviceN | 13:30.46 |
| Robin_Watts | kens: PDF spec, not PS spec, just in case :) | 13:31.35 |
| kens | Actually, thikning about it, I'll go make a PostScript file and distill it to PDF and look | 13:31.44 |
| Robin_Watts | I have to run out for a bit. | 13:36.19 |
| kens | NP | 13:36.23 |
| Robin_Watts | I will wait for your results with interest. | 13:36.30 |
| kens | I'm really supposed to be looking at why I get a biogus with to xshow.... | 13:36.38 |
| Robin_Watts | If you get an example file, I'd love to see it. | 13:36.50 |
| | Thanks. | 13:36.53 |
| kens | Looks like my memory is faulty, GS is knocking out the untouched tints. | 13:39.00 |
| Robin_Watts | kens: phew! | 13:39.28 |
| kens | OK FWIW page 245 of the PLRM contains the key point, anbd states that overpritn does apply to DeviceN spaces. | 13:43.19 |
| kens | goes back to fonts | 13:43.28 |
| sebras | tor8: ok, so I just checked the regressions and there are no issues. | 15:23.24 |
| | all seem to be progressions. | 15:23.29 |
| mvrhel_laptop | just reading logs. yes when you draw in deviceN without over print it erases the other colorants | 15:32.09 |
| | nothing special about devicen in those cases | 15:32.23 |
| | Robin_Watts: did my email about shadings make any sense? | 15:33.04 |
| kens | Robin_Watts : may be out currently | 15:34.01 |
| mvrhel_laptop | ok thanks | 15:34.11 |
| sebras | icem: hi, I saw that you asked about 698274 | 15:39.44 |
| | icem: as I understand tor8 this means that the bug is fixed | 15:39.54 |
| icem | when can I try out the fixed version? | 15:40.15 |
| | next version? | 15:40.26 |
| sebras | icem: yes, the fix was introduced some time after 1.11. | 15:40.39 |
| Robin_Watts | mvrhel_laptop: just got back. | 15:40.42 |
| kens | tor8 did reply on the bug .... | 15:40.43 |
| sebras | icem: and the next version seems to be planned for 1.12 | 15:40.47 |
| icem | ok thanks | 15:40.47 |
| | ah cool | 15:40.52 |
| | I'll be waiting | 15:40.55 |
| Robin_Watts | yes, it kinda made sense, but even so, I can't see why we're getting the results we are. | 15:41.02 |
| sebras | kens: I know, but icem was confused by the answer. if it helps to repeat it, and it is this easy I'm happy to do so a few times. :) | 15:41.20 |
| Robin_Watts | I *think* I tried changing to the ALTERNATIVE_SPOT_MAPPING code, and I got no improvement. | 15:41.20 |
| mvrhel_laptop | oh | 15:41.50 |
| | that would be odd | 15:41.53 |
| | that should map each individual pixel | 15:42.04 |
| Robin_Watts | icem, as tor8 said on the bug, it's in the git repo - if you clone and build, then you'll get the fixed version now. | 15:42.05 |
| mvrhel_laptop | let me try that | 15:42.06 |
| icem | ok thanks | 15:42.20 |
| Robin_Watts | mvrhel_laptop: brb. | 15:43.17 |
| mvrhel_laptop | oh looks like a bug in ALTERNATIVE_SPOT_MAP | 15:44.06 |
| | it should do a straight up conversion to device color. no need to look through and add up the dc components | 15:45.13 |
| | s/look/loop | 15:45.19 |
| | oh and loop on line 600 has a bug | 15:46.15 |
| | let me fix this up quick | 15:46.23 |
| | ok that fixed it | 15:51.37 |
| | looks pretty good | 15:51.46 |
| | png looks good anyway... psd is hosed a bit | 15:53.49 |
| | oh let me do something.... | 15:55.00 |
| | ok now they both work | 15:58.33 |
| | let me push this | 15:58.40 |
| | and you can review | 15:58.50 |
| sebras | Robin_Watts: may I bother you with a quick review of sebras/master? | 16:00.03 |
| | Robin_Watts: tor8 all but LGTM:ed before me verifying all the progressions and him logging out. I'd like to get this in as it fixes my customer bug. :) | 16:00.39 |
| mvrhel_laptop | Robin_Watts: ok pushed for you to have a look | 16:07.37 |
| sebras | Robin_Watts: oh, and I will take 'get lost, I'm doing spot colors' for an answer. ;) | 16:07.51 |
| mvrhel_laptop | That renders correctly for RGB and CMYK output | 16:07.54 |
| Robin_Watts | back. | 16:10.08 |
| | mvrhel_laptop: Thanks. I'll have a quick look at sebras thing and then pull that in. | 16:10.29 |
| | sebras: while (allowed) has become while (*allowed) | 16:11.45 |
| | I see, ok. | 16:12.41 |
| | lgtm then. | 16:13.36 |
| | mvrhel_laptop: urm... really? | 16:17.35 |
| | dd[j] = fz_clampi(255 * convert[j], 0, 255); | 16:17.51 |
| | That can't be right, surely. | 16:18.00 |
| sebras | Robin_Watts: thanks. | 16:18.10 |
| Robin_Watts | Suppose I have 2 spots, pink and mauve. | 16:18.28 |
| | the destination color should be some sum of contributions of the two. | 16:19.12 |
| | dd[j] = fz_clampi(dd[j] + 255*convert[j], 0, 255) or something ? | 16:19.58 |
| mvrhel_laptop | Robin_Watts: the conversion already converts it to RGB | 16:21.24 |
| Robin_Watts | mvrhel_laptop: That's not the point. | 16:21.35 |
| mvrhel_laptop | huh | 16:22.18 |
| Robin_Watts | If I have two spots X and Y, and I convert both of them down, then dd[0] needs to be a combination of something from X and something from Y. | 16:22.19 |
| | or I am more confused than usual? | 16:22.51 |
| mvrhel_laptop | Robin_Watts: so I have a source color space that say is two spots | 16:23.15 |
| | and a destination space that is RGB | 16:23.19 |
| Robin_Watts | yes. | 16:23.29 |
| mvrhel_laptop | the color converter will do the conversion from those two spots to RGB | 16:23.42 |
| Robin_Watts | actually, can we modify that ? | 16:23.46 |
| mvrhel_laptop | you are done | 16:23.51 |
| Robin_Watts | let me check the patch again. | 16:24.01 |
| | Oh!!!! | 16:24.27 |
| | I see now, sorry. | 16:24.49 |
| mvrhel_laptop | no problem | 16:25.58 |
| Robin_Watts | Thanks for sorting that. | 16:26.51 |
| | I dunno if you read the logs earlier, but my attempt at overprint ran into an unexpected problem. | 16:27.12 |
| mvrhel_laptop | I did read that | 16:27.18 |
| Robin_Watts | I know what to do now, so I'll fix that next. | 16:27.35 |
| mvrhel_laptop | I thought a bit about it last night and I can't think of a way to avoid not having a mask | 16:27.39 |
| | bit for each colorant | 16:28.11 |
| Robin_Watts | OK, I've updated robin/spots with the latest of everything. Just ignore the last commit :) | 16:28.52 |
| mvrhel_laptop | Robin_Watts: Did you happen to fix the DeviceN issue with the colorant names? | 16:28.53 |
| Robin_Watts | I did not. | 16:28.58 |
| mvrhel_laptop | ok. So what do you think of always taking the second entry of the DeviceN dict for the list of names | 16:29.22 |
| Robin_Watts | Urm, bear with me.... | 16:30.09 |
| | we pass through the resources looking for separation spaces. | 16:30.22 |
| | If we find them that gives us separation colorspaces, from which we can get equivalent colors. | 16:30.54 |
| | Then we pass through again, looking for devicen. | 16:31.03 |
| | some of the separations in devicen MAY be references to those separations. | 16:31.20 |
| | some of them may not be. | 16:31.28 |
| mvrhel_laptop | so it is possible we could have a separation space with PantoneX name | 16:32.28 |
| Robin_Watts | In the case where we find a named thingy in the DeviceN dict on the second pass for which we don't have a separation already, we should add that as a new separation, | 16:32.33 |
| mvrhel_laptop | and a DeviceN color spacd with PantoneX and PantoneY | 16:32.45 |
| Robin_Watts | does that sound reasonable? | 16:32.45 |
| mvrhel_laptop | is that what you mean? | 16:32.49 |
| Robin_Watts | yeah. | 16:32.52 |
| mvrhel_laptop | Robin_Watts: yes, we need to check against our already existing set of names | 16:33.31 |
| | we should always do that | 16:33.38 |
| Robin_Watts | I think this is exactly why I thought we need to have 2 passes, and I just failed to actually do anything useful in the second pass :( | 16:33.52 |
| mvrhel_laptop | we could have a case where we have the same name twice in different sep spaces | 16:33.54 |
| Robin_Watts | can we? | 16:34.05 |
| mvrhel_laptop | and we don't want to add it | 16:34.06 |
| | twice | 16:34.11 |
| | we could | 16:34.13 |
| | there is nothing that says we can't | 16:34.21 |
| Robin_Watts | oh, we can encounter the same separation twice during the traversal, but we only want to add it once, sure. | 16:34.36 |
| mvrhel_laptop | no | 16:34.40 |
| | this is different | 16:34.45 |
| Robin_Watts | If we encounter two different separations with the SAME name, that's illegal, but it could happen. | 16:34.57 |
| | so we should just take the first one, I reckon. | 16:35.08 |
| mvrhel_laptop | how is it illegal | 16:35.12 |
| Robin_Watts | The spec says so, doesn't it ? | 16:35.19 |
| mvrhel_laptop | bear with me | 16:35.21 |
| Robin_Watts | I thought separation names for a given page were supposed to be unique. | 16:35.44 |
| | otherwise, how can things like DeviceN which refer to separations by name work? | 16:36.05 |
| mvrhel_laptop | I am saying I could have color space object 15 0 | 16:36.36 |
| | which is a separation color space | 16:36.44 |
| | with a name of PantoneX | 16:36.50 |
| | I could also have a color space object 10 0 | 16:36.58 |
| | which is a separation color space with a name of PantoneX | 16:37.07 |
| | they are the same colorant | 16:37.16 |
| | and should be treated the same | 16:37.27 |
| Robin_Watts | right. | 16:37.33 |
| mvrhel_laptop | but I fear we might add the colorant twice | 16:37.38 |
| | in what we have here today | 16:37.46 |
| Robin_Watts | No, we specifically check for it existing already. | 16:37.58 |
| | cos I got that wrong originally :) | 16:38.06 |
| mvrhel_laptop | ok. Then I am confused with why devicen is an issue | 16:38.24 |
| | I look for the sep color spaces, add the colorants. I look for devicen color spaces and add the colorants | 16:38.44 |
| Robin_Watts | Suppose we have a file that has a /Separation /Orange | 16:39.13 |
| | and then later on has a /DeviceN [/Orange /Black] | 16:39.30 |
| mvrhel_laptop | yes | 16:39.37 |
| Robin_Watts | I was working on the idea that we'd rather have the separation /Orange be listed in our fz_colorspaces with the colorspace corresponding to the separation, rather than corresponding to the 0th channel of the DeviceN colorspace. | 16:40.24 |
| | Imagine if we have the same file that had /DeviceN [/Orange /Black] and then later on /Separation /Orange | 16:41.05 |
| | I'd like the fz_separations structure we get from those 2 files to be the same. | 16:41.40 |
| | when I want to calculate equivalent colors for an /Orange entry, I'd like to be doing it using the tint transform defined in the /Separation space, not the one defined in the /DeviceN space. | 16:42.13 |
| | am I making any sense at all? | 16:42.31 |
| mvrhel_laptop | I understand sort of. I would hope that DeviceN with values 1,0 would be the same as the Sep Orange with value 1 | 16:43.36 |
| | If not, then the file is crap | 16:43.54 |
| Robin_Watts | mvrhel_laptop: I would *hope* so, but intrinsically, it seems neater to use the simpler function than the more complex one. | 16:44.13 |
| mvrhel_laptop | yes I agree | 16:44.21 |
| Robin_Watts | maybe I'm being overly cautious. | 16:44.31 |
| mvrhel_laptop | So, lets get back to my original question | 16:45.02 |
| Robin_Watts | but certainly, I agree that we should run through the DeviceN list and add them if they aren't there already. | 16:45.03 |
| mvrhel_laptop | ok | 16:45.09 |
| | as I don't see how we are doing that now | 16:45.29 |
| Robin_Watts | Indeed. We are not. Because I evidently had a brain fart while writing that code | 16:45.54 |
| mvrhel_laptop | ok. just checking | 16:46.09 |
| Robin_Watts | If you want to fix that, that'd be great. | 16:46.22 |
| mvrhel_laptop | one last question | 16:46.22 |
| | I will take care of | 16:46.28 |
| | it | 16:46.30 |
| | If I have a file with a single sep color space and the color name is cyan I think we have an issue | 16:47.07 |
| Robin_Watts | ok... | 16:47.38 |
| mvrhel_laptop | I will dig a bit more on that too | 16:47.52 |
| Robin_Watts | what do you think is not happening that should be? | 16:48.06 |
| mvrhel_laptop | hold on let me run my test file through real quick. give me a moment | 16:48.26 |
| Robin_Watts | sure. | 16:48.31 |
| mvrhel_laptop | ok | 16:50.51 |
| | so here is the issue | 16:50.54 |
| | in resolve_color | 16:51.15 |
| | lin 347 | 16:51.19 |
| | else if (fz_colorspace_is_device_n(ctx, colorspace) && dest->seps) | 16:51.25 |
| | in this case, the colorspace is devicen (it was a sep space with name Cyan) | 16:51.45 |
| | but dest->seps is zero since it was Cyan | 16:51.54 |
| Robin_Watts | ok. | 16:51.58 |
| mvrhel_laptop | so it goes through the alternate tint transform | 16:52.05 |
| | which maps to RGB | 16:52.08 |
| | :) | 16:52.10 |
| Robin_Watts | which maps to the base colorspace. | 16:52.23 |
| mvrhel_laptop | we need to have some special logic as we don't want that to happen | 16:52.40 |
| Robin_Watts | dest->seps is not zero. | 16:52.49 |
| | dest->seps might be NULL, but it's not zero. | 16:52.57 |
| mvrhel_laptop | ok yes NULL | 16:53.03 |
| Robin_Watts | Walk me through this again... | 16:53.48 |
| mvrhel_laptop | Ok sorry | 16:53.52 |
| Robin_Watts | we call fz_page_separations and we get a structure back with what in it? | 16:53.59 |
| | No spots, or a single spot called 'Cyan' ? | 16:54.15 |
| mvrhel_laptop | So the source file has a single separation color space | 16:54.28 |
| | it has a colorant named Cyan | 16:54.34 |
| | So in the scan page for separations we get NULL | 16:55.38 |
| Robin_Watts | right. so when we call fz_page_separations, is that listed as a colorant, or do we suppress that because it's one of the special ones? (Genuine question, I don't know what the current code does, and I don't know WHAT it should do) | 16:55.44 |
| | OK, so the current code is not listing it. | 16:56.01 |
| mvrhel_laptop | we suppress it | 16:56.03 |
| | as its "special" | 16:56.08 |
| | And it is special | 16:56.18 |
| | as it is already support | 16:56.24 |
| Robin_Watts | So you then call the draw_device with an RGB pixmap and pix->seps == NULL. | 16:56.43 |
| mvrhel_laptop | no the pixmap is CMYK | 16:56.57 |
| Robin_Watts | oh, ok. | 16:57.09 |
| | so you call the draw_device with a CMYK pixmap, and pix->seps = NULL. | 16:57.24 |
| | which means give me a non-overprint correct rendering. | 16:57.43 |
| mvrhel_laptop | So now in resolve color | 16:58.32 |
| Robin_Watts | So then in resolve_color, line 347 we end up in the tint transform stuff. | 16:58.41 |
| mvrhel_laptop | Yes and the separation color space has as its base space RGB | 16:58.58 |
| Robin_Watts | Ah, right. | 16:59.12 |
| mvrhel_laptop | That was in the PDF source file | 16:59.13 |
| Robin_Watts | I follow. | 16:59.20 |
| mvrhel_laptop | It says if you don't know what to do with Cyan try RGB... | 16:59.29 |
| Robin_Watts | so I see various problems along the way, the last one of which is the one you started with. | 16:59.46 |
| mvrhel_laptop | So someplace we need to have some special logic for the process colorants of CMYK | 17:00.24 |
| Robin_Watts | Yeah. | 17:00.33 |
| | Arguably they should be listed in the initial fz_separations structure we get back for the page. | 17:00.48 |
| | and dropped from the separations structure that we actually render with. | 17:01.20 |
| | I suspect that the draw_device should have a specific option for "enable overprint simulation" rather than just looking at pix->seps or not to allow for this. | 17:03.52 |
| mvrhel_laptop | Robin_Watts: you have a pretty good idea of how you want the fz_separations structure to work. It is probably best for you to solve this one. I just wanted to paint the issue | 17:03.55 |
| Robin_Watts | mvrhel_laptop: I think you are right that it will need a fix in resolve_color. | 17:04.11 |
| mvrhel_laptop | If you want me to try to fix it there I can | 17:04.33 |
| Robin_Watts | I'm just thinking that if I ask "what separations are present on that page", I really ought to get Cyan listed, don't you think? | 17:04.41 |
| mvrhel_laptop | No | 17:05.01 |
| | I don't think so | 17:05.06 |
| Robin_Watts | ha! | 17:05.10 |
| mvrhel_laptop | Here is one reason why | 17:05.32 |
| | Imagine if I have a sep cyan color space | 17:05.55 |
| | and I also have transparency now | 17:06.22 |
| | And lets say the group color space is RGB | 17:07.34 |
| | In that case, we should be using the alternate tint transform and not carry around RGB+Cyan | 17:08.03 |
| | I worry that if we claim to have sep that is Cyan it would confuse the above case | 17:08.36 |
| | This only happens for Cyan, Magenta, Yellow and Black. | 17:09.09 |
| | If we had a spot that was PantoneX we would carry around RGB+PantoneX | 17:09.26 |
| | in the transparency | 17:09.36 |
| Robin_Watts | Hmm. | 17:10.38 |
| mvrhel_laptop | So if the destination color space for is CMYK, and the separation or deviceN color space has names that are only Cyan, Magenta Yellow or Black, we should not do the the alternate tint but map correctly to CMYK | 17:11.14 |
| | That is the special logic we need to add in resolve_color | 17:11.37 |
| Robin_Watts | When we ask "give me a list of the separations for this page", we are asking "what are the controllable set of separations on this page". | 17:11.45 |
| | i.e the set of separations that are present at source time in the page. | 17:12.19 |
| | cos we want to be able to enable/disable them in the rendering, right? | 17:12.39 |
| | hence when I ask "fz_page_separations", I expect to be told "Cyan exists there". | 17:13.44 |
| | We should have an understanding that Cyan/Magenta/Yellow/Black are special and won't be rendered. | 17:14.14 |
| | or maybe we can't really expect Cyan to be controlled.... | 17:14.55 |
| | OK, so I'll fold. | 17:15.07 |
| | Cyan shouldn't be listed in the fz_separations structure, and indeed it is not currently, so we're good there. | 17:15.34 |
| | So the problem is 'just' in resolve_color now ? | 17:15.48 |
| mvrhel_laptop | that is my thought | 17:15.54 |
| Robin_Watts | cool. | 17:16.00 |
| | and you have an idea of how to solve this? | 17:16.07 |
| mvrhel_laptop | Not immediately, but I will think a bit about it today | 17:16.42 |
| Robin_Watts | ok. | 17:17.09 |
| mvrhel_laptop | Have to run Ethan to bus. bbiab | 17:17.39 |
| | Robin_Watts: quick question for you | 18:36.43 |
| Robin_Watts | go for it. | 18:37.12 |
| mvrhel_laptop | what would you think of extending the is_device_n setting in fz_colorspace_s | 18:37.16 |
| | I would like it to be 0 if it is not devicen | 18:37.26 |
| | 1 if it is devicen but no cmyk colorants | 18:37.33 |
| | and something else if it is devicen and has cmyk colorants | 18:37.45 |
| | this way we have that information set at initialization | 18:38.03 |
| | and I can use it repeatedly later | 18:38.10 |
| | in deciding if we should use the alternate tint or not | 18:38.22 |
| Robin_Watts | rename it to be device_n_flags ? | 18:38.37 |
| mvrhel_laptop | that would be good | 18:38.43 |
| | then I can make an enum for the values | 18:39.00 |
| Robin_Watts | or just device_n | 18:39.04 |
| mvrhel_laptop | yes device_n | 18:39.12 |
| Robin_Watts | flags implies bitflags, and it's not that. | 18:39.13 |
| | so device_n sounds good. | 18:39.17 |
| mvrhel_laptop | right its not that | 18:39.19 |
| | ok | 18:39.21 |
| | thanks | 18:39.24 |
| | Forward 1 day (to 2017/07/27)>>> | |
Log of #mupdf at irc.freenode.net.