Log of #mupdf at irc.freenode.net.

 <<<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 
  it wasn't very clear from what Andersson said...00:44.40 
  at least I didn't understand it00: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 doing13: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 Hmmm13: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 + MyBlue13: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=013: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,013:13.54 
  OP = false, OPM=0 - just set all the components.13:14.09 
kens Yes13: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,213:15.45 
  or better... /DeviceN [/Magenta /MyBlue] with color 1,213:16.28 
kens assumes that by /Key you mean /Black13:16.39 
Robin_Watts oops, yes.13:16.50 
kens Hmm, OverprintMode keeps on talking about a DeviceCMYK colour space13:18.11 
Robin_Watts The easiest example is to look at Altona_Technical_1v1_x3.pdf13:18.15 
  and look at cell C513:18.23 
kens Oh but the example uses a DeviceN13: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 unchanged13: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 DeviceCMYK13:20.20 
  Not to DeviceN13:20.25 
  Overprint Mode only works with CMYK colours13: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 untouched13: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 it13:22.07 
  DeviceN specifies the inks exactly so you don't have to worry about the 'untouched' inks, they are untouched13: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 about13: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 value13:23.43 
  But you need that for DeviceN regardless13: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 answer13:24.34 
  DeviceN doesn't care baoput overprint13: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 alpha13: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 colours13: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 specified13: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 untouched13: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 DeviceN13: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 feature13:29.36 
  I'm going to go reaqd the spec on DeviceN13: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 look13:31.44 
Robin_Watts I have to run out for a bit.13:36.19 
kens NP13: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 
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 fonts13: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 colorants15:32.09 
  nothing special about devicen in those cases15:32.23 
  Robin_Watts: did my email about shadings make any sense?15:33.04 
kens Robin_Watts : may be out currently15:34.01 
mvrhel_laptop ok thanks15:34.11 
sebras icem: hi, I saw that you asked about 69827415:39.44 
  icem: as I understand tor8 this means that the bug is fixed15: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.1215:40.47 
icem ok thanks15:40.47 
  ah cool15:40.52 
  I'll be waiting15: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 oh15:41.50 
  that would be odd15:41.53 
  that should map each individual pixel15: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 that15:42.06 
icem ok thanks15:42.20 
Robin_Watts mvrhel_laptop: brb.15:43.17 
mvrhel_laptop oh looks like a bug in ALTERNATIVE_SPOT_MAP15:44.06 
  it should do a straight up conversion to device color. no need to look through and add up the dc components15:45.13 
  oh and loop on line 600 has a bug15:46.15 
  let me fix this up quick15:46.23 
  ok that fixed it15:51.37 
  looks pretty good15:51.46 
  png looks good anyway... psd is hosed a bit15:53.49 
  oh let me do something....15:55.00 
  ok now they both work15:58.33 
  let me push this15:58.40 
  and you can review15: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 look16: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 output16: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 RGB16:21.24 
Robin_Watts mvrhel_laptop: That's not the point.16:21.35 
mvrhel_laptop huh16: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 spots16:23.15 
  and a destination space that is RGB16:23.19 
Robin_Watts yes.16:23.29 
mvrhel_laptop the color converter will do the conversion from those two spots to RGB16:23.42 
Robin_Watts actually, can we modify that ?16:23.46 
mvrhel_laptop you are done16:23.51 
Robin_Watts let me check the patch again.16:24.01 
  I see now, sorry.16:24.49 
mvrhel_laptop no problem16: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 that16: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 mask16:27.39 
  bit for each colorant16: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 names16: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 name16: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 PantoneY16: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 names16:33.31 
  we should always do that16: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 spaces16:33.54 
Robin_Watts can we?16:34.05 
mvrhel_laptop and we don't want to add it16:34.06 
  we could16:34.13 
  there is nothing that says we can't16: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 no16:34.40 
  this is different16: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 illegal16:35.12 
Robin_Watts The spec says so, doesn't it ?16:35.19 
mvrhel_laptop bear with me16: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 016:36.36 
  which is a separation color space16:36.44 
  with a name of PantoneX16:36.50 
  I could also have a color space object 10 016:36.58 
  which is a separation color space with a name of PantoneX16:37.07 
  they are the same colorant16:37.16 
  and should be treated the same16:37.27 
Robin_Watts right.16:37.33 
mvrhel_laptop but I fear we might add the colorant twice16:37.38 
  in what we have here today16: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 issue16:38.24 
  I look for the sep color spaces, add the colorants. I look for devicen color spaces and add the colorants16:38.44 
Robin_Watts Suppose we have a file that has a /Separation /Orange16:39.13 
  and then later on has a /DeviceN [/Orange /Black]16:39.30 
mvrhel_laptop yes16: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 /Orange16: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 116:43.36 
  If not, then the file is crap16: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 agree16:44.21 
Robin_Watts maybe I'm being overly cautious.16:44.31 
mvrhel_laptop So, lets get back to my original question16: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 ok16:45.09 
  as I don't see how we are doing that now16:45.29 
Robin_Watts Indeed. We are not. Because I evidently had a brain fart while writing that code16:45.54 
mvrhel_laptop ok. just checking16:46.09 
Robin_Watts If you want to fix that, that'd be great.16:46.22 
mvrhel_laptop one last question16:46.22 
  I will take care of16:46.28 
  If I have a file with a single sep color space and the color name is cyan I think we have an issue16:47.07 
Robin_Watts ok...16:47.38 
mvrhel_laptop I will dig a bit more on that too16: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 moment16:48.26 
Robin_Watts sure.16:48.31 
mvrhel_laptop ok16:50.51 
  so here is the issue16:50.54 
  in resolve_color16:51.15 
  lin 34716: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 Cyan16:51.54 
Robin_Watts ok.16:51.58 
mvrhel_laptop so it goes through the alternate tint transform16:52.05 
  which maps to RGB16:52.08 
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 happen16: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 NULL16:53.03 
Robin_Watts Walk me through this again...16:53.48 
mvrhel_laptop Ok sorry16: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 space16:54.28 
  it has a colorant named Cyan16:54.34 
  So in the scan page for separations we get NULL16: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 it16:56.03 
  as its "special"16:56.08 
  And it is special16:56.18 
  as it is already support16: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 CMYK16: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 color16: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 RGB16:58.58 
Robin_Watts Ah, right.16:59.12 
mvrhel_laptop That was in the PDF source file16: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 CMYK17: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 issue17: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 can17: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 No17:05.01 
  I don't think so17:05.06 
Robin_Watts ha!17:05.10 
mvrhel_laptop Here is one reason why17:05.32 
  Imagine if I have a sep cyan color space17:05.55 
  and I also have transparency now17:06.22 
  And lets say the group color space is RGB17:07.34 
  In that case, we should be using the alternate tint transform and not carry around RGB+Cyan17:08.03 
  I worry that if we claim to have sep that is Cyan it would confuse the above case17: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+PantoneX17:09.26 
  in the transparency17: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 CMYK17:11.14 
  That is the special logic we need to add in resolve_color17: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 thought17: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 today17:16.42 
Robin_Watts ok.17:17.09 
mvrhel_laptop Have to run Ethan to bus. bbiab17:17.39 
  Robin_Watts: quick question for you18: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_s18:37.16 
  I would like it to be 0 if it is not devicen18:37.26 
  1 if it is devicen but no cmyk colorants18:37.33 
  and something else if it is devicen and has cmyk colorants18:37.45 
  this way we have that information set at initialization18:38.03 
  and I can use it repeatedly later18:38.10 
  in deciding if we should use the alternate tint or not18:38.22 
Robin_Watts rename it to be device_n_flags ?18:38.37 
mvrhel_laptop that would be good18:38.43 
  then I can make an enum for the values18:39.00 
Robin_Watts or just device_n18:39.04 
mvrhel_laptop yes device_n18: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 that18:39.19 
ghostscript.com #ghostscript