| | <<<Back 1 day (to 2016/06/28) | 20160629 |
| sebras | tor8: two minor fixes that I stumbled upon while testing on sebras/master | 11:28.10 |
| | tor8: concerning PAM output and also valgrind errors while attempting to open a path pointing to a directory. | 11:28.11 |
| | tor8: I'll log off for now, but I'll be back tomorrow. :) | 11:29.00 |
| tor8 | sebras: yes, I saw. LGTM. | 11:31.07 |
| Robin_Watts_Web | but this survived | 14:57.16 |
| sebras | kens: you around? | 15:21.06 |
| kens | sebras, yes | 15:21.23 |
| sebras | kens: I'm looking at the mupdf equivalent of base/sjpg_luratech.c::s_jpxd_write_data() | 15:21.49 |
| kens | Umm OK | 15:21.57 |
| sebras | kens: and I'm beginning to thing there might be a bug in there. | 15:22.00 |
| kens | You could easily be correct, I've not had to look for quite some time, possibly ever. | 15:22.18 |
| sebras | kens: consider the case where you have an image with three components (and consequently three channels) | 15:22.50 |
| kens | Am I goiung to need to look at source ? | 15:23.03 |
| sebras | kens: yes I think so. | 15:23.12 |
| kens | OK then carry on while I find the file | 15:23.20 |
| sebras | kens: and let's assume that channel 0 == 33 x 33 pixels | 15:23.41 |
| | kens: and the other two subsampled to 17 x 17. | 15:24.03 |
| kens | is listening | 15:24.07 |
| sebras | kens: that would make us vant to have hstep and vstep == 2 for channels > 0 | 15:24.44 |
| kens | Yes, but I can't remember ever seeing a PDF file where the channels aren't identical. I@m not sure that's leal in PDF | 15:25.11 |
| sebras | but we compute that as imagewidth / component width == > 33 / 17 ==> 1 | 15:25.18 |
| | oh! | 15:25.24 |
| kens | I'm not saying it isn't lega, but its worth checking | 15:25.40 |
| sebras | once we take care of that division, presumably by hstep = (iw + (cw - 1)) / cw | 15:26.18 |
| | kens: then you would need to check that you do not overstep the boundaries in all the if statements that use hstep/vstep. | 15:26.46 |
| kens | I'm not seeing that code anywhere, can you give me a clue ? | 15:27.06 |
| sebras | around line 206. | 15:27.33 |
| kens | I see hstep = state->width / cw | 15:27.58 |
| sebras | yes. | 15:28.08 |
| | I assume this should be something along the lines of hstep = (state->width + (cw - 1)) / cw | 15:28.32 |
| | consider the case where state->width == 33 and cw == 17 | 15:28.47 |
| | as it stands hstep == 1 | 15:28.53 |
| | but with my proposal hstep == 2 | 15:29.05 |
| | which seems more reasonable if you have the image width being 33 and the component width being 17. | 15:29.30 |
| kens | sebras you're going to have to take that up with someone who understand the Ghostscript implementation, not me | 15:30.34 |
| | THe PDF spec doesn't seem to disallow what you are saying though. | 15:31.46 |
| sebras | kens: no I cant see that it does. | 15:31.56 |
| kens | So technically it may be a bug yes | 15:32.13 |
| | report it to Henry ? | 15:32.21 |
| | :-D | 15:32.23 |
| sebras | I found this while attempting to get mupdf to decode a file properly. | 15:33.34 |
| | a separate .jp2-file that is, not being embedded in a .pdf | 15:33.56 |
| kens | Make it into a PDF and see what Acrobat makes of it | 15:34.07 |
| sebras | or gs. | 15:34.52 |
| | the problem is that this is a jp2-file. | 15:35.02 |
| | which I'm not sure is valid inside a .pdf. | 15:35.13 |
| kens | Should be | 15:35.29 |
| | PDF says JP2 or JPX | 15:35.37 |
| sebras | ah, yes! jp2 is a subset of jpx! | 15:35.53 |
| | ok. | 15:35.53 |
| | kens: luckily (for henrys) I think I can contribute a patch to fix it. | 15:37.17 |
| | :) | 15:37.19 |
| kens | I'm sure Henry will be happy :) | 15:38.06 |
| sebras | tor8: ty! will push soonish. | 15:41.22 |
| tor8 | sebras: I've already pushed the commits from this morning | 15:42.49 |
| | sebras: the open a directory bug fix LGTM | 15:43.16 |
| sebras | tor8: yeah, I was surprised that one was still in there. | 15:43.30 |
| tor8 | sebras: though I think the commit message is a bit misleading | 15:43.43 |
| | it would happen on <4 byte sized files too | 15:43.49 |
| | and opening directories is only possible on some platforms | 15:44.16 |
| HenryStiles | is happy | 15:44.27 |
| kens | :-D | 15:44.31 |
| sebras | :) | 15:44.45 |
| | tor8: in this case the underlying fd actually fails to open, which means that fz_read() returns 0 (treated as EOF) and hence it looks like we have a file < 4 byte. | 15:45.29 |
| HenryStiles | sebras: but were we able to reproduce a real bug in pdf against acrobat? | 15:45.35 |
| | sebras: did you make a pdf wrapper | 15:45.57 |
| | ? | 15:46.00 |
| tor8 | sebras: if the file fails to open, shouldn't we have thrown an exception? | 15:46.04 |
| sebras | HenryStiles: working on it. I don't have Acrobat Reader handy though, but I'll see what gs does with it. | 15:46.04 |
| | tor8: we do! inside fz_read(), which we then promptly catches and claim EOF. | 15:46.33 |
| tor8 | sebras: oh... heh. yeah, cascading failures of trying to recover. | 15:47.22 |
| sebras | tor8: indeed. | 15:48.08 |
| | tor8: I accidentally opened a directory, but you're right in that small files cause the same problem. | 15:48.42 |
| HenryStiles | sebras: you can also try xpdf, it is usually pretty solid for this kind of thing. | 15:51.15 |
| sebras | HenryStiles: I did try xpdf, and it looks really weird. same in evince. | 16:17.10 |
| | HenryStiles: care to help out in attempting to view it in acrobat for me? | 16:17.24 |
| HenryStiles | sebras: sure email the file | 16:19.23 |
| sebras | HenryStiles: done. | 16:20.50 |
| | HenryStiles: my patched mupdf renders this as a rgb gradient (red left, green middle, blue to the right) | 16:21.54 |
| | HenryStiles: xpdf does something really weird purpelish and evince does the same and immediately crashes on me (other jpx:s are fine). | 16:22.20 |
| | HenryStiles: gs renders part of it correctly, but then a diagonal pattern in the background. | 16:23.06 |
| | and generates number of valgrind complaints. | 16:23.31 |
| | tor8: do you prefer my latest version of the commit message on sebras/master? | 16:31.58 |
| HenryStiles | sebras preview (mac os x) and acrobat render what looks like the correct output and gs is wrong, so there should be a bug for this. The code that you were talking about seems to be the likely culprit | 16:33.49 |
| | nice to have the commit message reference the bugzilla number and test file, instead of simply fixing it. | 16:35.49 |
| sebras | HenryStiles: thanks. I'll report a bug and see if I can fix the gs code as well. I'll just attach a patch though. I hope that's ok? | 16:36.50 |
| HenryStiles | sure | 16:38.10 |
| sebras | HenryStiles: I was supposed to wokr on mupdf... ;) | 16:38.49 |
| HenryStiles | sebras: actually I just looked at the openjpeg output, not luratech. | 16:39.53 |
| sebras | HenryStiles: right, actually mupdf based on openjpeg does not handle this file at all as it doesn't support subsampled components. | 16:51.08 |
| mvrhel_laptop_ | rayjj: chris_x250 | 16:52.01 |
| | Bug 696875 | 16:52.03 |
| | when my name changes to mvrhel_laptop_ I cant get back on #artifex | 16:52.19 |
| HenryStiles | sebras: is that a deficiency of openjpeg or mupdf? | 16:52.31 |
| mvrhel_laptop_ | does someone need to add that alias? | 16:52.33 |
| sebras | HenryStiles: mupdf. | 16:53.11 |
| | HenryStiles: so it's something I could attempt to address after having completed luratech. | 16:53.28 |
| HenryStiles | sebras: maybe let's have an open bug for it. | 16:56.37 |
| sebras | HenryStiles: ok. | 16:57.25 |
| | HenryStiles: two bugs raised: one with a patch for gs (696884), and a pending one for mupdf (696885) | 17:25.47 |
| sebras | sleeps. | 17:33.21 |
| | Forward 1 day (to 2016/06/30)>>> | |
IRC Logs