| | <<<Back 1 day (to 2017/07/04) | 20170705 |
| etho | hi! how i make show pdf file in fullscreen? | 00:12.55 |
| avih | tor8: i think jsV_numbertointeger has UB. i think it must check against INT_MIN and INT_MAX before it returns a double as int. and it even explicitly casts inf to int, which AFAIK is explicitly UB | 10:32.15 |
| tor8 | avih: oops. that's a remnant from the spec defining the ToInteger primitive operation | 10:49.41 |
| | but everything in the spec is defined in terms of using doubles for all math (even internal integer arithmetic) | 10:49.55 |
| | and has checks for Infinity, etc, where the result is applied | 10:50.11 |
| avih | i guess except for array index? iirc that's defined in terms of INT32 (or UINT32?) | 10:50.29 |
| | re jsV_numbertointeger though, should it coerce at all cost? should it throw for out of range? | 10:52.50 |
| | re internally use doubles, well.. it has more precision and range than ints anyway, so why not? | 10:54.02 |
| defanor- | hello. i have an issue with scrolling in mupdf: i'd like to scroll bit-by-bit, and there's a down arrow key for that by default, but mupdf scrolls by a whole page if it's at the end of the page, and apparently there's no way to tell whether one is at the end -- so it essentially scrolls by an unpredictable amount of lines. is there a known workaround, or can it be fixed? | 10:59.48 |
| | the documentation also suggests that a nicer behaviour (scrolling by a constant length) can be achieved with a mouse scroll, but i can't check it atm, and heard that it doesn't work as documented | 11:01.01 |
| | (documentation = the man page) | 11:01.10 |
| tor8 | avih: relying on the common compiler behaviour for rounding out of range numbers has worked so far | 11:18.28 |
| | but you're right that we should check and clamp in the jsV_numbertointeger function | 11:18.39 |
| avih | if the compiler checks the range anyway, then it would optimize out your checks too | 11:23.38 |
| | but the more important question imo is how do you want it to behave to begin with? | 11:24.57 |
| | e.g. sometimes you use the result value of this for allocation, so int might not be big enough, and size_t would fit better, etc | 11:26.28 |
| | and if it's an array index, then it might need different behavior etc | 11:26.57 |
| tor8 | don't get me started on mixing signed and unsigned integer math. down that way lies MANY bugs. | 11:27.27 |
| | the one (only?) thing java did right was abolish unsigned integers | 11:28.04 |
| avih | if the behavior (of the spec) is defined well enough, then IMO they could be fixed one by one | 11:28.08 |
| Robin_Watts | mvrhel_laptop: Morning. You awake? | 15:31.56 |
| mvrhel_laptop | Robin_Watts: yes. :) Just saw your email | 16:20.39 |
| Robin_Watts | mvrhel_laptop: cool. | 16:21.02 |
| | right, so... | 16:21.08 |
| mvrhel_laptop | btw I am close to having a commit for the group color stuff. There are couple odd cases I am trying to track down though | 16:21.30 |
| Robin_Watts | We want to be able to feed pixmap data through lcms directly, right? | 16:22.05 |
| | i.e. we ask for a link, and then pass the scanlines data to cmsDoTransform all in one hit, right? | 16:22.28 |
| mvrhel_laptop | Yes. We would like to skip the spot colors and have the cmyk, gray, or rgb portion managed | 16:22.32 |
| | hmm all in one hit? | 16:22.44 |
| Robin_Watts | Right, so that means using the 'extra channels' for the spots. | 16:22.50 |
| | "all in one hit" = "one call to cmsDoTransform per scanline" | 16:23.02 |
| mvrhel_laptop | yes | 16:23.08 |
| | I was merging the link and the transform in you question :) | 16:23.42 |
| Robin_Watts | So, ignoring the problem with spots > 7... | 16:23.43 |
| | the link needs to be formed taking into account the number of spots. | 16:24.17 |
| | (cos that's part of the formatter specification) | 16:24.33 |
| mvrhel_laptop | Yes. | 16:25.03 |
| | I would really like to fix that but that is for another day | 16:25.16 |
| Robin_Watts | That would be a fix in lcms ? | 16:25.30 |
| mvrhel_laptop | Well, I would like to be able to have the link created using a copy command for existing links that may have a different formater but the same table | 16:26.05 |
| | The creation of the table is expensive | 16:26.19 |
| Robin_Watts | mvrhel_laptop: But that's not something that lcms can currently do. | 16:26.22 |
| mvrhel_laptop | correct | 16:26.27 |
| Robin_Watts | right. | 16:26.32 |
| mvrhel_laptop | That is something I would like to make it able to do | 16:26.33 |
| Robin_Watts | gotcha. | 16:26.39 |
| | so fz_get_icc_link is where we form the links. | 16:27.09 |
| | That doesn't know the number of spots. | 16:27.15 |
| mvrhel_laptop | yeah we are going to need to know that | 16:27.28 |
| Robin_Watts | I'm thinking I need to extend that to take the number of spots as well as the number of alpha channels. | 16:27.39 |
| | ok, that's doable. I had seen the problem, but not the solution when I started to discuss this :) | 16:28.33 |
| mvrhel_laptop | yes. I wonder if we should just merge them into an extra channels | 16:28.38 |
| | oh that wont work | 16:28.54 |
| | due to the premultiply | 16:28.57 |
| | never mind | 16:28.59 |
| | We need to know if one is an alpha | 16:29.09 |
| Robin_Watts | Do you want to email marti, or should I? | 16:29.29 |
| mvrhel_laptop | We don't need to pre or post muliiply the spots | 16:29.31 |
| Robin_Watts | He didn't answer my last email. | 16:29.41 |
| mvrhel_laptop | Robin_Watts: I can do it | 16:29.46 |
| | I will follow off of yours | 16:29.53 |
| Robin_Watts | Alpha won't change, and nor should the spots, so just getting the data left alone/passed through should be fine. | 16:30.23 |
| mvrhel_laptop | right | 16:30.31 |
| Robin_Watts | We don't use the alpha indicator to lcms do we? | 16:30.42 |
| | ah, the alpha indicator is just "extras", right. | 16:31.08 |
| mvrhel_laptop | As far as lcms is concerned yes | 16:31.25 |
| Robin_Watts | ok, I will push onwards. | 16:31.42 |
| mvrhel_laptop | We use if to know to un-alpha and re-alpha also | 16:31.51 |
| Robin_Watts | yeah. | 16:31.55 |
| mvrhel_laptop | ok. I may have a question for you later | 16:32.03 |
| | I have a weird case where I have an RGB source image and it goes fine to pam device but not to pgm | 16:32.35 |
| Robin_Watts | ok. | 16:33.19 |
| | oh, yeah, I did the cmyk halftone dithering sense fix here. | 16:33.45 |
| | and when I bmpcmp it, I get way more differences than I'd expect | 16:34.09 |
| | It's like in 50% halftones it's the other 50% that get set now. | 16:34.27 |
| | I can't explain it. | 16:34.32 |
| | Are you seeing that ? | 16:34.35 |
| | mvrhel_laptop: Currently MuPDF can cope with 32 components max. So CMYK+27 spots + alpha. | 17:01.44 |
| | I know PSD files can cope with 56 components max. | 17:02.00 |
| | Should we be considering upping that? | 17:02.11 |
| | (I'm trying to decide how far to up lcms' capabilities for 'extras') | 17:02.41 |
| ray_laptop | some people try to print color swatch pages (i.e., pantone colors) that have MANY swatches per page. Adobe PostScript had a DeviceN limit of 252 spot colors -- I don't know what Acrobat Reader has | 17:14.24 |
| Robin_Watts | lcms uses a bitfield to specify stuff. | 17:15.29 |
| ray_laptop | but the color swatch pages are usually just as useful with Alternate color | 17:15.30 |
| Robin_Watts | currently it has 9 bits free, and 3 bits reserved for "number of extra channels" | 17:15.54 |
| ray_laptop | Robin_Watts: so you are thinking about using some of the 9 bits for more channels? | 17:16.35 |
| Robin_Watts | I've currently got it set to use 5 bits instead. | 17:16.54 |
| | I am tempted to make it 6 so it can cope with the worst case PSD file. | 17:17.27 |
| ray_laptop | Ghostscript can only handle 64 channels total, currently, without some code changes | 17:17.37 |
| | so 6 bits would bring it in line with GS | 17:17.58 |
| Robin_Watts | OK, I'll use 6 bits, and I've shuffled it so that the extra bits are at the end of the word so extending it in future won't break the ABI. | 17:18.36 |
| ray_laptop | fork it up, royally ;-) | 17:19.13 |
| | Robin_Watts: FWIW, in our test suite, tests_private/comparefiles/Bug690206.pdf has 10 spot colors, and tests_private/comparefiles/Bug692961.pdf has 14, tests/pdf/PDFIA1.7_SUBSET/CATX9004.pdf has 13. The GS default limit is 14 without changing a #define | 17:25.52 |
| Robin_Watts | MuPDF is limited to 32 without changing a define. | 17:26.19 |
| | lcms as is would have us limited to CMYK+6+alpha | 17:26.39 |
| ray_laptop | mvrhel_laptop: the gs MAX_CHAN in gdevpsd.c is set to 15. Note that it gets the num_components_out from the device profile, and doesn't check if the number is > 15, so if an ICC profile has more than that, it'll corrupt the stack (tmp[MAX_CHAN] is on the stack) | 17:58.41 |
| | but if ICC profiles are limited to 15 components, that's not possible | 17:59.22 |
| Robin_Watts | ICC profiles look to be limited to 15 channels. | 18:05.21 |
| | The issue is not with that, it's with the 'extra channels' that can be carried around in blocks of data. | 18:05.38 |
| | So if we are rendering to CMYK+Spots, the ICC profile might expect to operate on CMYK, but we need lcms to pass through the spots stuff unchanged. | 18:06.17 |
| | AIUI at least. | 18:06.45 |
| | mvrhel_laptop: You here? | 18:06.48 |
| mvrhel_laptop | Robin_Watts: I am back | 18:20.15 |
| | reading logs... | 18:20.18 |
| Robin_Watts | mvrhel_laptop: Ah, cool. | 18:20.27 |
| | Don't think there is much contentious in the logs. | 18:20.38 |
| | I have a new question though... | 18:20.44 |
| mvrhel_laptop | Robin_Watts: You don't have my fixes for the group color spaces do you? So you might be seeing a lot of issues there | 18:22.10 |
| | Not sure | 18:22.15 |
| Robin_Watts | So, the plan is to have the draw device use fz_pixmaps of varying colorspaces, but all carrying the same set of spot planes (when we are spot rendering, rather than composite rendering) | 18:22.18 |
| | mvrhel_laptop: This is a conceptual problem, not a "what am I seeing" problem. | 18:22.34 |
| mvrhel_laptop | I was responding to your question above "If I was seeing that" | 18:23.06 |
| | sorry | 18:23.16 |
| Robin_Watts | oh, I see. No, my bad. | 18:23.24 |
| | That is but a minor annoyance :) | 18:23.36 |
| | So, if the PDF interpreter comes across a color in a separation color space. | 18:24.39 |
| | it'll call the draw device with a set of color values (actually just 1 value), and the colorspace. | 18:25.23 |
| mvrhel_laptop | Yes | 18:25.58 |
| Robin_Watts | I'm confused about what happens next. | 18:26.02 |
| | The draw device is supposed to say "Ah, that colorspace corresponds to spot X", so I'll do the drawing with a modified color ? | 18:26.28 |
| mvrhel_laptop | Well (ignoring overprint cases). If we are drawing in CMYK + spot color space then we draw in that spot and clear out the CMYK values | 18:26.56 |
| | i.e we will with 0 0 0 0 x | 18:27.09 |
| Robin_Watts | Right but how do we know what sot to draw in ? | 18:27.12 |
| mvrhel_laptop | fill | 18:27.14 |
| | not will | 18:27.16 |
| Robin_Watts | s/sot/spot/ | 18:27.18 |
| mvrhel_laptop | Oh you need to have a look up | 18:27.29 |
| | to know which spot you are dealing with | 18:27.37 |
| | i.e. a mapping | 18:27.45 |
| Robin_Watts | Are we guaranteed to have 1 colorspace per spot ? | 18:27.47 |
| mvrhel_laptop | from the single value to | 18:27.48 |
| | 0 0 0 0 0 x 0 | 18:27.56 |
| | for example | 18:27.57 |
| | hmm | 18:28.04 |
| Robin_Watts | i.e. should the fz_separations structure have 1 colorspace per separation ? | 18:28.25 |
| | and then I can check those each time ? | 18:28.41 |
| mvrhel_laptop | I would think if the page had 3 spots, we would need to know what position the spots map to in our color vector | 18:28.47 |
| | c,m,y,k are reserved with locations 0 1 2 3 | 18:29.08 |
| | the first spot we encounter codes to location 4 etc | 18:29.17 |
| Robin_Watts | mvrhel_laptop: Right. Having an array of colorspaces in the fz_separations structure would do that for us. | 18:29.39 |
| mvrhel_laptop | So when you encounter the first spot again in a fill command you will need a way to look it up | 18:29.42 |
| | yes | 18:29.46 |
| | hmm an array of color spaces? | 18:29.55 |
| | I would think spot names and locations would do | 18:30.04 |
| | don't you already have the spot names in the structure? | 18:30.28 |
| Robin_Watts | Ah, I do. | 18:30.44 |
| mvrhel_laptop | why can't they be in the order for the color vector? | 18:30.56 |
| Robin_Watts | The fz_separations structure has an array of names. | 18:31.17 |
| | If I can get a name from the fz_colorspace and look for a matching one, I'm sorted. | 18:31.27 |
| mvrhel_laptop | Right you will also need to worry about DeviceN cases too | 18:31.41 |
| Robin_Watts | Talk to me about DeviceN.... | 18:31.51 |
| mvrhel_laptop | So if you have spot1 and spot2 or Cyan and spot 3 | 18:31.55 |
| | you will need to map those correctly to the color vector | 18:32.04 |
| Robin_Watts | For separations, the fz_colorspace has a 'name' I can key on (I hope). | 18:32.41 |
| | What information do I get with a DeviceN ? | 18:32.47 |
| mvrhel_laptop | Essentially you want to take the fz_separations structure, the list of names in the DeviceN color space, the fill values for the deviceN color space and spit out a color vector that has CMYK+spots | 18:33.16 |
| | Robin_Watts it is like a sep color space, just with more colorants | 18:33.40 |
| | So you will have multiple names | 18:33.52 |
| Robin_Watts | OK, so currently the name for all separations is set to "Separation". | 18:34.03 |
| | That's not helpful. | 18:34.06 |
| | likewise for DeviceN I get "DeviceN". | 18:34.39 |
| | so for DeviceN I need a list of names. | 18:34.54 |
| mvrhel_laptop | Oh we dont parse the colorant names in either case yet? | 18:36.01 |
| | We must since they are going in fz_separations | 18:36.11 |
| Robin_Watts | Indeed not, as far as I can tell. | 18:36.11 |
| mvrhel_laptop | gs proof had them | 18:36.19 |
| Robin_Watts | But not from the interpreter. | 18:36.31 |
| mvrhel_laptop | oh | 18:36.51 |
| | ok | 18:36.57 |
| Robin_Watts | (or at least not from load_separation) | 18:37.02 |
| mvrhel_laptop | That makes sense. It was the device that was doing that? | 18:37.08 |
| Robin_Watts | probably, yes. | 18:37.20 |
| | ok, so I can do that. | 18:37.28 |
| mvrhel_laptop | cool | 18:37.33 |
| Robin_Watts | Do we ever have to apply ICC profiles to separations etc? | 18:37.49 |
| | Imagine I have an image in a separation space. | 18:39.05 |
| | Do those values go directly into the pixmaps, or do they get cmsDoTransformed ? | 18:39.29 |
| mvrhel_laptop | They will not get transformed | 18:42.07 |
| | gs can do such transforms but we are not going to fool with that in mupdf | 18:42.44 |
| Robin_Watts | so it's "just" a question of making sure I write the image values into the correct spots. | 18:42.44 |
| mvrhel_laptop | no one I know of has made use of it | 18:42.51 |
| | Robin_Watts: yes exactly | 18:43.00 |
| Robin_Watts | So I only ever have to call lcms on the first 'c' entries in color data, and it can ignore the next 's+a' entries. great. | 18:43.48 |
| mvrhel_laptop | Robin_Watts: yes | 18:44.04 |
| Robin_Watts | OK, so that's my work for tomorrow cut out then :) | 18:44.19 |
| mvrhel_laptop | I think I will be out tomorrow. I have to drive Ethan to Idaho for baseball early in the morning. Sending out an email now. I will be around late in the afternoon early evening my time but that will be a bit late for you | 18:45.08 |
| | We can chat friday morning my time though if you need | 18:45.22 |
| Robin_Watts | mvrhel_laptop: I hope I have enough to be getting on with. | 18:45.44 |
| mvrhel_laptop | Robin_Watts: yes it sounds like you have a perfect understanding of what needs to be done | 18:46.11 |
| Robin_Watts | I wonder if I just did something stupid... | 18:46.47 |
| | what SHA is your thirdparty/lcms2 please? | 18:46.58 |
| mvrhel_laptop | oh let me check | 18:47.37 |
| | e26bbdd3a7790cae4d9904439fdbf3c1b46b44e1 | 18:48.38 |
| Robin_Watts | ok, there are 2 commits after that now. | 18:49.57 |
| | one from you :) | 18:50.00 |
| | the other one from me. | 18:50.05 |
| mvrhel_laptop | hmm | 18:50.08 |
| Robin_Watts | http://git.ghostscript.com/?p=thirdparty-lcms2.git;a=shortlog;h=refs/heads/mupdf_changes | 18:50.11 |
| mvrhel_laptop | oh | 18:50.29 |
| | ok. I will get updated. Thanks! | 18:50.54 |
| Robin_Watts | mvrhel_laptop: I thought I'd just pushed something unexpected, but I forgot I wasn't on master. | 18:51.29 |
| | Does my change there look reasonable ? | 18:51.37 |
| mvrhel_laptop | Robin_Watts: where? | 19:05.16 |
| Robin_Watts | http://git.ghostscript.com/?p=thirdparty-lcms2.git;a=shortlog;h=refs/heads/mupdf_changes | 19:05.31 |
| | top one there. | 19:05.33 |
| | Urgh. Other than the whitespace. | 19:06.01 |
| | I'm just working on pulling in the other lcms2 changes that have happened since we forked. | 19:07.18 |
| mvrhel_laptop | Robin_Watts: Yes it looks good. Good idea to put that at the end | 19:09.17 |
| | oh cool about pulling in the other changes. Oh I need to write email to Marti | 19:09.39 |
| Robin_Watts | Wait... idaho... | 19:12.03 |
| | That's a long drive, right? | 19:12.09 |
| | google maps says 5 hours each way at least. | 19:16.04 |
| mvrhel_laptop | Robin_Watts: Yes exactly | 19:18.08 |
| | He has one game Thursday, one Friday, 2 Saturday and at least 2 Sunday | 19:18.32 |
| | So we are staying 3 night | 19:18.37 |
| | s | 19:18.39 |
| Robin_Watts | Oh, right. | 19:18.44 |
| | It sounded like "I'll be back by the evening". | 19:18.53 |
| mvrhel_laptop | no. I will be in Idaho in the hotel by then | 19:19.02 |
| | That would be a little crazy even for me | 19:19.20 |
| | Friday I should be able to work as he only has one game with chews up about 2 hours in the afternoon | 19:20.07 |
| | It was the 5 hour drive plus game tomorrow that keeps any real work from getting done tomorrow | 19:21.05 |
| | Robin_Watts: ok I sent off an email to Marti | 19:21.40 |
| | Interesting he gets fixes from Oracle... | 19:22.36 |
| | Just looking at the commits | 19:22.42 |
| | I really hope he takes what we have | 19:22.53 |
| | I don't want to have to keep merging that sort of stuff in | 19:23.06 |
| Robin_Watts | Yeah. | 19:23.24 |
| | mupdf_changes2 has the latest stuff pulled in. | 19:23.34 |
| mvrhel_laptop | awesome. Thanks Robin_Watts | 19:23.43 |
| Robin_Watts | no worries. | 19:23.48 |
| Robin_Watts | foods. | 19:24.05 |
| | Forward 1 day (to 2017/07/06)>>> | |
Log of #mupdf at irc.freenode.net.