| | <<<Back 1 day (to 2012/08/21) | 2012/08/22 |
| rayjj | alexcher: thanks. I agree and have closed the bug | 01:25.08 |
| | stoopid cmd_compress_bitmap doesn't work -- why do we bother to try to compress ? | 02:20.34 |
| | the RLE compressor can't decide on the basis of a single raster line (of all the same data) what the run length should be, but then the cmd_compress_bitmap bails because no data was consumed "-( | 02:22.54 |
| | :-( | 02:22.57 |
| | mvrhel: I see what is going on with the clist, but don't understand why yet. It is writing a different number of bytes than it reads (by a fairly large amount). | 02:42.13 |
| | I'll come back after dinner... | 02:47.27 |
| mvrhel | rayjj: ok | 03:33.09 |
| | rayjj: I was wondering about the cmd_compress_bitmap | 03:33.44 |
| | seemed really funny to me | 03:33.50 |
| | rayjj: I am done for the evening. I will chat with you tomorrow | 04:09.57 |
| ray_work | thinking about the cmd_compress_bitmap, I think the real problem is in the RLE compression filter -- it doesn't consume its input because it doesn't hit a change or its max repeat count, which seems wrong. | 04:54.53 |
| rayjj | the RLE filter is DEFINITELY honked up. It should save the value and count in its state and CONSUME the input | 05:27.50 |
| | mvrhel: (for the logs). I found at least one issue with the reading. The RLE is still non-functional since it is honked up. The problem is that the reading of the bitmaps didn't allow for 'short_size' of the last raster line | 06:30.32 |
| ray_work | grr.. ddd run locked up peeves :-( | 07:02.57 |
| rayjj | at least I could kill it from an SSH session from another computer :-/ | 07:06.39 |
| | well, I got rid of the SIGFPE. Now I have a Segmentation fault. :-( | 07:08.42 |
| | time for bed | 07:08.44 |
| | hi, chrisl, bye, chrisl | 07:11.13 |
| chrisl | g'nite rayjj | 07:11.28 |
| rayjj | see you in a few hours... | 07:11.41 |
| chrisl | sleep well | 07:11.52 |
| paulgardiner | Robin_Watts, tor8: there are a few commits on paulg/forms if you have a moment. | 13:47.01 |
| Robin_Watts | paulgardiner: Looking. | 13:55.25 |
| paulgardiner | Robin_Watts: ta | 13:55.35 |
| Robin_Watts | How many of them? 3? | 13:55.47 |
| | For the "treat NULL event value as "" in pdf_js_setup_event" one there is a subtle change in behaviour. | 13:57.14 |
| | Previously, if the fz_strdup failed, it would have already have set the js->event.target before the error got thrown. | 13:57.38 |
| paulgardiner | 6 commits altogether I think | 13:58.07 |
| Robin_Watts | Now, it only sets that after the fz_strdup completes, which is probably better, I reckon. | 13:58.23 |
| tor8 | Robin_Watts: http://ghostscript.com/~tor/stuff/zeniko.txt that's what I've come up that may be potentially bountiable by digging through the commit list. can you think of anything I missed? | 14:00.09 |
| paulgardiner | Robin_Watts: Yes. Behaviour changes was unintended, but I think liuckily an improvement | 14:00.37 |
| Robin_Watts | tor8: So 6 bounties? | 14:00.47 |
| tor8 | unless we want to merge the 3 xps ones into one | 14:01.07 |
| | but I think that's up to miles or henry to decide | 14:01.22 |
| | how generous they want to be | 14:01.28 |
| | individually those patches/features are quite small | 14:01.37 |
| | the symbolic font crap is a small bits of work, but the sum is quite a lot of effort which I think deserves recognition | 14:02.18 |
| Robin_Watts | Right. Gathering such things together into headings sounds perfectly reasonable to me. | 14:02.41 |
| | I haven't looked at the lists yet, but I will try to do so in a bit. | 14:03.00 |
| paulgardiner | Robin_Watts: pushed fix for the top-bit slip | 14:57.54 |
| Robin_Watts | I'm now confused by the code later in that same function. | 14:58.14 |
| | I get the chartorune. | 14:58.32 |
| | then we do a linear search in pdf_doc_encoding for the value of j that maps to rune ? | 14:59.01 |
| paulgardiner | yep | 14:59.14 |
| Robin_Watts | fair enough. | 15:00.13 |
| | linear search is nasty. | 15:00.23 |
| paulgardiner | ah good. Thought you'd found another cock up | 15:00.28 |
| | Robin_Watts: Yeah, but the code should rarely take that branch for most docs | 15:00.50 |
| Robin_Watts | If this is hammered a lot, we may want to have a bsearchable reverse version. | 15:00.53 |
| paulgardiner | Yes I can imagine us doing so | 15:01.43 |
| Robin_Watts | Can js->doc ever be null ? | 15:01.51 |
| paulgardiner | I don't believe so | 15:02.04 |
| | js should never be created without an already existing doc | 15:02.37 |
| | And js->doc is set in the js constructor | 15:02.58 |
| Robin_Watts | Ok, all look good to me. | 15:04.59 |
| paulgardiner | Brill thanks. | 15:05.08 |
| Robin_Watts | and pushed. | 15:06.03 |
| henrys | tor8:list looks fair to me, if it is everything. | 15:41.34 |
| Robin_Watts | In ref_s, why is boolval a ushort rather than a uchar ? | 15:45.02 |
| chrisl | Or even a bool? Why does it matter? | 15:54.07 |
| Robin_Watts | shorts are slower to access than chars or ints on some archs | 15:54.32 |
| chrisl | Even in a union? | 15:55.51 |
| Robin_Watts | yes. | 15:56.00 |
| chrisl | Well, it would make sense to make it a bool | 15:56.17 |
| Robin_Watts | Admittedly it's not huge, and it may not be current versions of chips, but... | 15:56.36 |
| chrisl | I thought it was only slower if it was aligned on a 2 byte boundary | 15:57.45 |
| Robin_Watts | ARMs pre v4 didn't have halfword load/store instructions. | 15:58.36 |
| | You either had to load/store ints and mask, or load/store bytes and orr together. | 15:58.50 |
| | but those are OLD chips. | 15:59.15 |
| | I just wondered if there was some special reason for this I wasn't following. | 15:59.33 |
| chrisl | Well, just for clarity, as I said, I think bool would better | 15:59.37 |
| henrys | I would check the code to see where that value is used before changing it. Knowing peter he probably sets the high byte to 1 and the low byte to 0 for "maybe" | 16:00.41 |
| | chrisl is now our investigator. | 16:04.59 |
| chrisl | For what? | 16:05.22 |
| chrisl | is suspicious about being volunteered things, now! | 16:05.34 |
| henrys | I was referring to the first sentence of the most recent support request | 16:05.58 |
| chrisl | Ah, right - 250 a day, plus expenses...... ;-) | 16:06.35 |
| henrys | ... there is a matter that I want you to investigate ... sounded funny upon first reading | 16:06.38 |
| kens | Does he get a piece of coloured chalk and a business card with question marks on it >? | 16:06.39 |
| henrys | I'm thinking more like Columbo with hat and topcoat. | 16:07.32 |
| Robin_Watts | I'm now not going to be able to think of Gemma as anyone other than Jessica Rabbit. | 16:08.02 |
| chrisl | Now that *would* be worth a trip up to Leeds ;-) | 16:08.33 |
| henrys | ;-) | 16:09.20 |
| chrisl | Anyway, industrial espionage aside, I think the problem is a terminology mismatch between PDF/PS and the UFST | 16:10.24 |
| kens | Time for me to go for a pizza, night all | 16:10.37 |
| Robin_Watts | Night kens | 16:10.46 |
| henrys | chrisl:well I'm glad it didn't suck up a lot of your time. | 16:11.19 |
| Robin_Watts | ghostscript-logs seems quiet. | 16:16.44 |
| Robin_Watts | moves downstairs to swap HDs in the macbook. back in a bit. | 16:18.10 |
| chrisl | henrys: well, we'll see once I've done some more testing. It has meant I didn't get a chance to do the copyright and bug bounty stuff yet | 16:19.26 |
| | I have to run an errand, bbiab | 16:21.33 |
| henrys | chrisl, Robin_Watts:thinking more about bugzilla and copyright notices, I am not sure it improves the situation legally, without a signature I don't think it really means much. | 16:41.17 |
| | with the usual IAMNAL | 16:42.02 |
| rayjj | henrys: there is legal precedent for 'shrink wrap' agreement that doesn't require signatures. The principal is that you are notified ahead of time, and agree to proceed anyway (IAMNAL) | 16:45.13 |
| henrys | let's hope scott-san doesn't bring his nasty texas west nile virus to the Bay. Wash your hands if you shake with him ;-) | 16:46.09 |
| rayjj | mvrhel: are you here ? | 16:46.25 |
| henrys | rayjj:there is that yes, but with that argument we should no longer need a signature? | 16:47.25 |
| | and I don't think that is what legal has recommended. | 16:47.38 |
| | I think Miles should follow up with the lawyer. | 16:47.52 |
| chrisl | Well, we can't reasonably get a signature for every patch we accept | 16:48.07 |
| rayjj | henrys: well, we'd need to make sure that we have the proper "I agree to these terms" click event (which we don't) | 16:48.10 |
| | chrisl: no, but we can make it a part of getting a user ID on bugzilla | 16:48.32 |
| chrisl | Yes, I *think* that should be sufficient | 16:48.50 |
| henrys | rayjj:I like that idea. | 16:48.58 |
| rayjj | chrisl: they'd do it once, then all future patches are under the terms (bounty program, copyright assignment, ...) | 16:49.29 |
| chrisl | Whatever we do, we shall have to be more careful when we get patches in other ways - I occasionally get patches via e-mail, or a link in the bug etc | 16:49.55 |
| rayjj | henrys: obviously, we'd need to run it past SOWIAL | 16:50.01 |
| henrys | How do we deal with all the folks in bugzilla, who will be the majority of the contributors? | 16:50.25 |
| rayjj | chrisl: I think a link in a bug would be covered, but with email we'd have to request agreement. But I am reasonably certain that it doesn't require a signature | 16:51.07 |
| chrisl | henrys: currently, for anything more than a trivial change, I explicitly ask for copyright assignment before accepting patches | 16:51.51 |
| rayjj | henrys: that's a question for a lawyer, but technically, we could hack bugzilla to have a 'has agreed' status for users when posting bugs or comments, and make them click to agree before posting | 16:53.13 |
| henrys | chrisl:yes so do I and if everyone did that we really wouldn't need to do anything. I think that is the only way to catch all problems - I don't see how any automated system is going to cover everything, so it is that vs. human error. | 16:54.55 |
| chrisl | I wonder - there are *lots* of retail sites and the like that have a "Terms and Conditions" link, and just a check box "I agree to the terms and conditions". If that's legal, we could add that to the bug report page | 16:55.41 |
| henrys | why don't we just step back from this until the meeting? I think when something like this happens the immediate response is to overreact best to let it stew for a bit. | 16:57.24 |
| mvrhel | rayjj: I am here now | 16:57.52 |
| | or ray_work | 16:58.27 |
| chrisl | henrys: probably a good idea - hopefully, we can at least get clear questions to put to a lawyer, then | 16:58.43 |
| rayjj | mvrhel: OK, so I found out what was going on with the clist reading. | 16:59.28 |
| mvrhel | rayjj: great! | 16:59.36 |
| rayjj | mvrhel: since the RLE is honked up, it was storing the bitmap uncompressed (which is fine), but it when height > 1 it writes lines up until the last with full raster, but the last line is 'short_raster' | 17:00.50 |
| | mvrhel: when reading, it didn't pay attention to that, so it consumed too much data from the clist | 17:01.31 |
| mvrhel | aha. that is what I was seeing | 17:01.59 |
| | an extra 20 bytes getting eaten | 17:02.12 |
| | why did this not happen in windows rayjj? | 17:02.27 |
| | or was it just because of the diff in the data streams? | 17:02.38 |
| rayjj | mvrhel: I put a change in late last night, and it doesn't get the SIGFPE, but now (later) I get a segfault. :-( Looking into that now | 17:02.40 |
| mvrhel | oh | 17:02.49 |
| rayjj | mvrhel: also the way I did it will read past the point that was written, so I think I am going to change the fix so that cmd_read_short_bits gets the 'bytes' value that comes from clist_bitmap_bytes | 17:05.27 |
| | mvrhel: so it will avoid calling 'cmd_read_data' with a count that is too large. | 17:06.18 |
| mvrhel | rayjj: ok. let me know if you need me to do anything | 17:06.48 |
| rayjj | mvrhel: I would like you or Robin_Watts to have a look at base/srle.c and let me know if you think I should just toss it out, or fix it so that it consumes its input. The way it is, it fails miserably as a filter | 17:11.32 |
| | mvrhel: it strikes me as badly written, but maybe it's worth salvaging. I'd like opinions. I've done RLE before and it shouldn't be so complex | 17:12.32 |
| | mvrhel: hmm... so, my fix (the one I did last night) isn't right somehow. I set a conditional breakpoint and found an unexpected condition -- the amount read was LESS than 'bytes' | 17:17.01 |
| mvrhel | rayjj: I have to head out to the dentist. bbiaw | 17:19.23 |
| Robin_Watts | mvrhel: bitmap_raster is different on windows and on linux. | 17:20.54 |
| rayjj | mvrhel: have fun (or nitrous) | 17:21.10 |
| mvrhel | rayjj: taking kids to dentist.... | 17:21.27 |
| Robin_Watts | cos of the fact that longs are 8 bytes on 64bit linux, but always 4 bytes on windows. | 17:21.28 |
| rayjj | Robin_Watts: right, which is why I think it doesn't fail on Windows | 17:21.30 |
| Robin_Watts | rayjj: That was my point, yes. | 17:21.41 |
| rayjj | but it _should_ be possible to find a case with 4 byte raster sizes that fails on windows since 'short_raster' is to a byte | 17:23.00 |
| Robin_Watts | rayjj: Yes. but I think it's probably enough to know WHY the current example fails on linux but not windows. | 17:23.33 |
| rayjj | I caught it in a funky case and am looking into it now (reading LESS than expected) | 17:23.47 |
| Robin_Watts | I'm looking into some valgrind wierdness with gx_dc_ht_colored_fill_rectangle | 17:24.04 |
| rayjj | hmm... the funky case is when cmd_read_data doesn't have enough in the buffer | 17:27.12 |
| | welcome back, ghostbot | 18:45.29 |
| | ddd sure doesn't like running with -ZL :-( | 18:46.48 |
| m4rtyr | is there a way i can run that line of code[mudraw -o out.png -w400 -h400 in.pdf 1] with php? | 18:49.10 |
| | if you dont know off the top of your head i will look it up, i just figured you would know | 18:49.56 |
| rayjj | m4rtyr: should be able to run it, but the paths for mudraw and the out.png may need to be specified | 18:51.12 |
| | Robin_Watts: does mudraw support -o - (to go to stdout ?) | 18:51.59 |
| m4rtyr | ok i have mudraw installed by using the path given when i checked to see if my box had it or not | 18:58.02 |
| | the command was: | 18:58.07 |
| | mudraw -o /var/www/markets/casestudies/Thumb_Exacq_ONVIF_Integration_Guide.pdf -w400 -h400 /var/www/markets/casestudies/Exacq_ONVIF_Integration_Guide.pdf 1 | 18:58.08 |
| | it came back with command not found | 18:58.29 |
| rayjj | m4rtyr: right, so you might need to specify the path for mudraw. see what: which mudraw gives you and use the full path | 19:03.43 |
| m4rtyr | oh the path where mudraw was installed? | 19:05.26 |
| | sorry i am a command line noob | 19:05.31 |
| Robin_Watts | "which mudraw" | 19:08.47 |
| m4rtyr | that doesnt yield anything | 19:09.08 |
| | which mupdf yields /usr/bin/mupdf | 19:10.13 |
| | that what you meant? | 19:10.21 |
| tor8 | Robin_Watts: ubuntu's mupdf may predate the mudraw name | 19:10.32 |
| | m4rtyr: does mupdfdraw or pdfdraw work? | 19:10.51 |
| m4rtyr | do i need to type mupdf before any of that? | 19:11.53 |
| | if not they both dont work | 19:12.04 |
| Robin_Watts | did you: apt-get install mupdf-tools ? | 19:12.32 |
| m4rtyr | oh i thought that was optional | 19:12.46 |
| | i have it now | 19:13.15 |
| | pdf draw works | 19:13.44 |
| | mupdfdraw says command not found | 19:14.04 |
| | so i need to use pdfdraw instead of mudraw | 19:14.30 |
| Robin_Watts | yes. | 19:16.10 |
| | I wonder if that version of pdfdraw is too old to have the -w and -h options though. | 19:16.28 |
| m4rtyr | it is | 19:16.36 |
| | lol | 19:16.37 |
| | just tried it | 19:16.39 |
| Robin_Watts | Rats. You may need to build from source then. It is dead easy. | 19:17.00 |
| rayjj | Robin_Watts: or use gs ;-) | 19:17.25 |
| m4rtyr | lol | 19:17.30 |
| | ok | 19:17.38 |
| | ill just use gs | 19:17.41 |
| rayjj | apt-get install ghostscript | 19:18.07 |
| | (since you didn't have it) | 19:18.21 |
| m4rtyr | i just did gs -h | 19:18.31 |
| | and it gives the install path | 19:18.35 |
| | ok i think it is installed now | 19:18.48 |
| rayjj | ah ha. Found my typo and now it works. time for clusterpush | 19:18.52 |
| m4rtyr | ok now how do i use gs | 19:19.33 |
| rayjj | m4rtyr: as mentioned above -dPDFFitPage -g148x148 will give you an output file (jpeg or png as determined by the -sDEVICE=___) but it the page will be centered. | 19:20.02 |
| m4rtyr | thats np | 19:20.35 |
| rayjj | m4rtyr: gs -q -sDEVICE=png16m -o out.png -g148x148 -dPDFFitPage -dTextAlphaBits=4 -dGraphicsAlphaBits=4 in.pdf | 19:21.00 |
| m4rtyr | holy crap i think it worked! | 19:22.27 |
| | yup | 19:24.36 |
| | wow | 19:24.36 |
| | thank you so much for your help | 19:24.39 |
| | i really appreciate it | 19:24.44 |
| rayjj | m4rtyr: great. | 19:24.46 |
| m4rtyr | 1 more question | 19:25.55 |
| | the -g | 19:25.59 |
| | is that heightxwidth | 19:26.04 |
| | or widthxheight | 19:26.08 |
| rayjj | -gWWWxHHH | 19:26.26 |
| m4rtyr | awesome | 19:26.31 |
| rayjj | the latter | 19:26.32 |
| m4rtyr | thanks | 19:26.32 |
| | if the file name already exists what happens? | 19:27.23 |
| rayjj | m4rtyr: it gets overwritten (assuming permissions allow it) | 19:27.47 |
| | m4rtyr: note that gs also supports: -o - which writes to stdout so you can redirect stdout or -o |pgm (to pipe output to pgm) | 19:29.13 |
| m4rtyr | dude, i have no clue what that even means | 19:29.41 |
| | i remember seeing the stdout | 19:29.56 |
| | but i dont know what it does | 19:30.02 |
| rayjj | m4rtyr: as in: gs -q -sDEVICE=png16m -o - -g148x148 -dPDFFitPage -dTextAlphaBits=4 -dGraphicsAlphaBits=4 in.pdf > out.png | 19:30.15 |
| m4rtyr | ohhh | 19:30.34 |
| | nah this needs to be all done at once | 19:30.49 |
| rayjj | m4rtyr: but if you don't need it, ignore what I just said ;-) | 19:30.52 |
| m4rtyr | basically users are going to be submitting pdfs and i need a thumbnail for them when they are displayed | 19:31.05 |
| | instead of the entire file | 19:31.19 |
| | and this all happens dynamically which is why i need the script | 19:33.19 |
| | but anyways | 19:33.23 |
| | again, you guys are the shit | 19:33.29 |
| | thanks for the help | 19:33.33 |
| rayjj | mvrhel: when you get back from your kids' torture, I've done the improved fix and it now works. | 19:36.52 |
| | mvrhel: I'm going to clusterpush it next | 19:37.08 |
| ray_laptop | Robin_Watts: your patch fb55f251 errors out on a windows debug build: .\base\gsptype1.c(1460) : error C2059: syntax error : '}' (and same on line 1461) | 19:51.09 |
| | Robin_Watts: it's quite happy with { 0 } | 19:54.13 |
| | oops. gxclist.c as well. trying to get windows to build ... I'll push the patch when it builds | 19:55.35 |
| | ah, just those two. | 19:55.45 |
| m4rtyr | hey guys, i feel like the image's resolution isnt being maintained a.k.a. the image is being distorted, why is this? | 20:02.35 |
| ray_laptop | Robin_Watts: if you want to look over the changes, you can when my cluster run is done. This includes mvrhel's patch for "Enabling of fast threshold code for color source images as well as monochrome images to cmyk devices" | 20:02.49 |
| | m4rtyr: distorted how ? | 20:03.16 |
| m4rtyr | it just doesnt look crisp | 20:03.24 |
| ray_laptop | crisp ??? | 20:03.37 |
| | how big is your thumbnail ? | 20:03.49 |
| m4rtyr | -g110x142 | 20:04.22 |
| ray_laptop | with anti-aliasing (-dTextAlphaBits=4 -dGraphicsAlphaBits=4) (or with mudraw) things will get blurry -- that's a REALLY tiny bitmap. try at least 640x480 | 20:05.03 |
| m4rtyr | ahhhhh ok | 20:05.31 |
| | what if i dont use (-dTextAlphaBits=4 -dGraphicsAlphaBits=4)? | 20:05.39 |
| ray_laptop | I don't know what you expect to see on a bitmap that small except a general idea of what's on the page | 20:05.47 |
| | hmm... my clusterpush had lots of differences. I don't know how many are due to my fix and which are mvrhel's, so re-running with just my fixes (no changes expected) | 20:44.00 |
| | Robin_Watts: I committed a fix for the Windows build problem | 20:44.20 |
| | bbiaw | 20:45.40 |
| | Forward 1 day (to 2012/08/23)>>> | |
IRC Logs