| <<<Back 1 day (to 2013/10/08) | 2013/10/09 |
mvrhel_laptop | looks like an issue with isolated knockout groups... | 00:06.29 |
| interesting pdfwrite inserts an isolated knockout group where there was not one before | 00:07.58 |
| in any event, the rendering is wrong | 00:08.09 |
ray_laptop | speak of the bot | 05:22.57 |
| repeating for the logs... | 05:24.50 |
| mvrhel_laptop: pdfwrite should only issue compositor actions corresponding to what it's given, right ? | 05:24.57 |
| but the PDF interpreter does insert isolated groups under some conditions. But I don't think any of those are knockout. | 05:25.07 |
mvrhel_laptop | ray_laptop: well, in this case, the original file had no isolated knockout in this area and the output did | 05:26.17 |
| it is what it is | 05:26.23 |
| at this point, I am just trying to fix the rendering side of stuff | 05:26.38 |
| i have the issue cut down to a small piece now | 05:26.56 |
| and I think I see my issue | 05:28.22 |
ray_laptop | mvrhel_laptop: is 'knockout' set in the file at all ? | 05:48.50 |
mvrhel_laptop | dont know | 05:49.05 |
| fading fast due to cold | 05:49.13 |
ray_laptop | if so, it could be that it's being left in the ExtGstate when the PDF interp pushes an isolated group. | 05:49.46 |
mvrhel_laptop | maybe. i will bring it up for ken to look at | 05:50.17 |
ray_laptop | at least you can get it off your plate :-) | 05:50.53 |
mvrhel_laptop | I see the issue that pdf14_mark_fill_rectangle_ko_simple is not updating the shape, nor tags | 05:52.48 |
| I will fix this in the morning | 05:52.56 |
| good night ray_laptop | 05:53.07 |
| that is my rendering issue | 05:53.19 |
| not ken's issue above | 05:53.27 |
| hopefully this will be the final trans. issue for awhile. I found a pile of problems | 05:53.57 |
| I was rather surprised | 05:54.03 |
| tty tomorrow | 05:54.19 |
ray_laptop | mvrhel_laptop: sleep well.. | 05:54.57 |
sebras2 | good morning! | 07:17.52 |
| hi | 07:18.04 |
ghostbot | salut | 07:18.04 |
sebras2 | ghostbot: hello ghostbot, long time no see. :) | 07:18.15 |
chrisl | hi sebras2, how are you? | 07:21.10 |
ghostbot | just great, chrisl | 07:21.10 |
chrisl | thanks ghostbot, nice to share ;-) | 07:21.48 |
sebras2 | :) | 07:34.56 |
| I'm doing fine. I even managed to dodge most of the typhoon hitting .tw and .cn recently. | 07:35.19 |
chrisl | So when does the vacation part of the trip start? | 07:36.16 |
sebras2 | unfortunately it is over already. | 07:40.19 |
| chrisl: so now I'm just working until the end of october. | 07:40.34 |
chrisl | Oh, I thought you were going to finish off with vacation. | 07:41.29 |
sebras2 | chrisl: that was the plan until my manager here mentioned that they have national week celebration 1-7th of october. | 07:42.28 |
| chrisl: so I felt obliged to move my vacation. | 07:42.44 |
chrisl | Ah, I suppose that was fair. | 07:43.04 |
sebras2 | chrisl: hard to say no, when they are paying for me to be here. :) | 07:43.49 |
| chrisl: luckily my flights weren't booked when I got the news. | 07:44.21 |
| chrisl: btw... did the 9 (10?!) year anniversary of mupdf go by unnoticed here..? | 07:44.44 |
chrisl | sebras2: I don't think the event got much air time! I think Tor still considers the exact date lost in the mists of time | 07:46.17 |
sebras2 | chrisl: the earliest checkin I could find a date for was september 24th 9 years ago. | 07:48.15 |
| chrisl: when are you celebrating gs 25th anniversary? :) | 07:48.42 |
chrisl | sebras2: "celebrate" may not be the right word...... ;-) | 07:49.31 |
sebras2 | chrisl: I'm sure you'd be welcomed over to the mupdf camp... ;) | 07:50.40 |
chrisl | sebras2: ghostscript still needs hacking on | 07:52.28 |
Robin_Watts | Morning tor7. | 09:03.45 |
tor7 | hi Robin_Watts | 09:03.52 |
Robin_Watts | So, were you going to look at the cmyk thing? | 09:03.56 |
tor7 | flip a coin for it? | 09:04.29 |
Robin_Watts | If you want it, it's yours. | 09:04.46 |
tor7 | leave it on my desk, and if I haven't done anything with it in a while and you're bored feel free to take it back | 09:06.29 |
| I'd be happy to look at it once I've finished procrastinating about sorting these stencil mask clipping issues with the gl device | 09:07.03 |
| it *should* be a trivial fix, but my brain just refuses to cooperate :( | 09:07.21 |
| Robin_Watts: the two svg commits on robin/master look fine to me | 09:09.42 |
Robin_Watts | tor7:Thanks. | 09:10.01 |
sebras2 | tor7: and the person you explain all difficult things to has left you stranded... :) | 09:10.19 |
tor7 | and you might want to drop zeniko's untaken commits from your branch, he has his own copies on zeniko/master | 09:10.23 |
| sebras2: yes. bad boy! | 09:10.42 |
Robin_Watts | tor7: They are there to remind me to think about them. | 09:10.58 |
| paulgardiner: I don't know if you'd gone by the time I found this the other day... | 12:21.49 |
| http://cgit.freedesktop.org/libreoffice/core/tree/oox/ | 12:22.04 |
| LibreOffice has its docx support written in C++ | 12:22.15 |
| and it's MPL licensed (which is good enough for us, I believe) | 12:22.29 |
| so that might be another thing to consider. | 12:22.41 |
paulgardiner | Robin_Watts: yeah ta, I saw you put that up, and bookmarked it | 12:22.42 |
Robin_Watts | ok. I can close the browser tab now then :) | 12:22.55 |
paulgardiner | :-) | 12:23.04 |
Robin_Watts | tor7: 2 more commits on robin/master | 13:03.46 |
paulgardiner | tor7: were you happy for me to push those 2 iOS commits we discussed the other day? | 13:06.55 |
tor7 | paulgardiner: the second one is fine, the first one I wasn't sure if you wanted to rework more. it can go in as is, but I would like it to be made simpler if possible in this or another commit | 13:08.08 |
| Robin_Watts: fz_run_t3_glyph, shouldn't that be used elsewhere as well? | 13:09.01 |
| Robin_Watts: pixmap typo LGTM | 13:09.22 |
| though pix->colorspace && pix->colorspace != gray, the null-check is redundant | 13:09.54 |
| oh wait, no, nvm. | 13:10.19 |
| scratch that last sentence :) | 13:10.25 |
paulgardiner | tor7: okay, although I think the code in MuDocumentController.m could only be made more complicated by any change. It's just that the contents of MuTapResult.m is the price of the simplicity of the MuDocumentController addition (and is possibly a price too high). | 13:14.25 |
tor7 | paulgardiner: I'll leave it up to you, the code looks fine to go in as is. | 13:22.12 |
paulgardiner | okay ta. I may well just change it to switch on type and access the C union. | 13:24.25 |
Robin_Watts | tor7: I could make fz_render_t3_glyph_pixmap call fz_run_t3_glyph | 13:48.11 |
| and now you come to mention it, I can simplify the error handling in run. So let me rework that a bit. | 13:49.16 |
| tor7: better version up there now. | 13:57.41 |
tor7 | Robin_Watts: yeah, that looks good to commit. | 14:00.39 |
Robin_Watts | tor7: Thanks. | 14:02.19 |
| tor7: One of the next things to look at for the SVG output device is shadings. | 14:33.53 |
| I'm tempted to try to get shadings via images working as a first step, cos we can always drop back to that. | 14:34.25 |
tor7 | Robin_Watts: right. | 14:38.33 |
| apart from shadings with functions, getting the triangle meshes to work with opengl was trivial | 14:38.49 |
| the functions, I'm thinking of saving until I rewrite the device to use shaders | 14:39.12 |
Robin_Watts | I suspect that SVG will be able to cope with gradients and radial fills, but that meshes may be too much for it. | 14:39.58 |
tor7 | yeah. | 14:41.43 |
| and with the background and parametric color functions, we definitely need an image backup | 14:42.11 |
Robin_Watts | tor7: urgh. So, for some shadings, they are infinite in extent, and constrained only by the size of the current clipping path. | 15:18.21 |
kens | Yes that's true | 15:18.41 |
Robin_Watts | This means I need to hold a clip stack in the svg device :( | 15:18.53 |
kens | Not just a current clip ? | 15:19.05 |
tor7 | Robin_Watts: keep a scissor stack in device space | 15:19.23 |
| or just use the page size | 15:19.40 |
Robin_Watts | kens: I need to be able to get the current clip whenever I do a shading. | 15:19.45 |
| and I'm not passed the current clip as part of the shading device entry point. | 15:20.01 |
kens | ah well in that case... | 15:20.10 |
Robin_Watts | so the device needs to keep track - hence it needs to be a stack. | 15:20.17 |
| tor7: Yeah, I was thinking a stack of rects. | 15:20.38 |
tor7 | Robin_Watts: I'd just keep the scissor stack (maybe we should add that to the null-device) | 15:20.42 |
Robin_Watts | tor7: How can we add that to the null device? | 15:21.11 |
tor7 | Robin_Watts: in the fz_device_s struct | 15:21.39 |
| and the null-device functions could manage it | 15:21.49 |
| before forwarding calls | 15:22.03 |
Robin_Watts | Ah, so the actual function types wouldn't change. | 15:22.08 |
| i.e. no extra params. | 15:22.15 |
tor7 | and it'd be there in the fz_device *dev struct if any device wants it | 15:22.23 |
| Robin_Watts: yeah. no visible change to existing code. | 15:22.35 |
Robin_Watts | That would mean that the null device would have to do work on clips/pop clips etc. | 15:22.48 |
tor7 | though we might be able to prune some fz_rect arguments to some calls | 15:23.05 |
Robin_Watts | which isn't ideal for stuff like the bbox device. | 15:23.05 |
tor7 | it already does that, though, for the error_depth stuff | 15:23.44 |
Robin_Watts | tor7: yeah, but bounding a path is harder work than just checking error_depth, right? | 15:24.09 |
tor7 | Robin_Watts: true enough. | 15:24.34 |
| we could cache the fz_path (and fz_text) bounding boxes | 15:24.59 |
| cache the value as applied to a fz_identity matrix and then just multiply the result when fz_bound_xxx is called | 15:25.26 |
Robin_Watts | except we want the path bbox under the ctm. | 15:25.36 |
tor7 | though that may lead to suboptimal bboxes under non-orthogonal rotations | 15:25.58 |
Robin_Watts | which with rotations etc could be hugely out. | 15:26.10 |
tor7 | if non-orthogonal matrix, recalculate proper bbox, else use cached? | 15:26.58 |
Robin_Watts | If we move the clip stack processing into the null device, does that simplify bits of the draw device? | 15:28.09 |
| or are we going to end up doing stuff twice? | 15:28.22 |
| We could enable/disable the null device doing clip collation with a device hint. | 15:30.03 |
| That way we only take the hit when the device says it needs it. | 15:30.20 |
| I like that idea. | 15:30.23 |
Micha` | Howdy people. | 15:30.29 |
Robin_Watts | Micha`: hi. | 15:30.42 |
Micha` | Ah, Robin_Watts, great to see you; I have another MuPDF question :-) | 15:30.59 |
Robin_Watts | go for it. | 15:31.07 |
Micha` | So, again, this is Android focused: any reason why the so-called historical events in a MotionEvent bundle are not processed? | 15:32.14 |
Robin_Watts | Micha`: That probably needs to go to paulgardiner. | 15:32.37 |
tor7 | the draw device scissor stack handling could be simplified, I would hope | 15:32.39 |
Micha` | Robin_Watts: Ah, thanks; let's try that then. | 15:33.09 |
tor7 | and yes, a device hint would be a good way to enable/disable it | 15:33.11 |
Micha` | paulgardiner: ping? | 15:33.15 |
Robin_Watts | Let me fiddle with doing a scissor stack in the null device enabled/disabled with a hint and see how it works out. | 15:33.33 |
paulgardiner | Micha`: possibly my lack of knowledge of Android. What processing do you think might be missing? | 15:34.06 |
Micha` | paulgardiner: Yeah, I'm not being clear here, sorry. So I'm talking about MuPDFReaderView.java:OnTouchEvent. When an ACTION_MOVE comes in, it may be bundled with other such actions. According to the doc, these should be processed starting with the "historical" events, then the current event. | 15:35.48 |
| Something like http://pastebin.com/r4KzL3GF | 15:36.13 |
paulgardiner | Micha`: Oh okay. I didn't know that. I'd guess it was unimportant, other than when we are drawing Ink annotations. | 15:36.48 |
| For Ink annotations, we might manage a smoother drawing by considering the historical events. | 15:37.09 |
Micha` | True that :-) I've been disappointed by the PDF annotators on the market, so I'm trying to make one based on MuPDF, hence my specific needs. | 15:38.00 |
| I may start by just building on MuPDF, adding such things as color selection for Ink annotations, then fork when it gets too focused on my needs. | 15:39.17 |
Robin_Watts | Micha`: That'd be great. Improving the annotation support is on our list of things to do, but it keeps getting delayed by other stuff. | 15:40.09 |
| If you can feed anything back to us, we'd be very interested in seeing it. | 15:40.21 |
Micha` | In particular, I want to be able to change ink color in a transparent way, hence create multiple annotations without the user knowing, which is not good thing for MuPDF, I'll fork by then. | 15:40.36 |
Robin_Watts | You want to be able to create annotations that are transparent? | 15:41.31 |
paulgardiner | I think I get it: drawings in multiple colors | 15:42.19 |
Micha` | paulgardiner: precisely. | 15:42.29 |
| Hence having multiple annotations behave as one. | 15:42.38 |
| -- or altogether remove the concept of annotations from the user interface. | 15:42.54 |
Robin_Watts | Well the core changes to mupdf (to expose the ability to change the ink color in a nice programmatic way) is something we'd be interested in. | 15:43.17 |
| The changes to the android viewer specifics, probably not then. | 15:43.33 |
paulgardiner | Robin_Watts: actually I think those are in | 15:43.35 |
Robin_Watts | oh, right. | 15:43.39 |
paulgardiner | it's just at the Android level they are not used | 15:43.49 |
Micha` | paulgardiner: Color is hardcoded in the android jni. | 15:43.53 |
Robin_Watts | gotcha. | 15:43.57 |
| Micha`: Well, if you can offer us improvements to the app to allow the color to be set, we'd be interested in that, right paulgardiner ? | 15:44.22 |
Micha` | As far as I can tell, I'm not planning to touch the core library. | 15:44.50 |
paulgardiner | Yes definitely. I'm not sure we are uninterested in the idea of making it transparent | 15:44.52 |
Micha` | Ok then, I will let you know when I have some interesting things done. It'll certainly be a slow start, as I'm still unsure about a few parts of the app's structure, but I'll have something at some point :-) | 15:47.38 |
Robin_Watts | Micha`: MuPDF is released under the GNU GPL, as I'm sure you know. | 15:49.44 |
| We also release it commercially though, so if we did take any patches back from you, we'd need to get you to sign a CLA. (It can be done electronically I believe). | 15:50.31 |
| I mention this up front, just because I'd hate to see you spend time and then consider it wasted. | 15:51.02 |
| but I look forward to seeing what you can come up with. | 15:51.28 |
Micha` | That's no trouble. The FSF does the same, AFAIR. | 15:51.40 |
paulgardiner | tor7: a quick iOS question, the answer to which there is no reason why you should know, but worth a try: | 15:52.54 |
Robin_Watts | Getting contributors to sign a CLA is not unusal. | 15:52.54 |
| but the fact we are dual licensed commercially and under the GNU GPL is a little more unusual. | 15:53.22 |
Micha` | That's right, and I have no trouble with that; in fact, I do like this business model. | 15:55.31 |
Robin_Watts | great. | 15:57.12 |
paulgardiner | tor7: if I keep the pixmap pointer, and the CGDataProviderRef that wraps it, then if I alter the pixmap data, should I be able to reuse the CGDataProviderRef to create a new CGImage? | 15:59.04 |
Micha` | You said there is a todo list with items on annotation support, right? Any of those concerned with ink? | 15:59.56 |
ramy | hi, I have built mupdf and tried to integrate it in my android application, but every time I integrate it the search feature doesn't work!! | 16:02.01 |
| Although when I run it without integrating it with anything, it works!! | 16:02.41 |
| echoo | 16:07.00 |
kens | sees no question | 16:07.35 |
Micha` | :-) | 16:07.55 |
ramy | I have built mupdf and tried to integrate it in my android application, but every time I integrate it the search feature doesn't work!! | 16:08.11 |
Robin_Watts | ramy: OK. | 16:09.01 |
Micha` | :-D | 16:09.07 |
Robin_Watts | So... our code works, and when you add your code, it doesn't. | 16:09.19 |
| My first thought is "well, it's probably your code at fault then". | 16:09.58 |
Micha` | My, it's been a long time since I stayed in a developer IRC chan. Love it. | 16:10.07 |
Robin_Watts | My second thought is "We can't possibly be asked to find the problem without seeing the code in question, can we?" | 16:10.52 |
ramy | I was using an old version of mupdf which is 1.2 | 16:11.36 |
Robin_Watts | And my third thought is "We don't go bug hunting in other peoples code for them, unless they are at least a supported customer." | 16:11.53 |
ramy | it was working without any errors, but I wanted to update to 1.3 | 16:12.17 |
kens | "Our three chief weapons..." | 16:12.18 |
ramy | I did the same steps | 16:12.33 |
ray_laptop | ramy: so now you need to debug it | 16:13.44 |
ramy | when I did, the search didn't find the word | 16:14.34 |
Robin_Watts | ramy: If you can point us to a bug with the code *as we supply it*, then we'll put it on the list of things to look at. | 16:14.36 |
ramy | ok Robin, and happy to made kens laugh :) | 16:16.09 |
kens | I think that was Micha` | 16:16.22 |
Micha` | What a surprisingly unhelpful report you had here! All complete with the multiple exclamation marks and overall redundancy. Pretty sure this was someone from a competing company making fun of you, though. | 16:21.17 |
kens | Oh no, that's pretty normal, you should see the Stack Overflow forum | 16:21.42 |
Micha` | I thought SO was fairly well moderated, is it not? | 16:22.43 |
kens | Sure, but you still see a lot of questions like that | 16:22.56 |
ray_laptop | Micha`: AFAICT, SO isn't moderated. | 16:23.04 |
kens | Or at least I do | 16:23.05 |
| ray_laptop : its 'peer moderated' | 16:23.14 |
| And people do close questions, ptu them on hold, and edit them | 16:23.30 |
ray_laptop | kens: Oh, right. I guess that is a form of review, but all the junk makes it in | 16:23.37 |
kens | Yeah, but *someone* has to look at it to decide if its junk.... | 16:23.58 |
Robin_Watts | ray_laptop: You should see the junk that doesn't get through. Have you looked at youtube comments? :) | 16:24.08 |
ray_laptop | Robin_Watts: no, I haven't. You mean there are youtube comments about ghostscript ? | 16:24.41 |
Micha` | :-D | 16:24.47 |
Robin_Watts | No, just youtube comments in general :) | 16:24.58 |
ray_laptop | Robin_Watts: oh, yes. My kids are you tubers and every now and then I check to see what they are viewing (particularly if I hear a lot of laughing) | 16:25.45 |
Robin_Watts | tor7: You here for a sanity check ? | 16:26.17 |
Micha` | Robin_Watts: You said there is a todo list with items on annotation support, right? Any of those concerned with ink? | 16:27.33 |
Robin_Watts | actuallly, scratch that. | 16:27.34 |
| Micha`: There doesn't appear to be an entry on our official ToDo list for annotations. Probably there should be. | 16:28.51 |
| Our first concern would be to extend the core of the app with the other annotation types we don't support yet. | 16:29.42 |
| and to expose those (where possible) into the Android viewer. | 16:30.06 |
Micha` | Yeah, I went through this section of the ISO ref, boy are there many of those. | 16:30.31 |
Robin_Watts | so I don't think ink has anything specific that we're immediately looking at doing. | 16:30.53 |
| What do you consider it is missing? | 16:31.01 |
ray_laptop | mvrhel_laptop: Bug 693365 that you closed as fixed on 9-18-2013 is crashing with a different command line. Do you want me to re-open the bug with the new command line or open a new bug ? | 16:33.31 |
Micha` | Ah; I meant there are a lot of annotation types, not missing annotation types. Not that I know which ones are missing, though, as I have no use of these. My current annotation process is to convert the PDF to a bitmap and work with it on LectureNotes (basically, MSPaint). Hence Inking is my only concern :-) | 16:33.47 |
ray_laptop | Micha`: linking as in following links ? | 16:34.24 |
Robin_Watts | Micha`: right, sorry, I meant, "what do you consider missing for ink annotations?" | 16:36.25 |
| ray_laptop: inking, not linking :) | 16:36.38 |
ray_laptop | Robin_Watts: sorry -- I misread the upper case I as l and my brain inserted an i | 16:37.25 |
| they look alike on the font I have :-( | 16:37.57 |
Robin_Watts | easy mistake. | 16:38.19 |
Micha` | Robin_Watts: That was the reason why I asked you what's on the list: I don't see anything missing. Or maybe an option to render the list of points with lines between them instead of curves; the ISO standard says it's up to the implementation, but the library may offer the choice. | 16:38.35 |
Robin_Watts | tor7: fz_clip_image_mask takes a rect and a ctm. rect has already had the ctm applied to it. | 16:38.53 |
| Micha`: The todo list entry would be to add other annotation types that we don't support yet. | 16:39.15 |
| tor7: fz_begin_mask gets an area. Presumably that is supposed to similarly have had all the matrices applied to it (especially as we aren't given a transform at this point) | 16:40.56 |
| fz_begin_mask is called from xps_begin_opacity | 16:42.39 |
| and xps_begin_opacity just passes through the area. | 16:42.53 |
| so again, we'd like to assume that xps_begin_opacity is always passed area transformed by the ctm. | 16:43.12 |
| The call to xps_begin_opacity in xps_parse_gradient_brush doesn't look to hold that up. | 16:43.45 |
| Likewise xps_parse_path and xps_parse_tiling_brush and xps_parse_canvas | 16:44.43 |
| I must be misunderstanding :( | 16:44.48 |
kens | Night all | 16:52.13 |
Robin_Watts | tor7: Simpler one. fz_clip_path(dev, path, rect, even_odd, ctm); The rect is ALWAYS null. | 16:53.02 |
| Can we just remove it ? | 16:53.05 |
| I've arranged that it's non NULL most of the time. | 17:14.06 |
mvrhel_laptop | ray_laptop: ping | 17:15.16 |
ray_laptop | mvrhel_laptop: pong | 17:16.36 |
mvrhel_laptop | ray_laptop: you can reopen that is fine. | 17:16.46 |
| just please give the command line | 17:16.52 |
ray_laptop | mvrhel_laptop: debugbin/gswin32c -r300 -dMaxBitmap=0 -Z: -sDEVICE=psdcmyk -o x.psd tests_private/comparefiles/Bug693365.pdf | 17:17.53 |
| mvrhel_laptop: or do you want me to put that in the bug ? | 17:18.21 |
mvrhel_laptop | if that is the problem. yes please | 17:21.32 |
| ray_laptop: thanks | 17:23.27 |
ray_laptop | mvrhel_laptop: OK, I re-opened the bug and attached the command line and the call stack | 17:36.47 |
mvrhel_laptop | great. thanks. now if I can get this knockout stuff all working.... | 17:37.35 |
ray_laptop | darn. gs_cet.ps fowls up saved-pages mode somehow for the psdcmyk device :-( | 17:37.53 |
| If I put --saved-pages-test AFTER gs_cet.ps, all is OK, but before it's totally honked up. | 17:38.45 |
| and my idea of actually starting saved-pages-test mode right before running a file doesn't help because gs_cet.ps is run the same as any input file. | 17:39.49 |
| now I have to figure out what, among all the screwy things gs_cet.ps does, is causing the issue :-( | 17:40.49 |
| have to run an errand. bbiaw | 17:43.39 |
mvrhel_laptop | Robin_Watts: ping | 19:16.07 |
Robin_Watts | pong | 19:16.13 |
mvrhel_laptop | make file question for you | 19:16.19 |
| I forgot to add in memory__h for gsicc_lcms2.c in lib.mak | 19:16.42 |
| with my last commit | 19:16.49 |
| looking at lib.mak | 19:16.55 |
| I see stuff that is not clear to me | 19:17.13 |
Robin_Watts | Just updating. | 19:17.21 |
| ah, right. | 19:18.42 |
| There is some magic here. | 19:18.46 |
mvrhel_laptop | yes. I was not sure where to add in memory__h | 19:19.46 |
| I remember I needed to do it. saw this stuff and meant to ask you | 19:20.02 |
Robin_Watts | We build gsicc_lcms.c twice to give gsicc_lcms_0.obj and gsicc_lcms_1.obj | 19:20.08 |
| and then we copy whichever one of those is appropriate to be gsicc_lcms.obj | 19:20.27 |
mvrhel_laptop | oh the CP_ command | 19:20.51 |
| so I should add it to both _1 and _0 | 19:21.08 |
| I see | 19:21.10 |
Robin_Watts | The 0 or 1 is determined by whether we have 'SHARE_LCMS' or not. | 19:21.14 |
| So, yes, add it to both. | 19:21.18 |
mvrhel_laptop | ok thank you | 19:21.22 |
Robin_Watts | no worries. | 19:21.28 |
mvrhel_laptop | ok knockout stuff has been pushed. I do see one file that still has a minor issue, but lots of progressions which is good | 19:27.40 |
tor7 | paulgardiner: (for the logs) sorry, I have no idea. | 20:40.21 |
| Robin_Watts: back. | 20:46.14 |
| Robin_Watts: so, the various rects to the tile functions are a separate issue. the rects to the begin_mask, etc, are essentially the scissor stack/bboxes to scissor with | 20:47.15 |
| I don't remember the exact details, but I think they have the ctm pre-applied in the general case | 20:47.34 |
| they are in general smaller than the current scissor rect (they should be using the bbox of the contents of the mask, given in the PDF file) | 20:49.08 |
| and yes, please zap the rect to fz_clip_path, I never really understood why we needed it in the first place | 20:49.59 |
| Robin_Watts: oops, I think you might have missed a message or two | 20:50.22 |
mvrhel_laptop | ick. 693365 is really ugly to debug. | 22:02.46 |
| henrys: knockout has been completed with quite a few progressions in the test suite. I am going to get back to mupdf now | 22:03.36 |
henrys | great news, mvrhel_laptop | 22:05.05 |
mvrhel_laptop | first step is to fix a couple issues in the winRT store app and get it updated with the various fixes, then I will hopefully wrap up the phone | 22:12.01 |
| and, in my short absence of working with mupdf the winrt solution was broken.... | 22:13.11 |
| that is working with gs | 22:13.17 |
| looks like glyph.c is missing | 22:36.13 |
| Robin_Watts: for the logs, if you can review and commit to golden my commit of the fix for the winRT solution I would appreciate it | 22:42.49 |
Robin_Watts | ok. | 23:19.50 |
| mvrhel_laptop: done. | 23:26.19 |
| ooh. I have a gradient in my svg file! | 23:30.12 |
mvrhel_laptop | Robin_Watts: thanks | 23:47.41 |
| Forward 1 day (to 2013/10/10)>>> | |