| | <<<Back 1 day (to 2015/08/18) | 20150819 |
| sebras | tor8: (for the logs) there's a gif decoder signedness patch over at sebras/master that I think you might have forgotten..? | 00:13.18 |
| shelly_ | morning all, long time no see. I saw in the logs that Henry is thinking of rerunning the fuzzing tests, is this still going ahead or can I continue with the ones that still segfault? | 07:00.23 |
| kens | Wow, that was quick... | 07:00.41 |
| Robin_Watts | Powering down PC. back from the laptop on and off throughout the day. | 07:17.26 |
| RobinWattsLenovo | ismail: hi. Thanks for the email. | 11:22.43 |
| | (assuming it's the same ismail :) ) | 11:22.53 |
| ismail | RobinWattsLenovo: you are welcome :) | 11:41.20 |
| | I re-discovered mupdf and pdf reading became much better for me (at least on Linux) | 11:43.13 |
| tor8 | RobinWattsLenovo: a handful of commits for review on tor/master ... especially a fix for the utf-8 command line argument handling in windows | 13:11.17 |
| | I'd forgotten to rename some fz_optindw to fz_optind | 13:11.48 |
| | and the getoptw.c had some major bugs -- printf with %s on wchar_t* strings | 13:12.21 |
| kens | paulgardiner : do you have an example for bug #696159 ? I thought that the /V field should be in either PDFDocEncoding or Unicode, the Unicode being denoted by the string beginning with the Unicode BOM (0xFFFE) | 13:26.13 |
| paulgardiner | Oh right | 13:26.38 |
| | That sounds familiar now you mentionit | 13:26.52 |
| kens | I'm not certain, and I'm having trouble finding it in the PDF reference, but most 'non-marking' things in PDF are defined that way | 13:27.21 |
| | You only use the font's encoding when drawing the PDF contents | 13:27.34 |
| paulgardiner | Just sent a pdf to support | 13:29.14 |
| kens | OK one sec | 13:29.20 |
| paulgardiner | Using the font encoding would be daft I can see | 13:30.13 |
| kens | The first one I see there has hte Unicode BOM | 13:30.55 |
| | 'THe Korean letter is....' | 13:31.11 |
| | And in fact that's the only /V in there | 13:31.23 |
| | So that's one's definitely Unicode | 13:31.40 |
| | I'm 'fairly' certain that if its not Unicode it shoudl be treated as PDFDocEncoding, but I'm having trouble naling a reference | 13:32.32 |
| paulgardiner | Easier to fix than I thought then. | 13:32.33 |
| kens | :-) | 13:32.37 |
| | Damn, I did a cluster test and had no problem, I committed the code and now it is showing a seg fualt. How does that happen ? | 13:33.19 |
| | Yeah I don't believe that seg fault. I can't see how my code could cause that. | 13:35.43 |
| | I thnk its one of the new crop of indeterminisms that are occuring recently | 13:36.01 |
| | paulgardiner : I found that reference | 13:37.45 |
| | The /V key for text fields is defined as a 'text string' | 13:37.56 |
| | text strings are defined in table 3.31 on page 156 of the 1.7 PDF spec | 13:38.20 |
| paulgardiner | Great. Thanks Ken | 13:38.38 |
| kens | "text string | 13:38.41 |
| | Bytes that represent characters encoded | 13:38.41 |
| | using either PDFDocEncoding or UTF-16BE with a leading byte-order marker (as defined in Text String Type on page 158.)" | 13:38.41 |
| henrys | paulgardiner: I added a link to your NUI schedule to the workflowy and we'll discuss it at the meeting. | 13:39.18 |
| paulgardiner | Yeah. I need till in some guestimates for the yet to do stuff | 13:40.01 |
| | s/till/fill/ | 13:40.09 |
| | Great! I have no openssl in muy mupdf thirdparty directory and I have no recollection of what exactly I need to put there and where to get it. | 13:49.17 |
| | ... but I seem to have guessed correctly. :-) | 13:55.56 |
| tor8 | Robin_Watts: so ... origin/master doesn't build in release mode on my MSVC 2005 | 14:41.14 |
| | I have applied the service patch | 14:41.18 |
| | and 1.7 builds | 14:41.20 |
| Robin_Watts | tor8: wossa fault? | 14:52.50 |
| tor8 | linker crashes | 14:53.35 |
| Robin_Watts | runs a release rebuild. | 14:53.36 |
| | tor8: urk. | 14:53.48 |
| tor8 | I'm bisecting, looks like it might be somewhere among the LARGFILE commits | 14:53.56 |
| Robin_Watts | yes, I get the same crash. | 14:54.55 |
| tor8 | it's the "Enable FZ_LARGEFILE for all windows builds." that causes it | 14:55.22 |
| rayjj | kens: When vector devices flatten transparency (PDF 1.3, ps2write, etc.) isn't Graphics/Text Alphabits relevant. Does it still cause the error message ? | 15:17.31 |
| kens | rayjj yes it is then relevant, but you aren't really producing a PDF file, you are producing an image wrapped up in a PDF file. | 15:18.01 |
| | Sice the pdfwrite devcie won't see the get_bits call (its handled by the rendereing device) it won't cause the problem | 15:18.21 |
| rayjj | kens: right. Does it work (have any effect, generate no spurious errors/warnings) ? | 15:19.00 |
| | kens: I could try it. I just thought you would know. | 15:19.23 |
| kens | haven't tried it, I don't anticipate any problmes | 15:19.29 |
| rayjj | kens: OK, I'll try ps2write and if it works, I'll add a comment to bug 696156 to that effect | 15:20.16 |
| kens | OK | 15:20.26 |
| Robin_Watts | tor8: I guess the next question is, is it the _LARGEFILE64_SOURCE or fz_off_t being 64bit. | 15:22.32 |
| rayjj | darn, it wasn't doing it for a while, but now my laptop has started again losing focus on the active window intermittently (aggravating). After it does, Alt-tab shows a 'zombie' icon (the default one) but it won't switch to it | 15:26.02 |
| Robin_Watts | procmon might tell you what is stealing focus ? | 15:26.26 |
| rayjj | Robin: yeah, but it is _so_ noisy. I might shut down as many apps as I can and have a go | 15:27.03 |
| Robin_Watts | rayjj: You can set filters, but figuring out what filter to use is the trick :( | 15:28.43 |
| | Damn. Gotta reboot. | 15:30.02 |
| sebras | tor8: why is mutiff.c separate from muimg.c? | 15:36.09 |
| | tor8: is it due to the multipage thing? | 15:37.47 |
| rayjj | found it. It is Dell Quickset -- trying to disable it now... | 15:51.54 |
| mvrhel_laptop | RobinWattsLenovo: So there is a minor commit on my mupdf repos for you to look over | 15:54.53 |
| | Thanks for getting back to me | 15:55.07 |
| Robin_Watts | mvrhel_laptop: Hmm. the #include "iapi.h" thing is going to break the android build unless I copy that header in. | 16:07.45 |
| mvrhel_laptop | right | 16:07.51 |
| | I was going to ask you about that | 16:07.56 |
| | do you not want it? | 16:08.02 |
| Robin_Watts | but it's probably the right thing to do, unless we want to have the api definitions we use inline. | 16:08.12 |
| | Could we wrap the entire file in #ifdef SUPPORT_GPROOF ? | 16:08.47 |
| | That way it won't break non gproof builds on android. | 16:09.11 |
| mvrhel_laptop | that makes sense | 16:09.46 |
| | will extern fz_document_handler gprf_document_handler; in document.h be ok? | 16:10.51 |
| | since gprf_document_handler will disappear | 16:11.24 |
| Robin_Watts | Yes, that's fine. | 16:11.31 |
| mvrhel_laptop | ok | 16:11.33 |
| fredross-perry | Robin_Watts: can we talk about proofing and pages? | 16:14.42 |
| Robin_Watts | We can. | 16:15.24 |
| fredross-perry | ;-) | 16:15.41 |
| Robin_Watts | I have not had a chance to look yet. | 16:16.06 |
| | My current feeling is that the java interface MuPDFCore offers is fine as it is. | 16:16.47 |
| | The UI only operates on the "current" page. | 16:17.08 |
| | I suspect the implementation of that is broken though currently, and I need to tweak it so that it works right by making some mupdf.c changes. | 16:17.37 |
| fredross-perry | Android is pre-rendering pages that are not yet current. So I suspect that when I call the proofing function in core, that itâs operating on the last-rendered page, not the current. | 16:18.48 |
| | Seem likely? | 16:18.56 |
| Robin_Watts | entirely possible. | 16:19.06 |
| | I believe Core knows what page is current though. | 16:19.24 |
| mvrhel_laptop | Robin_Watts: I updated the file in my repos | 16:19.40 |
| Robin_Watts | so when Core calls the JNI functions it can pass the page number through and I can work with that. | 16:19.48 |
| | mvrhel_laptop: Looks good to me. | 16:20.13 |
| mvrhel_laptop | ok thanks | 16:20.17 |
| fredross-perry | Thatâs what I was hoping for. I took a stab at that yesterday, but I donât think I got it right. | 16:20.27 |
| rayjj | kens: (for the logs) Sorry, but I re-opened bug 696156. Turns out that AlphaBits>1 works for ps2write IFF the PDF has transparency, but crashes (no error) on the sample file | 16:21.59 |
| | kens: unfortunately, if someone is converting with ps2write and wants AlphaBits when flattening transparency, some pages may have transparency and some not, so IMHO we should work if the params are set, and just ignore them if irrelevant to the vector device (pdfwrite 1.4) | 16:24.08 |
| fredross-perry | UI-wise, I was also thinking we could ask the user for the resolution as they are entering proofing mode, with a default of 300. | 16:36.50 |
| Robin_Watts | fredross-perry: Yes. That was my thought. | 16:37.22 |
| fredross-perry | I can get that going | 16:37.38 |
| | mvrhel_laptop: what did you say you would use for a default set of resolutions? | 16:38.30 |
| mvrhel_laptop | fredross-perry: 300 | 16:52.58 |
| fredross-perry | yes, but you said a list of chices, like 72, ... | 16:53.20 |
| | choices | 16:53.23 |
| mvrhel_laptop | oh | 16:53.25 |
| fredross-perry | I want to have the android build ask the user for one | 16:53.48 |
| mvrhel_laptop | Right now I have 72,96,150,200,600,1200,2400 | 16:54.12 |
| | oops | 16:54.23 |
| | 200 should be 300 | 16:54.29 |
| Robin_Watts | mvrhel_laptop: Is that a drop down menu where you can select one of those, or enter a specific one of your own devising? | 16:55.20 |
| mvrhel_laptop | right now its a drop down menu where you select. I need to add the option of setting a custom one too | 16:55.48 |
| | you can select the icc profiles too and it should remember the ones that you have used in the past. | 16:56.36 |
| | right now though I need to figure out why I am only seeing a black image after rendering.... | 16:57.28 |
| fredross-perry | thanks | 16:58.16 |
| Robin_Watts | mvrhel_laptop: Have you updated your gs exe (and dll) since my commit the other day? | 16:59.36 |
| | One of the cases in the gproof device within gs was broken, and it meant that the rgb image was coming out all black (or all white) depending on pointer values. | 17:00.31 |
| mvrhel_laptop | Robin_Watts. I thought I did | 17:20.27 |
| | but let me make sure I actually rebuilt the dll.... | 17:20.38 |
| Robin_Watts | mvrhel_laptop: Also, there looked to be about 4 cases in there, and I only fixed/checked the one case that I was using. | 17:21.02 |
| mvrhel_laptop | ok | 17:21.14 |
| sebras | tor8: have I mentioned that I really dislike jpegxr? :-P | 17:38.27 |
| mvrhel_laptop | Robin_Watts: did we want to make gproof part of the standard windows build? | 18:02.23 |
| Robin_Watts | I dunno. I have a commit on my repos that does that, but I have been loathe to push it. | 18:02.46 |
| mvrhel_laptop | otherwise, everytime I do an update of gs for gsview, I have to do in there an add it to the mak file | 18:03.19 |
| | s/do/go/ | 18:03.25 |
| Robin_Watts | Then let's add it! | 18:03.45 |
| mvrhel_laptop | ok sounds good to me | 18:03.54 |
| | will you go ahead and commit | 18:04.03 |
| | Robin_Watts or I can do it if you are busy | 18:18.55 |
| Robin_Watts | mvrhel_laptop: I can do that. | 18:19.41 |
| | Done. | 18:22.29 |
| henrys | hmm shelly is now back? I just started looking at these jbig2 problems assuming he wasn't available | 18:22.50 |
| mvrhel_laptop | Robin_Watts: great. thanks | 18:25.49 |
| | lunch | 19:29.08 |
| fredross-perry | henrys: robin_watts: here is one that presnts a choice of resolutions: http://ghostscript.com/~fred/gsproof-dev.apk | 20:34.40 |
| shelly_ | hi henry, definitely back, is there something you want me to look at first or shall I continue with fuzzing segfaults? | 21:24.22 |
| henrys | shelly_: sure I fixed this http://bugs.ghostscript.com/show_bug.cgi?id=696052 so skip that one. | 21:26.40 |
| shelly_ | henrys: ok, do you have any specific bugs you want me to check? | 21:32.09 |
| mvrhel_laptop | and I finally have gsview working through the various gproof hurdles | 21:35.12 |
| | now, to clean up a few things | 21:35.26 |
| fredross-perry | mvrhel_laptop: let me know when youâve checked in something I can check out and steal from. Thanks. | 21:43.03 |
| Robin_Watts | fredross-perry: That looks lovely. | 22:32.39 |
| | Seems quite fast too. | 22:32.56 |
| fredross-perry | On my Nexus 7 not so much. What are you running? | 22:33.25 |
| Robin_Watts | LG G3 | 22:33.32 |
| | actually, seems slower with a bigger file. | 22:34.11 |
| fredross-perry | I think if we can sort out the page stuff, I could be more or less done, at least demoable. | 22:35.04 |
| Robin_Watts | yeah. That'll be my job for tomorrow (should be able to use my proper PC rather than my laptop) | 22:35.28 |
| rayjj | Robin: "actually seems slower with a bigger file". Are you surprised? ;-) | 22:43.47 |
| henrys | shelly for the logs anyting that is bountiable | 22:47.07 |
| rayjj | henrys: I assume that we assume testing is free (we don't pay bounties for something we've already fixed) which is what you've been seeing. | 22:48.42 |
| henrys | yeah he's good about that | 22:50.05 |
| rayjj | henrys: yeah, shelly is good. I was curious about the "policy" | 22:51.01 |
| henrys | if they were standing in line to fix problems it'd be a concern ;-) | 22:53.18 |
| | Forward 1 day (to 2015/08/20)>>> | |
IRC Logs