| <<<Back 1 day (to 2013/01/13) | 2013/01/14 |
kens | Robin_Watts : ping | 11:51.42 |
Robin_Watts | pong | 11:51.46 |
tor8 | echo... | 11:51.57 |
kens | can you look at my latest bmpcmp results, test 1: | 11:51.59 |
| DO you see some cross marks ? | 11:52.14 |
Robin_Watts | I see turtles. | 11:52.29 |
kens | Damn, firefox cache messing up | 11:52.38 |
| thanks | 11:52.42 |
Robin_Watts | Shfit reload? | 11:52.44 |
kens | turtles is what I expected | 11:52.48 |
| shift reload does nothing useful | 11:52.57 |
Robin_Watts | Chrome FTW. | 11:53.07 |
kens | Yeah, I'm just running it now | 11:53.19 |
Robin_Watts | ass. pdf14 problems. | 11:54.30 |
| I've got a pdf14clistcmykspot device, with colorinfo that says: | 11:55.41 |
| max_components=num_components=14 | 11:55.48 |
| and a depth of 128. | 11:55.56 |
kens | 14 components ? wow.... | 11:56.08 |
Robin_Watts | 14 is standard. | 11:56.15 |
kens | Its really using that many ? | 11:56.31 |
Robin_Watts | no. 14 is the default we run at for spots etc. | 11:56.41 |
kens | Oh, I was assuming that num_coponents was the actrual number | 11:56.56 |
Robin_Watts | The problem is that 128/14 = 9, not 8. | 11:57.01 |
| (well, it may be using that number, I don't know). | 11:57.15 |
kens | My bmpcmp results make much more sense with Chrome, firefox only seemed to refresh 'some' of the images, which made no sense at all | 11:57.57 |
t4nk629 | hi all...anyone know how to import mupdf library in my own android project? | 14:56.41 |
Robin_Watts | t4nk629: Hi. Sure, lots of people have done it. | 14:57.03 |
| Will your project be released under the GNU GPL? | 14:57.24 |
t4nk629 | is a prototype | 14:57.59 |
| it will be not released | 14:58.07 |
Robin_Watts | ok, that's fine. | 14:58.27 |
| Well, it's not hard to do; we have some java classes that wrap a native library, built from C. | 14:59.54 |
| Just import those into your app, and you're sorted. | 15:00.08 |
t4nk629 | i have to import libmupdf.so and libmupdfthirdparty.a? | 15:01.50 |
Robin_Watts | just libmupdf.so, I believe. | 15:02.59 |
| All the .a's get built into a single .so that has everything in, IIRC. | 15:03.26 |
t4nk629 | ok...but when i try to load libmupdf.so i got java.lang.UnsatisfiedLinkError | 15:04.57 |
| :( | 15:04.59 |
Robin_Watts | t4nk629: For what symbol ? | 15:05.22 |
| The load of libmupdf.so happens in MuPDFCore.java IIRC. | 15:05.48 |
t4nk629 | Cannot load library: load_segments[907]: 1867 failed to map segment from 'libmupdf.so' | 15:06.01 |
Robin_Watts | That doesn't give me enough to go on. | 15:07.36 |
t4nk629 | ok | 15:07.57 |
| i use System.load("path/to/libmupdf.so") | 15:08.48 |
Robin_Watts | t4nk629: Why are you using that at all? | 15:09.09 |
| The native lib (the .so) has a very specific interface tied tightly to MuPDFCore.java. | 15:09.45 |
| Thus you should let MuPDFCore do the loading. | 15:09.56 |
t4nk629 | so i have just to import Mupdfcore.java in my project? | 15:11.00 |
Robin_Watts | t4nk629: You should import MuPDFCore.java into your project, yes. But not 'just' that - there are a whole series of java classes that work together to give the viewer. | 15:12.31 |
| You need to import all the relevant java classes, including MuPDFCore. | 15:13.00 |
t4nk629 | ok...i'm importing them :) | 15:14.18 |
Robin_Watts | henrys: Hey. | 15:38.28 |
| Is it reasonable to assume that dev->color_info.depth should be a multiple of dev->color_info.num_components ? | 15:38.59 |
| And more specifically that dev->color_info.depth = dev->color_info.num_components * bits_per_plane ? | 15:39.25 |
henrys | hi I see sags is back | 15:41.40 |
Robin_Watts | henrys: Yes, I mailed him. | 15:42.10 |
| electrician here. brb. | 15:42.24 |
henrys | I have a completely bizarre problem the X11 device doesn't work for PCL, it is being treated as a printer device - wanting an output file. I wonder what could have caused that. | 15:43.28 |
chrisl | henrys: I assume that's not with a build of master? | 15:46.32 |
henrys | yes it is. | 15:47.00 |
| it works for you on linux? | 15:47.28 |
chrisl | Hmm, seems to work okay for me..... let me do a fresh build | 15:47.31 |
t4nk629 | hey...i have imported all java files | 15:48.17 |
| but mupdfcore.java can't find mupdf library | 15:48.47 |
henrys | chrisl:I haven't looked in quite some time, been doing the xps stuff with gs only. | 15:49.40 |
chrisl | henrys: it's working fine for me | 15:50.49 |
henrys | strange | 15:52.15 |
| ./pcl6 -Z# ~/tests_private/tests_private/pcl/pcl5cfts/fts.0282 | 15:52.36 |
| GPL Ghostscript GIT PRERELEASE 9.07: **** Could not open the file . | 15:52.36 |
| ../gs/base/gsdevice.c(1047): Returning error -9. | 15:52.38 |
| Warning interpreter exited with error code -9 | 15:52.39 |
| Flushing to end of job | 15:52.40 |
| GPL Ghostscript GIT PRERELEASE 9.07: **** Could not open the file . | 15:52.41 |
| let me do a clean build | 15:53.13 |
| I thought I did but maybe not | 15:53.30 |
chrisl | Well, my path to the file is different, but I get the display window up as I'd expect.... | 15:55.21 |
henrys | and a clean build fixes it. | 15:55.40 |
| sorry | 15:55.42 |
chrisl | Still, very strange symptom! | 15:56.02 |
Robin_Watts | Maybe you were not getting x11 as the default device? | 16:11.01 |
henrys | Robin_Watts: that would explain it yes. | 16:16.25 |
Robin_Watts | jpeglib v9 has shipped. | 16:27.06 |
| chrisl: something to look at before the release? :) | 16:27.21 |
kens | I htink relelase is too close | 16:27.39 |
chrisl | Yeh, I think something for *after* the release | 16:29.12 |
| Robin_Watts: does it have our patch in it? | 16:29.56 |
Robin_Watts | It does. | 16:30.00 |
| http://www.infai.org/jpeg/ | 16:30.05 |
chrisl | Cool, we might get away with no patches :-) | 16:31.14 |
Robin_Watts | Yay, electrics done in porch. | 16:31.26 |
kens | So outside light, outside socket too ? | 16:40.40 |
Robin_Watts | yeah. | 16:45.55 |
| outside light, lights in porch, inside and outside sockets. | 16:46.08 |
kens | Outside socket very very useful. Not least for Xmas lights | 16:46.23 |
| Now you cna have an inflatable illuminated Santa Clasu :-) | 16:46.35 |
| OK I think that solves my problem with CIEBased spaces and ps2wrie. | 16:47.18 |
| GOt to go out and buy some new boots | 16:47.26 |
| Bye all | 16:47.31 |
Robin_Watts | kens: outside *double* socket :) | 16:47.40 |
| night. | 16:47.46 |
kens | Santa Claus *and* reindeer then :-P | 16:47.57 |
tor8 | Robin_Watts: wonder what the old libjpeg v9 was about then, back in august last year... | 17:04.54 |
Robin_Watts | was probably 9 alpha or something. | 17:06.01 |
tor8 | Robin_Watts: I've dropped the v9 tarball into our thirdparty jpeg.git | 17:08.20 |
Robin_Watts | takes dog to vets. back in a bit. | 17:14.19 |
sebras | tor8: doesn't seem like the changes are earth shattering... the follows well with the discussion on mature vs. immature libraries though... | 17:16.17 |
ray_laptop | I'm puzzled why bug 693541 is just showing up now if the commit happened April 2012 | 17:49.28 |
| bug 693562 mentions a company. I suggested that the bug/problem be taken up with them. | 17:58.09 |
Robin_Watts | ray_laptop: The user ought to be able to upgrade themselves. If not, then it's a fair sign that there is a GPL violation. | 18:04.17 |
| ray_laptop: bug 693541... | 18:04.48 |
ray_laptop | Robin_Watts: not if it's one of our customers | 18:05.16 |
Robin_Watts | should we always have that dev->color_info.depth = dev->color_info.num_components * bits_per_component ? | 18:05.31 |
| ray_laptop: Ah, and are they one of our customers? | 18:05.46 |
ray_laptop | Robin_Watts: as you mention ('541) we have to include the tag plane in the depth | 18:07.15 |
Robin_Watts | ray_laptop: Should the tag plane not count as a component then? | 18:07.47 |
| If not, then we have a problem, because the code assumes plane_depth = depth/num_components. | 18:08.30 |
ray_laptop | Robin_Watts: yes. It gets 'rendered' (although the "blending" for pdf14 is handled differently to the blending of other components) | 18:08.31 |
| Robin_Watts: sorry I misread your statement. The tag plane is included in the 'depth' | 18:09.01 |
Robin_Watts | Right. I see that the code includes it in the depth. It does not currently include it in the number of components though. | 18:09.32 |
ray_laptop | Robin_Watts: the tag plane isn't one of the num_components, but there does have to be a plane allocated for it | 18:09.56 |
Robin_Watts | OK, so the fact that the code assumes that plane_depth = depth/num_components is a problem. | 18:10.16 |
ray_laptop | Robin_Watts: yes | 18:10.50 |
Robin_Watts | So... any ideas for how to get around this? | 18:11.12 |
ray_laptop | e.g. tagged RGB will have a depth of 32 | 18:11.19 |
Robin_Watts | Do we add dev->color_info.extras ? | 18:11.27 |
| and have the use of tags set that? | 18:11.45 |
ray_laptop | I haven't looked into what's going on here (I've started looking at '537) | 18:11.53 |
Robin_Watts | Or do I make the gxdso_is_native_planar return 0 or the plane depth rather than 0 or 1 ? | 18:12.47 |
ray_laptop | Robin_Watts: changing the dso return sounds OK. | 18:14.22 |
mvrhel_laptop | good morning | 18:14.25 |
Robin_Watts | mvrhel_laptop: Hi. Just discussing bug 693541. | 18:14.30 |
| ray_laptop: I will have a look into that after I get back from fetching Helen from the station. | 18:14.59 |
mvrhel_laptop | oh from your commit :) | 18:15.33 |
Robin_Watts | That means the clist device 'is_planar' flag will change from 0 or 1 to 0 or depth as well. | 18:15.34 |
| "my" commit, yes :) | 18:15.42 |
ray_laptop | Robin_Watts: but the 'depth' is critical in the clist because the depth when writing and the depth when reading MUST exactly correspond. Otherwise we get clist errors | 18:16.16 |
Robin_Watts | ray_laptop: Right. None of that will change. | 18:16.30 |
ray_laptop | mvrhel_laptop: his commit last April (which is just showing up now ????) | 18:16.54 |
Robin_Watts | ok, time for me to head out again. thanks guys. | 18:17.00 |
ray_laptop | Robin_Watts: OK. later | 18:17.11 |
Robin_Watts | mvrhel_laptop: if you have any comments I'll check the logs later for them. | 18:17.13 |
mvrhel_laptop | Robin_Watts: ok. | 18:17.21 |
| ray_laptop: I was teasing him a bit. That was mostly my stuff but when I made it there was a mix up since Robin_Watts had tweaked one thing and when I committed it went in as his | 18:18.13 |
| so everytime there is an issue with it, it ends up in Robin's lap | 18:19.19 |
ray_laptop | mvrhel_laptop: still doesn't explain why the problem is just surfacing now :-/ | 18:19.30 |
mvrhel_laptop | don't know. it was a huge change in the code | 18:19.44 |
| kind of like the icc stuff | 18:19.51 |
| there is a bug tail | 18:20.02 |
| there were certainly a lot more issues in may and june | 18:20.36 |
henrys | ray_laptop:on windows does gs - < myps.ps pause at the prompt with showpage? I've always assumed stdio would not work with command prompt - well it doesn't on unix anyway. | 18:21.08 |
| curious if the behavior is the same on windows and thought you might know off the top of your head. | 18:21.47 |
ray_laptop | henrys: no. '-' disables prompting | 18:21.49 |
henrys | thanks | 18:21.56 |
ray_laptop | henrys: in psi/imainarg.c run_stinn: /* Set NOPAUSE so showpage won't try to read from stdin. */ | 18:24.10 |
| oops that label is 'run_stdin:' | 18:24.27 |
| henrys: I guess Use.htm should maybe mention that | 18:25.21 |
henrys | I think so. | 18:25.52 |
| marcosw:ping | 18:40.09 |
marcosw | henrys: morning | 18:40.16 |
henrys | can you make alexcher the jbig2dec owner on bugzilla and move all bugs to him. | 18:41.00 |
| ? | 18:41.02 |
| I can do it but it seemed like something in your domain let me know. | 18:41.23 |
marcosw | will do. | 18:41.34 |
henrys | alexcher:please bounty these as needed shelly likes to fix jbig2dec stuff. | 18:42.04 |
| alexcher:you are officially the jbig2dec owner. | 18:44.19 |
marcosw | henrys: done. there are 9 open bugs,. | 18:45.55 |
henrys | marcosw:and how did I get 693505? | 19:03.42 |
alexcher | henrys: yes, I'm doing this. | 19:04.18 |
marcosw | henrys: you and ray are listed in who_owns_what.txt as owning tiffsep.dev. | 19:06.37 |
henrys | alexcher:probably 693505 should get some priority if it is still crashing | 19:10.19 |
alexcher | henrys: It crashes. I took a quick look a few days ago but didn't see the cause of the problem immediately. | 19:12.58 |
ray_laptop | mvrhel_laptop: I am looking at bug 693541. It is getting confused about 'depth'. The pattern tile (that has transparency). The pdf14cmyk device somehow has a 'depth' of 0x18. I'm going to trace into it and see why, but I may need to consult with you. | 19:34.03 |
mvrhel_laptop | ray_laptop: ok | 19:34.39 |
| are there spot colors in the file? | 19:35.00 |
ray_laptop | mvrhel_laptop: note that the tile that was written (and read back) is OK. It had depth=0x20 when written and read, but it fails to load the pattern because the 'tdev' (pdf14cmyk) has the wrong depth | 19:35.01 |
mvrhel_laptop | is this a PS file or a PDF file? | 19:35.27 |
ray_laptop | mvrhel_laptop: it's a very simple file, and the num_components == 4 | 19:35.38 |
| mvrhel_laptop: PDF (has transparency) | 19:35.51 |
mvrhel_laptop | oh yes | 19:35.57 |
ray_laptop | thus the pdf14cmyk device | 19:35.58 |
mvrhel_laptop | so it is possible that the depth can be 18 if the group is an RGB color space | 19:36.25 |
| 0x18 that is | 19:36.30 |
ray_laptop | mvrhel_laptop: I'm setting breakpoints for the setup and depth location now... | 19:36.38 |
mvrhel_laptop | my point is that it is not unusual to see changes between 0x20 and 0x18 | 19:37.00 |
ray_laptop | mvrhel_laptop: when it writes the pattern, it has depth=0x20 | 19:37.07 |
mvrhel_laptop | ok as long as it has the same depth when reading and writting then all is ok | 19:37.22 |
| if not, then that is the issue | 19:37.28 |
ray_laptop | right. so I'm looking at it now to see why the depth is wrong when reading. | 19:37.51 |
mvrhel_laptop | it is possible it was wrong when it was written too... | 19:38.12 |
| not too, but instead | 19:41.07 |
ray_laptop | mvrhel_laptop: OK, stepping through writing. the get_pdf14_device_proto during writing the pattern is coming up with pdf14cmykspot 4 num_components=4, depth=0x20 | 19:48.01 |
mvrhel_laptop | ray_laptop: sounds reasonable. the trick here is to make sure that what ever groups are pushed in place during the writing are also in place during the reading | 19:49.19 |
| since if the pattern fill is occurring within a different group for some reason between writing and reading, that would be an issue. an interesting issue would be if the same pattern was used withing two different groups | 19:50.28 |
| not sure if we would handle that properly | 19:50.37 |
| s/withing/within/ | 19:50.53 |
| where the two groups had different color spaces | 19:51.18 |
| I would suspect that we would put different tiles in place | 19:51.35 |
| one in each color space | 19:51.46 |
| one of us should make a test file like that | 19:52.10 |
| heading off for lunch | 19:52.45 |
| bbiaw | 19:52.50 |
ray_laptop | OK. So it looks like the pattern is being written without taking into account the color space set by a 'BEGIN_TRANS_GROUP' that, when reading, changes the colorspace to RGB (3 components, depth=0x18) | 20:20.50 |
| need a lunch break before diving into it more. | 20:23.24 |
Robin_Watts | How odd. ray_laptop has been looking into the same bug as me, and has been finding completely different results... | 20:44.44 |
| http://hzqtc.github.com/2012/04/poppler-vs-mupdf.html | 20:45.14 |
| tor8: ^ | 20:45.22 |
tor8 | Robin_Watts: pretty impressive numbers. I didn't think cairo was *that* slow... | 20:50.41 |
Robin_Watts | And those figures are from last April. | 20:51.45 |
liucougar | Robin_Watts: hi | 20:57.16 |
| Robin_Watts: did you notice the last comment in http://bugs.ghostscript.com/show_bug.cgi?id=693545 ? | 21:00.50 |
mvrhel_laptop | bbiaw | 23:21.38 |
| Forward 1 day (to 2013/01/15)>>> | |