| <<<Back 1 day (to 2014/05/06) | 2014/05/07 |
Robin_Watts | paulgardiner_lap (or tor, for the logs): MuPDF bugfix on robin/master | 09:14.22 |
| 3rd commit. | 09:14.31 |
kens | heading out for a bit, back in a couple of hours | 09:17.51 |
paulgardiner_lap | Robin_Watts: Will just look. There's one on by mupdf repo too if you have a moment | 09:34.45 |
| Robin_Watts: LGTM | 09:41.31 |
Robin_Watts | paulgardiner_lap: The icon sizes one? seems plausible. | 09:54.38 |
paulgardiner_lap | That's him. Ta | 10:01.27 |
| Robin_Watts: I see you pushed all three. I reviewed only the last of the three. Had the others already been reviewed? | 10:03.29 |
| Oh no. You've pushed the first | 10:04.15 |
| Oops | 10:04.18 |
| You mean 3rd from the head | 10:04.35 |
| Also LGTM | 10:06.30 |
| tor8: any preference on tag for the 1.4 ios release? I thought 1.4-ios | 10:49.15 |
tor8 | 1.4-ios is good | 10:52.52 |
| Robin_Watts: paulgardiner_lap: a handful of commits on tor/master for review | 11:58.59 |
Robin_Watts | tor8: I have slight reservations about zenikos patch, but I can't see it actually being harmful. | 12:30.18 |
| all look good to me., | 12:30.25 |
tor8 | Robin_Watts: yeah. I might be willing to dig deeper into libjpeg internals to see if I can find another way around it. | 12:31.04 |
| but as it only scans the actual markers, I don't think it should affect performance | 12:31.27 |
Robin_Watts | tor8: The only proper way to do it would be to look for the DNL marker, which should be after the first scan, if it's going to be there at all. | 12:32.02 |
| but the jpeg lib can't rewind the stream. | 12:32.14 |
| hence a fix entirely within jpeglib would require jpeglib to do a load of extra buffering on EVERY file. | 12:32.34 |
tor8 | Robin_Watts: yeah. the test file from Raed still gets this file partially wrong. | 12:32.39 |
Robin_Watts | howso? | 12:32.53 |
tor8 | the /Height in the PDF bigger than the actual encoded height | 12:32.58 |
Robin_Watts | Ah, yes. | 12:33.08 |
tor8 | so we get a truncated image warning | 12:33.10 |
| I looked at the last 6 bytes of the file data and the height value I see there was about the missing size smaller | 12:33.47 |
| so it might make sense to do a pre-scan for the DNL marker and patch using that data instead of the PDF width/height | 12:34.09 |
Robin_Watts | jpeglib *could* be made to spot the DNL, but changing the declared height at that last stage would break all sorts of contracts. | 12:34.20 |
| tor8: If we could hunt safely for the DNL that would be ideal. | 12:34.39 |
tor8 | I still have 50 open bugs that I need to classify, fix or close... and that's not counting all the enhancements which need a vigorous scrubbing of WONTFIX | 12:35.32 |
| hi zeniko | 12:37.51 |
zeniko | tor8: I'm not happy with the JPEG patch yet | 12:38.13 |
| AFAICT, there's no DNL marker in that file and -1 (0xFFFF) hasn't a special meaning, either | 12:38.49 |
tor8 | zeniko: feel free to rework it, I've pushed it because it fixes a bug from a loud customer. | 12:38.56 |
| but some cleaner way of fixing this would be good | 12:39.28 |
Robin_Watts | zeniko: There is a DNL in that file, I *think*. Right at the end. | 12:39.37 |
| If it's the file I looked at before at least. | 12:39.43 |
zeniko | Robin_Watts: right, as far as I read the spec, that's not even the correct location, though | 12:42.14 |
Robin_Watts | DNL should come after the first scan. | 12:42.26 |
| which in a non-progressive file is the only scan, hence the end. | 12:42.48 |
zeniko | for some reason, my segment scanning code failed to find it (that's why I assumed that it was missing or in the wrong place) | 12:45.52 |
| anyway, Adobe Reader ignores the DNL for this file and simply cuts the height (I assume once it runs out of data) | 12:47.40 |
| and libjpeg doesn't support DNL but also happily cuts if the height is reduced to below 65500 | 12:48.09 |
| which is what I'd rather do: https://code.google.com/p/sumatrapdf/source/detail?r=8776 | 12:48.27 |
Robin_Watts | I'd rather set the jpeglib max to be 65535, frankly. | 12:50.49 |
| Cos their reasons for having it at 65500 are poor to say the least. | 12:51.01 |
tor8 | I'd rather not have to patch libjpeg though | 12:51.20 |
| because then we'll run into trouble with all the distros using a non-patched libjpeg | 12:51.41 |
Robin_Watts | Is a prescan for DNL going to hurt performance? | 12:51.59 |
| I fear it will. | 12:52.04 |
| cos it will require us to decode streams twice, right? | 12:52.16 |
| actually, how is the current patch working? Do we have the jpeg data in a buffer? | 12:52.54 |
| oh, of course we do. | 12:53.03 |
tor8 | Robin_Watts: we have the jpeg data in a buffer, so we can quickly skip through the marker segments | 12:53.22 |
Robin_Watts | Then I'd favour looking for a DNL marker and rewriting the header if it's found. It's the closest thing to 'right' we can do. | 12:53.54 |
zeniko | Robin_Watts: that won't however match Adobe Reader's behavior (which is my baseline) | 12:54.33 |
Robin_Watts | The difference being that we will render correctly and they won't ? | 12:55.58 |
zeniko | what's correct in case of underdefined error handling? | 12:56.23 |
Robin_Watts | What's the difference in the renderings? | 12:57.25 |
zeniko | If in the document in question, I modify the DNL to result in too small a height, Adobe Reader still renders the full height (which should be alright, since the original height wasn't 0 so the DNL shouldn't apply anyway) | 12:57.32 |
| if anything, I'd rather use the height specified in the PDF instead of what the undersupported DNL says, if the JPEG reports too large a value | 13:00.24 |
tor8 | sebras: there's a commit on tor/master for your review | 13:14.38 |
zeniko | tor8: Robin_Watts: four small commits on zeniko/mupdf for review | 13:20.57 |
sebras | tor8: I'll look later tonight. | 13:29.58 |
tor8 | zeniko: LGTM | 13:30.24 |
| sebras: it's a simple commit, I nuke the platform/debian directory | 13:30.36 |
| I'm not sure if you still make your own debian packages from it, | 13:31.00 |
| but upstream debian has their own stuff which has diverged quite a bit from our debian files | 13:31.14 |
| or is it downstream? ;) | 13:31.33 |
chrisl | tor8: it's like the Escher picture - it's both up and downstream..... http://www.mcescher.com/wp-content/uploads/2013/10/LW439-MC-Escher-Waterfall-19611.jpg | 13:33.44 |
sebras | tor8: alright, remember that the icon files are in the git repo though. should they ever ask for them. | 13:37.03 |
tor8 | sebras: there's plenty of copies of the icons... maybe I should put the canonical icon image files in docs/ | 13:48.13 |
sebras | tor8: that's a good idea. | 14:05.07 |
tor8 | Robin_Watts: sebras: one more on tor/master. sadly it adds another few 100k onto the executable size :( | 14:06.54 |
| I was hoping that we'd never see any of these files in the wild... but I guess that was hoping for too much | 14:07.09 |
sebras | tor8: ok. this one will have to wait for later tonight. I will look though. | 14:07.32 |
tor8 | sebras: hey, you have enough accumulated overtime to look at my patches right now! STAT! ;) | 14:07.59 |
sebras | STAT? | 14:08.09 |
| tor8: yes, but I have my colleague sitting right next to me... | 14:08.33 |
tor8 | tsk tsk ;) | 14:08.42 |
henrys | kens:might have been faster to tell ray it's XPS first and have him rewrite ;-) | 15:14.53 |
kens | henrys, yeah maybe,I guess.... | 15:18.24 |
henrys | kens: easy enough to do a mono XPS output device like PXL but I don't think it's worth it. | 15:20.22 |
kens | I'd say not, hno | 15:20.52 |
henrys | unless we get requests | 15:21.11 |
chrisl | Sure mono would have to be raster? | 15:21.18 |
kens | why ? | 15:21.26 |
henrys | chrisl: no | 15:21.30 |
chrisl | Mono, not grayscale? | 15:21.41 |
kens | images would suck, but :-) | 15:21.56 |
henrys | yes XL is grayscale I guess | 15:22.17 |
| pxlmono | 15:22.20 |
| chrisl: you're right we wouldn't want to halftone with high level output | 15:23.02 |
| chrisl: it would be 8 bit | 15:23.24 |
| which could have considerable savings | 15:23.31 |
chrisl | I take it high level devices ignore ProcessColor? | 15:24.05 |
| Or, rely on the device to implement it | 15:24.20 |
kens | they have a processcolormodel | 15:24.52 |
henrys | kens: I thought it worked in pdfwrite certainly not XPS | 15:24.54 |
kens | pdfwrite does gray scale, no monochrome | 15:25.16 |
| we don't want to render ourselves in this case, because the device sdriver has all the device specific cleverness in it | 15:25.40 |
chrisl | I'd have thought if you set ProcessColorModel to DeviceGray the device would just see DeviceGray colours, unless it did the special stuff pdfwrite does..... | 15:26.44 |
kens | No, that's not how the oclour stuff works | 15:27.09 |
| unless you go low level of course | 15:27.30 |
chrisl | So high level devices do have to implement it "manually" | 15:27.53 |
kens | colour conversion, yes | 15:28.30 |
henrys | marcosw: any idea why banding vs non-banding testing missed C411.bin, you can see in ray's bmpcmp it has an obvious difference? | 15:29.22 |
| paulgardiner_lap: we had some discussion yesterday about setting up a forum and Robin_Watts said you had some experience. Any ideas for the SOT forum? | 15:51.57 |
paulgardiner_lap | henrys: sorry no. For Glidos I was offered a subcategory on the vogons forum. I had no need to set one up. | 15:53.58 |
| Very Old Games On New Systems | 15:54.22 |
kens | :-) | 15:54.45 |
| I still play nethack, does that count ? :-D | 15:54.59 |
paulgardiner_lap | I'd say it does | 15:55.16 |
kens | ASCII graphics only though | 15:55.28 |
| I don't like the tile set versions | 15:55.41 |
Robin_Watts | A lot of people use phpBB, but that's a bit long in the tooth these days. | 15:56.38 |
henrys | you have to go through this for stack exchange, http://area51.stackexchange.com/faq but that would probably save us a lot of grief | 15:56.48 |
Robin_Watts | henrys: Yeah, but then we're not in the position of being admins for the site, AIUI. | 15:59.20 |
| We're just "people that happen to answer most of the questions". | 15:59.29 |
| If we host our own forum, we have more scope to be little hitlers :) | 15:59.52 |
henrys | Robin_Watts: more scope to be system admins ;-( | 16:00.21 |
| we do have a new guy working for us that will handle it though, so maybe not so bad | 16:00.56 |
DragoonAethis | Hellllllo, if I could suggest that, http://www.discourse.org/ | 16:01.19 |
Robin_Watts | http://www.discourse.org/ sounds interesting. | 16:01.20 |
DragoonAethis | :D | 16:01.25 |
henrys | very appealing to have a cloud solution with pro's running it. | 16:01.45 |
DragoonAethis | I came here to mention this: http://git.ghostscript.com/?p=mujs.git;a=commit;f=jsi.h;h=9e41afffa65f4c42aa7e68ddb2ffcacaadaa32ed | 16:02.02 |
| On MSVC2013, this doesn't work, and can be replaced with `#define signbit(x) (_copysign(1.0, (x)))` | 16:02.22 |
kens | But what about earlier versions of MSVC ? Does it work there too ? | 16:02.58 |
paulgardiner_lap | vBulletin is apparantly popular | 16:03.27 |
DragoonAethis | Looks like it, I've seen that here: http://permalink.gmane.org/gmane.comp.video.mesa3d.devel/46399 | 16:03.34 |
| (vB costs a lot) | 16:03.39 |
kens | copysign seems to exist in 2008 | 16:03.40 |
| Hmm I don't seem to have 2005 installed on this machine | 16:05.21 |
henrys | I'm ready to recommend discourse.org to ron for setup, but I'll wait a bit for challenges or other ideas. | 16:12.16 |
tor8 | DragoonAethis: how does it fail on MSVC2013? | 16:21.53 |
DragoonAethis | in jsi.h, C2059: syntax error : 'sizeof' on line 27 | 16:28.52 |
henrys | chrisl: so the artifex.com page now is correct with agpl? Seems that way. | 16:34.58 |
chrisl | henrys: yes, it was sorted last week | 16:35.52 |
mvrhel_laptop | dr. appt. bbiaw | 16:43.38 |
ray_laptop | chrisl: I'm trying to build on windoze (yeah, I know, my first mistake), but I am getting "NMAKE : fatal error U1073: don't know how to make '.\obj\gssprintf_.obj'". I don't get this if I go back to a314230 (before the TRIO commit) | 16:43.42 |
| chrisl: Since it is the end of the day, and it's windoze, do you want me to fix it ? | 16:44.33 |
| (I missed kens to see if he is having the same issue) | 16:44.59 |
chrisl | ray_laptop: no, it's I'll fix it - give me a sec...... | 16:45.01 |
ray_laptop | chrisl: OK, thanks. | 16:45.57 |
chrisl | ray_laptop: if you pull now, it should work | 17:00.05 |
ray_laptop | hmm... I don't get it. grep SHARE_TRIO base/*.mak psi/*.mak doesn't show it ever being set | 17:00.46 |
| chrisl: sorry. I typed too slowly. pulling now... | 17:01.03 |
chrisl | ray_laptop: yeh, I forgot about Windows, sorry. I had a weird problem with the configure.ac check, and by the time I'd sorted that out, I just wanted shot of it! | 17:02.30 |
ray_laptop | chrisl: thanks. Works OK now | 17:02.51 |
| and the grep shows the macro being set in msvc.mak | 17:03.22 |
| I guess kens hadn't updated his tree in a while (nor mvrhel) | 17:03.49 |
| the other couple of usual windows folks | 17:04.05 |
chrisl | No, I guess not. Thanks for spotting it anyway - I must admit, I wish we didn't always use "_0" and "_1" for the shared thing.... | 17:04.44 |
ray_laptop | Robin_Watts henrys or chrisl: can one of you see if the log message is better now on http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commit;h=d2111f620ad95a5deb918c8d64be04012025fed1 | 17:07.04 |
Robin_Watts | ray_laptop: Being really picky... | 17:07.57 |
henrys | ray_laptop: fine for me | 17:08.05 |
Robin_Watts | This means that whole line segments that are not present within a band can be omitted which speeds up path rendering for bands. | 17:08.06 |
ray_laptop | Robin_Watts: fine | 17:08.08 |
Robin_Watts | No, wait, ignore me. | 17:08.26 |
| Looks lovely to me. | 17:08.36 |
ray_laptop | henrys: Robin_Watts: thanks. pushing... | 17:08.51 |
| marcosw: fix for Bug 695205 pushed for cust 870 | 17:11.18 |
| marcosw: I'll let you notify the customer | 17:11.46 |
Robin_Watts | mvrhel_laptop, henrys: I am touching my nose. Who gets to reply to the ETS customer enquiry? | 17:12.15 |
ray_laptop | Robin_Watts: is the Differences in 122 of 3061 non-pdfwrite/ps2write test(s) for your recent Bug 694801: fast_cmyk_to_rgb caching broken. fix OK ? Doesn't seem like something I'd expect from just a cache fix | 17:13.56 |
Robin_Watts | ray_laptop: I ran a bmpcmp and the changes are expected. | 17:14.28 |
ray_laptop | (as you said, ignore me if I'm just being picky) | 17:14.28 |
Robin_Watts | I pushed first, then ran the bmpcmp afterwards on a reverted commit. | 17:14.48 |
henrys | Robin_Watts: we could just leave it to marcosw ;-) That was my thought. | 17:15.11 |
Robin_Watts | so the bmpcmp on my page now shows the diffs "the wrong way round". | 17:15.13 |
ray_laptop | Robin_Watts: OK, just being annoying :-) | 17:15.28 |
Robin_Watts | ray_laptop: I was somewhat surprised to see the number of diffs too :) | 17:15.44 |
| ray_laptop: The caching was horribly broken, so that it was failing to detect that colors had changed. hence we were getting bad results out. | 17:16.28 |
ray_laptop | Robin_Watts: oh, that does sound bad. So I missed the regression I should have been picky about when that got broken :-) | 17:18.15 |
Robin_Watts | yeah. | 17:18.25 |
| I optimised the code which produced lots of rounding errors. | 17:18.52 |
| and hidden in those rounding errors were genuine errors. Meu Culpa etc. | 17:19.08 |
| Mea, even. | 17:19.13 |
henrys | Robin_Watts, mvrhel_laptop : if the read me and other docs in toolbin/halftone/ETS/ don't answer a reasonable question I guess marcos will report a bug, no? | 17:19.51 |
Robin_Watts | henrys: Sure. | 17:25.26 |
henrys | wonders if support should be digested for engineering, avoiding context switches, I find it distracting but I might be more sensitive than others. | 17:25.48 |
ray_laptop | IRC gives me plenty of practice reading interleaved topics :-) | 17:28.04 |
Robin_Watts | henrys: You should use windows more. | 17:30.12 |
| Whenever my machine reboots, I forget to run the mail client, and I get 12 hours of productivity. | 17:30.34 |
chrisl | Oh, I thought you meant because he'd welcome the distraction :-) | 17:30.54 |
henrys | Robin_Watts: jesus if this anti malware crap pops up and tells me to update my database one more time I'm hackintoshing the laptop | 17:31.31 |
Robin_Watts | henrys: What antimalware? | 17:31.53 |
| malware bytes? | 17:32.01 |
henrys | yeah that one | 17:32.09 |
Robin_Watts | only installs that when required. | 17:32.24 |
henrys | like chrisl I thought using windows has hardened you to distraction. | 17:32.57 |
Siecje | I'm getting this weird error https://dpaste.de/3VLS | 20:03.59 |
sebras | Siecje: the warning mentions that the file might have been damaged. | 20:04.50 |
| Siecje: so maybe Ghostscript is unable to successfully recover all the data. | 20:05.47 |
| Siecje: it's impossible for the gs developers to say without having access to the problematic file. | 20:06.05 |
| Siecje: if you are able to successfully view the file in a pdf viewer, e.g. Adobe Acrobat, then I'd suggest that you file a bug over at http://bugs.ghostscript.com/ and attach the file (I believe that you can mark attachments private if you so desire). | 20:07.17 |
Siecje | I'm running a script that uses python's pdfminer to open pdfs and create some .png files | 20:08.11 |
| It works, but I get this error on Linux Mint | 20:08.19 |
| I can open the PDFs | 20:08.31 |
| and power points I guess | 20:10.17 |
| ghostscript -v | 20:15.05 |
| GPL Ghostscript 9.10 (2013-08-30) | 20:15.05 |
sebras | tor8: why didn't you stick UniHojo-UTF32-* and UniHojo-UTF8-* in your cmaps branch as well? | 22:28.27 |
| tor8: btw, if you ever need a jpeg xr library, microsoft has released one under bsd: https://jxrlib.codeplex.com/ | 22:34.51 |
| tor8: seems like there is a decent chance that fz_load_jxr() and fz_load_jxr_info() can be populated now! :) | 22:36.16 |
| tor8: https://git01.codeplex.com/jxrlib | 22:38.16 |
Robin_Watts | sebras: aren't there patents? | 23:08.58 |
| Forward 1 day (to 2014/05/08)>>> | |