| | <<<Back 1 day (to 2018/07/05) | 20180706 |
| ray_laptop | mvrhel_laptop: it's less noisy here :-) | 16:11.25 |
| mvrhel_laptop | ray_laptop: I am easy | 16:11.39 |
| ray_laptop | the issue is that I have a pattern-clist that is doing an image with a softmask, and it builds an ICC table which it writes to it's (memfile) pattern-clist. All good | 16:12.32 |
| mvrhel_laptop | ICC table? | 16:13.39 |
| | oh you mean the clist entries | 16:15.25 |
| ray_laptop | but then when the pattern-clist is being played back to the underlying device c_pdf14trans_write gets PDF14_BEGIN_TRANS_MASK does gsicc_read_serial_icc to get the iccprofile (which only reads the header part) | 16:15.26 |
| mvrhel_laptop | wait | 16:16.09 |
| ray_laptop | then line 7257 calls gsicc_get_profile_handle_clist to "load the rest of the profile buffer" | 16:16.17 |
| mvrhel_laptop | c_pdf14trans_write is happening during the clist read? | 16:16.19 |
| ray_laptop | the pattern-clist is being read, then the "main" device clist is being written | 16:16.50 |
| mvrhel_laptop | ok just trying to keep track of where we are with respect to who is reading and who is writing | 16:17.24 |
| ray_laptop | so the iccprofile is loaded from the pattern-clist (all works fine) | 16:17.48 |
| | but gsicc_get_profile_handle_clist returns the profile_handle, and throws away the buffer | 16:19.05 |
| mvrhel_laptop | what do you mean "throws away"? | 16:19.38 |
| ray_laptop | after it gets the profile using gscms_get_profile_handle_mem | 16:19.41 |
| | gsicc_manage.c line 2502 | 16:20.10 |
| mvrhel_laptop | oh ok. yes | 16:20.20 |
| | it allocates | 16:20.26 |
| | and frees | 16:20.29 |
| | it does not need the buffer any longer | 16:20.36 |
| | it has the handle from lcms I think at this point | 16:20.50 |
| | yes in profile_handle | 16:21.09 |
| ray_laptop | so the profile written in gdevp14.c line 6028 is ONLY the header | 16:21.33 |
| mvrhel_laptop | ray_laptop: hold on. can we continue in like 5 minutes. | 16:22.01 |
| ray_laptop | sure. | 16:22.08 |
| mvrhel_laptop | ok. brb | 16:22.11 |
| ray_laptop | oh, and line 7257 threw away the profile_handle (dummy) | 16:25.33 |
| mvrhel_laptop | ok I am back now | 16:34.08 |
| ray_laptop | mvrhel_laptop: ok. So the problem is that the profile_handle gets discarded (I think) | 16:35.21 |
| | and this is why "how did this ever work" occurs tome | 16:35.43 |
| mvrhel_laptop | ray_laptop: ok so lets back up | 16:36.05 |
| | trying to follow you | 16:36.15 |
| ray_laptop | np | 16:36.21 |
| mvrhel_laptop | So we are in PDF14_BEGIN_TRANS_MASK | 16:36.30 |
| | case in | 16:36.42 |
| | pdf14_clist_create_compositor | 16:36.44 |
| ray_laptop | specifically PDF14_BEGIN_TRANS_MASK case in c_pdf14trans_write | 16:37.24 |
| mvrhel_laptop | uh | 16:37.40 |
| | line 7257 is in pdf14_clist_create_compositor | 16:37.56 |
| | or am I missing something | 16:38.29 |
| | how are we in c_pdf14trans_write | 16:38.42 |
| ray_laptop | we are READING the pattern-clist, which in pdf14_clist_create_compositor, and WRITING that compositor action into the main clist (line 7324) | 16:40.19 |
| | so we get to c_pdf14trans_write from line 7324 through clist_create_compositor gxclimag.c line1268 | 16:42.28 |
| mvrhel_laptop | hmm so what is it that we are trying to accomplish. Is there an ICC profile in the pattern clist that needs to get written into the main clist? | 16:44.01 |
| ray_laptop | mvrhel_laptop: this all happens because the pattern-clist playback is happening (via tile_by_steps) during the writing of the main clist. This is unusual | 16:44.04 |
| | mvrhel_laptop: yes. we need to make sure that the clist_icc_addentry call from line 6028 has a VALID profile_handle to write into its icctable | 16:45.18 |
| mvrhel_laptop | I have to admit I am a little puzzled by what I see from lines 7256-7261 | 16:45.25 |
| | The handle should not be written into the table | 16:45.50 |
| | That would be wrong | 16:46.10 |
| | Only the ICC buffer data is written | 16:46.20 |
| ray_laptop | what does need to get written? (the buffer?) | 16:46.20 |
| mvrhel_laptop | yes | 16:46.25 |
| | the handle would not be valid on playback | 16:46.38 |
| ray_laptop | the comment implies that it is making that call to load the buffer, but that isn't what it is doing | 16:46.50 |
| mvrhel_laptop | ray_laptop: ok | 16:47.13 |
| | I am just saying that we don't put handles in the table | 16:47.29 |
| ray_laptop | OK, so rather than calling gsicc_get_profile_handle_clist I need a new function: gsicc_get_profile_buffer_clist | 16:47.30 |
| mvrhel_laptop | I would think that already exists | 16:47.47 |
| | we have to read the data out of the clist already someplace | 16:47.58 |
| ray_laptop | it's in the first part of the gsicc_get_profile_handle_clist | 16:48.41 |
| mvrhel_laptop | oh clist_read_chunk(pcrdev, position + GSICC_SERIALIZED_SIZE, | 16:48.54 |
| | I guess I did not forsee us needing to read and write the buffer from clist to clist | 16:49.24 |
| | So it does not exist | 16:49.41 |
| | I only planned on getting the profile hanlde | 16:50.12 |
| | although I am still puzzled by those one lines | 16:50.26 |
| | 7256-7261 | 16:50.37 |
| ray_laptop | mvrhel_laptop: yes. This unusual case happens because we are playing back the pattern-clist calls into the main clist. Usually was copy the pattern clist into the main clist and do the playback when the main clist is being rendered | 16:50.46 |
| mvrhel_laptop | right | 16:50.57 |
| | that was my understanding of how the pattern clist works | 16:51.06 |
| | why would be not be doing that | 16:51.11 |
| | writing it over and over back into the main clist seems.... oddd | 16:51.29 |
| | and even odd | 16:51.33 |
| ray_laptop | usually, yes, but not if high-level path filling is disabled in the main clist (-Z,) | 16:51.44 |
| mvrhel_laptop | oh | 16:51.53 |
| | now I see how rare this is.... | 16:52.13 |
| | you asked me how it ever worked | 16:52.23 |
| | well, it never worked | 16:52.29 |
| | for that case | 16:52.30 |
| ray_laptop | it gets into this via pdf14_clist_fill path via clist_fill_path in gxclpath.c line 758 | 16:52.59 |
| | I just (while we were talking) tumbled to the fact that it is because I have -Z, set that this is what is causing the unusual sequence | 16:54.04 |
| mvrhel_laptop | ray_laptop: so yes, you will need to write some code to handle this clist to clist icc profile writing | 16:54.07 |
| | ray_laptop: if you want me to do it, I can try but I will need a sample file | 16:55.32 |
| ray_laptop | mvrhel_laptop: and I don't see any reason to load the profile handle in line 7257 -- seems like at the least it would leak memory for the profile_handle | 16:55.36 |
| | mvrhel_laptop: I should be able to handle it. I just needed to bounce it off of you | 16:55.57 |
| mvrhel_laptop | ray_laptop: yes. I am going to take a closer look at that | 16:56.00 |
| | does the file you have stumble into that section without this -Z, | 16:56.17 |
| | setting | 16:56.19 |
| ray_laptop | mvrhel_laptop: well, since I am going to replace that call, I wouldn't suggest spending time looking into it. | 16:56.39 |
| mvrhel_laptop | ray_laptop: oh ok. Is that section of code only excercised with -Z,? | 16:57.02 |
| | I wonder if I wrote that with a plan to go back and finish something.... | 16:57.36 |
| | :/ | 16:57.53 |
| ray_laptop | it doesn't hit that code without -Z, | 16:57.58 |
| mvrhel_laptop | ok that makes me feel a little better | 16:58.09 |
| | ray_laptop: thanks for stumbling on it | 16:58.31 |
| | if you need anything let me know | 16:58.39 |
| ray_laptop | mvrhel_laptop: the only reason I can think of is to make sure that the profile is valid (so it can error out if it isn't) | 16:58.41 |
| mvrhel_laptop | but like you said, it leaks... | 16:58.56 |
| ray_laptop | would leak, except it probably never gets used. | 16:59.24 |
| mvrhel_laptop | ray_laptop: so yes, philmont was cancelled. Just found out yesterday. Real bummer | 16:59.55 |
| ray_laptop | I'm not sure what Heather is going to do for the rest of the summer. Not that it paid very much, tho' | 17:00.38 |
| mvrhel_laptop | We are working on doing a 5 day outing here in the PNW. Won't have all the cool activities (shooting etc) but Ethan will get in a lot of his camping requirements | 17:00.41 |
| | ray_laptop: I think there is a lot of work to do at Philmont | 17:01.22 |
| | so she is probably still working | 17:01.28 |
| ray_laptop | I figured Philmont, etc. was more of an #artifex topic | 17:01.35 |
| mvrhel_laptop | true.... | 17:01.46 |
| ray_laptop | mvrhel: (for the logs) I fixed that issue with transparency and the pattern-clist playback during parsing. I'll post that change for your review. | 21:43.53 |
| | mvrhel: I just refactored the existing routines to add the one I want and have the one that was being used previously use that and another existing function | 21:44.49 |
| | getting closer... | 21:44.58 |
| | Forward 1 day (to 2018/07/07)>>> | |
Log of #ghostscript at irc.freenode.net.