IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2013/01/13)2013/01/14 
kens Robin_Watts : ping11:51.42 
Robin_Watts pong11: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 up11:52.38 
  thanks11:52.42 
Robin_Watts Shfit reload?11:52.44 
kens turtles is what I expected11:52.48 
  shift reload does nothing useful11:52.57 
Robin_Watts Chrome FTW.11:53.07 
kens Yeah, I'm just running it now11: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=1411: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 number11: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 all11: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 prototype14:57.59 
  it will be not released14: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.UnsatisfiedLinkError15: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 ok15: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 back15: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 build15:47.31 
t4nk629 hey...i have imported all java files15:48.17 
  but mupdfcore.java can't find mupdf library15: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 me15:50.49 
henrys strange15:52.15 
  ./pcl6 -Z# ~/tests_private/tests_private/pcl/pcl5cfts/fts.028215: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 -915:52.39 
  Flushing to end of job15:52.40 
  GPL Ghostscript GIT PRERELEASE 9.07: **** Could not open the file .15:52.41 
  let me do a clean build15:53.13 
  I thought I did but maybe not15: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 
  sorry15: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 close16:27.39 
chrisl Yeh, I think something for *after* the release16: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 lights16: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 boots16:47.26 
  Bye all16:47.31 
Robin_Watts kens: outside *double* socket :)16:47.40 
  night.16:47.46 
kens Santa Claus *and* reindeer then :-P16: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.git17: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 201217: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 customers18: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 depth18: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 it18: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: yes18: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 3218: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 morning18: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 errors18: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. later18: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 his18:18.13 
  so everytime there is an issue with it, it ends up in Robin's lap18: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 code18:19.44 
  kind of like the icc stuff18:19.51 
  there is a bug tail18:20.02 
  there were certainly a lot more issues in may and june18: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 prompting18:21.49 
henrys thanks18: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:ping18:40.09 
marcosw henrys: morning18: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 crashing19: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: ok19: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 depth19: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 == 419:35.38 
  mvrhel_laptop: PDF (has transparency)19:35.51 
mvrhel_laptop oh yes19:35.57 
ray_laptop thus the pdf14cmyk device19:35.58 
mvrhel_laptop so it is possible that the depth can be 18 if the group is an RGB color space19:36.25 
  0x18 that is19: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 0x1819:37.00 
ray_laptop mvrhel_laptop: when it writes the pattern, it has depth=0x2019:37.07 
mvrhel_laptop ok as long as it has the same depth when reading and writting then all is ok19:37.22 
  if not, then that is the issue19: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 instead19: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=0x2019: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 reading19: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 groups19:50.28 
  not sure if we would handle that properly19:50.37 
  s/withing/within/19:50.53 
  where the two groups had different color spaces19:51.18 
  I would suspect that we would put different tiles in place19:51.35 
  one in each color space19:51.46 
  one of us should make a test file like that19:52.10 
  heading off for lunch19:52.45 
  bbiaw19: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.html20: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: hi20: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 bbiaw23:21.38 
 Forward 1 day (to 2013/01/15)>>> 
ghostscript.com
Search: