| <<<Back 1 day (to 2013/08/14) | 2013/08/15 |
mvrhel_laptop | ray_laptop: oh ok | 00:03.13 |
| ray_laptop: I have to run my daughter to karate. I may give you a call in a bit. I had talked with miles | 00:04.10 |
ray_laptop | mvrhel: OK. | 00:04.38 |
| call whenever | 00:04.46 |
mvrhel_laptop | it will be like 30 minutes or so | 00:04.48 |
ray_laptop | mvrhel: should be about right. My son's piano is at 5:30 and I'll be waiting till 6 | 00:05.19 |
chrisl | ray_laptop: good morning/evening | 06:37.21 |
Robin_Watts | mvrhel: I have an rpi, yes, but I've not powered it up yet. | 07:36.05 |
| I have a beagleboard that I have used for ARM gs/mupdf stuff before. | 07:36.26 |
kens | congratulations on the release chrisl | 08:07.04 |
chrisl | kens: thanks, good to get it done. Now back to real work..... | 08:08.11 |
kens | :-) | 08:08.28 |
| Oh oh | 08:09.00 |
| I htinkI just pushed the wrongbranch somehow | 08:09.09 |
chrisl | To where? | 08:09.52 |
kens | OK looks like I pushed it to branch, so that's OK | 08:09.52 |
| Seems I pushed my ramfs branch, I'm unsure why | 08:10.06 |
chrisl | It won't do any harm | 08:10.58 |
kens | Yeah, but it was surprising to me | 08:11.19 |
| Because I was *not* on that branch | 08:11.36 |
| It does explain why it took such a long time to push though | 08:12.08 |
| OK there's the real one done now | 08:12.44 |
tor7 | Robin_Watts: could you sanity check the mupdf win32 binary release on mupdf.com/download/ please? | 09:34.04 |
| if it checks out fine, I'll upload to google code and make the webpage announcement | 09:34.16 |
Robin_Watts | tor7: looking now. | 10:41.46 |
| tor7: I suspect we should be putting it on downloads.ghostscript.com/public/mupdf-1.3/ | 10:42.51 |
tor7 | Robin_Watts: rather than google code? | 10:43.06 |
Robin_Watts | rather than mupdf.com/download | 10:43.26 |
| mupdf.com/download is casper hosted right? | 10:43.38 |
| downloads.ghostscript.com bandwidth costs us nothing. | 10:43.50 |
tor7 | considering they're shutting down google code downloads soon it may be worth moving off of it | 10:43.50 |
Robin_Watts | casper bandwidth costs us. | 10:43.55 |
tor7 | Robin_Watts: yes, we don't link to mupdf.com/download/ anywhere though | 10:44.05 |
Robin_Watts | ah, ok. | 10:44.16 |
tor7 | all the download links point to google code | 10:44.17 |
| this is just for archiving and our private use, should google code go down | 10:44.35 |
Robin_Watts | tor7: Right. | 10:44.42 |
tor7 | putting all the files on downloads.ghostscript.com sounds like a good idea. what's needed to upload files there? | 10:45.03 |
Robin_Watts | tor7: Log in details are in ~robin on casper. | 10:45.16 |
| DownloadsInformation.txt or something equally strangely named :) | 10:45.27 |
| cos I have the memory of a fish. | 10:45.44 |
tor7 | Robin_Watts: you have a lot of files in ~robin! | 10:45.55 |
| right, got the file | 10:46.09 |
| FTP? ugh. | 10:46.16 |
Robin_Watts | FTP is what I use. Other options may be available. | 10:46.32 |
tor7 | I'm so used to scp/sftp these days | 10:46.45 |
| Login incorrect... | 10:47.37 |
chrisl | tor7: I can upload it if you prefer - I'm used toftp://ftp...... | 10:48.15 |
tor7 | I was about to do it, but the login details in ~robin don't work for me :( | 10:48.39 |
Robin_Watts | tor7: You're using the godaddy ones, right? | 10:49.07 |
chrisl | They worked this morning..... | 10:49.07 |
tor7 | Robin_Watts: ah, no. was using the opentransfer one | 10:49.43 |
chrisl | Robin_Watts: maybe you should remove the non-godaddy ones? We don't have the ix account any more, do we? | 10:50.01 |
Robin_Watts | chrisl: yeah. | 10:50.09 |
tor7 | the godaddy etryn doesn't have a ftp server host name | 10:50.29 |
chrisl | ftp://downloads.ghostscript.com | 10:50.51 |
| Robin_Watts: and I meant to ask, on the godaddy site, there's "/public" directory, as well as the "/downloads/public" - should we empty out "/public", since we don't, AFAIK, use it? | 10:52.01 |
Robin_Watts | chrisl: Yes, cos I've just been staring at it being very confused :) | 10:53.24 |
chrisl | Yeh, me too! | 10:53.34 |
| Do you want to do it - if you're connected? | 10:53.46 |
Robin_Watts | chrisl: For now, I'm going to rename it to "public-deleteme" | 10:54.03 |
chrisl | Okay | 10:54.12 |
Robin_Watts | I'm not a coward, oh no. | 10:54.21 |
| Anyone here have a kindle? | 10:55.50 |
| (or a kindle app somewhere) | 10:55.59 |
chrisl | And probably delete http://downloads.ghostscript.com/public/mupdf-1.1-tech-preview/ too? | 10:56.04 |
Robin_Watts | chrisl: Or move it to archive or something. | 10:56.16 |
chrisl | Well, surely the 1.1 "tech preview" is long outdated now? | 10:56.41 |
Robin_Watts | chrisl: yes, but we keep all the old gs versions around, right? | 10:56.56 |
| We should similarly have the old mupdf versions around. | 10:57.06 |
chrisl | We keep release, not release candidates, betas etc | 10:57.21 |
Robin_Watts | the tech preview was a release, IMHO. | 10:57.39 |
chrisl | And frankly, I think we shop stop keeping all those old versions, and just keep the last four or so | 10:58.14 |
tor7 | chrisl: all the mupdf release files are in ~tor/public_html/mupdf/download/archive/ | 10:58.59 |
chrisl | tor7: but not the "1.1 tech preview" | 11:00.07 |
tor7 | chrisl: no, robin did that one | 11:00.19 |
| and marcosw said he was going to move the mupdf files to /var/www somewhere but that hasn't happened yet | 11:00.54 |
chrisl | tor7: yeh, I think he keeps asking you if he should do it, when you are not around..... | 11:01.51 |
tor7 | well if he asks again, just say I said Yes! Do it already! :) | 11:02.22 |
chrisl | tor7: I will if I'm around - I usually see the question hours later, too | 11:03.07 |
Robin_Watts | tor7: Sorry, got distracted. The windows binaries look fine to me. | 11:18.47 |
tor7 | Robin_Watts: fab. thanks. | 11:29.54 |
| chrisl: Robin_Watts: okay, release is done. | 11:48.52 |
Robin_Watts | Evilness: Things to commit just before you leave your job... https://gist.github.com/aras-p/6224951 | 11:59.12 |
kens | Hmm chrisl I see someone complaining that GSView 5 is not compatible with GS 9.08, I wonder what changed.... | 13:29.27 |
| I feel a git bisect coming on | 13:29.43 |
Robin_Watts | performs the ray summoning tea making ceremony. | 14:04.32 |
kens | Drat, the problem with GSView is somethign to do with VM allocation mode and setpagdevice and SAFER, if I turn off SAFER it works. | 14:30.14 |
| Hmm, or maybe I tested that wrongly | 14:31.11 |
Robin_Watts | So ray has this cunning "no dropout downscaler", that picks the darkest color out of all the contributions for a given pixel to be the one that it uses. | 14:39.58 |
| In order to do that he has to know what 'darkest' means (i.e. if we are in additive or subtractive spaces). | 14:40.19 |
| And he's judging that by looking at penum->dev->color_info.polarity == GX_CINFO_POLARITY_ADDITIVE | 14:41.02 |
| but that tells us about the destination space of the scale, not the source data space when we have an ICC transform. | 14:42.50 |
| I fixed a problem here where the space was being ignored, and consequently I'm now seeing some files look worse. | 14:43.27 |
tor7 | Robin_Watts: is the image data already transformed by the /Domain and /Range entries? | 14:46.01 |
| and then there's transfer functions... | 14:46.09 |
Robin_Watts | tor7: I'm going to say no. | 14:47.10 |
| oh, well. domain and range maybe. | 14:47.24 |
| transfer functions, no. | 14:47.33 |
chrisl | kens: sorry, I've been having lengthy swearing fit at someone complaining about GSView this soon after the release! | 14:47.44 |
tor7 | Robin_Watts: just tossing out wild ideas that may impact the definition of "darkest" that may not be obvious | 14:47.44 |
| BlackIs1 | 14:47.46 |
Robin_Watts | tor7: Indeed. | 14:47.57 |
kens | NP chrisl | 14:48.10 |
Robin_Watts | Essentially, I've convinced myself that ray's code is wrong (possibly because it predates all that). | 14:48.21 |
| but I haven't figured out how to do it 'right' yet :) | 14:48.31 |
| I'm also not convinced that this code is being used in the right cases anyway. | 14:49.27 |
| The 'antidropout downscaler' is used when interpolation is required and we are going to a halftone device. | 14:49.56 |
| and the one thing you can say about this code is that it is NOT interpolating. | 14:50.42 |
henrys | kens:sigh that could restart the release testing I wonder what change caused it? | 14:51.00 |
Robin_Watts | henrys: Too late. Chrisl released already. | 14:51.22 |
henrys | oh didn't get through my mail yet. | 14:52.07 |
kens | henrys I know the change :-( | 14:52.32 |
| brb | 14:53.10 |
henrys | we may have a bad release - I can't see breaking gsview in a release. | 14:54.23 |
chrisl | Oh, well, so much for getting with real work...... | 14:55.12 |
kens | The commit was 939e32ff | 14:56.02 |
chrisl | Hmm, could we do a GSView release that doesn't user -dSAFER? | 14:56.41 |
kens | Trying to match the behaviour of Adobe interpreters (contra to the spec) for the benfit of ancient WP documents, while at the same time not breaking DPS | 14:56.54 |
| chrisl I'm not sure that works, I'm about to try it properly | 14:57.14 |
| No, turning off SAFER just makes it go wrong differently | 14:57.57 |
Robin_Watts | mvhrel: Morning. I'm hitting some vaguely color related problems here. When you have a few minutes can I bend your ear about them please? | 14:58.52 |
chrisl | kens: Oh :-( I'm rather concerned that GSView should depend on internal stuff like that - that seems *very* wrong | 14:59.08 |
kens | chrisl I'm not totally sure what's going on, it seems likely that its the ViewerPreProcess hook that's causing the problem | 15:00.01 |
| Of course I have no idea how to tell what GSView is actually sending to Ghostscript | 15:01.29 |
henrys | kens:the commit doesn't have a bug number? | 15:01.43 |
kens | henrys its a continuation of earlier work, commit 073f7be bug #687702 | 15:02.42 |
henrys | let's release once a year this time ;-) | 15:03.02 |
Robin_Watts | bug 687702 | 15:03.11 |
chrisl | Hmm, I thought GSView had a logging function that dumped what it send to GS, but I can't see it now :-( | 15:04.33 |
henrys | seriously I was going to recommend every 9 months at the next meeting. | 15:04.42 |
kens | I've been looking for it | 15:04.42 |
chrisl | henrys: I don't like 9 month release intervals, too confusing | 15:05.48 |
kens | command line invocation with -d then go hunting for the temporary files seems to be the answer | 15:06.10 |
henrys | chrisl: like a baby ;-) | 15:06.19 |
chrisl | kens: Ah, I knew I'd got it work at some point | 15:06.50 |
kens | Yeah, now I have to try and make it work.... | 15:07.05 |
chrisl | henrys: if it's a choice between 9 month releases and a child, I'll suffer the 9 nine month releases! | 15:07.31 |
| henrys: do you happen to know Norbert's company's customer number? We seem to have two listed by that name | 15:08.33 |
henrys | there are 2 customers I think you want 661 | 15:10.01 |
kens | Well, GSView is calling setpagedevice with Global VM set | 15:10.22 |
chrisl | Thanks | 15:10.24 |
| kens: I thought the way you'd done the changes that should work? | 15:10.59 |
kens | Ah, in fact it seems to be calling .locksafe when the problem occurs, so it *is* using undocumented internal operators | 15:11.03 |
chrisl | Eeek! | 15:11.19 |
kens | If I read this correclty, the line which causes a problem is "currentglobal true setglobal .locksafe setglobal" | 15:11.52 |
| I'll have to try that here now | 15:12.07 |
chrisl | wonders what .locksafe does..... | 15:12.20 |
henrys | Robin_Watts: since ray isn't here do you know if the band temp files are left for the entire job before deleting? | 15:12.24 |
kens | chrisl indeed that line seems to trigger the problem on GS | 15:12.49 |
Robin_Watts | henrys: I don't know, but it sounds likely. | 15:12.50 |
henrys | Robin_Watts: thanks I'll check. | 15:13.19 |
kens | mutters horribly about people using undocumented language extensiosn | 15:14.08 |
Robin_Watts | henrys: Can the code safely know that a band's file is done with? The device can getbits the same band multiple times if it wants, right? | 15:14.26 |
henrys | job or page is the question? | 15:15.17 |
chrisl | henrys: is this page clist files? | 15:15.56 |
henrys | I understand it must save at least a page. | 15:15.58 |
Robin_Watts | oh, sorry, I assumed they would be deleted at the end of each page. | 15:16.06 |
chrisl | IIRC, clist files are (or should be) truncated at the end of the page, ready for the next page (in normal use) | 15:16.50 |
Robin_Watts | chrisl: They have to go from "write" to "read" mode in order to be rendered. | 15:17.13 |
| hence a file *can't* contain more than 1 pages information, AIUI. | 15:17.33 |
henrys | I'lll figure it out, trying to understand how this customer could possibly go over 2 gigs with the fairly simple job he has. | 15:18.06 |
chrisl | Robin_Watts: yes, but we don't delete and create new clist files for each page, we open the same file, and truncate it | 15:18.15 |
Robin_Watts | chrisl: Ah! I did not know that. Thanks. | 15:19.55 |
kens | chrisl it may take me a little while to figure out why this is causing an invalidaccess. Setting /.LockSafetyParams always causes an invalidaccess, no matter what the VM status, I have no idea why yet. | 15:20.03 |
henrys | oh wait a minute he's pcl no band file in memory | 15:20.15 |
| unless he's configured it differently. | 15:20.32 |
chrisl | Robin_Watts: that's my understanding, anyway, it is a while since I looked at it, and may possibly have changed with "saved page" | 15:21.01 |
Robin_Watts | Hmm. I scared mvrhel off. | 15:21.18 |
chrisl | kens: take your time - I'm not in a huge rush to go through a release process again..... :-( | 15:22.00 |
kens | Yeah I figured that, but if I've broken GSView we probably need to fix it | 15:22.26 |
| Of course it would help if the user had tried it *before* the release instead of after | 15:22.41 |
chrisl | Perhaps we need a Windows developer to volunteer to test it before releases. I vote for Marcos! | 15:23.41 |
| (even though he's not a Windows user, nor (officially) a developer!) | 15:24.07 |
kens | I can (and probably should now) do that, it never occured to me to try it before | 15:24.08 |
Robin_Watts | mvrhel_laptop: Morning | 15:24.20 |
henrys | I take that back it is gs | 15:26.21 |
ray_laptop | good morning, all | 15:27.25 |
Robin_Watts | Aha. | 15:27.40 |
| Morning ray_laptop | 15:27.44 |
| ray_laptop, mvrhel_laptop: I've found a problem with the antidropout downscaler to do with colorspaces/ICC etc. | 15:28.27 |
| I'd like to run it past the pair of you, so can we find a time where you can all spare 15 minutes? | 15:28.49 |
mvrhel_laptop | Robin_Watts: ok. I will be back in about 15 minutes | 15:28.54 |
| must eat | 15:29.09 |
Robin_Watts | great, thanks. | 15:29.10 |
ray_laptop | OK. I'll be here -- my wife is taking my son to tennis | 15:29.27 |
| BTW, Robin_Watts you had a question about the clist files. Is that all straightened out ? | 15:30.04 |
chrisl | ray_laptop: I seem to remember you fixed a problem some time ago where clist files weren't being properly truncated between pages - am I right, or did I imagine that? | 15:30.21 |
henrys | ray_laptop:the customer is complaint the banding file with your recent change is greater than 2 gig is that expected? Or should I look into it. | 15:30.45 |
| ? | 15:30.46 |
ray_laptop | clist files (the pair) are for a single page, and "rewind" and start writing after rendering to be re-used for the next page | 15:30.55 |
henrys | s/complaint/complaining | 15:31.10 |
Robin_Watts | ray_laptop: clist question was henrys, not me. | 15:31.40 |
ray_laptop | henrys: the change for "default" image handling when interpolated clist only affects patterns that are large enough to triigger pattern-clist | 15:32.32 |
| chrisl: I don't know of any case where clist files don't get handled properly | 15:33.31 |
henrys | ray_laptop:with your last change the customer claims he is overflowing /tmp which is 2G, is that expected? | 15:33.40 |
chrisl | ray_laptop: I think I was thinking of bug 693621 - so probably not relevant to the customer henrys is talking about | 15:35.29 |
ray_laptop | henrys: I suppose it _could_ happen. with pattern-clist, they are smaller but then when rendering interpolated patterns, it is S..L..O..W | 15:35.38 |
| hmm... I wonder if it is writing the pattern in for many bands. | 15:37.41 |
| henrys: I haven't plowed through email. Is there an email with a file ? | 15:38.16 |
henrys | ray_laptop:it's the bug you just fixed. - don't use high level images .... | 15:38.59 |
| ray_laptop:http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=6c7d9d1 | 15:40.42 |
ray_laptop | henrys: I didn't look at the clist size. Let me see what I get | 15:43.45 |
kens | chrisl I have a quick and almost certainly safe fix for the invalidaccess, which thensimply revelas another problem, inability to find ProcSet resources | 15:45.41 |
| I wonder how much magic GSView is usig :-( | 15:46.11 |
ray_laptop | henrys: I only get 28Mb clist with that file (bug 694514) | 15:46.54 |
henrys | ray_laptop:oh okay I'll continue sparring with them. | 15:48.09 |
ray_laptop | page 3 is a little larger, but still only 35 Mb | 15:49.17 |
chrisl | kens: Okay, well, I'll be going out at 5. I'll check the logs when I get back, so leave a message here (or e-mail) if you need anything from me | 15:50.21 |
kens | OK | 15:50.29 |
chrisl | When is Marcos due back from vacation? | 15:50.48 |
kens | next week as far as I know | 15:51.00 |
ray_laptop | henrys: bug 693621 _might_ be an issue. They are back at 9.05 | 15:51.02 |
kens | Oh joy, looks like GSView is trying to redefine pdfmark | 15:51.48 |
chrisl | WTF? | 15:52.01 |
kens | userdict /pdfmark {...} bind put | 15:52.34 |
| Its a massive redefinition too | 15:52.47 |
chrisl | I suppose in userdict it *should* be okay..... | 15:53.19 |
kens | Well, it seems to be causing an undefined resource error, don't know how yet | 15:53.51 |
| Trying to reproduce in GS | 15:54.02 |
ray_laptop | I guess Russell wanted to capture some of the pdfmark info to affect the "view" ? | 15:54.44 |
kens | Perhaps. WOrks perfectly when isolated out of GSView :-( | 15:55.05 |
chrisl | Off now - good luck kens! | 15:59.12 |
kens | bye chrisl | 15:59.23 |
ray_laptop | bye, chrisl | 15:59.34 |
henrys | ray_laptop:you are looking the cfile in the -Z: output for sizes right? | 16:01.41 |
ray_laptop | henrys: actually I was just looking in my temp dir while the job was being rendered | 16:03.31 |
| henrys: but -Z: agrees with it. It's just with pattern clist, it is rather "noisy" repeating the info for each band (129) | 16:04.29 |
henrys | ray_laptop:the cfile offset I have suggests double what you got but not anywhere near what the customer is reporting | 16:04.58 |
ray_laptop | henrys: for page 1 -Z: shows [:]clist_end_page at cfile=28937683, bfile=4768 | 16:05.56 |
| which agrees with the temp file size I saw | 16:06.14 |
| henrys: maybe they are using a different file ? | 16:06.36 |
henrys | right I got [:]clist_end_page at cfile=65112421, bfile=77648 | 16:06.46 |
| I'm using debug though are you? | 16:07.00 |
Robin_Watts | figures mvrhel is having a Robin-on-holiday sized breakfast... | 16:07.30 |
henrys | Robin_Watts: how was the food in Africa? | 16:08.17 |
| other than your mishap? | 16:08.25 |
Robin_Watts | At the places we stayed, brilliant. | 16:08.34 |
| except for 1 night when I was served "lamb" that was at best "mutton". | 16:09.00 |
ray_laptop | Robin_Watts: he's probably running his son to computer camp | 16:09.03 |
Robin_Watts | and it was the day after that where I was ill. | 16:09.12 |
| but then I'd also just visited the Himba tribe that day, who's primary claim to fame is that they never wash. | 16:09.46 |
ray_laptop | henrys: yes, I'm using debug, that's the only time -Z: prints out the file sizes | 16:09.51 |
Robin_Watts | It's an interesting testament to the power of technology that despite living without basic sanitation, let alone power, or internet or anything like that, that all the 3 or 4 year old kids there instantly twigged I had a touch screen on my camera, and were panning and zooming images without being shown how. | 16:11.16 |
ray_laptop | henrys: I don't understand how you get that | 16:11.19 |
henrys | ray_laptop: oh I thought you had set that up to output even with non debug but I guess that was just the timing and memory | 16:11.47 |
| ray_laptop:maybe something platform specific? | 16:12.21 |
ray_laptop | what do the tot_raw sizes say ? | 16:13.42 |
henrys | ray_laptop:debugbin/gs -Z: -dNOPAUSE -dSAFER -dBATCH -r600 -Ilib:Resource/Font -sDEVICE=tiffg4 -sOutputFile=BEAZH3P3.patch600.tiff ~/Downloads/BEAZH3P3.pdf | 16:14.05 |
ray_laptop | henrys: the clist isn't (afaik) 32/64 bit specific (at least not supposed to be) | 16:14.13 |
| henrys: mine is similar: debugbin/gswin32c -q -r600 -sDEVICE=tiffpack -sOutputFile=x.tif -Z: /c/temp/Bug694514.pdf | 16:14.50 |
haxwithaxe | is there a list somewhere of supported PDF versions for mupdf? | 16:14.55 |
henrys | tot_raw are in line with the other numbers. | 16:15.07 |
ray_laptop | haxwithaxe: all versions | 16:15.15 |
haxwithaxe | all features of all versions as of 1.2? | 16:15.32 |
ray_laptop | I have [:]tot_raw=33536, tot_compressed=0 [:]tot_raw=28267161, tot_compressed=0 | 16:15.59 |
Robin_Watts | haxwithaxe: 1.2 (and indeed 1.3, released today) will open all versions of PDF. | 16:16.05 |
haxwithaxe | awesomeness | 16:16.22 |
Robin_Watts | Claiming to support "all features" of PDF would be something that no one can do though, as there are so many wierd and wacky extensions out there. | 16:16.43 |
haxwithaxe | this will make my report to our japanese developers very short :P | 16:16.47 |
Robin_Watts | like 3d graphics, movies etc. | 16:16.52 |
haxwithaxe | yeah | 16:16.54 |
| oh yeah we don't even support that in our software :P | 16:17.09 |
Robin_Watts | but in terms of the standard features, we have them pretty well covered. | 16:17.12 |
| haxwithaxe: Which software is this? | 16:17.18 |
haxwithaxe | Antenna House Formatter | 16:17.29 |
| we do some of the multimedia stuff now but it's not display only inclusion | 16:17.49 |
Robin_Watts | ok, so you make a PDF creation tool. | 16:18.12 |
haxwithaxe | yup | 16:18.21 |
Robin_Watts | What is your interest in MuPDF? (He asks nosily :) ) | 16:18.24 |
haxwithaxe | FO or XML+XSLT or HTML+CSS to PDF | 16:18.37 |
| i have written a tool to test the output of our software that uses mupdf to render the PDF's to PNG's | 16:19.19 |
Robin_Watts | haxwithaxe: Isn't that just mudraw? :) | 16:19.47 |
haxwithaxe | yup | 16:19.54 |
| i don | 16:20.03 |
| t | 16:20.04 |
| even use the library :P | 16:20.10 |
Robin_Watts | fair enough :) | 16:20.19 |
haxwithaxe | i just use a copy of the mudraw binary | 16:20.27 |
Robin_Watts | If you ever want to be able to distribute that without having the GPL hassles, come back and talk to us. We can do commercial licenses too. | 16:20.55 |
haxwithaxe | mupdf is credited and GPL is included | 16:20.57 |
henrys | ray_laptop:I uploaded clist.log to casper in my home directory, it has all the output. | 16:21.51 |
haxwithaxe | we've talked to you guys previously but the GPL isn't a hassel in this case as we aren't altering the GPL'd code. | 16:21.56 |
ray_laptop | haxwithaxe: but you have to make sure that the mupdf that you use can be replaced by the user | 16:22.05 |
haxwithaxe | my former coworker has also contributed some patches | 16:22.11 |
| yeah | 16:22.19 |
| we only include it for windows users and they can swap it out with anything that has the same behaviour | 16:22.48 |
| linux and osx have to bring their own | 16:23.09 |
| we have customers running RH4 so we try to make everything modular <_< | 16:24.20 |
ray_laptop | henrys: that is strange | 16:24.25 |
| what if you leave out the -Ilib:Resource/Font ? | 16:25.41 |
haxwithaxe | i can give you guys a link to the demo and a demo license if you would like. it's not terribly exciting though :P | 16:26.29 |
mvrhel_laptop | ok I am back | 16:26.37 |
| what was to take 15 minutes took 45 :( | 16:26.49 |
Robin_Watts | mvrhel_laptop: No worries. | 16:26.56 |
mvrhel_laptop | ha | 16:27.03 |
| laughing at the comment above | 16:27.11 |
Robin_Watts | So, ray may be tied up with henrys, but I'll burble away and he can read the logs etc. | 16:27.32 |
| So if interpolation is required with an image, and it's a downscale, and we are going to a halftoned device, we have a special antidropout downscaler written by ray. | 16:28.22 |
| Effectively it looks at each of the source pixels that contribute to the downscaled pixel, and picks the darkest value. | 16:29.05 |
| hence if we downscale high res faxes etc, we don't lose the fine lines - they stay black. | 16:29.38 |
| In order to do this, it needs to have some concept of what "darker" means. | 16:29.59 |
| i.e. it needs to know if it's working in an additive or a subtractive space. | 16:30.14 |
| and based on that it keeps the min or max values respectively. | 16:30.33 |
| mvrhel: making sense so far ? | 16:30.40 |
mvrhel_laptop | yes | 16:30.55 |
Robin_Watts | OK, so the problem comes in the _icc variants of the code. | 16:31.13 |
| In those variants, the downscale happens pre-color conversion. | 16:31.38 |
| and we detect whether we are in additive or subtractive space based on the result of the color conversion. | 16:32.09 |
| hence if we have an icc link that maps from a source space where 0 is white, to one where 255 is white (or vice versa), we get the 'darker' test wrong. | 16:32.59 |
mvrhel_laptop | this sounds like a paradox.... | 16:33.04 |
| how do we detect based on the result of conversion when we have not yet done the conversion | 16:33.24 |
Robin_Watts | mvrhel_laptop: What I am saying is "our detection of additive/subtractive is broken". | 16:33.56 |
ray_laptop | Robin_Watts: where is that detection done ? | 16:34.20 |
Robin_Watts | And my next question is "can we fix it?" | 16:34.22 |
| gxiscale.c | 16:34.37 |
| line 323 | 16:34.40 |
| iss.ColorPolarityAdditive = | 16:34.48 |
mvrhel_laptop | ok. if we are using the source space, why not use its additive/subtractive setting | 16:34.50 |
Robin_Watts | penum->dev->color_info.polarity == GX_CINFO_POLARITY_ADDITIVE; | 16:34.50 |
mvrhel_laptop | not the device | 16:34.56 |
Robin_Watts | mvrhel_laptop: Do we have that info ? | 16:35.32 |
mvrhel_laptop | sure. do we have a source color space | 16:35.44 |
ray_laptop | Robin_Watts: we know the image colorspace | 16:35.51 |
Robin_Watts | ok. For extra credit, we should consider Decode arrays and transfer functions too. | 16:36.44 |
ray_laptop | Robin_Watts: it's in penum->pcs (also pcs is set to that) | 16:37.02 |
Robin_Watts | So, can I change the code to use penum->pcs->color_info.polarity in all cases? | 16:37.38 |
| Or only in the icc case ? | 16:37.42 |
mvrhel_laptop | Robin_Watts: sometimes we do interpolation before conversion and sometimes we do it the other way. Are you sure that this does not also happen with the case you are looking at here? | 16:38.16 |
| i.e. iss.early_cm | 16:38.24 |
Robin_Watts | I am not sure. | 16:38.31 |
mvrhel_laptop | I guess if we are downscaling | 16:38.58 |
Robin_Watts | In the case I have captured in the debugger, the conversion happens late. | 16:39.01 |
mvrhel_laptop | we are doing conversion after | 16:39.04 |
| I would think | 16:39.08 |
| I would hope | 16:39.10 |
| which makes sense | 16:39.28 |
Robin_Watts | It may be that the detection has to change according to whether we convert before or afterwards. | 16:39.39 |
mvrhel_laptop | sorry just thinking aloud on IRC | 16:39.40 |
haxwithaxe | dangerous :P | 16:39.49 |
mvrhel_laptop | if we are using the downscaler I am pretty certain we will be doing conversion after based upon line 244 | 16:40.29 |
| so you def want to look at what the image color space | 16:40.54 |
Robin_Watts | OK. I shall experiment a bit based on using pcs. Thanks. | 16:41.01 |
mvrhel_laptop | and its polarity | 16:41.03 |
| ray_laptop: did you see the email from takane-san? | 16:41.56 |
| It looks like generating PCL will be useful for us to compare for those files | 16:42.33 |
ray_laptop | mvrhel: no. The last email I have from him was on Aug 1 | 16:43.49 |
mvrhel_laptop | he also has PS data | 16:43.52 |
| ray_laptop: I will forward to you | 16:43.59 |
ray_laptop | was I cc'ed ? | 16:44.08 |
mvrhel_laptop | on the reply from miles, yes with the attachements | 16:44.33 |
| today at 1:44am | 16:44.52 |
| miles was up late | 16:44.56 |
| ray_laptop: ^^ | 16:45.14 |
henrys | can we cc: tech@artifex.com on all of this business mvrhel_laptop? | 16:45.19 |
mvrhel_laptop | henrys: yes | 16:45.48 |
ray_laptop | mvrhel: I only see the PCL xlsx attachments | 16:46.21 |
henrys | thanks, mvrhel_laptop | 16:46.29 |
| bbiab | 16:46.30 |
ray_laptop | mvrhel: I don't understand how an ARM 9 at 600 MHz does the 20 page j12 in 7.3 seconds ? | 16:48.32 |
| oh. pages per minute. that makes more sense | 16:49.09 |
Robin_Watts | How do I figure out the polarity from pcs again? | 16:49.59 |
kens | chrisl for the logs. I believe I have a fix for GSView now, but I want to do some more builds and tests. I'm off out in 5 minutes for a couple of hours, but I've kicked off the cluster tests and the builds, will be back later | 16:57.14 |
Robin_Watts | mvrhel_laptop: ^ | 16:57.16 |
| ray_laptop, mvrhel_laptop: Other bits of code appear to work on the basis that if a colorspace has 4 or more components it's subtractive. Is that reasonable ? | 17:04.26 |
ray_laptop | Robin_Watts: nope | 17:04.53 |
| but it usually works | 17:05.07 |
Robin_Watts | ok, so how do I figure out polarity from a pcs ? | 17:05.14 |
mvrhel_laptop | Robin_Watts: so DeviceN is the one that could cause you some issues | 17:07.04 |
| as its components may be additive or subtractive | 17:07.33 |
Robin_Watts | mvrhel_laptop: You're saying I need to examine the pcs->type field and write code for each case ? | 17:08.02 |
mvrhel_laptop | actually, deviceN will not be using the icc flow | 17:08.06 |
| iirc | 17:08.13 |
ray_laptop | the pcs->type->index is the first clue. If it's gs_color_space_index_DeviceGray or gs_color_space_index_DeviceRGB then it's additive | 17:08.33 |
mvrhel_laptop | Robin_Watts: I am thinking out loud again | 17:08.35 |
| right to ray_laptop | 17:08.43 |
Robin_Watts | ray: makes sense. If not... | 17:08.56 |
ray_laptop | if it is gs_color_space_index_Indexed then you have to look at the base space | 17:09.14 |
mvrhel_laptop | CMYK and sep are subtractive | 17:09.20 |
ray_laptop | but I don't recall if the sample_unpack does the conversion from indexed space | 17:09.57 |
mvrhel_laptop | Robin_Watts: so for DeviceN we will not be using the icc work flow | 17:13.09 |
| so you will never find yourself in that code | 17:13.22 |
ray_laptop | Robin_Watts: so for indexed you use penum->pcs->base_space->type->index to see | 17:13.46 |
mvrhel_laptop | i.e. you will be in image_render_interpolate | 17:13.48 |
Robin_Watts | ok. | 17:14.10 |
| I'm wondering if the neatest solution to this isn't to write a function that takes a colorspace and returns a polarity. | 17:14.33 |
| hence it would be nice if we could cope with all cases. | 17:14.42 |
| rather than to just cope with the ones we'll meet in this case. | 17:14.56 |
ray_laptop | Robin_Watts: image_render_interpolate does the mapping to the base space colors for you when is_indexed | 17:15.26 |
| is_index_space, that is | 17:15.44 |
| BTW, the decode has already been done to your data by the time it gets to you | 17:17.20 |
Robin_Watts | ray_laptop: Right. but as I say, I think the neatest solution (if it's possible) would be to have a function that takes any pcs and returns the polarity. | 17:18.29 |
| It's the kind of thing that we ought to have somewhere, right? | 17:18.38 |
| If there are technical reasons why it can't be done, then fair enough, but otherwise it's probably worth the additional pain to get something that actually works in all cases. | 17:19.14 |
ray_laptop | probably should have. helps everybody get the same result (rather than hacks like basing it on num_components) | 17:19.48 |
mvrhel_laptop | yes I agree | 17:20.26 |
ray_laptop | touches nose. it's a "color" issue ;-) | 17:20.33 |
Robin_Watts | agrees with ray. | 17:20.53 |
| and has his finger on his nose too :) | 17:21.05 |
ray_laptop | Robin_Watts: so how does getting the polarity wrong sqush the image ? | 17:21.14 |
Robin_Watts | ray_laptop: No, this is a separate thing. | 17:21.26 |
ray_laptop | Robin_Watts: I see. | 17:21.53 |
Robin_Watts | The squishing was down to broken code where we accumulated scancolumns when the bpp was < 8. | 17:21.56 |
| repeated runs of colors were being squished. | 17:22.11 |
| I've fixed that. | 17:22.14 |
| but while I was floundering around in this code, I spotted that we weren't being consistent in our handling of the polarity. | 17:22.42 |
mvrhel_laptop | hey | 17:22.44 |
ghostbot | hi, mvrhel_laptop | 17:22.44 |
Robin_Watts | I've fixed that too locally, and it shows up problems - hence leading me to this issue. | 17:23.03 |
ray_laptop | Robin_Watts: I hadn't finished email. mvrhel called me and reminded me that I owe him something :-) | 17:23.07 |
| Robin_Watts: were you going to fix the bug in the downscale filter that you found ? | 17:24.46 |
Robin_Watts | ray_laptop: The bug I found in the downscale filter was the inconsistent handling of polarity. | 17:25.27 |
ray_laptop | (the while loop not checking polarity) | 17:25.28 |
Robin_Watts | I have a fix for that here. | 17:25.32 |
ray_laptop | Robin_Watts: OK. Thanks. | 17:25.41 |
Robin_Watts | but I can't commit that, as this issue (the fact that we are using the wrong polarity in some cases) means we get some regressions from it. | 17:26.03 |
| If we can fix this issue, then I can commit the fix, and we should get progressions. | 17:26.22 |
mvrhel_laptop | so, Robin_Watts are you fixing the polarity issue, or do I need to write a function for handing back polarity given a pcs? | 17:27.08 |
Robin_Watts | mvrhel_laptop: If you could write me that function, I'd be well away. | 17:27.29 |
| please. | 17:27.33 |
mvrhel_laptop | ok. Robin_Watts it will not take long but I want to work on these performance numbers first and so it might not be done until tomorrow if that is ok? | 17:28.12 |
| or late tonight (early morning for you) | 17:28.27 |
Robin_Watts | That's fine. I'm happy to sit on this for now. The customer is happy, which is the main thing. | 17:28.29 |
mvrhel_laptop | good deal | 17:28.34 |
Robin_Watts | Thanks. | 17:28.38 |
mvrhel_laptop | new modem is not too shabby. 84Mbps down load speed and 12 upload | 17:31.12 |
ray_laptop | oh, great. cust 532 spotted ANOTHER anomaly on the AppleStart (it's been there all along, but they just noticed it) | 17:36.52 |
| at least gs gets it right. I just have to find out how there code is getting it wrong :-( | 17:37.46 |
| holy cow! It took my laptop (2.4 GHz i7) over a minute to "print" J11_acrobat.pdf from Acrobat out through the HP Color LaserJet 9500 PCL6 driver and the file is 72Mb !!! | 17:54.51 |
mvrhel_laptop | whoa | 17:56.01 |
ray_laptop | oops. misread it. not 72Mb, it's 720Mb | 17:57.21 |
chrisl | ray_laptop: you mentioned a FAPI error yesterday - did you need me to look into it? | 18:19.18 |
haggl | hey, anyone there? | 18:22.39 |
mvrhel_laptop | J11 does have transparency. | 18:22.42 |
haggl | Errm I mean is a mupdf developer currently reading this? | 18:23.43 |
ray_laptop | there are at least 4 here | 18:24.42 |
chrisl | henrys: around? | 18:24.52 |
henrys | yes | 18:25.05 |
ray_laptop | chrisl: not urgent, but I'll post a bug | 18:25.07 |
chrisl | henrys: if kens has a fix for this GSView issue, do I throw together a 9.09 RC tomorrow with the fix? | 18:25.45 |
| ray_laptop: okay, thanks | 18:26.01 |
ray_laptop | I was trying git bisect to find where it broke, and there were too many versions that segfaulted on it | 18:26.11 |
| ooh what else can we sneak in :-) | 18:26.43 |
chrisl | ray_laptop: if it worked in 9.06 but seg faults now, it was probably the move of FAPI into the graphics lib | 18:26.51 |
ray_laptop | chrisl: but seriously the fixes for the transparency (mine and mvrhel's) would be nice since they fix some issues customers have reported | 18:27.53 |
mvrhel | I agree | 18:28.26 |
| there were quite a few progressions in the test files with that one | 18:28.51 |
henrys | chrisl: I don't know the extant of the fix. maybe we should add ray_laptop changes and restart testing? | 18:28.52 |
ray_laptop | and Robin_Watts' fix for the image squishing, but that customer is usually happy with patched versions | 18:29.17 |
chrisl | If we include fixes other than Ken's then we'll need to retest - that's another week, at least | 18:29.35 |
Robin_Watts | haggl: yes. | 18:29.45 |
chrisl | Well, actually more than a week, since we'll have to wait Marcos's return | 18:30.21 |
Robin_Watts | We *could* include my fix for the squishing on the grounds that none of Marcosw's tests show it up. | 18:30.24 |
ray_laptop | chrisl: b89761f Fix for problem with double application of alpha when composing isolated groups. and | 18:30.24 |
| e9f0f0e Fix bug 694455. Incorrect CTM when rendering SMasks. | 18:30.26 |
| The two fixes I mentioned cause quite a few progressions | 18:31.11 |
chrisl | Robin_Watts: we've said that kind of thing before, and been bitten by it | 18:31.30 |
Robin_Watts | chrisl: Indeed. | 18:31.58 |
ray_laptop | chrisl: but I don't feel strongly if you just want to keep it to the minimum | 18:32.20 |
chrisl | The trouble is, the longer we leave it, the more people are going to stumble the problem with 9.08 | 18:32.32 |
Robin_Watts | For this fix, there are cases that are definitely broken in the original code. And all that we risk is that they are differently broken in the fixed version :) | 18:32.33 |
| but I completely understand that you might want to just do the minimum. | 18:32.51 |
mvrhel | I can tell this is Chris' favorite time of the year | 18:32.53 |
haggl_cooking | Robin_Watts: Ah hello again! :-) I've got some more patches for mupdf, including an auto-zoom function, and some improvements of the presentation mode. Should I open separate advancement bugs for all of them? | 18:33.13 |
Robin_Watts | haggl_cooking: please. | 18:33.33 |
chrisl | mvrhel: do I get more grumpy? | 18:33.33 |
ray_laptop | bbiaw. Pick up son from tennis... | 18:33.41 |
mvrhel | you? never | 18:33.42 |
chrisl | Hmph! | 18:33.48 |
henrys | not the end of the world if we miss august | 18:33.58 |
chrisl | henrys: no but 9.08 is already out there, that's my worry | 18:34.19 |
| I guess I could try to pull 9.08 and put a note on the website? | 18:34.52 |
henrys | chrisl:I think that's what we want to do unfortunately. | 18:35.33 |
chrisl | henrys: Okay, I'm going to do that now - damage limitation..... | 18:35.58 |
henrys | okay bbiab | 18:36.40 |
haggl_cooking | Robin_Watts: Ok. But there's likely more to come. I love simple, small applications and I'm very unhappy with just about every PDF reader out there. MuPDF is just great, but imho it lacks some essential features -- which I'm planning to implement if you don't mind. | 18:38.22 |
Robin_Watts | haggl_cooking: ok, thanks. | 18:38.46 |
| We are planning to write a better viewer app. | 18:39.01 |
| but we keep getting distracted. | 18:39.12 |
| We have a decent app on Android and one coming along nicely for Windows 8/Phone/Surface. | 18:39.46 |
| but the linux and win32 apps are showing their age. | 18:40.00 |
| oh, he's gone. | 18:40.04 |
haggl_cooking | re | 18:42.58 |
| I accidentially hit the 'WLAN' button. Very annoying. | 18:43.14 |
| So you're planning to rewrite the X11 app from scratch? | 18:43.40 |
| And windows.. Doesn't SumatraPDF use the mupdf library? | 18:44.26 |
mvrhel_laptop | haggl_cooking: we have written a new viewer for windows 8 and working on one for the windows phone. I am going to be doing a new windows desktop viewer that will use mupdf for pdf and gs for PS | 18:48.09 |
chrisl | Okay, 9.08 is history. | 18:51.28 |
haggl_cooking | mvrhel_laptop: Ah ok cool. But what about GNU? | 18:53.06 |
mvrhel_laptop | haggl_cooking: I am doing the windows work. I am not sure who is doing linux side of things | 18:54.20 |
Robin_Watts | haggl_cooking: tor7 was doing a GTK based one. | 18:54.35 |
haggl_cooking | Robin_Watts: Hmm, I kind of like the fact that it does NOT use GTK or Qt or whatever. | 19:01.40 |
| ..but I realize that most people would probably diagree. I'm a nerd - what can I say? ;-) | 19:03.06 |
chrisl | haggl_cooking: you're not alone, but a lot of people want features in the "viewer" that are really nasty to implement with using a toolkit | 19:04.41 |
| Robin_Watts: did you see that your commit failed on the cluster? | 19:05.56 |
haggl_cooking | chrisl: Yep. A nice printing-dialog perhaps? | 19:07.20 |
chrisl | haggl_cooking: not sure, printer is a whole other issue (takes much more than just a dialog!). But easy searching, annotation adding and stuff like that..... | 19:08.37 |
| haggl_cooking: and frankly there is an element of a lot of people just want something that "looks a bit nicer"....... | 19:10.19 |
Robin_Watts | chrisl: ass. | 19:11.09 |
| chrisl: no space left on device ? | 19:11.46 |
chrisl | Robin_Watts: I don't think it's your commit, i7 got a "no space left device" error for some reason..... | 19:11.46 |
Robin_Watts | yeah. I got to go, sorry! | 19:11.58 |
chrisl | But my clusteroush seems to have worked | 19:12.02 |
haggl_cooking | chrisl: "Looks" depend on the user's taste. To me things look nice when they have as few fancy graphics, toolbars and other stuff that just uses up screen space as possible. :-D But you are right of course. | 19:14.02 |
chrisl | haggl_cooking: yeh, I prefer fairly minimal, but a lot of people like the eye candy these days | 19:15.14 |
haggl_cooking | So as I understand it, the current X11 version will sooner or later be abandoned and replaced by a GTK+ version? | 19:15.24 |
chrisl | At some point, yes, that's the plan | 19:15.46 |
| GTK+ but *NOT* GNOME! | 19:16.04 |
| haggl_cooking: and as tor7 likes things even more minimalist than I do, it's not likely to be over-burdened with pointless bells and whistles | 19:17.24 |
haggl_cooking | Yeah.. whatever happened to GNOME is a whole different story.. | 19:17.30 |
| chrisl: That sounds good. | 19:18.03 |
| chrisl: But in that case I won't invest too much time and energy in improving the current version. | 19:19.54 |
chrisl | haggl_cooking: probably wise. | 19:20.23 |
haggl_cooking | chrisl: I have my moments. ;-) | 19:20.56 |
chrisl | :-) | 19:21.21 |
haggl_cooking | Oh, there's a mystery that maybe someone here can solve: | 19:22.21 |
| I had this PDF file - pretty large one: about 1500 pages or so - from which I wanted to print a few pages. | 19:23.43 |
| I tried to do that in evince: gs was thinking and thinking and thinking and finally obviously gave up, because the printer printed a blank page with some hieroglyphs. | 19:25.04 |
| After that I tried to print the same pages in the same order from the same PDF: After a few seconds the printer delivered it like a charm. | 19:26.00 |
| oO | 19:26.06 |
chrisl | From where did you print in the second attempt? | 19:26.35 |
haggl_cooking | Oh, forgot: xpdf | 19:26.53 |
| I think they are both using the poppler library. | 19:27.11 |
chrisl | Nope, poppler is a fork of xpdf | 19:27.28 |
| So it may be a bug in evince, or poppler, or it may be down to exactly how the different apps drive cups (and how that, in turn, drives Ghostscript). It's almost impossible to guess | 19:28.35 |
haggl_cooking | That's what I thought. | 19:29.03 |
| I had similar problems with several PDF files. Always the same: Evince sucked, xpdf rocked. | 19:30.03 |
chrisl | What I would previously have suggested would be to talk to the evince devs, and hopefully they could help figure out if it's an evince problem. *OR* tell you the information you need to talk to the CUPS people. Then the CUPS devs could assess if it's a CUPS problem, or Ghostscript problem, and tell you what to tell us so we could reproduce it for ourselves. But that doesn't seem to work too well in practice :-( | 19:31.16 |
haggl_cooking | ^^ | 19:32.08 |
| That's one of the reasons why I arrived at mupdf. | 19:32.22 |
chrisl | Trouble is, people often get referred to us because "it's a gs problem", but usually have no idea (and no way get an idea) what to tell us so we can investigate. | 19:34.59 |
| "I just print just LibreOffice" isn't terribly helpful, from our point of view! | 19:36.24 |
mvrhel_laptop | all sorts of overclock options on the raspberry pi | 19:39.10 |
chrisl | mvrhel_laptop: is the overclocking control from software, or firmware? | 19:41.30 |
tkamppeter | chrisl, why are you bumping the GS version from 9.09 to 9.10 already? | 19:42.54 |
mvrhel_laptop | when you do raspi-config it comes up with a little menu that I imagine is coming from firmware | 19:43.17 |
chrisl | tkamppeter: there's a bug in 9.08 that breaks GSView | 19:43.21 |
ray_laptop | tkamppeter: we're going to have to release a 9.09, so the PRE-RELEASE bumps to 9.10 | 19:43.33 |
tkamppeter | chrisl, so I will have to update the Ubuntu package again in the next days? | 19:44.11 |
chrisl | mvrhel_laptop: shame. I was thinking you could write a little shell script which sets the clock speed high, runs GS, then sets the clock speed back - make us look good ;-) | 19:44.14 |
| tkamppeter: within the next two weeks - we're probably going to do another release QA | 19:44.42 |
tkamppeter | chrisl, will it get ready for Ubuntu FF ~24 of August? | 19:49.26 |
chrisl | tkamppeter: if I knew that..... I really don't know, tbh | 19:50.18 |
haggl_cooking | chrisl: Yeah, I would imagine ghostscript is not exactly a trivial piece of software.. ;-) | 19:52.08 |
chrisl | haggl_cooking: it's freakin' bucket load of headaches, just now! :-( | 19:52.39 |
| tkamppeter: if you make sure henrys knows your deadline, that might influence how we handle the 9.09 release | 19:53.19 |
tkamppeter | chrisl, are there a lot of changes between 9.08 and 9.09? Or is it only a little patch to get GSView working? Is it important for Linux/Ubuntu? | 19:53.24 |
| henrys, hi | 19:53.50 |
chrisl | tkamppeter: My preference was for just the one patch, others felt it would be beneficial to have more changes. My feeling is that the GSView patch (in its current form) would not require a complete release QA | 19:54.39 |
| tkamppeter: for the FF, would it sufficient to have a release candidate, or does it have to be full release? | 19:55.27 |
tkamppeter | I think an RC would be enough, RC->Final consists usually only of bug fixes. | 19:56.32 |
chrisl | tkamppeter: okay, I'm pretty confident we'll have a release candidate available during next week - whichever approach we choose | 19:57.25 |
henrys | tkamppeter: sorry I was away , but it looks resolved. | 19:58.13 |
tor7 | henrys: I pushed out the mupdf 1.3 release today | 20:05.34 |
chrisl | mvrhel_laptop: on your pi, do you have a gui running? | 20:14.23 |
ray_laptop | mvrhel: I don't think PCL5C (or PXL) are going to help us. I suspect the driver is using RasterOps because some pages are VERY SLOW. On my laptop, J12.pcl takes 145 seconds. page 11 takes 57 seconds page 20 takes 20 seconds | 20:14.34 |
kens | chrisl how much longer are you lurking online tonight ? | 20:14.58 |
chrisl | kens: until I get bored..... | 20:15.10 |
kens | OK, I'm hopinh to have this squared away shortly, one of my tests didn't run for some reason | 20:15.27 |
| and of course it was the important one | 20:15.37 |
chrisl | i7 is having issues, I disabled it, for now | 20:15.51 |
kens | Probably best | 20:16.06 |
| OK GSView 5 is OK with 64-bits, now to test the 32-bit one | 20:16.42 |
chrisl | kens: You may have seen: there's a bit of debate about whether to pull in more fixes than just yours.... | 20:17.03 |
kens | chrisl if it w3ould tke me a long time, then fine, if I cna get it tonight I'd say no | 20:17.20 |
| I'm still wading through the logs in odd moments, its been a busy night | 20:18.06 |
| GSView 5 32-bit is OK | 20:21.06 |
| global setpagdevice dictioanry is OK both with and without -dSAFER and startup is OK both ways. Just need the cluster test now | 20:23.24 |
| One more test..... | 20:41.18 |
| My source had fallen behind so I've pulled and merged and will test agaiin for certainty | 20:41.41 |
chrisl | Well, although the suspense of kens's clusterpush is almost killing me, I think I'm going to call it a night...... | 20:48.40 |
kens | I would not attempt to do a release tonight chris anywa | 20:49.10 |
| Is there a Linux equivalent of GSView ? | 20:49.20 |
chrisl_away | That was *far* from my mind! | 20:49.25 |
kens | :-) | 20:49.29 |
chrisl_away | kens: there was a GS GUI on linux, but it is long dead. IIRC, there was a GSView port, but I think it's dead, too | 20:50.14 |
mvrhel_laptop | chrisl: no gui running | 20:50.27 |
kens | Fair enough, was just wondering if there's anything else worth smoke testing | 20:50.39 |
chrisl_away | mvrhel_laptop: okay, that's how mine is setup (for now) | 20:50.51 |
mvrhel_laptop | cool | 20:51.02 |
chrisl_away | kens: having said that, gv is still available on the Ubuntu repos, so..... | 20:51.37 |
kens | Ummm | 20:52.16 |
| You have a Ubuntu VM ? | 20:52.28 |
chrisl_away | kens: ping me in the morning, and I will try it out then | 20:52.33 |
kens | OK thanks | 20:52.39 |
mvrhel_laptop | rayjj: ok about pcl. if your laptop is that slow, we are best not to even fool with it. | 20:52.54 |
chrisl_away | I'll need to fathom how to tell it what Ghostscript exe to use | 20:53.00 |
kens | Yes, that could be a challenge | 20:53.12 |
chrisl_away | I know it can be done, just can't quite remember how | 20:53.31 |
kens | Job for the morning | 20:54.20 |
| connection timed otu ? :-O | 20:54.33 |
kens | is jinxed | 20:55.04 |
chrisl_away | Looks like casper has had a network hiccup | 20:55.16 |
kens | I'll restart :-( | 20:55.26 |
chrisl_away | Or possibly another job for the morning | 20:55.39 |
chrisl_away | really is going away - 'night folks! | 20:57.21 |
kens | LOoks like cluster hhas died, so I'm off to bed | 21:02.31 |
ray_laptop | Robin_Watts: do you have an iPhone | 21:34.03 |
| scott-san wants help with his | 21:34.14 |
| who else drank the Apple koolaid and has iPhone ? | 21:41.33 |
henrys | if all the customers went on vacation when marcosw went â¦. | 21:42.39 |
| ray_laptop:genius bar in Denton? | 21:44.03 |
ray_laptop | henrys: genius juxtaposed with Denton doesn't seem likely | 21:45.13 |
henrys | he just called me so it can't be that broken ;-) | 21:45.36 |
| if have an iphone | 21:46.08 |
ray_laptop | henrys: no, he has a problem with getting his pictures in iPhoto after he connects it. | 21:46.18 |
henrys | Robin_Watts has a droid if I recall | 21:46.20 |
ray_laptop | henrys: probably. I think Marcos may have an iPhone, but he's on vacation | 21:46.41 |
henrys | ray_laptop:if you synchronize in iTunes it will import automatically when new pictures are seen on the device - assuming he has connect the device to the computer with a usb cable. | 21:48.41 |
ray_laptop | henrys: he said he "sync'ed" | 21:49.06 |
| henrys: from working with my wife's iPod touch, that's what I thought | 21:49.36 |
| oh, well... | 21:50.03 |
| not surprising that gs is best at PostScript. No transparency, no funky RasterOps. That's what mvrhel and I see as highest performance | 21:51.00 |
henrys | ray_laptop:sabrina uses the iPhone/iphoto setup all the time doing art stuff ⦠| 21:52.25 |
ray_laptop | PDF 1.3 _might_ be similar | 21:52.32 |
| henrys: I bet | 21:52.39 |
henrys | ray_laptop:now the customer comes back with too much ram, same problem, ugh | 21:53.01 |
Robin_Watts | ray_laptop: I have an android phone. I have an ipod touch which is my ios device. | 22:00.23 |
henrys | ray_laptop:scott doesn't have a mac does he? maybe this is for Ellen? | 22:05.34 |
selim | hello | 23:07.12 |
| after which I found the search parameters: -dDoNumCopies but it seems not to work | 23:08.52 |
| you think what ? | 23:18.34 |
| plinnell can you help me | 23:21.26 |
| Please I really need help | 23:41.02 |
| Forward 1 day (to 2013/08/16)>>> | |