| | <<<Back 1 day (to 2014/05/18) | 2014/05/19 |
| Robin_Watts | JakeSays: You'd need to write custom code for that. | 07:59.55 |
| | Every image is converted to a pixmap before being plotted. | 08:00.33 |
| | You'd need to make sure that you are rendering to an rgb pixmap (as the target of the draw device) and you'd need to process every image pixmap into an R-only RGB pixmap before calling the actual paint image routines. | 08:02.10 |
| JakeSays | Robin_Watts: hey thanks for getting back to me. i ended up tweaking fz_draw_fill_image_mask | 08:14.26 |
| | just hardcoded colorbv | 08:15.13 |
| tor8 | Robin_Watts: JakeSays: wouldn't that be something the pdf-op-processing filter could do? change the color fill value of image masks, or replace the image colorspace to one that maps everything to grayscale-but-red | 08:57.19 |
| Robin_Watts | tor8: yeah, probably. | 08:57.41 |
| | but nobbling the fz_draw_fill_image_mask is a quick and easy hack if it works. | 08:58.14 |
| tor8 | Robin_Watts: which makes an even stronger case for some scripting language bindings to access this stuff, so you can do this without having to code stuff in C and rebuild | 08:58.35 |
| | yes, certainly! | 08:58.42 |
| chrisl | I wouldn't have thought the pdf op filter stuff would work for that in its current form | 08:58.42 |
| Robin_Watts | chrisl: You'd need to write a new filter set (or modify the pass thru). | 08:59.25 |
| tor8 | or walk through the display list and edit the nodes in there, whichever might be easier | 09:00.01 |
| chrisl | It also currently bypasses a bunch of the page setup stuff, so you'd need to write (and maintain) that yourself, too | 09:00.10 |
| tor8 | but hacking the draw-device's colorbv conversion works fine for a quick hack | 09:00.15 |
| | Robin_Watts: did you get a chance to look at the two commits on tor/master yet? | 09:01.29 |
| Robin_Watts | looking now | 09:01.50 |
| chrisl | tor8: how about using Postscript as a scripting language? ;-) | 09:01.51 |
| tor8 | chrisl: that's one of the benefits of gs, actually. being able to do all sorts of tweaks by inserting postscript code on the command line. | 09:02.27 |
| chrisl | tor8: that generally doesn't work that well for PDFs because of the way the PDF interpreter is implemented (hacked!) | 09:03.11 |
| Robin_Watts | tor8: The unresolvable link destinations one; can the commit message mention the file/bug that showed the problem please? | 09:03.31 |
| | Otherwise in 6 months when we get another bug in the same area, we'll not be able to check this. | 09:03.50 |
| kens | If I ever get the time, I intend to rework the PDF interpreter to make that kind of scripting easier.... | 09:03.53 |
| Robin_Watts | but otherwise LGTM. | 09:03.57 |
| tor8 | Robin_Watts: right, it showed up as a side-effect when I fixed another bug in a file. I'll dig and see if I can locate the file name again and mention it in the commit message. | 09:04.35 |
| Robin_Watts | The second commit; what happens if you get a type 3 font with a 0 sized font bbox ? | 09:04.54 |
| | How about fz_max(1000, fz_max(x1 - x0, y1 - y0)) ? | 09:05.53 |
| tor8 | Robin_Watts: it'd be broken :) we haven't got any such in any of the cluster tests. | 09:05.54 |
| Robin_Watts | 1000 being the typical design size, right? | 09:06.07 |
| tor8 | Robin_Watts: yeah. | 09:06.13 |
| kens | I htink I've seen some in our test suite, in PostScript at least | 09:06.16 |
| | Robin_Watts : 1000 isn't really typical for type 3 fonts | 09:06.51 |
| | FOr type 1 fonts, yes, but not type 3 | 09:07.00 |
| | But its better than breaking ;-) | 09:07.13 |
| tor8 | type3 fonts are all over the place. on the other hand, this particular case deals with post-transform bboxes | 09:07.58 |
| Robin_Watts | I have to run H to the station. bbs. | 09:08.03 |
| tor8 | so I'd prefer matrix_expansion * 2 or something like that rather than 1000 | 09:08.14 |
| Robin_Watts | ok. | 09:08.23 |
| JakeSays | Robin_Watts: yeah its definitely a hack but it worked for what i was trying to do | 09:08.37 |
| chrisl | tor8: I reworked the libjpeg memory stuff a bit: http://git.ghostscript.com/?p=user/chrisl/mupdf.git;a=commitdiff;h=3fd11d45 | 09:09.08 |
| JakeSays | tor8: i'm using C# as the 'scripting language'. lol | 09:09.49 |
| tor8 | chrisl: I see no difference from that to what I looked at last week. | 09:30.19 |
| chrisl | tor8: ah, that's probably because I forgot to push the update.... hang on.... | 09:38.12 |
| | tor8: here we go: http://git.ghostscript.com/?p=user/chrisl/mupdf.git;a=commitdiff;h=f08b62cc | 09:41.09 |
| tor8 | chrisl: yeah, that looks nicer. | 09:44.48 |
| | if you think it's ready I'll polish it up and fix the try/catch stuff | 09:46.29 |
| | are we keeping jcustmem.c identical between gs and mupdf? | 09:46.47 |
| | sorry, jmemcust.[ch] | 09:46.57 |
| | biab, lunch | 09:47.19 |
| chrisl | tor8: I think it's ready, yeh. It passes the cluster on both mupdf and gs..... | 09:59.14 |
| | tor8: yes, the plan is to keep those files identical between gs and mupdf. When I get time, I'll try to convince the libjpeg people they might benefit from it - or a variation of it, anyway | 09:59.40 |
| tor8 | chrisl: cleaned up commit on tor/master, and one to apply consistent 2-space indentation to jmemcust.[ch] that you might want to reuse for gs | 12:13.10 |
| | http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commitdiff;h=ca5bace1af9f2203a8c4a9490844c5f78b4b24e5;hp=5faaa444cb08a19eb9eb932010bb70cb3e3423f4 | 12:13.52 |
| | http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commitdiff;h=e45a88273c3577356962bcd452d3ef228ea9fc99;hp=ca5bace1af9f2203a8c4a9490844c5f78b4b24e5 | 12:14.08 |
| | chrisl: oops, wrong commit id. I mean http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commitdiff;h=74b752acf569375711e8a537256f115d3e6076d4;hp=5faaa444cb08a19eb9eb932010bb70cb3e3423f4 | 12:16.32 |
| chrisl | tor8: looks fine, thanks | 13:09.19 |
| kens | chrisl do you remember the 'debug' operator in GHostscript ? The 'do nothing' operator you can set a break on ? | 13:27.02 |
| chrisl | .setdebug | 13:27.21 |
| kens | THat's it, thanks | 13:27.26 |
| chrisl | And it takes a boolean and a string as parameters - can't remember which way round, though | 13:27.51 |
| kens | I cna find out, remembering the operator name was defeating me.... | 13:28.10 |
| | string then boolean it seems | 13:29.44 |
| chrisl | tor8: I've pushed the libjpeg memory stuff to ghostpdl, too. | 14:14.52 |
| Robin_Watts | mupdf died on the cluster with that commit. | 14:32.40 |
| chrisl | Hmm, I don't understand that error..... | 14:36.02 |
| kens | tor8 ping ? | 14:37.25 |
| tor8 | kens: pong. | 14:45.49 |
| kens | tor8 Private message | 14:46.06 |
| henrys | anybody have an expense report template in Excel they like? The current one results in frequent reporting errors - folks are entering values outside the extant of the formulas and under reporting. Like to just replace the current form with something less error prone. | 14:47.18 |
| kens | I only have a PDF< would be happy to have something better (electronic) | 14:47.44 |
| chrisl | tor8: Not quite sure about why the cluster doesn't like that commit, but: http://git.ghostscript.com/?p=user/chrisl/mupdf.git;a=commitdiff;h=e49544fb | 14:48.02 |
| | Seems to work okay | 14:48.07 |
| Robin_Watts | chrisl: If that cluster pushes OK, then consider it reviewed. | 14:48.48 |
| chrisl | Robin_Watts: It just finished | 14:48.59 |
| Robin_Watts | cool. | 14:49.03 |
| chrisl | I wonder what the cluster does differently to cause that problem...... | 14:51.58 |
| tor8 | chrisl: I wonder if it could have picked up a system wide header file? | 14:53.17 |
| chrisl | tor8: I thought of that, but I have libjpeg-dev installed here, too..... | 14:53.44 |
| tor8 | chrisl: and it works for me both with and without the libjpeg-dev package installed... | 14:55.08 |
| | something really weird going on | 14:55.13 |
| chrisl | Yeh, but as removing that include fixes the cluster, and does not result in any warnings, I'm not going to lose any sleep over it.... | 14:55.52 |
| zeniko | henrys: openjpeg 2.0.1 (and 2.1.0) is out with almost all of our bug fixes included | 15:05.19 |
| | our diff to 2.1.0 has become far more manageable: https://code.google.com/p/sumatrapdf/source/browse/trunk/ext/_patches/openjpeg.patch | 15:05.37 |
| | (of course, it still contains a few crash fixes missing in upstream) | 15:06.07 |
| | haven't gotten any rendering regressions in my own testsuite | 15:06.33 |
| henrys | zeniko: I can't remember if you have access to our cluster | 15:07.27 |
| zeniko | I do | 15:07.53 |
| | tor8: anything left to do for bug 694851? | 15:08.55 |
| tor8 | zeniko: no, I think we can close that and you can claim the bounty. | 15:09.37 |
| zeniko | thanks | 15:09.54 |
| tor8 | zeniko: I've closed it now. | 15:10.16 |
| henrys | chrisl: any objections to openjpeg 2.1.0 + zeniko's patch in the gs tree? | 15:23.35 |
| chrisl | henrys: no objections - I was hoping to get Shelly to look at it, but if it's straight forward, then we just go with it | 15:25.02 |
| henrys | chrisl: ah good point I'll send him email | 15:30.09 |
| chrisl | henrys: I asked him to look at #695146 - I had a (probably vain) hope that 2.1.0 might resolve it | 15:32.01 |
| henrys | chrisl: did he say anything about http://bugs.ghostscript.com/show_bug.cgi?id=694691 | 15:34.42 |
| | ? | 15:34.53 |
| chrisl | Oh, yes. We're a little confused - the OpenJPEG people turned down the first patch in making that stuff happen - then suddenly accepted it, and did a release before he could move onto the next stage..... | 15:36.25 |
| | henrys: But now that first stage has been accepted, he's ready to move onto the next bit - but he's had a lot on in his day job, so hasn't had much time to devote to our stuff - not sure when that will change | 15:38.10 |
| mvrhel_laptop | henrys: I dont know how much real work I am going to be getting done the next couple days. I have a pile of things to get wrapped up around to get ready for this trip | 15:39.00 |
| henrys | mvrhel_laptop: completely understood. Are you good demo-wise? | 15:39.27 |
| mvrhel_laptop | well wrt SOT is there any thing newer that I should have. I still have the one that I got from the last trip. | 15:40.22 |
| Robin_Watts | mvrhel_laptop: I don't know that we have anything hugely newer to give you. | 15:41.12 |
| mvrhel_laptop | Robin_Watts: ok that is what I figured | 15:41.24 |
| Robin_Watts | actually, we might have a version with "Artifex" in there rather than "Picsel". | 15:41.48 |
| mvrhel_laptop | ok. I was just going to ask that | 15:41.59 |
| Robin_Watts | What are you demoing on? ios or android ? | 15:42.03 |
| mvrhel_laptop | android | 15:42.07 |
| henrys | chrisl, zeniko seems like we should wait for that to be done, then integrate everything. I know none of the openjpeg issues fixed by upgrading are needed by artifex customers. Not sure how important these problems are for sumatra | 15:42.47 |
| chrisl | henrys: if there's not much effort involved, I don't see a problem pulling in the new version. As I said, I'm not sure how soon Shelly will have the time to come back to it, at the moment | 15:44.44 |
| henrys | chrisl: do you want to go ahead with that or I can do it. | 15:50.37 |
| chrisl | henrys: I'm happy to do it, but it will be tomorrow or Wednesday before I get to it | 15:51.19 |
| henrys | chrisl: fine for me. | 15:51.49 |
| chrisl | Okay, I'll get it done | 15:52.09 |
| mvrhel_laptop | Robin_Watts: so do we have an apk with the artifex logo that I should use? | 15:54.57 |
| Robin_Watts | mvrhel_laptop: We'd have to make one up, I think. | 15:57.27 |
| mvrhel_laptop | oh ok | 15:58.52 |
| Robin_Watts | Just pondering. | 15:59.40 |
| | Our customer releases are coming off the smartoffice-2-1-28-release-branch | 15:59.56 |
| | but in theory we should have all that good stuff back on master. | 16:00.08 |
| | The font changes haven't made it onto either yet, because they completely screw the tests (the automated tests get confused by the fact that the text is laid out differently) | 16:00.56 |
| | Let me try a build now. | 16:03.04 |
| kens | night all | 16:03.50 |
| zeniko | henrys: we don't rely on you updating openjpeg, as SumatraPDF has the code included in its own repo (currently at 2.1.0 + patches) | 16:24.01 |
| | I haven't heard back from the openjpeg devs on the latest segfault, though | 16:24.37 |
| mvrhel_laptop | Robin_Watts: ok. just let me know if I need to do anything other than install an apk. | 16:25.34 |
| Robin_Watts | mvrhel_laptop: It should just be a question of installing an apk. I'm building now and will test it when it's done. | 16:30.19 |
| mvrhel_laptop | Robin_Watts: awesome. thanks | 16:32.46 |
| | need to run suit to cleaners. bbiab | 16:32.57 |
| Robin_Watts | mvrhel_laptop: (For the logs) smartoffice.apk is in my casper homedir. | 16:58.32 |
| mvrhel_laptop | Robin_Watts: ok I will grab it and install. thanks | 21:26.56 |
| sebras | tor8: hm.. 'range limits out of range in cmap'... is this really a warning..? | 23:17.21 |
| | tor8: oh and can't we make curl build when we do make third? | 23:21.21 |
| | that was one of my aims with my old patch. | 23:21.36 |
| | Forward 1 day (to 2014/05/20)>>> | |
IRC Logs