| | <<<Back 1 day (to 2013/06/04) | 2013/06/05 |
| ray_laptop | I now understand why the clipping change fixed bug 694290. The clip box ends up "empty" when it intersects it with the page rect, but the "outer_box" is NOT empty before the change because gx_cpath_set_outer_box is gets values that are not mapped to a device pixel (it uses fixed_floor and fixed_ceiling) | 01:05.31 |
| | With the change, the pcpath.bbox is 0xffff1c00 but before it was 0xffff1b7a. The fixed_floor gives 0xffff1b00 and fixed_ceiling gives 0xffff1c00 for the value that is not an exact device pixel. | 01:12.09 |
| | at least I'll be able to sleep tonight -- I hate when things work and I don't know why. :-) | 01:12.41 |
| mvrhel_laptop | Robin_Watts: for when you come on, I did an amend to my the top commit in my repos that had your suggestions. It was good for me to do it since there were some issues | 06:03.21 |
| paulgardiner | tor8, Robin_Watts: couple of commits on paul/master - maintaining the separate xref sections on document load, and creating a new section on update. No alteration to saving as yet. The diffs are very confused so it's going to be hard to check | 11:26.22 |
| Robin_Watts | OK. | 11:34.53 |
| | http://www.virgin-atlantic.com/us/en/travel-information/customer-service/latest-news.html | 12:18.38 |
| | paulgardiner: Will pick you up on friday morning at 7:45ish. | 12:23.36 |
| paulgardiner | Oh. That's an improvement :-) | 12:25.05 |
| Robin_Watts | yeah, half hour better. | 12:25.26 |
| | We should be at heathrow by 9ish, which is 2.5 hours before the flight - loads of time for hand luggage only. | 12:26.52 |
| paulgardiner | Hmmm. How many breakfasts can we fit into 2.5 hours? Ah, should be okay. | 12:33.05 |
| Robin_Watts | "reinstate" | 12:35.16 |
| | I dislike the use of '0' for the whence field in fz_seek, I much prefer SEEK_SET. | 12:36.50 |
| | (and yes, I know it's tor8's fault :) ) | 12:37.01 |
| paulgardiner | Oh yes. I prefer SEEK_SET... and correct spellings! | 12:45.33 |
| Robin_Watts | I am confused by the "If an XRefStm contains a Prev field, it should be ignored" comment. | 12:46.35 |
| | Because it immediately follows a place where you read the xrefstm trailer, and drop any produced object. i.e. nothing to do with Prev. | 12:47.12 |
| paulgardiner | In the spec somewhere. I'll see if I can find the page | 12:47.15 |
| Robin_Watts | THEN you read Prev out of the current trailer and work with that. | 12:47.27 |
| | i.e. I can't see any special handling of the Prev in the xrefstm case. | 12:47.58 |
| paulgardiner | The dropped trailer may have had a Prev tag | 12:49.23 |
| Robin_Watts | Ah. | 12:49.41 |
| paulgardiner | pdf_read_xref will have stored the trailer for that particular section. | 12:50.07 |
| Robin_Watts | "Read the XRefStm trailer, and throw the object away. We never follow any Prev tag therein, as the spec says it should be ignored" ? | 12:50.53 |
| | (and add a reference to the spec section in question) | 12:51.04 |
| paulgardiner | Yeah. Good thought | 12:52.08 |
| Robin_Watts | Is there potential for a maliciously constructed file to get us into an infinite loop in pdf_read_xref_sections ? | 12:52.47 |
| | trailer->prev = trailer ? | 12:53.02 |
| | or even trailer->prev = trailer2, trailer2->prev = trailer ? | 12:53.15 |
| paulgardiner | The original code had protection and I believe I've maintained it. | 12:53.24 |
| Robin_Watts | ah, right, sorry. | 12:54.02 |
| | so you have. | 12:54.06 |
| | OK, that concludes my nitpicking for the first commit :) | 12:54.56 |
| paulgardiner | These need careful looking at. I appreciate it. I just hope you can make sense of the diffs for the second one. I'm less confident of the correctness of that one | 12:56.18 |
| Robin_Watts | If xref has ctx in, why do we pass ctx to pdf_resize_xref ? | 12:59.04 |
| | It's a static function, so there is no need to maintain the API. | 12:59.32 |
| paulgardiner | A pdf_xref doesn't have a ctx, I think | 12:59.44 |
| Robin_Watts | paulgardiner: Certainly used to. | 12:59.59 |
| paulgardiner | That's pdf_document, which is often used in the form "pdf_document *xref" | 13:00.33 |
| Robin_Watts | Ah, you're right. | 13:01.05 |
| | Sorry. Indeed, confusing diffs :) | 13:01.15 |
| | "populating" vs "active"... | 13:13.57 |
| | I get that it's "populating" because it's the xref section that is currently being populated. | 13:14.32 |
| | but after the pdf has loaded, it's not really populating, right? (unless we make changes to the document). | 13:14.56 |
| paulgardiner | But then those routines shouldn't be used | 13:15.16 |
| Robin_Watts | Would 'active' be a better name? Especially if we want to allow people to 'step back to a previous version of the doc' ? | 13:15.22 |
| | pdf_get_populating_xref_entry will still be used, right? | 13:15.32 |
| | oh. no, pdf_get_xref_entry will be used ? | 13:16.28 |
| paulgardiner | Or pdf_get_new_xref_entry if updating | 13:16.59 |
| | I'm amazed that you are managing to make sense of those diffs | 13:17.50 |
| | pdf_get_new_xref_entry (which may be static IIRC) pushes a new section on the end if that hasn't been done already since loading and also allows for that section to grow | 13:19.31 |
| | We may need to enhance the API later to deal with access to old sections | 13:20.22 |
| Robin_Watts | AIUI, each section of the xref you load is defined for entries 0 to max | 13:20.53 |
| paulgardiner | Yes, where max may differ between sections | 13:21.29 |
| Robin_Watts | I wonder if it would be better to only have the entries defined in each section that are actually defined. | 13:21.34 |
| | i.e. if the first xref defines 0 to 1000, and the second defines 1000 to 2000, why hold 0 to 2000 in the second section? | 13:22.05 |
| | I've got to grab some lunch. Will continue staring at this afterwards. | 13:22.32 |
| paulgardiner | Yes. Just to avoid adding more complication to the data structures. That optimisation could be added lated | 13:22.45 |
| | later | 13:22.49 |
| Robin_Watts | paulgardiner: ping | 14:07.21 |
| paulgardiner | pong | 14:07.28 |
| Robin_Watts | In pdf_get_new_xref_entry... | 14:07.28 |
| | you doc->num_xref_sections++ | 14:07.39 |
| | then you resize | 14:07.42 |
| | if the resize fails, you've still done the increment. | 14:07.59 |
| | You should increment after the resize. | 14:08.14 |
| paulgardiner | Yeah. How does fz_resize_array fail? I guess the fact that it throws means that ->table is left unchanged, but is it still a valid memory pointer? | 14:09.19 |
| Robin_Watts | doc->xref_sections = fz_resize_array(ctx, doc->xref_sections, ...) | 14:09.48 |
| | if resize_array throws, then doc->xref_sections will be unchanged. | 14:10.02 |
| paulgardiner | and still valid? | 14:10.14 |
| Robin_Watts | yes. | 14:10.18 |
| | It's just realloc. | 14:10.23 |
| paulgardiner | Okay. Good call | 14:10.24 |
| Robin_Watts | In pdf_replace_xref you don't mean fz_var(ctx); :) | 14:11.39 |
| | I suspect you mean fz_var(trailer); | 14:12.01 |
| paulgardiner | Yup :-) | 14:12.23 |
| Robin_Watts | and might you need a rethrow | 14:12.27 |
| | ? | 14:12.29 |
| paulgardiner | Oops! Yes. That's careless | 14:12.50 |
| Robin_Watts | In pdf_close_document... | 14:17.07 |
| | you do pdf_free_xref(xref); then immediately access xref->page_objs | 14:17.23 |
| | That may be fine actually. It might we one of the doc == xref things. | 14:18.38 |
| paulgardiner | Christ! That's a complete mess | 14:18.52 |
| | Oh. Yes. You are right. | 14:19.56 |
| Robin_Watts | paulgardiner: could we rename pdf_free_xref to be free_document_xref_sections ? | 14:19.58 |
| paulgardiner | I thought I'd made a complete mess of that for a minute | 14:20.07 |
| | Good yes | 14:20.26 |
| Robin_Watts | pdf_populate_next_xref_level : same increment/resize thing. | 14:21.02 |
| | other than that, it's fine. | 14:21.47 |
| paulgardiner | Yeah. I've done that one | 14:22.05 |
| | So hopefully none of that should break pdf_write in any way, or support for linear pdf | 14:23.34 |
| | I've done some tests and it seems okay. Cluster says it's fine | 14:23.51 |
| Robin_Watts | so all those are fixed in the latest versions? | 14:28.18 |
| paulgardiner | Robin_Watts: I've just corrected the issues you spotted and repushed. I'm just going to set up another cluster test. | 14:28.35 |
| Robin_Watts | paulgardiner: You're missing michaels latest commit in your history. | 14:29.06 |
| | I don't suppose that will matter to the cluster test though as it's mostly WinRT stuff. | 14:29.22 |
| paulgardiner | A rebase needed? | 14:29.24 |
| Robin_Watts | paulgardiner: at some point, but I can do that when it's time to push if needed. | 14:29.44 |
| paulgardiner | okay ta | 14:29.57 |
| | Unless you can easily kill my cluster test | 14:30.27 |
| Robin_Watts | paulgardiner: You can kill your own cluster test. | 14:30.33 |
| | "git cluster abort" | 14:30.38 |
| paulgardiner | ah right brilliant | 14:30.49 |
| Robin_Watts | but I wouldn't bother. | 14:30.50 |
| | tor8, paulgardiner: There is a commit to fix leaking xps images on robin/master | 14:33.07 |
| paulgardiner | Okay | 14:33.17 |
| | Robin_Watts: did you push it yet? | 14:41.55 |
| Robin_Watts | paulgardiner: I was waiting for your tests. | 14:42.06 |
| paulgardiner | I mean yours to your repo | 14:42.20 |
| Robin_Watts | paulgardiner: yeah, should be there. | 14:43.15 |
| | 5th one in. sorry. | 14:43.27 |
| paulgardiner | I was confused by its saying 18h ago | 14:44.15 |
| Robin_Watts | Morning mvrhel_laptop. I pushed your commit to golden. | 14:46.12 |
| mvrhel_laptop | Robin_Watts: ok great. thanks | 14:47.48 |
| | I have to help get the kids off to school and then will be back. I may need your help cleaning up a few things in git.... | 14:48.31 |
| Robin_Watts | mvrhel_laptop: No problem. | 14:48.44 |
| paulgardiner | Robin_Watts: I think fz_new_image_from_data can still leak if fz_new_image_from_buffer throws | 14:55.28 |
| Robin_Watts | you're right. | 14:56.08 |
| paulgardiner | And "keeping" the original buffer rather than creating a new one has a risk of aliasing, but I'd imagine you wouldn't have done it if that was really a possibility | 14:57.06 |
| | Cluster still says my commits are okay. | 14:58.25 |
| Robin_Watts | paulgardiner: Yeah, aliasing not a problem here. | 14:58.53 |
| | new version of my commit online now. | 15:00.50 |
| | pushed your changes. | 15:02.23 |
| paulgardiner | ta | 15:09.32 |
| Robin_Watts | paulgardiner: Are you happy with my revised patch? | 15:11.22 |
| paulgardiner | Still looking | 15:12.00 |
| | Should you be freeing data? | 15:12.54 |
| | I thought only buffer | 15:13.10 |
| Robin_Watts | ownership of "data" passes in. | 15:13.52 |
| | hence if the buffer fails to make, I need to free data. | 15:14.22 |
| | possibly, fz_new_buffer_from_data should be responsible for freeing data if it fails to make. | 15:14.57 |
| paulgardiner | Did you miss that on the last version? My memory of it was just buffer being freed | 15:15.47 |
| Robin_Watts | I did miss that on the last version. | 15:16.01 |
| paulgardiner | Ah okay. Fine then | 15:16.22 |
| Robin_Watts | thanks. | 15:16.26 |
| | marcosw: Bug 694083... | 15:16.34 |
| paulgardiner | np | 15:16.36 |
| Robin_Watts | You say I broke stuff on 1f80c02. | 15:16.45 |
| marcosw | Robin_Watts: good morning to you too | 15:16.52 |
| Robin_Watts | Did it not all get fixed on the next one? | 15:16.56 |
| | Morning marcosw :) | 15:16.59 |
| marcosw | Robin_Watts: probably. It's fixed now. | 15:17.44 |
| Robin_Watts | Right. There was a stupid typo in the first commit. | 15:17.59 |
| marcosw | the nightly regression ran between the 1f80c02 and the next one, otherwise I wouldn't have noticed it. | 15:19.15 |
| | btw, when are you leaving for MIA? | 15:19.23 |
| Robin_Watts | friday morning | 15:19.41 |
| | If we're not there by the meeting on saturday, it'll be cos we're all still in the immigration line. | 15:20.17 |
| marcosw | me too :-) Odd how the time difference works. | 15:20.18 |
| | was it bad when you went to boston (?) last week? | 15:21.27 |
| Robin_Watts | boston took 1 hour. | 15:22.04 |
| | last time at miami it took 2 hours. | 15:22.14 |
| kens2 | 2+ | 15:22.33 |
| Robin_Watts | supposedly miami is worse now than it was (and is one of the worst places) | 15:22.38 |
| kens2 | Miami is always bad, now its diabolical | 15:22.58 |
| Robin_Watts | the worse thing is that 4 jumbos arrive at more or less the same time, so depending on small differences in timing, you can end up with huge differences in queue length. | 15:24.01 |
| marcosw | I'm so spoiled, between my German passport and Global Entry I haven't stood in a customs line in forever. | 15:24.39 |
| Robin_Watts | sadly, we can't do global entry :( | 15:28.15 |
| mvrhel_laptop | ok I believe I have found the Igor softmask issue | 16:45.26 |
| Robin_Watts | mvrhel_laptop: PDF/A day in seattle. on August 14th/15th. | 16:49.09 |
| mvrhel_laptop | Robin_Watts: through what organization? | 16:49.38 |
| Robin_Watts | let me forward the email to tech | 16:49.40 |
| | pdfa.org | 16:49.49 |
| | oh, it went to support as well anyway. | 16:50.23 |
| ray_laptop | In order to have something to work on while flying (and while tuning out other people during the staff meeting ;-) ) I've started work on a branch for bug 693684. | 17:20.31 |
| mvrhel_laptop | hmmm. there seems to be a key missing part of my simulated overprint code | 17:22.33 |
| | oh ok | 17:23.03 |
| ray_laptop | Not much is there yet, but I'd like folks to review the documentation change at http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=blob_plain;f=gs/doc/Use.htm;hb=HEAD#Rendering_parameters | 17:23.06 |
| mvrhel_laptop | helps when I search on the entire solution and not just current document | 17:23.16 |
| Robin_Watts | ray_laptop: Did you still want another pair of eyes on some code? | 17:23.44 |
| mvrhel_laptop | ray_laptop: are you moving stuff that was off in other areas of the doc into this part? | 17:24.26 |
| | I think that we talked about this at one time | 17:24.33 |
| Robin_Watts | http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=bb2956b6218c08998c1869327ba0073dee951474 | 17:24.39 |
| ray_laptop | Robin_Watts: just the device param changes for now. | 17:25.19 |
| Robin_Watts | ray_laptop: yesterday you were requesting that either I or henrys look at something... | 17:25.46 |
| ray_laptop | Robin_Watts: but any other comments are welcome. BTW, in the log msg, I forgot to mention that this was bug 693684 | 17:26.13 |
| Robin_Watts | +<code>InterpolateControl</code> less than 0 <b>forces</b> interpolation | 17:26.51 |
| | +but limits the interpolation to the absolute value of the control value. | 17:26.53 |
| | what control value ? | 17:27.04 |
| mvrhel_laptop | oh interesting | 17:28.09 |
| ray_laptop | rather than "control value" is "the value of the parameter" ?? | 17:28.28 |
| Robin_Watts | Having read the docs, I have no idea what the values other than 0, 1 and -1 mean. | 17:28.51 |
| mvrhel_laptop | so with CMYK colors, we do simulate overprint for a device like tiff32nc always. regardless of the setting of -dSimulateOverprint since we can. | 17:29.14 |
| | it was simulating spot color overprinting that I enabled with this | 17:29.32 |
| | for those devices | 17:29.36 |
| | ray_laptop: what do you think we should do for this | 17:29.46 |
| ray_laptop | Robin_Watts: OK. I can add an example. For example, -dInterpolateControl=4 would only interpolate images to at most 4x4 device pixels | 17:29.56 |
| mvrhel_laptop | previously we would simulate the overprinting of CMYK colors always and spots never got simulated | 17:30.16 |
| | with my change you can enable or disable the overprint simulation of the spot colors | 17:30.32 |
| | but the cmyk color are always overprint simulated | 17:30.50 |
| Robin_Watts | ray_laptop: You mean that if we specify a value, f, s.t. f > 1, we will only interpolate to at most an upscale factor of f ? | 17:31.02 |
| ray_laptop | mvrhel_laptop: you mean we would perform overprinting on the C, M, Y, and K components (since they are already separate, it didn't need simulation) | 17:31.12 |
| mvrhel_laptop | this may seem like odd behavior compared to AR | 17:31.14 |
| | yes | 17:31.17 |
| ray_laptop | mvrhel_laptop: but I think that defaulting to SimulateOverprint makes sense | 17:31.36 |
| mvrhel_laptop | and if someone turns it off.... | 17:31.52 |
| | then I need to ignore any overprint stuff | 17:32.23 |
| | including colorants the device supports | 17:32.35 |
| ray_laptop | Robin_Watts: If the image requires upscaling, due to the CTM and ImageMatrix, then we will only interpolate _down_ to the the given number of device pixels (e.g. 4) | 17:33.02 |
| mvrhel_laptop | ray_laptop is multiplexing.... | 17:33.14 |
| Robin_Watts | ray_laptop: I don't follow. | 17:33.43 |
| ray_laptop | If the image doesn't upscale by at least 4:1, then with InterpolateControl=4, interpolation is skipped | 17:33.48 |
| Robin_Watts | Ah. For f > 1, f specifies the minimum scale factor required before interpolation occurs. | 17:34.21 |
| ray_laptop | mvrhel_laptop: yes, I think that's what AR does when you have Overprint Preview unchecked. ( ignores any overprint stuff including colorants the device supports) | 17:35.07 |
| Robin_Watts | For f < 0, |f| specifies the maximum scale factor that interpolation will happen too. | 17:35.17 |
| ray_laptop | Robin_Watts: AND it limits how finely we will interpolate. | 17:35.35 |
| | Robin_Watts: AND it limits how finely we will interpolate when f > 0 | 17:36.11 |
| | mvrhel_laptop: I actually haven't looked at what Acrobat creates when saving to TIFF CMYK with Overprint Preview off (with a file that does some visible stuff on the C, M, Y or K channels) | 17:37.54 |
| mvrhel_laptop | ray_laptop: ok. sounds good. I will make us have overprint simulation on by default and when it is disabled we will ignore overprinting | 17:38.01 |
| | ray_laptop: let me try that | 17:38.23 |
| | the tiff save | 17:38.27 |
| ray_laptop | does mupdf do Overprint Preview ? | 17:38.39 |
| | since it is on by default with AR, it seems like we would want to. | 17:39.10 |
| mvrhel_laptop | hmmm it appears that I can only turn off overprint in the advanced settings | 17:39.23 |
| | and when I leave those settings it always reverts back to showing it with overprint | 17:39.41 |
| ray_laptop | mvrhel_laptop: It may require full Acrobat, not just the free reader | 17:39.47 |
| mvrhel_laptop | I have the full version | 17:39.52 |
| | and like I said, I can "preview" it in a special menu | 17:40.11 |
| ray_laptop | mvrhel_laptop: what's a good file to try ? | 17:40.12 |
| | mvrhel_laptop: and what version of Acrobat are you using ? | 17:40.34 |
| mvrhel_laptop | the one attached to bug 694295 | 17:40.39 |
| ray_laptop | iirc, they defeatured some later versions. | 17:41.00 |
| mvrhel_laptop | Acrobat 9 pro | 17:41.00 |
| ray_laptop | mvrhel_laptop: thanks for the bug # | 17:41.00 |
| mvrhel_laptop | I refuse to upgrade since they removed several nice features with the upgrades | 17:41.22 |
| ray_laptop | mvrhel_laptop: OK, same as what I have. | 17:41.41 |
| Robin_Watts | For f>1, and a desired upscale of factor F: | 17:42.10 |
| | If f <= F, no interpolation | 17:42.12 |
| | otherwise the image is interpolated to F/f and that image is plotted without interpolation at factor f. | 17:42.14 |
| | For f = 1, no interpolation is ever done. | 17:42.16 |
| | For f = 0, no interpolation is done except when the /Interpolate flag in the image is true. | 17:42.18 |
| | For f < 0, and a desired upscale of factor F: | 17:42.19 |
| | If |f| <= F, interpolation | 17:42.21 |
| | otherwise, the image is interpolated to f and then plotted without interpolation at factor F/f. | 17:42.22 |
| ray_laptop | mvrhel_laptop: and I've refused to upgrade for the same reason. I was considering it until kens mantioned the issues with 10 | 17:43.20 |
| | Robin_Watts: I think I follow that. and when f < 0, interpolation is performed on every image, regardless of the image /Interpolate setting | 17:44.13 |
| Robin_Watts | ray_laptop: I think I would (personally) prefer something like that explanation rather than english text. | 17:45.14 |
| | fixed to be correct of course. | 17:45.21 |
| | Or maybe have the english text too. | 17:45.28 |
| | Am I right in thinking that /Interpolate is only consulted for f = 0 ? | 17:46.15 |
| ray_laptop | Robin_Watts: I'll take a shot at revising the doc with an example. Thanks for the comment. If you weren't clear, then at least 99.9% of other readers probably wouldn't understand | 17:46.29 |
| Robin_Watts | ray_laptop: "an" example won't help. | 17:46.51 |
| ray_laptop | Robin_Watts: /Interpolate is used whenever f >= 0 | 17:46.52 |
| mvrhel_laptop | hmm with overprint simulation on by default this is going to change a lot of files | 17:46.56 |
| Robin_Watts | ray_laptop: Oh. | 17:47.10 |
| | Could I suggest swapping 0 and 1 ? | 17:47.22 |
| mvrhel_laptop | not to mention I also need to make sure all is fine with the separation devices, which I needed to do anyway | 17:47.28 |
| Robin_Watts | /Interpolate is clearly not used as specced at the moment when f = 1. | 17:47.51 |
| ray_laptop | Interpolate is ignored if f < 0 (always interpolate), or when the upscale factor is < f | 17:48.05 |
| Robin_Watts | ControlInterpolation = 0 => never interpolate makes sense. | 17:48.09 |
| mvrhel_laptop | so if someone is going out to tiffsep and overprint simulation is off I need to ignore then too | 17:48.10 |
| Robin_Watts | ControlInterpolation = 1 => interpolate as in the spec also makes sense. | 17:48.23 |
| | /Interpolate only being consulted when f >= 1 also makes sense. | 17:48.47 |
| | and special values being > 1 and < 0 makes sense. | 17:48.58 |
| | 0 and 1 seem swapped to me at the moment. | 17:49.07 |
| ray_laptop | Robin_Watts: InterpolateControl=1 would do the same as 0 so I "overloaded' the parameter to have it be equivalent to some really big number. | 17:49.16 |
| Robin_Watts | ray_laptop: eh? | 17:49.41 |
| ray_laptop | Robin_Watts: but if you think that is too confusing, then I'm willing to have -dNOINTERPOLATE be equivalent to -dInterpolateControl=999999999 (or 1g) | 17:50.20 |
| Robin_Watts | InterpolateControl=f (for some integer f > 1) means 'only interpolate to within a factor of f of the desired output resolution', right? | 17:51.07 |
| ray_laptop | Robin_Watts: well, swapping 0 and 1 would make more sense, thinking about it. Thus the default in the devices is 1 | 17:51.22 |
| | Robin_Watts: for backward compatibility | 17:51.31 |
| Robin_Watts | InterpolateControl=f (for some integer f > 1) means 'only interpolate to within a factor of f of the desired output resolution - and then only when /interpolate is set', right? | 17:51.41 |
| | ray_laptop: Right. | 17:51.44 |
| | That was my thought. | 17:51.49 |
| ray_laptop | Robin_Watts: right | 17:51.54 |
| Robin_Watts | fab. | 17:52.02 |
| ray_laptop | OK. Would it be too confusing to have the code use the 0 and 1 the other way ? The issue is that some devices use the C hack of initializing the device structure only up to the parameter they care about, then assuming that the remainder of the structure will be filled with 0's | 17:53.58 |
| | Too mitigate confusion in the code, I could compare with INTERPOLATE_CONTROL_ON and INTERPOLATE_CONTROL_OFF (where ON == 0 and OFF = 1) | 17:55.07 |
| Robin_Watts | ray_laptop: yeah, I feared you might say that (about the C init) | 17:56.37 |
| ray_laptop | unfortunately, too few initializers doesn't even produce a warning :-( | 17:56.43 |
| Robin_Watts | You could have the param be: interpolationcontrolminusone | 17:57.00 |
| ray_laptop | huh?? | 17:57.18 |
| | I'll pretend you didn't suggest that ;-) | 17:57.43 |
| | Robin_Watts: I like the user's parameter being 0 for NOINTERPOLATE and the current (standard) behaviour being 1 as the default. | 17:59.25 |
| Robin_Watts | ray_laptop: 0 being nointerpolate and 1 being default as far as the user is concerned is a good thing. | 18:00.02 |
| ray_laptop | I'll see if I can code it in a way that is not too confusing, but allows for the default value being 0 in the device struct. | 18:00.05 |
| | Robin_Watts: d'accord | 18:00.16 |
| Robin_Watts | swapping the values within the dev is nasty, but I understand why, and I'm inclined to agree with it. | 18:00.38 |
| ray_laptop | at least this lets us eliminate the hacks in gs_init.ps (and work with PDL's other than PS and PDF) | 18:01.53 |
| | of course, gs_init will still have to permute -dDOINTERPOLATE and -dNOINTERPOLATE into the InterpolateContol={1, 0} values | 18:03.28 |
| | of course, gs_init will still have to permute -dDOINTERPOLATE and -dNOINTERPOLATE into the InterpolateContol={-1,1} values that is | 18:03.49 |
| | of course, gs_init will still have to permute -dDOINTERPOLATE and -dNOINTERPOLATE into the InterpolateContol={-1,0} once again :-( | 18:04.08 |
| | I'll probably get it confused again when I update gs_init.ps :-/ | 18:05.46 |
| | but at least it's easy to test. I'll probably make up a simple example with images at a variety of upscale factors in the same file | 18:06.36 |
| | Robin_Watts: thanks again for the suggestions. | 18:08.02 |
| Robin_Watts | no worries. | 18:08.10 |
| ray_laptop | I wonder if kens wants to come to Seattle in August ? | 18:09.35 |
| mvrhel_laptop | ok so I have the -dSimulateOverprint=false working to not do overprint even with CMYK colorants | 18:19.27 |
| | and -dSimulateOverprint=true by default | 18:19.37 |
| | ray_laptop: what is your opinion about the separation devices though | 18:19.48 |
| | I guess those will also be disabled if someone specifies -dSimulateOverprint=false | 18:20.07 |
| | I just need to check that -dSimulateOverprint=true does not cause issues with tiffsep and psdcmyk now | 18:20.30 |
| | iirc something was going wrong in that case | 18:20.42 |
| win8dev | Hello. Can anyone help me get pointed in the right direction with MuPDF? | 19:34.42 |
| | I'm trying to use it to display a PDF in a windows 8 app. However, the documentation is very sparse. I was thinking that the Document.DrawPage(...) method would take a buffer and put pixels into that could then be displayed as a bitmap. However, I'm not having much luck. | 19:34.52 |
| | Figured it out. lol thanks | 19:53.37 |
| ray_laptop | I see from LinkedIn that Max has been at Onyx for 23 years. I hope he doesn't experience what I did after 23 years at my previous company (less than one month after my 23rd anniversary). The President and VP of HR come into my office, shut the door and sat down. Next thing was that 15 of my department were "RIFed" that day, and seven of us had 1 month. Three months later the company was shut down. | 20:14.03 |
| mvrhel_laptop | ugh. the overprint simulation issue has just dragged in the clist.. | 20:58.29 |
| | Robin_Watts: you still up? | 22:00.47 |
| | tor8: so I have one tiny change that is needed in an open jpeg header file that is needed to ensure that the ARM platform will compile in visual studio. I am not sure how I commit the thirdparty submodule changes | 22:05.42 |
| | or Robin_Watts ^^ | 22:05.47 |
| | a little late in the evening for you guys. especially with travel coming... | 22:07.45 |
| | henrys: do you know if there is anything special that I need to do, do commit in the submodule? | 22:08.11 |
| | s/, do/, to/ | 22:08.26 |
| henrys | mvrhel_laptop: I haven't dealt with the yet | 22:26.24 |
| mvrhel_laptop | ok np. I will wait and chat with tor or robin tomorrow | 22:26.45 |
| | I have plenty in the way of softmasks and overprint to keep me busy | 22:27.04 |
| Robin_Watts | mvrhel_laptop: Hi | 23:11.25 |
| | So, change into thirdparty/openjpeg | 23:11.43 |
| | and commit the change. That will go into the git submodule. | 23:12.05 |
| mvrhel_laptop | Robin_Watts: ok | 23:13.00 |
| Robin_Watts | You can then push that to the remote repo | 23:14.43 |
| mvrhel_laptop | Robin_Watts: for some reason it complains that my submodule is dirty | 23:14.58 |
| Robin_Watts | Then you change back to the mupdf root dir. | 23:14.59 |
| mvrhel_laptop | any idea what that means? | 23:15.05 |
| Robin_Watts | dirty means there are changes in there that aren't committed. | 23:15.23 |
| | if you change into thirdparty/openjpeg and do git status it should show you. | 23:16.12 |
| mvrhel_laptop | ok. it shows the one file being modified | 23:17.00 |
| | oh I see | 23:17.39 |
| Robin_Watts | so, commit that change. | 23:18.02 |
| | Then change back into mupdf | 23:18.13 |
| | then git add thirdparty/openjpeg | 23:18.22 |
| | then git commit (and say something like "Pull in submodule change for ARM build") | 23:18.51 |
| mvrhel_laptop | hmm now when I am in here is says current HEAD Detached | 23:19.03 |
| | and that I am working on no branch do I want to create a branch now | 23:19.28 |
| | does that seem correct? | 23:20.15 |
| Robin_Watts | At the moment we're on "zeniko_fixes" | 23:20.16 |
| | Probably you want to do: | 23:20.25 |
| | git branch artifex | 23:20.30 |
| | git checkout artifex | 23:20.34 |
| | or maybe: mupdf rather than artifex. | 23:20.44 |
| mvrhel_laptop | so create a branch in the third party submodule | 23:21.21 |
| Robin_Watts | Yes. create a mupdf branch in the third party submodule. | 23:21.33 |
| | commit the submodule changes to that branch. | 23:21.40 |
| | then push that branch to the remote repo. | 23:22.01 |
| | then once that's done, we can change the mupdf repo itself to tell it to use that branch. | 23:22.23 |
| mvrhel_laptop | hmm. It is not clear to me that I am in the zienko_fixes branch, so I dont know how all of tis will merge in | 23:24.15 |
| | that, is I don't know what I am branching off of | 23:24.28 |
| | this third party module stuff is weird | 23:24.39 |
| | ok I am branching of of ziniko_fixes | 23:24.58 |
| Robin_Watts | mvrhel_laptop: The problem with the git submodule stuff is that mupdf specifies the position of the submodule by SHA, not by branch name. | 23:25.07 |
| | hence you're in detached head state unless you tell your submodule what branch name to use. | 23:25.58 |
| | but it sounds like you're doing OK. | 23:26.05 |
| mvrhel_laptop | hmm. I will fool with this later. off to ump a championship little league game... | 23:28.11 |
| | Forward 1 day (to 2013/06/06)>>> | |
IRC Logs