| | <<<Back 1 day (to 2017/06/19) | 20170620 |
| sebras | tor8: I had a look at tor/master yesterday and they all looked resonable to me. | 09:27.56 |
| tor8 | sebras: thanks. | 09:30.50 |
| sebras | git logga | 09:38.15 |
| tor8 | sebras: https://git-scm.com/images/logo@2x.png | 09:39.05 |
| sebras | tor8: :) | 09:40.27 |
| | tor8: I just prepared sebras/master with a few commits if you want to have a look. | 09:40.54 |
| | tor8: the top one might be controversial. | 09:41.01 |
| sebras | just learned that fz_throw(ctx, FZ_ERROR_GENERIC, "cannot convert document: %s", fz_caught_message(ctx)) is bound to fail | 16:11.54 |
| | you' | 16:13.44 |
| | ll get an endless string of "cannot convert document: cannot convert document: cannot convert document: ..." that while pretty is not what I desired. | 16:14.12 |
| malc_ | sebras: i smell macro fun here | 16:17.50 |
| Robin_Watts | sebras: Is there a trivial workaround for that? | 16:29.25 |
| | Not really. | 16:30.07 |
| | although... | 16:30.23 |
| | We could make fz_caught_message(ctx) copy the message one entry down on the stack before returning it :) | 16:31.56 |
| sebras | Robin_Watts: or better yet have fz_vthrow() format the message in a stack buffer and then copying it into the error output buffer? | 16:42.12 |
| Robin_Watts | sebras: That's nicer. | 16:42.26 |
| | apart from being slower on every single throw. | 16:42.44 |
| sebras | Robin_Watts: it would be. | 16:42.52 |
| | Robin_Watts: I'll talk to tor8 once the lcms stuff is fixed. | 16:43.43 |
| | Robin_Watts: something leads me to believe that he'd have an opinion on this matter. | 16:43.54 |
| Robin_Watts | sebras, tor8, mvrhel_laptop: I've been going back and forth on this all day. | 16:57.54 |
| | We need a way to get the separations on a page. | 16:58.09 |
| | We already have such a mechanism for gproof files, but we need it for PDF too. | 16:58.33 |
| | Currently, we have an fz_page_get_number_of_separations call, and then a fz_page_get_separation_details(ctx, page, num, ...) call. | 16:59.11 |
| | Now, for gproof files that's fine because we keep a structure that lists all the separations with each page. | 16:59.43 |
| | For PDF it's harder, cos we need to do a time consuming search through the file. | 17:00.01 |
| | Now, I *could* keep a structure per page and just load it when the page starts, but that's contrary to the spirit of what tor has been fighting for, in trying to keep our layers 'thin'. | 17:01.06 |
| | So, I was thinking that I'd change the API slightly to be 'fz_separations *fz_page_separations(ctx, page)'. | 17:01.46 |
| | And that would return us a structure that we can then interrogate to get details of the page separations. | 17:02.06 |
| | (how many, and then for each one, what its name/rgb equivalent is etc) | 17:02.32 |
| | That way, for PDF, I'd just do the search when asked. | 17:03.11 |
| | the caller can keep the structure around, and we don't end up searching multiple times. | 17:03.46 |
| | That seems pretty clear cut to me. | 17:03.57 |
| | The next bit is where it gets harder... | 17:04.04 |
| | With gproof, we can enable/disable separations. | 17:04.16 |
| | so I need a call to say fz_disable_separation. | 17:05.47 |
| | Do I have that as a page level thing, or an fz_separation thing? | 17:06.01 |
| | Having it as a page level thing keeps the property that the 'fz_separation structure you were returned was a snapshot of the situation when you asked for it' | 17:07.08 |
| | i.e. it makes sure people don't expect it to be updated live as the file is edited. | 17:07.34 |
| | but the downside to that is that you need to know how many separations there are, so you've got to have a separation structure anyway to know that. | 17:08.01 |
| | Basically, should the API be fz_disable_separation_on_page(ctx, page, num); or fz_disable_separation_on_page(ctx, seps, num); | 17:09.56 |
| | The latter means I need to pickle a page into the fz_separation structure, and we frown on that, right? | 17:10.34 |
| Robin_Watts | notes tumbleweeds. | 17:10.57 |
| sebras | Robin_Watts: I was trying to figure out why 9322cd236f2c74461ab5d20e0a399035051628ae causes "warning: assert: overwrite hash slot" to appear when mutool draw -s t pdfref17.pdf | 17:26.55 |
| Robin_Watts | 2 things with the same hash key (or the same thing twice) being inserted into the hash table. | 17:28.19 |
| | but more than that, I have no idea. | 17:29.19 |
| sebras | Robin_Watts: neither do I, right now. | 17:29.31 |
| | Robin_Watts: why do we need to be able to enable/disable separations? | 17:29.58 |
| Robin_Watts | sebras: It's part of the gproof stuff. | 17:30.12 |
| | So we can toggle different colorants on and off. | 17:30.23 |
| sebras | Robin_Watts: oh, and this happens without rerendering the page? | 17:30.53 |
| Robin_Watts | sebras: No, you disable a colorant, then rerender. | 17:31.12 |
| | It happens without gs rerendering :) | 17:31.21 |
| | gproof works by getting gs to render a .gproof file. MuPDF can then pan and zoom around that page quickly. | 17:32.04 |
| sebras | Robin_Watts: ok, I'm a bit clueless about these things, but why wouldn't this be some type of configuration for the the device used to render? | 17:32.15 |
| Robin_Watts | And MuPDF can then toggle different colorants on and off. | 17:32.17 |
| | Different thing, I think. | 17:33.04 |
| | Currently, MuPDF doesn't have a draw device that supports spots. | 17:33.27 |
| | i.e. we only ever generate grey, or cmyk, or rgb output. | 17:33.41 |
| | When we add the ability to render to an arbitrary set of output planes (like say cmyk+spots), then we can configure that to choose what planes are included in the output. | 17:34.39 |
| | What we are doing here, is changing what separations are looked at in the *input*. | 17:35.09 |
| | i.e. the configurations here alter the rgb or cmyk renditions we get out. | 17:35.25 |
| | Does that make sense ? | 17:35.28 |
| sebras | yes. | 17:35.36 |
| | though to me this feels similar to the setting we have saying "ignore images". | 17:36.14 |
| | those images _are_ part of the input but we ask them to not be shown. | 17:36.30 |
| Robin_Watts | Possibly. | 17:36.46 |
| sebras | with my limited understand of this these things seem conceptually similar in that you are asking what should be taken into account when rendering. | 17:37.11 |
| Robin_Watts | Not all input formats are capable of avoiding separations. | 17:37.14 |
| sebras | Robin_Watts: oh. | 17:37.36 |
| Robin_Watts | (indeed, only gproof can, currently. PDF cannot, in general). | 17:37.39 |
| sebras | Robin_Watts: once mupdf supports lcms, then separations would still be the reason to keep gproof around? | 17:38.25 |
| | Robin_Watts: somehow I conflate these two things into each others opposites. | 17:38.43 |
| Robin_Watts | Once mupdf supports lcms, and the draw device supports separations, then we could consider dropping gproof. | 17:39.18 |
| sebras | Robin_Watts: right. | 17:39.42 |
| Robin_Watts | I'm doing the prep work for "draw device supports separations" now. | 17:40.02 |
| | but I'm not prepared to drop gproof until we have everything in like blending group colorspaces and transfer functions. | 17:41.00 |
| sebras | make sense (to me). | 17:43.12 |
| Robin_Watts | But do I pickle an fz_page into the fz_separations structure? | 17:43.51 |
| | Ah, no, I don't need to. | 17:44.23 |
| sebras | Robin_Watts: I don't understand this well enough to answer. | 17:44.27 |
| | to me the existing call fz_control_separation_on_page() seems mysterious. | 17:44.50 |
| Robin_Watts | sebras: No, I've been flip flopping on this all day, so it's unreasonable to expect anyone else to be instantly up to speed. | 17:45.08 |
| sebras | since that call is per page then I see no reason not to have the output rendering color space per page, or whether images should be taken into account also per page. | 17:45.44 |
| | though in the latter two cases we do that per rendering, right? | 17:46.07 |
| Robin_Watts | sebras: No, that feels different to me. | 17:46.47 |
| | Well.... | 17:47.27 |
| | eventually, what will happen, I think, is that we'll say "Give me a draw device that is capable of rendering to separations, with these ones enabled." | 17:48.10 |
| | scratch that. | 17:48.43 |
| | eventually, what will happen, I think, is that we'll say "Give me a draw device that is capable of rendering to separations." | 17:48.58 |
| | and then we'll run the page through, and rather than the separations being mapped down to either rgb or cmyk and composited, we'll get n channels of output, one for each separation. | 17:49.47 |
| | And we can potentially enable/disable separations in the draw device. | 17:50.31 |
| | but that doesn't fit with gproof. | 17:50.41 |
| sebras | Robin_Watts: right. | 17:50.47 |
| Robin_Watts | so I think I'm going to do the simplest thing I can do now that will accomodate PDF and gproof, and we can remove the gproof wrinkles later. | 17:51.07 |
| sebras | Robin_Watts: so in that case what if you render to rgb but you don't want separations to be "emulated" in rgb..? | 17:51.12 |
| | I'm guessing this is what it is about..? | 17:51.20 |
| Robin_Watts | sebras: yeah, that's what gproof lets you do. | 17:51.31 |
| | And it works at the page level. | 17:51.49 |
| sebras | Robin_Watts: when using gproof, is the entire document rendered by gs, or is that done per page? | 17:52.39 |
| Robin_Watts | For GProof we are talking about "Device Colorants". | 17:52.46 |
| | In PDF Separations can both mean "Device Colorants" and "Composite colors", I believe. This whole area is a mindfuck. | 17:53.32 |
| | sebras: gs renders pages one at a time for gproof I think. | 17:53.56 |
| sebras | Robin_Watts: how many pages per batch does mupdf ask gs to render? one? | 17:54.11 |
| Robin_Watts | gs is invoked 1 page at a time. | 17:56.10 |
| | but MuPDF holds 3 pages typically (current, current-1, current+1) | 17:56.31 |
| | sebras: It depends if you're talking about lib or app :) | 17:56.50 |
| sebras | ah, yes. | 17:56.57 |
| | so worst case we'd rerender 3 pages if we had to redo it all from the beginning. | 17:58.00 |
| Robin_Watts | gs rendering is slow, hence this stuff is designed to avoid rerendering. | 17:59.02 |
| | the gproof file format contains an rgb image, plus individual planes. | 17:59.29 |
| | so muPDF can either just show the rgb, or (if a colorant is toggled on/off), we can recomposite from the individual planes. | 18:00.04 |
| sebras | oh, but in that case, then gs doesn't need to rerender, right? | 18:00.42 |
| Robin_Watts | sebras: Indeed. The whole point is avoid gs having to rerender. | 18:01.01 |
| | sebras: Indeed. The whole point is to avoid gs having to rerender. | 18:01.08 |
| | Damn, this is actually simpler than I had thought. | 18:02.11 |
| sebras | so, if the client asked for rgb+spot1 or just rgb or rgb+spot2 (if there are two, e.g.) via the device why couldn't gprf-doc reach through fitz and use that to determine how to recomposite? | 18:02.41 |
| Robin_Watts | 'client' ? | 18:03.40 |
| sebras | app/whatever that want's to render a gproof file. | 18:03.55 |
| Robin_Watts | If the draw device was setup to ask for particular spots ? | 18:04.09 |
| sebras | yes. | 18:04.21 |
| Robin_Watts | well, currently, the control for gproof is done at the page level. | 18:04.37 |
| | and the device never sees a page. | 18:05.02 |
| sebras | wouldn't that require you to set up the control of separations in a way that would minimize the changes necessary later on when the draw device can indeed render to N colors? | 18:05.18 |
| Robin_Watts | it just sees device calls coming in, which may come from a display list, or may come from a page. | 18:05.21 |
| | I may want to extend the device interface to allow the pages to ask that kind of question, but not right at this moment :) | 18:06.42 |
| | I think I have a plan to get me somewhere sane. | 18:07.01 |
| mvrhel_laptop | Robin_Watts: ok I am here | 18:08.03 |
| | sorry about that | 18:08.05 |
| | can I ask my question first? | 18:08.11 |
| | It will be an easy one | 18:08.17 |
| Robin_Watts | sebras: Leave it with me for a while, and you can critique what I come up with. | 18:08.18 |
| | mvrhel_laptop: Sure. I'm done for a bit I think. | 18:08.30 |
| mvrhel_laptop | ok. So this is in the lcms branch | 18:08.40 |
| | right now in pdf_run_page_contents we set up the default_cs stuff and put it in the device | 18:09.08 |
| Robin_Watts | Yes. | 18:09.47 |
| mvrhel_laptop | It turns out that I am going to need to access this in pdf_run_page_contents_with_usage to make sure that we use the proper color space if we happen to push a group | 18:09.51 |
| sebras | Robin_Watts: gladly, I'm as confused as I was before. not sure how my questions made things clearer for you either. :) | 18:09.57 |
| mvrhel_laptop | I saw that pdf_run_page_with_usage also calls pdf_run_page_contents_with_usage | 18:10.15 |
| | when does one use pdf_run_page_with_usage? | 18:10.30 |
| Robin_Watts | sebras: I think you made it clear to me that this rearrangement is just a short term stepping stone, so I should do what is easy. | 18:10.39 |
| mvrhel_laptop | I am a little confused by the api here? | 18:10.40 |
| sebras | Robin_Watts: ok, makes sense. | 18:11.10 |
| Robin_Watts | mvrhel_laptop: Right. pdf_run_page_contents_with_usage is the 'innermost' one. | 18:11.24 |
| mvrhel_laptop | ok wouldnt we set up the defaults there? | 18:11.46 |
| | then | 18:11.47 |
| Robin_Watts | yes, that feels better to me. | 18:11.56 |
| mvrhel_laptop | otherwise, it seems they could get circumnavigated | 18:12.07 |
| Robin_Watts | pdf_run_page_contents is the 'old' api. | 18:12.18 |
| mvrhel_laptop | That will help me with my issue | 18:12.25 |
| | ok | 18:12.28 |
| Robin_Watts | pdf_run_page_contents_with_usage was added to allow us to specify the 'Usage' string. | 18:12.41 |
| mvrhel_laptop | Basically, if the page contains a group we need to make sure to push a group with the proper color space | 18:12.51 |
| Robin_Watts | the Usage string is used to determine the appearance for OCGs. | 18:12.56 |
| mvrhel_laptop | at the onset | 18:12.56 |
| | of the page | 18:12.57 |
| | OCG? | 18:13.09 |
| Robin_Watts | Optional Content Group. | 18:13.15 |
| mvrhel_laptop | optiona content | 18:13.18 |
| | ok | 18:13.20 |
| | ok. I will move the default stuff then | 18:13.37 |
| Robin_Watts | cool. | 18:13.41 |
| | If possible, can we that in a separate commit? | 18:13.55 |
| | If possible, can we do that in a separate commit? | 18:14.03 |
| | cos that should probably get squashed back into the initial lcms commit. | 18:14.15 |
| | no big deal if you can't do that, I can massage it later. | 18:14.25 |
| mvrhel_laptop | Robin_Watts: yes. let me do that seperate | 18:16.13 |
| | As it should be in the lcms branch not part of this transparency stuff | 18:16.31 |
| | Robin_Watts: so after updating to robin/lcms_squashed. mudraw does not build for me | 18:45.24 |
| Robin_Watts | mvrhel_laptop: what error? | 18:45.48 |
| mvrhel_laptop | hmm you know what. let me see if something screwed up in vs | 18:46.01 |
| | starting over. hold on | 18:46.09 |
| tor8 | Robin_Watts: annotations in pdf have the same problem of pickling the list once in the get_annotations call and not being robust against changes after that | 18:46.34 |
| Robin_Watts | tor8: Turns out I didn't need to pickle the list, so I'm feeling happier. | 18:47.00 |
| tor8 | as long as we don't anticipate edits showing up in the returned list (instead, get a new list after edits) we should be okay, until we can figure something better out for both these cases | 18:47.01 |
| mvrhel_laptop | bbiab | 18:51.04 |
| avih | tor8: i know you need some motivation, so here's a decent standard compliant (i think/hope) Number.toString https://0x0.st/l6f.txt | 19:07.12 |
| | :) | 19:07.16 |
| | that's js. i bet you'd want to rewrite that in c :p | 19:07.29 |
| | the isNaN(this) test is incorrect i think. but overall should be easy to fix the initial checks. | 19:12.33 |
| mvrhel_laptop | Robin_Watts: so on my repos on the robin_lcms_b branch there is a commit | 22:06.16 |
| | if you can add that I would appreciate it | 22:06.27 |
| | my earlier issue was a screw up on visual studio | 22:07.31 |
| | so I am finding VS 2017 to be a little less stable than 2015 was | 22:07.45 |
| | It has crashed on me several times | 22:07.55 |
| Robin_Watts | mvrhel_laptop: I'll pull that in tomorrow. | 23:08.20 |
| mvrhel_laptop | Robin_Watts: ok thanks | 23:08.30 |
| Robin_Watts | I'll run through tor8's list with him and try and do as much as we can towards getting this committed. | 23:08.52 |
| | Did you see anything in there that you objected to? | 23:09.01 |
| mvrhel_laptop | Robin_Watts: Some things I don't quite follow. Let me take a quick look | 23:15.06 |
| | We can't do any lazier load of the output intent | 23:16.58 |
| | It is a document level thing | 23:17.15 |
| | At least I don't see how | 23:17.31 |
| | Mudraw actually may need to access it | 23:17.55 |
| | to know what type of bit map to allocate if it really wants to do proper color managment | 23:18.15 |
| | fz_colorspace_is_pdf_cal -> fz_colorspace_is_cal (no need to mention | 23:18.39 |
| | PDF in fz namespace, imo) | 23:18.40 |
| | I actually prefer pdf_cal | 23:18.49 |
| | since only pdf has those | 23:18.54 |
| | but I can go either way | 23:18.59 |
| | The rest seem reasonable to me Robin_Watts | 23:20.39 |
| Robin_Watts | cool, thanks. | 23:22.23 |
| mvrhel_laptop | ok one blend case in ghent working | 23:42.55 |
| | enough of that for the day. I think the others will fall into place | 23:43.06 |
| | Forward 1 day (to 2017/06/21)>>> | |
Log of #mupdf at irc.freenode.net.
