| | <<<Back 1 day (to 2017/07/26) | 20170727 |
| sebras | tor8: trivial patch on sebras/master. | 10:43.29 |
| Robin_Watts | sebras: lgtm. | 11:30.05 |
| | sebras, tor8: The first 6 commits on robin/spots are pretty trivial and ready to go now. | 11:30.30 |
| tor8 | Robin_Watts: yes. the first 6 on robin/spots LGTM | 11:31.54 |
| Robin_Watts | tor8: Thanks. | 11:32.23 |
| sebras | Robin_Watts: thanks for LGTMing that patch. | 11:36.54 |
| Robin_Watts | sebras: no worries. | 11:37.02 |
| | tor8, sebras: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=61814e69e040c222d1e35cebc6c9a85032e75bf6 | 12:11.20 |
| | Some MSVC project file fixes for 64bit builds. | 12:11.29 |
| tor8 | Robin_Watts: LGTM | 12:25.26 |
| Robin_Watts | Thanks. | 12:28.39 |
| tor8 | Robin_Watts: 3 commits on tor/master | 12:44.50 |
| | the last one redoes the HTML output, please give it a spin and see if you like the output | 12:45.09 |
| | it does two flavors of HTML output | 12:45.48 |
| | if you ask for 'html' then it gives you absolute positioned stuff to match the pdf page layout exactly | 12:46.04 |
| | and with 'xhtml' it does very rudimentary semantic stuff suitable for reflow | 12:46.17 |
| | the intent is that with xhtml we would be able to use our own html output with our epub layout engine to do reflow | 12:46.44 |
| Robin_Watts | First 2 lgtm. | 12:46.54 |
| | And the 3rd one looks extremely plausible. | 12:50.06 |
| sebras | Robin_Watts: lgtm and I'm so happy I didn't break w32 this time! :) | 12:50.16 |
| Robin_Watts | tor8: I'd say commit it, cos I'm not going to have a chance to play with it for a while at least. | 12:50.46 |
| tor8 | Robin_Watts: thanks. | 12:52.09 |
| | Robin_Watts: https://ghostscript.com/~tor/out.html | 13:32.18 |
| sebras | tor8: load_devicen() seems to have a problem. | 13:32.40 |
| | tor8: it loads the base colorspace on line 195, derefs it on line 199 but then checks the pointer again at line 209 | 13:33.09 |
| | as far as I can tell pdf_load_colorspace() can never return NULL. | 13:33.44 |
| tor8 | points at robin and mvrhel | 13:33.47 |
| sebras | I'll whip up a patch removing the check. | 13:34.02 |
| | Robin_Watts: my patch on sebras/master clusters well and removes a coverity warning. | 13:48.57 |
| Robin_Watts | sebras: lgtm | 13:56.06 |
| | Thanks. | 13:56.10 |
| | Morning mvrhel_laptop | 15:25.38 |
| mvrhel_laptop | Good morning | 15:25.59 |
| Robin_Watts | I merged your fix in. | 15:26.41 |
| mvrhel_laptop | Oh great. Thanks | 15:27.02 |
| | So I am trying to figure out why I am not finding the DeviceN color space in that shading file you shared with me | 15:27.30 |
| | Did you need me to look at anything in particular today Robin_Watts ? | 15:27.49 |
| | If not I will work on that | 15:28.00 |
| Robin_Watts | mvrhel_laptop: Not so far. | 15:28.03 |
| mvrhel_laptop | ok | 15:28.06 |
| Robin_Watts | mvrhel_laptop: OK, got time for a dumb question? | 16:44.08 |
| | On the altona test file (Altona_Technical_1v1_x3.pdf), A11... | 16:44.38 |
| | That's a DeviceGray image. | 16:44.51 |
| | Does that count as an image all in the black separation for the purposes of overprint ? | 16:45.12 |
| | Gah. I have a dreadful feeling I've run into a different dead end. | 16:53.12 |
| | So I have A11 working, but in a nasty way I'm not entirely happy with. | 17:24.16 |
| mvrhel_laptop | Robin_Watts: let me review that. There are a few rules, but I believe the answer is yes | 17:24.23 |
| Robin_Watts | What should the colorant name for /DeviceGray be? | 17:24.29 |
| | "Gray" ? | 17:24.34 |
| mvrhel_laptop | We need to make sure color managment maps gray to K | 17:24.44 |
| | when the target pixmap is cmyk | 17:24.51 |
| | So we need to be a little careful with things like Gray, Red, Green Blue | 17:25.37 |
| | Picture this case | 17:25.41 |
| | Suppose I have file that has a spot color named "Red" | 17:26.06 |
| | If we are drawing out to an RGB pixmap and have RGB + spots due to us being in a transparency group, we dont want to draw to the process Red | 17:27.25 |
| | that may not be a problem | 17:27.47 |
| Robin_Watts | We don't ? | 17:27.53 |
| mvrhel_laptop | but just something to keep in mind | 17:27.56 |
| | no we don't | 17:27.58 |
| Robin_Watts | hmm. | 17:28.13 |
| mvrhel_laptop | Adobe does not do that | 17:28.13 |
| Robin_Watts | Currently I have arranged so that every colorant gets a name. | 17:28.25 |
| mvrhel_laptop | I made a special file to test that | 17:28.26 |
| Robin_Watts | RGB spaces get "Red" "Green" "Blue" | 17:28.42 |
| mvrhel_laptop | A sep, or device N color that is Red, Green or Blue | 17:28.53 |
| Robin_Watts | CMYK get "Cyan" "Magenta" "Yellow" "Black" | 17:29.06 |
| mvrhel_laptop | is different than the additive Red, Green Blue colors | 17:29.09 |
| Robin_Watts | Lab gets "L" "a" "b" | 17:29.12 |
| | and Gray gets "Gray" | 17:29.18 |
| | I look for matching spot and colorant names. | 17:29.29 |
| mvrhel_laptop | These can't conflict with any real spots | 17:29.30 |
| | in the source | 17:29.38 |
| Robin_Watts | so based on what you're saying, possibly I should remove the names for the RGB process colorants, cos they should never match with spots. | 17:30.01 |
| mvrhel_laptop | That is my belief | 17:30.13 |
| | Same with Gray | 17:30.23 |
| | I have to run Ethan to bus | 17:30.31 |
| | bbiab | 17:30.32 |
| Robin_Watts | Remove Gray too. ok. | 17:30.41 |
| | then how will I know that it's a gray space? | 17:30.58 |
| | and should be considered part of the black plane? | 17:31.11 |
| | re | 17:58.07 |
| mvrhel_laptop | Robin_Watts: back... | 17:58.08 |
| Robin_Watts | So I was just pondering stuff. | 17:58.26 |
| mvrhel_laptop | So, in the color management code, we likely need to have special handling of DeviceGray | 17:59.00 |
| | when the target pixmap is CMYK | 17:59.08 |
| Robin_Watts | Should we extend your "NOT_DEVICE_N" "DEVICE_N_SPOTS_ONLY" etc stuff. | 17:59.08 |
| | to be more general? | 17:59.21 |
| | GRAY/RGB/CMYK/DEVICEN_SPOTS_ONLY/DEVICEN_CMYK/DEVICEN_CMYK_SPOTS | 17:59.56 |
| | etc | 18:00.03 |
| mvrhel_laptop | Robin_Watts: I guess I need a scenario described on why | 18:00.12 |
| | DeviceGray would be good to know | 18:00.37 |
| | as that requires special handling | 18:00.46 |
| Robin_Watts | Ok, so let's take the example of when I get a devicegray bitmap to plot, with OP=true, OPM=1 | 18:00.48 |
| mvrhel_laptop | That is different than ICC gray | 18:00.53 |
| | to what pixmap? | 18:01.12 |
| Robin_Watts | to cmyk+spots | 18:01.22 |
| mvrhel_laptop | ok | 18:01.24 |
| | so I can tell you what should happen | 18:01.33 |
| | Assuming the target color space was DeviceGray and not an ICC gray, the Gray should be treated as K. That is true regardless of overprint | 18:02.16 |
| | not target | 18:02.23 |
| | source | 18:02.25 |
| | sorry | 18:02.27 |
| Robin_Watts | right. | 18:02.55 |
| | Let's have a look at the altona file together... | 18:03.11 |
| | There is a new out.psd in my casper homedir that shows my latest results. | 18:03.44 |
| | I have a ref.psd generated by ghostscript that I'm using as a side by side reference in photoshop. | 18:04.32 |
| | Turning the Black plane off in photoshop, I see that we're getting a load of composite blacks (A1-3 and B1-3 for example) that should really be K. | 18:05.50 |
| mvrhel_laptop | let me open the file | 18:06.02 |
| Robin_Watts | I suspect that is exactly the "keep DeviceGray as K" case that you are talking about. | 18:06.28 |
| mvrhel_laptop | wait which altona file are we looking at | 18:08.17 |
| Robin_Watts | Altona_Technical_1v1_x3.pdf | 18:08.35 |
| mvrhel_laptop | oh sorry | 18:08.38 |
| | hold on | 18:08.40 |
| | ok I have it open now | 18:09.13 |
| Robin_Watts | I am being assisted by a puppy. This is not going to end well. | 18:09.17 |
| mvrhel_laptop | :) | 18:09.22 |
| Robin_Watts | I put some hacky code in to spot the bitmap being in DeviceGray space, and that sorted A11. | 18:10.08 |
| | But it broke A5. | 18:10.16 |
| | I wish they did a version of this file with each cell one per page. | 18:10.45 |
| mvrhel_laptop | Yes that would be nice | 18:11.07 |
| Robin_Watts | would save cutting it down each time. | 18:11.20 |
| mvrhel_laptop | So right now is A25 etc (non-overprint) going to composite cmyk | 18:12.00 |
| | If so, maybe I should fix that | 18:12.09 |
| | oh your problem is probably the mask creation | 18:13.00 |
| Robin_Watts | mvrhel_laptop: Turning the black plane off in photoshop certainly makes it look like that is the case. | 18:13.02 |
| | the overprint bitmap? | 18:13.20 |
| mvrhel_laptop | And photoshop shows the same | 18:13.24 |
| | oops | 18:13.48 |
| | acrobat shows the same | 18:13.53 |
| Robin_Watts | If you could handle the composite black issue, that would be great. | 18:14.20 |
| | Can I run through the way I've done the overprint bitmap stuff with you? | 18:14.34 |
| mvrhel_laptop | Robin_Watts: you are probably going to want to do some special handling though when you have a DeviceGray image | 18:14.43 |
| Robin_Watts | I'm a tad worried I may have been dumb. | 18:14.44 |
| mvrhel_laptop | to be efficient | 18:14.53 |
| | Robin_Watts: let me pull your latest | 18:15.16 |
| | hold on | 18:15.18 |
| Robin_Watts | I'll settle for working to start with :) | 18:15.19 |
| | I have an fz_overprint_t structure, that consists of a uint32_t | 18:18.52 |
| mvrhel_laptop | converting 8 of 21.... | 18:19.16 |
| Robin_Watts | (actually an array of them in theory, but given our current FZ_MAX_COLORS setting, just one) | 18:19.18 |
| | We pass a pointer to that structure into the low level painting operations. | 18:19.48 |
| | IF that pointer is NULL (or the structure is all 0's) then we don't do any overprinting. | 18:20.14 |
| | (i.e. the old way of working). | 18:20.20 |
| mvrhel_laptop | ok | 18:20.24 |
| Robin_Watts | If the structure is non null, we call a different set of plotting routines. | 18:20.41 |
| | instead of doing: | 18:20.43 |
| | for (i = 0; i < n; i++) d[k] = colork[k]; | 18:21.10 |
| | for each pixel, we now do: | 18:21.14 |
| | for (i=0; i < n; i++) if (fz_overprint_component(op, i)) d[k] = color[k]; | 18:21.47 |
| | fz_overprint_component checks to see if the given bit is zero. | 18:22.14 |
| mvrhel_laptop | that makes sense | 18:22.23 |
| Robin_Watts | so setting a bit in the word means "NEVER TOUCH THIS COMPONENT" | 18:22.46 |
| | Now, that works well for paths and text, because the color is set initially, and I can set it appropriately to allow for the zero components. | 18:23.25 |
| mvrhel_laptop | oh images and shadings not so simple | 18:23.59 |
| Robin_Watts | but I have this creeping feeling that it's not going to work so well for pixmaps, where the color components change on every pixel of the pixmap. | 18:24.05 |
| | yeah. | 18:24.12 |
| | I may have to change the inner loops to be: | 18:24.34 |
| | for (i =0; i < n; i++) if (fz_overprint_component(op,i) && color[k] != 0) d[k] = color[k]; | 18:25.16 |
| | Does that sound right to you? | 18:26.36 |
| mvrhel_laptop | ok. I think I see our get out of jail free card | 18:27.50 |
| Robin_Watts | If I have a CMYK+Orange+green+purple destination, and a duotone Orange+Green image, and I'm plotting that... | 18:28.10 |
| mvrhel_laptop | See last part of section 4.5.6 in spec | 18:28.14 |
| | About nonzero overprint mode | 18:28.29 |
| Robin_Watts | and a pixel is orange = 1, green = 0, I should only set the orange thing, right? | 18:28.35 |
| | reading that now. | 18:28.39 |
| | So shadings are exempt from overprint. | 18:29.49 |
| mvrhel_laptop | overprint mode | 18:29.57 |
| Robin_Watts | oh, right, opm. That doesn't save us from having to get OP right though. | 18:30.18 |
| mvrhel_laptop | has no effect for images and shadings | 18:30.19 |
| | correct. But we dont need your other loop ever | 18:30.38 |
| Robin_Watts | What other loop ever? | 18:30.46 |
| mvrhel_laptop | for (i =0; i < n; i++) if (fz_overprint_component(op,i) && color[k] != 0) d[k] = color[k]; | 18:30.53 |
| Robin_Watts | Why not? | 18:31.02 |
| mvrhel_laptop | fz_overprint_component(op,i) should have the information baked into it | 18:31.10 |
| | about the color | 18:31.12 |
| | color[k] should not be changing | 18:31.21 |
| Robin_Watts | Suppose I have my aforementioned CMYK+O+G+P space. | 18:31.26 |
| mvrhel_laptop | ok | 18:32.00 |
| Robin_Watts | and I have a 2x2 image in /DeviceN [/Orange/Green] with values 0,0 0,1 1,0 1,1 | 18:32.06 |
| mvrhel_laptop | ok | 18:32.32 |
| | and overprint is true | 18:32.36 |
| | and overprint mode has no effect | 18:32.42 |
| Robin_Watts | And suppose I have a background of 0.5 in every component on the screen already. | 18:32.52 |
| | What do I end up with? | 18:33.03 |
| mvrhel_laptop | well CMYK and P remain unchanged | 18:33.23 |
| Robin_Watts | 0,0 plots as what ? Nothing changes? | 18:33.23 |
| mvrhel_laptop | Orange and Green get blown away by the image | 18:33.40 |
| Robin_Watts | Orange and Green get blown away, even when the components are 0? | 18:34.03 |
| | Orange and Green get blown away, even when the pixel values are 0? | 18:34.23 |
| mvrhel_laptop | Yes. The 0 value is only relevant when OPM is true | 18:34.23 |
| | OPM is not valid for images | 18:34.31 |
| Robin_Watts | OK, there is something wrong with my understanding here then. | 18:34.56 |
| | As I understood it, OPM determines whether CMYK are treated in the same way as spots or not. | 18:35.22 |
| mvrhel_laptop | no | 18:35.27 |
| | OPM true, makes you interpret 0 values in CMYK special | 18:36.13 |
| | so if I have OPM true | 18:36.21 |
| | and I am filling with a CMYK value of [.9, .4, 0, .2] | 18:36.41 |
| | that is the same as if I did OP with a deviceN of [Cyan, Magenta, Black] | 18:37.02 |
| Robin_Watts | Ah! So it's my understanding of OP that's broken then :) | 18:37.32 |
| mvrhel_laptop | so OPM only comes into play when doing solid fills, strokes, text fills, strokes with CMYK colors | 18:37.47 |
| | if I am doing a fill with sep, or deviceN it has no effect | 18:38.14 |
| | if I am doing an image or a shading it has no effet | 18:38.23 |
| Robin_Watts | I thought that OP=1 meant "don't alter an output_component[k] if input_component[k] == 0", and OPM set whether that applied to just spots, or to spots + process | 18:38.57 |
| mvrhel_laptop | no | 18:39.06 |
| Robin_Watts | But now I see that's wrong. | 18:39.10 |
| mvrhel_laptop | OP means only draw with colorants of color space | 18:39.20 |
| | leave others alone | 18:39.28 |
| | hence your mask | 18:39.33 |
| | OPM makes the mask definition dependent upon the CMYK source color | 18:39.57 |
| Robin_Watts | so I need to revisit the code with that in mind. | 18:39.58 |
| mvrhel_laptop | but the drawing logic should be the same | 18:40.09 |
| Robin_Watts | yeah, the drawing code is fine, it's the setup of the mask that needs tweaking. | 18:40.29 |
| mvrhel_laptop | and for (i =0; i < n; i++) if (fz_overprint_component(op,i) && color[k] != 0) d[k] = color[k]; should be fine | 18:40.32 |
| | we do need to think a liittle about DeviceGray | 18:40.51 |
| | though | 18:40.53 |
| Robin_Watts | Urm, wait... | 18:40.56 |
| mvrhel_laptop | oops | 18:41.06 |
| | wrong one | 18:41.09 |
| Robin_Watts | Right :) | 18:41.13 |
| mvrhel_laptop | for (i=0; i < n; i++) if (fz_overprint_component(op, i)) d[k] = color[k]; | 18:41.19 |
| | is good | 18:41.21 |
| | :) | 18:41.28 |
| | let me read a bit about DeviceGray | 18:42.07 |
| | and overprint | 18:42.09 |
| | I forget if that is affected by OPM or if it is treated like DeviceN (black) | 18:42.30 |
| | when it comes to overprint | 18:42.36 |
| | oh | 18:44.17 |
| | it has no effect on overprint, but blows everything away. once I fix the Gray to K resolving then we should be good | 18:45.01 |
| | ugh. we need to look through the shadings that are in the resources for color spaces too | 18:59.51 |
| | to find the devicen and sep color spaces | 19:00.07 |
| Robin_Watts | ok, I've updated robin/spots in light of my less-broken understanding of OP/OPM. | 19:01.25 |
| | Thanks for pointing that out. | 19:01.30 |
| | Is "White" a special name? | 19:01.46 |
| | I'm going to have to quit for the night soon. | 19:02.43 |
| mvrhel_laptop | Robin_Watts: no | 19:03.52 |
| | White should be treated like any other spot colorant | 19:04.02 |
| Robin_Watts | Right. | 19:04.15 |
| mvrhel_laptop | Robin_Watts: I should have a few minor fixes for you to look at in the morning | 19:04.24 |
| | Robin_Watts: what date do you leave? | 19:04.34 |
| Robin_Watts | So tomorrow, I will remove "Red", "Green", "Blue" etc. | 19:04.36 |
| | mvrhel_laptop: couple of weeks. | 19:04.40 |
| mvrhel_laptop | ok. I think we are on track then | 19:04.47 |
| Robin_Watts | yeah, I hope so. | 19:04.53 |
| mvrhel_laptop | I do see one shading bug that popped up since I fixed an issue to find the Spot colorants | 19:05.20 |
| | I will look into that | 19:05.24 |
| Robin_Watts | and I will tweak the device_n flag thing to tell me whether it's a DeviceGray thing or not. | 19:05.31 |
| mvrhel_laptop | right. We will want to know when we resolve color if the original color space was DeviceGray | 19:06.17 |
| | Then if we are going to CMYK pixmap we will just treat Gray as K | 19:06.52 |
| Robin_Watts | Is "DeviceGray == K" the only special case like that | 19:09.42 |
| | ? | 19:09.43 |
| mvrhel_laptop | Robin_Watts: yes | 19:20.56 |
| | There is nothing else like it | 19:21.10 |
| | And overprint should be disabled since the source color space is Gray | 19:21.39 |
| | not a subtractive space | 19:21.46 |
| Robin_Watts | Urm... | 19:23.43 |
| | A11 in the example file... | 19:24.26 |
| | If memory serves that's a DeviceGray bitmap, and overprint is not disabled for that. | 19:24.58 |
| | mvrhel_laptop: How would you feel about: | 19:27.28 |
| | typedef enum | 19:27.32 |
| | { | 19:27.33 |
| | FZ_CS_TYPE_OTHER, | 19:27.35 |
| | FZ_CS_TYPE_DEVGRAY, | 19:27.36 |
| | FZ_CS_TYPE_DEVN_SPOTS, | 19:27.38 |
| | FZ_CS_TYPE_DEVN_SPOTS_CMYK, | 19:27.39 |
| | FZ_CS_TYPE_DEVN_CMYK | 19:27.41 |
| | } fz_colorspace_type; | 19:27.42 |
| mvrhel_laptop | That should give us all we need | 19:28.12 |
| | Robin_Watts: so quick question for yoy | 19:30.28 |
| | you | 19:30.29 |
| | actually never mind | 19:31.35 |
| Robin_Watts | (hmm. I'm getting the ick on this. Maybe we should just use a bitfield. | 19:31.46 |
| | bit0 = gray | 19:31.52 |
| | bit1=devn | 19:31.59 |
| | bit2=has cmyk | 19:32.05 |
| | bit3=has non cmyk spots | 19:32.17 |
| mvrhel_laptop | Robin_Watts: ok I am fine with a bit settinng | 19:32.55 |
| Robin_Watts | I'll have a play. | 19:33.09 |
| mvrhel_laptop | I am having trouble understanding the need for find_devn | 19:33.11 |
| | find_seps already handles the devicen colorants | 19:33.24 |
| | I don't understand the need for the second scan | 19:33.39 |
| | In pdf_page_separations | 19:34.01 |
| Robin_Watts | because of my ill defined concerns about using /DeviceN's for the fallbacks when we could be using /Separations. | 19:34.14 |
| mvrhel_laptop | but find_seps deals with them | 19:34.24 |
| | so lets say I have 3 color spaces. | 19:34.47 |
| Robin_Watts | find_seps finds DeviceN spaces and plucks any separations that it refers to out. | 19:34.58 |
| mvrhel_laptop | actually lets say I have 2 color spaces | 19:35.00 |
| Robin_Watts | go on. | 19:35.14 |
| mvrhel_laptop | oh | 19:35.17 |
| | yes | 19:35.29 |
| | how is that different than what find_devn should do | 19:35.48 |
| Robin_Watts | The idea was that the second pass would find any colorants listed in DeviceNs that weren't given as explicit Separation spaces, and would make separation entries using the DeviceN as the colorspace. | 19:36.11 |
| mvrhel_laptop | actually please explain what would go wrong if I did not scan with find_devn | 19:36.16 |
| Robin_Watts | AIUI, DeviceN's can say "this is made up of /Foo and /Bar" | 19:36.43 |
| mvrhel_laptop | those are the colorants yes | 19:36.57 |
| | and lets look at the code for find_seps | 19:37.05 |
| Robin_Watts | and they *can* point to real separation spaces for /Foo and /Bar, or they can choose not to. | 19:37.06 |
| mvrhel_laptop | hmm | 19:37.17 |
| Robin_Watts | If they DO point to real separation spaces, then my thought was that we should pick them up and add them to the list. | 19:37.38 |
| mvrhel_laptop | no | 19:37.53 |
| Robin_Watts | If the didn't, we should ignore them for now, and keep searching, because we might find the real separation spaces for /Foo and /Bar later on. | 19:38.00 |
| | THEN we do the second pass. | 19:38.06 |
| mvrhel_laptop | I don't understand "and they *can* point to real separation spaces for /Foo and /Bar, or they can choose not to" | 19:38.21 |
| Robin_Watts | And in the second pass, if we haven't already found /Foo and /Bar, we fake up entries for them. | 19:38.42 |
| | From memory the definition for a DeviceN is something like: | 19:39.02 |
| mvrhel_laptop | [ /DeviceN names alternateSpace tintTransform attributes ] | 19:39.16 |
| Robin_Watts | [/DeviceN [/Foo /Bar] ... .... <optional attributes>] | 19:39.25 |
| mvrhel_laptop | yes | 19:39.39 |
| Robin_Watts | right, so if we look in attributes at /Colorants, we might get a list of separation spaces that correspond to /Foo and /Bar. | 19:40.06 |
| mvrhel_laptop | oh | 19:40.10 |
| | wait | 19:40.24 |
| | hmm ok I see | 19:41.37 |
| | what you are trying to do | 19:41.42 |
| | so gs never uses the /Colorants entry | 19:42.00 |
| | it is optional | 19:42.01 |
| | I do understand now though what you are doing | 19:43.26 |
| | in adding the Colorants separations | 19:43.42 |
| Robin_Watts | This was concocted by my fevered brain in the absence of consultation with you. | 19:43.48 |
| mvrhel_laptop | I am going to have a few minor fixes here | 19:43.54 |
| Robin_Watts | so it's possible it's overly complicated. | 19:43.56 |
| mvrhel_laptop | it is a bit ;) but now that my small brain understands I think we are good | 19:44.21 |
| Robin_Watts | I will bow to your experience on this if you want to simplify it. | 19:44.24 |
| mvrhel_laptop | no I think it could be worthwhile to do it this way at some point. I just am fixing a few minor issues and got confused | 19:44.57 |
| Robin_Watts | I was disquieted by the idea of using an n-ary function to given a spot equivalent when there was a 1-ary function available. | 19:45.10 |
| mvrhel_laptop | yes fair enough | 19:45.19 |
| | that makes sense for the final squashing | 19:45.30 |
| Robin_Watts | gotta go. Have a good one. | 19:55.12 |
| mvrhel_laptop | ok good night. small commit for you on my blendspot repos | 19:57.43 |
| | now let me see what is going wrong in the shading after that change | 19:58.08 |
| | a few pixels are coming out white in the file you gave me | 19:58.22 |
| Robin_Watts | mvrhel_laptop: Thanks. I'll look at that tomorrow. | 23:06.44 |
| | I've pulled it, and squashed it back. New code on robin/spots, but I'll be updating it again tomorrow. | 23:22.58 |
| | Forward 1 day (to 2017/07/28)>>> | |
Log of #mupdf at irc.freenode.net.