| | <<<Back 1 day (to 2017/07/18) | 20170719 |
| mvrhel_laptop | Robin_Watts: Three simple commits on my blend_color branch for you | 00:36.20 |
| | Fixes for psd output | 00:36.24 |
| | done for now. dinner time | 00:36.40 |
| vtorri | hello | 04:35.49 |
| mubot | Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 04:35.49 |
| vtorri | I use st = fz_open_memory(***) in a block try(ctx) | 04:37.02 |
| | I have 2 questions: | 04:37.08 |
| | 1) should I keep the stream st until I drop the context, or may I drop the stream just after the document is opened ? | 04:39.02 |
| | 2) if fz_open_memory() does not fail, but another function fails, should I drop it in the catch block , | 04:40.47 |
| | ? | 04:40.51 |
| tor8 | morning Robin_Watts | 09:28.11 |
| | I've looked over the robin/spots branch (up to 'fix use-after-free') and don't see any major issue | 09:28.33 |
| | a couple of nitpicks | 09:28.38 |
| | the inconsistent terminology (in the spec and hence our code) drives me batty though | 09:29.12 |
| | spots, separations and devicen. what say you to just screw the pdf spec and use 'spot' consistently throughout our code. it's pithier than separation and easier to type. | 09:30.00 |
| | other nitpicks: enums should be UPPERCASE (I know, I prefer lowercase too, but consistency...) | 09:30.52 |
| | we IMAO shouldn't use const for objects, especially not reference counted ones where we need to cast away the constness | 09:31.27 |
| | only for structs and pointers where we pass "values" (such as matrices and rectangles, that sort of thing) | 09:31.47 |
| | so I disapprove of the "Add some consts" commit | 09:32.02 |
| | well, parts of it, the ones that add const to fz_colorspace, not the const float * parts, those are good | 09:32.30 |
| | a few places call the new pixmap constructors with 0 instead of NULL | 09:33.13 |
| Robin_Watts | tor8: I am tempted to agree with about spots vs separations. | 09:43.07 |
| | and I can change the enums. | 09:43.18 |
| | We never need to cast away const in any of the commits on that branch. | 09:43.36 |
| tor8 | Robin_Watts: cool. I need to head out for a long lunch, back in an hour or two. | 09:45.56 |
| Robin_Watts | tor8: see you. | 09:46.07 |
| | tor8: For the logs... I've updated the enums to uppercase. | 10:31.24 |
| | I've not changed any of the const stuff - everything that has been made const is truly const, including the fz_colorspaces. | 10:32.01 |
| | We never take or drop references to any of the const fz_colorspaces, hence we never have to cast it away. It makes stuff much clearer, IMAO. | 10:32.32 |
| | And I'd like to discuss the separations/spots/devicen thing when you get back. | 10:33.41 |
| | The spots within a pixmap are the colorants that we actually choose to plot as separate things. | 10:34.39 |
| | Separations are a list of possible notional separations - some of which may be spots, and some may be disabled, or may be composite. | 10:35.14 |
| | There is enough of a difference there, that I think we'd be poorly served by rolling the two together. | 10:35.39 |
| | And DeviceN is a different kettle of monkeys too. DeviceN is a colorspace that nominates several separations (which may or may not be spots). | 10:36.29 |
| | OK, strange difference resolved - I'd removed 2 more lines than I meant to. | 11:38.16 |
| | which means all the commits on robin/spots (which now include michaels fixes) cluster test with no differences. | 11:38.38 |
| tor8 | Robin_Watts: separations (spot colors) can be rendered into separate channels, converted into equivalent RGB/CMYK colors, or ignored completely | 13:48.35 |
| Robin_Watts | tor8: right. | 13:48.47 |
| tor8 | Robin_Watts: is the distinction between 'separation' and 'spot' terminology that useful? | 13:48.55 |
| | a separation rendered as a separation is a spot, but otherwise not? | 13:49.07 |
| Robin_Watts | hence separations are things that "come from the source" - they are things that we can control. | 13:49.18 |
| | spots are things that are physically rendered. | 13:49.24 |
| | I reckon that is a useful distinction. | 13:49.39 |
| | separations in PDF file need not correspond to spot colours. | 13:50.18 |
| | but they are things that can be identified and controlled individually. | 13:50.31 |
| tor8 | my mental model has it as the source has named colorants (separation and devicen colorspaces) which if we want in the output we create a pixmap with separation planes | 13:50.33 |
| Robin_Watts | Not all separations have to be colorants. | 13:50.46 |
| tor8 | gloss and varnish, etc? | 13:50.58 |
| Robin_Watts | I could have a "pink" separation that mapped to process colors. | 13:51.13 |
| | but it would still be identifiable (and hence controllable) within the PDF file. | 13:51.27 |
| | so you can miss out the "pink" from the final rendered image even though it's not a separate spot color. | 13:51.57 |
| tor8 | okay, so control of separations in the source document is a separate (pun not intended) mechanism from mapping separations to channels in the output pixmap? | 13:51.58 |
| | I had thought the thing we'd do is if a separation has a matching channel in the output pixmap, we'd render to that channel, otherwise we'd use the alternate tint transform to get at the equivalent RGB/CMYK process color | 13:53.01 |
| Robin_Watts | tor8: I think the way I've got it planned, ... yes, that. | 13:53.11 |
| tor8 | but now you also mention wanting to be able to tell the renderer to drop the color completely instead? | 13:53.40 |
| | s/color/separation/ | 13:53.50 |
| Robin_Watts | tor8: Yes. If you set the separation to disabled, it gets dropped completely. | 13:54.09 |
| tor8 | so the workflow is to get a fz_separations from the page, tweak which channels you want to keep, composite, and drop and then use that separations struct when creating a pixmap? | 13:55.02 |
| Robin_Watts | Yes. | 13:56.21 |
| | tor8: if you pass the draw device a pixmap with no separations struct, it assumes you want "simple" rendering (i.e. what we do now). | 13:56.55 |
| | if you pass the draw device a pixmap with a separations struct then it assumes you want a rendering that correctly respects overprint. | 13:57.59 |
| | So, to do that, it "promotes" the pixmap internally to a cmyk+spots one, renders to that, and then converts down from cmyk+spots to whatever pixmap you passed it. | 13:58.38 |
| | (so spots that are in the supplied pixmap come out as spots, ones that aren't come out as composite, but with overprint correct). | 13:59.08 |
| tor8 | that's the whole resolve_spots voodoo in the draw device? | 14:00.47 |
| | could that possibly live in a utility function and not contaminate all over the fz_draw_clip_image_mask etc functions? | 14:01.14 |
| Robin_Watts | tor8: No, that's the fz_copy_pixmap_area_converting_seps and fz_clone_pixmap_area_with_different_seps functions :) | 14:02.15 |
| | and it lives in separation.c | 14:02.26 |
| tor8 | I meant if it's possible for the client to call those after rendering instead of us doing it automagically | 14:02.52 |
| Robin_Watts | resolve_spots does the "here is colorspace + color array, convert that to an appropriate color array to match this pixmap" work. | 14:03.09 |
| | tor8: No, we want it pickled in, IMAO. | 14:03.26 |
| tor8 | Okay. | 14:03.35 |
| Robin_Watts | People want to be able to call the draw device with the pixmap they want, and have all the difficult stuff taken care of for them. | 14:03.52 |
| tor8 | Fair enough. | 14:04.03 |
| | though, if a printer is say CMYK+Gloss how easy is it to create a CMYK pixmap with a "Gloss" channel and not bother digging through the page separations struct and controlling things on and off? | 14:05.11 |
| Robin_Watts | tor8: Crumbs. | 14:06.14 |
| | So far, in my head, I've been working with the idea that you'd get the page separations struct and work from there. | 14:06.37 |
| | To do what you describe, you'd need to create your own separations struct, and make a pixmap from that. | 14:07.32 |
| | And we'd have to rely on the names of the colorants being the same for them to match up. | 14:07.50 |
| | It *should* work, I think, but I've not really thought about that | 14:08.02 |
| tor8 | mapping to a specific ink in a printer I would hope you'd need to do some sort of name matching | 14:08.30 |
| Robin_Watts | Gah. I think I'm rendering spots right. I have a .psd file here that looks plausible in a hex editor. | 14:10.30 |
| | but very little reads cmyk psd files. | 14:10.57 |
| tor8 | Robin_Watts: the reference (page 267 in pdfref17) mentions matching separation colorspace colorant names by name | 14:11.06 |
| Robin_Watts | and nothing other than photoshop appears to read cmyk+spots ones. | 14:11.10 |
| | tor8: yeah, so I *think* we're OK. | 14:11.19 |
| tor8 | and always using the alternate tint transform if none can be found | 14:11.21 |
| Robin_Watts | I may have to extend pamview.html to do psds too :( | 14:12.12 |
| tor8 | the spec also uses the term 'composite' for an output consisting of process colorants *plus* spot colorants combined | 14:12.32 |
| | gimp can't read anything but RGB :( | 14:13.00 |
| | I had envisioned the separations api as being a list of colorant names (and not much more) | 14:14.19 |
| | the page returns a list of separations, that we could pick and choose from when creating a pixmap | 14:14.38 |
| | or we can create a pixmap with our own list of extra colorant names | 14:14.48 |
| | and in the draw device, when we see a Separation space we match the colorant name to a pixmap channel and render to that | 14:15.16 |
| | maybe that's too naive a view though | 14:15.24 |
| Robin_Watts | It's a list of "virtual" colorant names, effectively. | 14:15.31 |
| tor8 | and if we can't find a matching colorant channel, we'd invoke the alternate tint to whatever we have | 14:15.44 |
| | as the base colorspace fro the pixmap | 14:15.57 |
| Robin_Watts | The separations structure buried in the pixmap works like that. | 14:16.18 |
| tor8 | with appropriate care taken for "All" and "None" | 14:16.22 |
| Robin_Watts | It's a list of the spots we have enabled. | 14:16.37 |
| | If we have a matching one, we draw it. If not, we drop back to composite. | 14:17.07 |
| tor8 | if we change the fz_separations stuff to be a simple list of names only, the client has two ways of handling them. | 14:18.54 |
| | either it has a hardcoded list of channels it knows, and always uses that (say for a printer) | 14:19.07 |
| | or we want to debug stuff, and just pass along the list of separations from the page | 14:19.21 |
| | or it wants more control, in which case it can make a new separation struct, copying the channels it wants to keep | 14:19.52 |
| Robin_Watts | tor8: well, you need a list of names. | 14:20.10 |
| tor8 | that loses the ability to disable a spot completely, but the I can't see much support in the PDF spec for that behavior | 14:20.13 |
| Robin_Watts | and you need "equivalent colors". | 14:20.20 |
| tor8 | a list of aliases per colorant? | 14:20.28 |
| Robin_Watts | tor8: The idea of controlling separations is mentioned in the spec for each. | 14:21.15 |
| | tor8: The idea of controlling separations is mentioned in the spec, I believe. | 14:21.21 |
| | and everything I've done has been careful not to break the gproof device. | 14:21.47 |
| | I believe that we can work in exactly the way you want with what I have. | 14:22.02 |
| | the fz_separations device is pretty much as lightweight as you can want it to be. | 14:22.19 |
| | s/device/struct/ | 14:22.24 |
| tor8 | Robin_Watts: does PDF return a fz_separations? I can't find it in the code. | 14:24.48 |
| Robin_Watts | tor8: pdf_page_separations, yes. | 14:25.04 |
| | see pdf-page.c 729 | 14:25.26 |
| tor8 | found it. that looks through the resources for separation and devicen colorspaces | 14:26.27 |
| Robin_Watts | yes, and it populates an fz_separation structure from it. | 14:26.50 |
| tor8 | not using the pdf page /SeparationInfo dictionary | 14:26.52 |
| Robin_Watts | tor8: The what now!?! | 14:27.06 |
| tor8 | page 147 in the pdfref17 spec | 14:27.24 |
| | also section 10.10.3 | 14:27.33 |
| Robin_Watts | tor8: right, but that's not the same... | 14:28.02 |
| sebras | vtorri: if you do st = fz_open_memory(...); and then e.g. fz_open_document_with_stream(..., st); after that you can immediately drop your stream reference using fz_drop_stream() since fz_open_document_with_stream() keeps its own reference. so this might mean you'd not want to drop in in fz_catch() but instead in fz_always(), depending on what your code looks like. | 14:28.36 |
| Robin_Watts | I could be wrong, but SeparationInfo might just be for "preseparated" pages. | 14:28.57 |
| | altona uses separations, but has no SeparationInfo. | 14:29.42 |
| | That's a separate beast :( | 14:29.48 |
| sebras | Robin_Watts: tell me that pun was intended! :) | 14:31.04 |
| Robin_Watts | sebras: sadly, no. It's unavoidable :) | 14:31.20 |
| sebras | Robin_Watts: oh, I forgot... you're British. ;) I wish I could do the same so effortlessly. | 14:32.09 |
| tor8 | Robin_Watts: it's all very confusing to me | 14:36.51 |
| | sebras: "Use annotation color when synthesizing text annotations" LGTM | 14:37.09 |
| | "Synthesize annotation appearance if a normal appearance is present." I'm not sure I see how the commit message and code relate | 14:37.36 |
| Robin_Watts | tor8: Yup. It confuses me too. | 14:37.41 |
| tor8 | in my naivete I'd have hoped a simple new_pixmap(cmyk, ["Pink", "Glossy"]) call would just do the magic when the draw device sees the Separation colorspaces | 14:38.37 |
| | also, I hate the DeviceN name... such a kluge when they decided to make Separation colorspaces more than one channel | 14:39.08 |
| | and then the even more confusing NChannel thing | 14:40.36 |
| Robin_Watts | tor8: We may be able to do some helper functions eventually. | 14:40.48 |
| | reboot time. brb. | 14:42.52 |
| sebras | tor8: s/present/absent/ fixed on sebras/master | 14:45.16 |
| | tor8: I guess I had a not in there somewhere. | 14:45.27 |
| tor8 | sebras: LGTM. | 14:45.53 |
| sebras | tor8: I did get a progression in fts_32_3225.pdf because it changed color. | 14:47.27 |
| | tor8: what is more puzzling is that when I view that file using evince and mupdf the text markup box has widely different sizes. | 14:48.00 |
| | tor8: still not sure where that comes from. | 14:48.22 |
| tor8 | sebras: gs also looks more like evince on that file | 15:00.58 |
| sebras | tor8: yes, because the highlight is done using halfcircle caps I think. | 15:02.56 |
| tor8 | sebras: well, this is in code I've got on my todo list to revisit | 15:03.49 |
| sebras | tor8: kens: though I just discovered that if I alter the coordinates in QuadPoints a bit (along with Rect) gs and evince do not agree, but mupdf diverges more. not sure what acroread does. | 15:04.33 |
| kens | Umm, what ? | 15:04.50 |
| kens | has not been paying attention | 15:04.58 |
| sebras | tor8: kens: see fts_32_3225-manipulated.pdf in my account on casper | 15:05.06 |
| kens | OK I copied it, what should I do with it ? | 15:06.12 |
| sebras | kens: run it in gs and acroread and see if they look similar. | 15:06.31 |
| kens | They look the same to me | 15:06.47 |
| | A concave left edge, convex right edge and a crossing point | 15:07.02 |
| | Am I missing something ? | 15:07.22 |
| | I admit the edges are not in quite the same place | 15:07.39 |
| | Just very similar | 15:07.46 |
| sebras | kens: thanks, I can't test with acroread at the moment and evince draws a convex left edge an crossing point at the middle and a doubly concave spike to the right. | 15:07.52 |
| | kens: and mupdf is not at all the same. | 15:08.11 |
| kens | Oh acroread looks exactly the same as GS from that perspective. | 15:08.17 |
| | THe left edge is positioned slightly differently (GS is at 72 dpi which may be relevant) but overall the sahpe is the same | 15:08.43 |
| sebras | kens: yeah, how is the width determined? is the text being contained taken into account? | 15:09.05 |
| | kens: because mupdf only covers half of that line of text. | 15:09.15 |
| kens | IIRC its jut the points of the highlight | 15:09.28 |
| sebras | kens: from reading the spec I think only QuadPoints should be used, so I'm puzzled as to why mupdf is not correct. | 15:09.45 |
| kens | The text isn't part of the highlight (I could be wrong) | 15:09.47 |
| | MuPDF maybe expects the points to be sane ? | 15:10.20 |
| sebras | kens: even if I use the original, unedited file only half of the first line of text is covered by the highlight. | 15:10.43 |
| kens | Umm, dunno then, sorry | 15:10.59 |
| tor8 | sebras: the current mupdf text markup synthesis largely disregards the quadpoints | 15:16.48 |
| | you'd have to ask paul about why, but I think the code could do with some improvements (and yes, I'm going to, real soon now ^TM) | 15:17.21 |
| | sebras: it uses qp 1 and 2 as the 'bottom' line and expects the file to follow the example image in figure 8.9 on page 634 on the spec, I reckon | 15:18.42 |
| sebras | tor8: also there's implementation 92 which means that the QuadPoints need not be sorted as specified. | 15:20.56 |
| | tor8: thank you, adobe! | 15:21.07 |
| tor8 | sebras: yeah. | 15:21.31 |
| | I'll deal with it later. | 15:21.36 |
| kens | sebras that was what I was thinking of | 15:21.52 |
| tor8 | sebras: and considering the QadPoints in the file is [ 45 628 550 628 45 572 550 572 ] I'd say note 92 applies | 15:23.04 |
| sebras | yes, I think that is the case too. | 15:27.51 |
| | how does one determine which one is "the next vertex in a counterclockwise direction"? | 15:28.44 |
| vtorri | sebras: thank you | 15:29.09 |
| sebras | I guess that is simply the point immediately after the one with the smallest y coordinate. | 15:29.23 |
| tor8 | sebras: assuming it's a convex polygon, you can check the winding by using cross products, etc. | 15:29.36 |
| sebras | and by immediately after I mean immediately after it in the QuadPoints array. | 15:29.41 |
| tor8 | but I suspect they just mean "the next point in the array" | 15:30.04 |
| kens | I think GS sorts the co-ords, but I don't recall exactly | 15:30.10 |
| sebras | kens: do you know roughly where this happens in gs so I could read up on the source? | 15:30.28 |
| | kens: I have no idea about where to look. | 15:30.37 |
| | or even if I want to... | 15:30.46 |
| kens | sebras it'll be in the PDF inerpreter, which is written in PostScript.... | 15:30.49 |
| | So I expect you don't want to | 15:31.03 |
| | If you aks me tomorrow I'll look then for you, but I'm stuck in verifying seg faults right now | 15:31.20 |
| sebras | right, forgot about that. | 15:31.21 |
| | kens: np. | 15:31.27 |
| tor8 | heading out for a few hours again. back later tonight. | 15:34.31 |
| sebras | tor8: alrighty! | 15:34.53 |
| mvrhel_laptop | Robin_Watts: did you see my psd fixes? | 16:19.01 |
| Robin_Watts | mvrhel_laptop: I did. I pulled them all in and rebased them back. | 16:19.18 |
| | I made another fix too. | 16:19.26 |
| mvrhel_laptop | ok great | 16:19.28 |
| Robin_Watts | now I get a .psd file that Photoshop accepts. | 16:19.39 |
| | I made a really simple file that plotted an orange rectangle, and that's properly rendering now. | 16:20.04 |
| | mvrhel_laptop: I've just updated robin/spots to the latest. | 16:20.56 |
| mvrhel_laptop | ok. I will update | 16:21.07 |
| Robin_Watts | the cluster is giving it a clean bill of health now I believe. | 16:21.23 |
| mvrhel_laptop | great. Are you pushing to golden then? | 16:22.13 |
| Robin_Watts | mvrhel_laptop: tor8 had many comments. | 16:22.48 |
| mvrhel_laptop | Robin_Watts: soon we should think about adding psd device to cluster testing | 16:23.05 |
| Robin_Watts | I've addressed all his comments bar one, I think, and I'm pushing back against that. | 16:23.11 |
| mvrhel_laptop | once we get spots and overprint in place | 16:23.21 |
| | Robin_Watts: The const comment? | 16:23.30 |
| Robin_Watts | mvrhel_laptop: yeah. I'd need to update bmpcmp for that :) | 16:23.30 |
| | yeah. | 16:23.33 |
| mvrhel_laptop | I dislike const so I side with tor, but that it me | 16:23.53 |
| Robin_Watts | const is a pain because it stops you doing things you shouldn't be doing :) | 16:24.54 |
| mvrhel_laptop | exactly :) | 16:25.32 |
| | And I tend to be a bull in the china shop | 16:25.50 |
| | Although on myth busters they did bring a bull into a china shop. And nothing broke | 16:26.13 |
| Robin_Watts | :) | 16:26.27 |
| icem | Robin_Watts, MuPDF works great and perfectly with PDFs (I did find that it has problems opening large ePub files) | 17:07.33 |
| | the images are not there or distorted | 17:07.47 |
| Robin_Watts | icem: open a bug report, and attach such an epub :) | 17:08.05 |
| icem | it's a 200MB epub | 17:08.20 |
| Robin_Watts | Are you running out of memory ? | 17:08.54 |
| icem | no | 17:08.57 |
| | is it legal to attach an epub to the bug report? | 17:09.23 |
| Robin_Watts | then presumably the same problem should happen with a smaller epub. | 17:09.32 |
| | depends on the copyright on the epub. | 17:09.39 |
| icem | Robin_Watts, I really don't mind posting the file (I won't get in trouble right?) | 17:13.49 |
| | on the bug reporting site* | 17:14.46 |
| Robin_Watts | icem: If our bugzilla will take it, sure. | 17:14.59 |
| | let us know, and we can mark it private. | 17:15.05 |
| icem | what's the link for posting bugs? | 17:15.31 |
| | got it! | 17:17.30 |
| Robin_Watts | bugs.ghostscript.com | 17:17.34 |
| icem | Robin_Watts, I just uploaded the file with the report.. | 17:26.33 |
| Robin_Watts | Thanks, I've marked it as private. | 17:32.59 |
| icem | ok | 17:33.03 |
| mvrhel_laptop | so mudraw does not really work with portfolios? | 18:21.38 |
| | It did render a page that says "For the best experience, open this PDF portfolio in AcrobatX or Adobe Reader X or later" | 18:22.27 |
| | Funny | 18:22.32 |
| | ok on to beat on transparency with spots... I have several interesting test files that I used for gs | 18:24.06 |
| Robin_Watts | mvrhel_laptop: mutool will extract portfolios for you. | 18:32.14 |
| mvrhel_laptop | Robin_Watts: Not really a problem. Just surprised. | 18:32.31 |
| Robin_Watts | but to avoid that page you need to do all sorts of javascripty stuff. | 18:32.36 |
| | (basically the PDF file is just that message, with some javascript to say "don't show that, show a menu of the enclosed files". | 18:33.20 |
| mvrhel_laptop | ah ok | 18:35.07 |
| Robin_Watts | Gah. Couldn't figure out why I was seeing cluster diffs, and it turned out to be that sebras had fixed stuff and I'd not pulled it in. | 18:42.34 |
| mvrhel_laptop | oh | 18:43.39 |
| Robin_Watts | 28 diffs. | 18:43.56 |
| | so easy enough to ignore if you know about them. | 18:44.09 |
| | I've updated my branch now. | 18:44.32 |
| mvrhel_laptop | Robin_Watts: so pdf_page_separations needs to be updated to also look in the resources any forms | 18:46.35 |
| | of any | 18:46.42 |
| Robin_Watts | oh, yes. I'd forgotten that. | 18:46.53 |
| mvrhel_laptop | Do you want me to try to do that? | 18:47.39 |
| | Or is it easy/fast for you to do? | 18:47.47 |
| | I have some test files that I am using to get the trans blending working that rely on it | 18:48.09 |
| Robin_Watts | urm... | 18:48.23 |
| | I can have a quick look if you want. | 18:48.29 |
| mvrhel_laptop | either way | 18:48.33 |
| | if you are in the middle of something | 18:48.41 |
| | I can hack something together | 18:48.45 |
| | and you can throw it out later ;) | 18:48.51 |
| Robin_Watts | Give me 10 mins) | 18:49.26 |
| mvrhel_laptop | ok | 18:49.30 |
| | good lord. just listening to a Sam Harris pod-cast. This mess you brits had in Rotherham is a bit shocking | 18:59.25 |
| | Political correctness run amok to a level that really boggles the mind | 19:00.06 |
| Robin_Watts | This is the child abuse thing? Yeah, it's dreadful. | 19:00.53 |
| mvrhel_laptop | yes | 19:00.56 |
| Robin_Watts | There is a decent 2 part drama about it called "Three Girls". | 19:01.13 |
| mvrhel_laptop | I will have to look that up. Not sure I can stomach it though. | 19:01.37 |
| Robin_Watts | mvrhel_laptop: OK, robin/spots has a commit on the top that might work. | 19:02.54 |
| mvrhel_laptop | cool. Thanks Robin_Watts | 19:03.01 |
| Robin_Watts | no problem. | 19:03.05 |
| | I'm trying to update the plotters so that images will work. | 19:03.28 |
| mvrhel_laptop | sounds good | 19:03.36 |
| Robin_Watts | mvrhel_laptop: The same thing as happened in Rotherham, has subsequently been found to have happened about 30 other places around the UK, AIUI. | 19:05.47 |
| mvrhel_laptop | That was what they mentioned on Sam Harris | 19:06.01 |
| | All disturbing. The thing that I have trouble wrapping my head around is the fact that due to the ethnicities of the people the police and social workers did nothing due to worry of being labeled racist or islamaphobes | 19:07.17 |
| | Talk about propaganda for the far right to use.... | 19:08.00 |
| | When you swing that far not to hurt someones feelings something is wrong | 19:08.23 |
| Robin_Watts | indeed. | 19:08.28 |
| mvrhel_laptop | You may find this podcast interesting/disturbing. https://www.samharris.org/podcast/item/is-this-the-end-of-europe. I am going to read Douglas Murray's book next | 19:10.34 |
| Robin_Watts | mvrhel_laptop: We get the Spectator here every week. It's a very good read. | 19:11.46 |
| | Don't always agree with everything in it, but it's always interesting and thought provoking. | 19:12.12 |
| mvrhel_laptop | Yes. I found Douglas Murray's comments expressed in a way that clarified several difficult topics | 19:13.41 |
| Robin_Watts | The "how far do you swing to avoid offence" is an interesting thing. It happens in daily life all the time. How many times on Social Media do people not "like" stories that tell an uncomfortable truth for fear of other people thinking badly of them? | 19:15.31 |
| | It's why there are WAY more left leaning memes on facebook than right. | 19:15.47 |
| mvrhel_laptop | yes. That is true. I had not thought of that. | 19:16.09 |
| | That is why I don't put bumper stickers on my car.... | 19:16.24 |
| | I guess I should go ahead and put the darwin sticker on there.... | 19:16.42 |
| | I think you would really like the Sam Harris pod-casts if you have the time. He has guests who really push the envelope in various ways. | 19:17.26 |
| | All listener supported | 19:17.33 |
| | So he can do what ever he wants | 19:17.41 |
| | If you listen to the above pod cast I would be curious to hear your thoughts | 19:18.03 |
| | anyway back to the salt mine.... | 19:18.09 |
| Robin_Watts | I have it open in a tab. Will listen tomorrow. | 19:18.44 |
| mvrhel_laptop | cool | 19:18.48 |
| | Robin_Watts: so the forms fix did not quite work. The file I have has an xobject which has another xobject in its resource, which finally has a color space in its resource | 19:24.42 |
| | Is there any ready made code that drills down through these forms with a check for cycles? | 19:25.04 |
| Robin_Watts | mvrhel_laptop: ah, so it needs to rejigged to recurse. | 19:25.08 |
| mvrhel_laptop | yes | 19:25.11 |
| Robin_Watts | not that I can remember, but we have a system in place to check for cycles. | 19:25.30 |
| | (pdf_mark_obj etc) | 19:25.34 |
| mvrhel_laptop | right. I can work on it if you want | 19:25.44 |
| Robin_Watts | so that will need to be retrofitted to it. | 19:25.47 |
| | yeah, I'm gonna have to quit any sec. | 19:25.54 |
| mvrhel_laptop | ok I will do it. and you can look at it in the morning | 19:26.13 |
| | thanks! | 19:26.20 |
| Robin_Watts | no worries. | 19:27.00 |
| | Woo Hoo! First blood with altona. It's suddenly looking much more populated. | 19:39.47 |
| mvrhel_laptop | cool | 20:02.25 |
| | Robin_Watts: you still there? | 20:02.30 |
| | I had a what is probably a simple question | 20:03.18 |
| Robin_Watts | I am here. | 20:06.06 |
| | but being called away. sorry! | 20:07.25 |
| mvrhel_laptop | np | 20:08.08 |
| | I am fine | 20:08.09 |
| Robin_Watts | Top left altona image is corrupted, but all the rest look OKish. Will dig into that tomorrow. | 20:14.10 |
| tor8 | Robin_Watts: okay, I guess I can live with const fz_colorspace in the color converter | 21:16.22 |
| | Robin_Watts: which I guess means everything up to and including "fix use-after-free" LGTM | 21:17.24 |
| | haven't read the 'update draw device' commit yet | 21:17.37 |
| Robin_Watts | tor8: cool, thanks. | 23:11.13 |
| | Forward 1 day (to 2017/07/20)>>> | |
Log of #mupdf at irc.freenode.net.