| | <<<Back 1 day (to 2014/06/11) | 2014/06/12 |
| kens | aha good morning chrisl | 09:09.11 |
| chrisl | hi kens | 09:09.28 |
| kens | can you spare me a few minutes to run a test ? | 09:09.42 |
| chrisl | Sure | 09:09.49 |
| kens | bug 695309 | 09:09.59 |
| chrisl | Just catching up on e-mails..... | 09:10.02 |
| kens | I can't get it to give me a problem, henrys valgrind does show problems, but all in fclose() | 09:10.25 |
| | I'm just creating a real 64-bit Lnux VM but its taking a while | 09:10.41 |
| chrisl | Hmm, I wonder what "current" version really means.... | 09:11.09 |
| kens | Hmm where's the 'current' ? | 09:11.38 |
| chrisl | Oh, I mean "master" | 09:11.51 |
| kens | Well, henrys created the bug.... | 09:12.05 |
| | I tried the 9.10 release on Windows, and the azbsolute latest code on 32-bit Linus and both were OK for me | 09:12.30 |
| chrisl | I kind of feel that memory corruption reports need to include a SHA | 09:12.58 |
| kens | Hmm, I guess.... | 09:13.16 |
| chrisl | It works for me - let me try valgrind.... | 09:13.47 |
| kens | But given the customer report is 9.10 and I assume Henry was using soemthign recent, it looks lilke it ought to be easy top reproduce, and I can't :-( | 09:13.48 |
| chrisl | And I get no valgrind errors at all | 09:14.24 |
| kens | Then I'm stumped.... | 09:14.32 |
| chrisl | I'll try 9.10 in a moment - I'm doing a debug build of master and will run that with valgrind. That sometimes picks up issues it misses in a release build | 09:15.19 |
| kens | Umm, OK don't waste too much time on this though. I suspect that its one or more of the problems with txtwrite taht have been fixed. I'm not absolutely convinced Henry reproduced a problem. | 09:16.01 |
| | There certainly have been real bugs in txtwrite previously | 09:16.23 |
| chrisl | Still no valgrind errors with a debug master, so building 9.10 now..... | 09:17.19 |
| kens | I'm willing to believe 9.10 shows a bug :-) | 09:17.50 |
| chrisl | Oh, yes "kaboom!" | 09:18.38 |
| | *** Error in `./gs': corrupted double-linked list: 0x000000000229f0d0 *** | 09:18.48 |
| kens | OK well that I can believe | 09:18.59 |
| | I'm inclined to close the report as 'fixed' and tell tehm to use current code, since they seem to be experimenting with the device. | 09:19.31 |
| chrisl | I get a bunch of invalid read/write errors from valgrind, then a bunch of "invalid frees" - I have a feeling this might be one of the cases where you were allocating a single byte buffer, and writing a multibyte string to it, or something like that | 09:21.15 |
| kens | COuld easil;y be | 09:21.29 |
| | I'm not sure I want to try and track down exactly which fix it was. | 09:21.44 |
| chrisl | I can try to bisect it if you like | 09:21.56 |
| kens | TO be honest, they could just take the current devioce code and use it on an earlier instgance I htink | 09:22.06 |
| | I don't think its very reliant on the version of GS | 09:22.21 |
| chrisl | The spec_op stuff wouldn't work | 09:22.31 |
| kens | Umm, that's true | 09:22.47 |
| | The trouble is, if we figure out which fix was this one, that will just lead them to find the next one, and the next one.... | 09:23.20 |
| | I'd rather they used current code | 09:23.30 |
| chrisl | Yes, I agree - better they find new issues ;-) | 09:24.14 |
| kens | ANyway,thanks for the confirmation, I'll update the bug report. | 09:24.47 |
| chrisl | I am, however, bemused by henrys's valgrind report as it says he's using 9.15, and get no valgrind errors *at all* | 09:25.35 |
| kens | That is indeed peculiar | 09:25.50 |
| | I have seen valgrind give those kinds of errors, but I've ignored them because the application was working OK | 09:26.15 |
| chrisl | Indeed. I suspect those are spurious | 09:27.08 |
| tor8 | http://mupdf.com/downloads/archive/mupdf-1.5-windows.zip I would appreciate if someone could sanity checking the release files before I announce it | 10:16.29 |
| kens | I'll get them now | 10:16.42 |
| | all three executables seem to work | 10:19.32 |
| tor8 | kens: thanks! | 10:19.39 |
| kens | NP | 10:19.46 |
| tor8 | chrisl: the git is tagged, tarballs and zipfiles uploaded and mupdf.com updated ... anything you need to do as well? | 10:21.37 |
| chrisl | tor8: I'll do the commercial release later today. I'll update ghostscript.com now | 10:23.01 |
| | tor8: ghostscript.com is done, thanks..... | 10:24.42 |
| tor8 | chrisl: thanks. | 10:25.16 |
| | Robin_Watts: do you or paul want the honor of making a new android release? | 10:25.32 |
| Robin_Watts | tor8: Urm... I can do it. | 10:37.54 |
| | tor8: What's the difference between a .ttc and a .ttf? | 11:26.58 |
| | We seem to have DroidSansFallback{,Full}.ttc and the android build is expecting .ttf | 11:27.22 |
| pedro_pc | Robin_Watts> truetype collections (multiple fonts) | 11:31.38 |
| Robin_Watts | tor8: Ah. in pdf-fontfile.c the HAVE_INCBIN sections are wrong? | 11:31.40 |
| | pedro_pc: yeah. | 11:31.51 |
| tor8 | Robin_Watts: hm, does android have different fontfile stuff? | 11:32.48 |
| Robin_Watts | I think maybe I just need to regenerate the generated dir. | 11:32.48 |
| tor8 | I was going to suggest regenerating the generated dir | 11:33.02 |
| Robin_Watts | hehe. I went to the twiki thinking "I should write up notes on how to do the android release" and found... http://twiki.ghostscript.com/do/view/MuPDF/AndroidReleases | 11:33.51 |
| | tor8: Hmm. It's looking for droidsansmono.ttc and I only have a .ttf | 11:34.35 |
| tor8 | Robin_Watts: I'd double check your git checkout then... | 11:37.05 |
| | oh, wait. droidsansmono? | 11:37.31 |
| | that one should still be a ttf | 11:37.35 |
| Robin_Watts | hmm. Second regenerate seems to have changed that. odd. | 11:37.45 |
| tor8 | only the fallback ones should be ttc. | 11:37.48 |
| | I might've botched the android makefile edits? | 11:37.55 |
| Robin_Watts | android makefiles don't do generation. | 11:38.10 |
| | seems to be working now. odd. | 11:38.24 |
| tor8 | you doing the generate with win32 project batch file? | 11:38.53 |
| Robin_Watts | yes. | 11:39.00 |
| | well, the VS solution that calls that. | 11:39.06 |
| tor8 | hm, no, that one also lists DroidSansMono.ttf | 11:39.19 |
| Robin_Watts | tor8: No idea what happened there. All seems to be happy now. | 11:39.35 |
| deningrad | good afternoon everybody | 11:42.18 |
| | could I ask an information about MuPdf? | 11:43.12 |
| Robin_Watts | deningrad: Afternoon. Sure. Don't ask to ask, just ask :) | 11:43.55 |
| deningrad | Robin_Watts: thanks :) I use linux (xubuntu) and I cannot find a way to upgrade my current version of mupdf (1.3.) to the latests (1.4 or 1.5) ..thanks | 11:45.56 |
| tor8 | deningrad: that's really up to the linux distro maintainers, unless you're willing to "side-load" install mupdf outside of their package management system | 11:46.48 |
| deningrad | tor8: thanks | 11:47.19 |
| tor8 | it's quite safe and simple to do, just download the latest release tarball, and run "make" then "sudo make install" to install if the first step went okay | 11:47.35 |
| | that will install mupdf in /usr/local/ | 11:47.58 |
| Robin_Watts | deningrad: Of course, you could always mail the ubuntu maintainers and ask why they are so far behind... | 12:02.09 |
| | OK, so new versions of MuPDF android version. | 13:25.00 |
| kens | can't test that, sorry | 13:25.15 |
| Robin_Watts | http://ghostscript.com/~robin/MuPDF-50.apk <- Any arm device | 13:25.18 |
| | http://ghostscript.com/~robin/MuPDF-51.apk <- Any armv7a device | 13:25.27 |
| | http://ghostscript.com/~robin/MuPDF-52.apk <- Any x86 device | 13:25.39 |
| | http://ghostscript.com/~robin/MuPDF-53.apk <- Any mips device | 13:25.47 |
| henrys | chrisl, kens I see that bug in head - 9.15 | 13:33.03 |
| kens | chrisl which version of MS compiler are you using to make binaries on Windows ? | 13:33.16 |
| | henrys neither cris nor I can reproduce it | 13:33.27 |
| chrisl | kens: vs200 | 13:33.51 |
| | vs2005 | 13:33.55 |
| | henrys: you can see the "bug" or you can see valgrind errors? | 13:34.15 |
| henrys | *** Error in `./gs': corrupted double-linked list: 0x000000000264a9a0 *** then infinite loop - I assume itâll crash if I waited | 13:35.28 |
| chrisl | Hmm, I can't get that to happen on the current code, just on 9.10 | 13:35.59 |
| kens | thanks for the info chrisl | 13:36.07 |
| Robin_Watts | henrys is clearly not running it on windows though... | 13:36.13 |
| henrys | chrisl: I works for me on mac os | 13:36.27 |
| kens | well no, nor is the reporter, not chris, nor I | 13:36.28 |
| Robin_Watts | henrys: Where are you running it? linux or macos? and 32 ot 64bit ? | 13:37.01 |
| henrys | henrysx6 64 linux | 13:37.30 |
| | chrisl: do you see a valgrind problem? | 13:37.49 |
| kens | chris said valgrind was clean for him | 13:38.12 |
| chrisl | On the current code, valgrind is clean for me | 13:38.21 |
| | This is on x64 linux | 13:38.35 |
| henrys | chrisl: doing a clean build | 13:38.58 |
| kens | mine was x32 Linus (as well as WIndows) I only just got my 64-bit VM set up and haven't built GS there yet | 13:39.10 |
| chrisl | Robin_Watts: a very quick spin with MuPDF-51.apk seems okay | 13:39.24 |
| Robin_Watts | chrisl: Thanks. Much appreciated. | 13:39.32 |
| henrys | chrisl, kens yeah right you are clean build and it works | 13:42.40 |
| kens | wonders what was liongering.... | 13:43.09 |
| chrisl | henrys: weird - I wonder what dependencies are borked up..... :-( | 13:43.15 |
| henrys | but I had 9.15 code is this a very recent fix? | 13:43.15 |
| kens | 1111111111111THe only 'recent' fix is the BOM and it shouldn't bethat | 13:43.37 |
| chrisl | It could be a recent fix in glibc - the errors were in the glibc code, after all! | 13:44.04 |
| henrys | Iâll bisect it bothers me | 13:44.04 |
| kens | I pointed at 2 likely fixes in the mail I sent to support | 13:44.35 |
| henrys | pedro_pc:ugh now Good wants us to upgrade for the heartbleed fix | 13:46.56 |
| Robin_Watts | We don't run a server. | 13:48.17 |
| | hence we can't be doing heartbeat responses. | 13:48.37 |
| | hence we can't be affected. | 13:48.42 |
| henrys | we are using an old api | 13:49.08 |
| Robin_Watts | so? | 13:49.21 |
| henrys | that apparently bleeds | 13:49.31 |
| Robin_Watts | Then they should rebuild the server for that old API to use a new OpenSSL. | 13:49.56 |
| henrys | Robin_Watts: did you wan the request forwarded to you as well? | 13:50.04 |
| Robin_Watts | No change is required on our part. | 13:50.10 |
| | henrys: If you want. It seems to be they are saying "we are too incompetent to be able to fix our server, so you need to do some work." | 13:50.38 |
| kens | wonders if Robin has considered a career in international diplomacy :-) | 13:51.46 |
| Robin_Watts | Surely our first response should be to say "Can't you just fix your server? As a company trading on your security credentials, surely this is not beyond your abilities?" | 13:52.13 |
| henrys | Robin_Watts: they warned of this on the phone, that the legacy system as we are using would leave us weill several problems | 13:52.20 |
| | with several problems | 13:53.03 |
| Robin_Watts | henrys: Sure, but this one deserves a push back, surely? | 13:53.11 |
| | whatever, I'll shut up. | 13:53.25 |
| henrys | Robin_Watts: I wouldnât want the clowns âfixingâ the âworkingâ server that all our customers are using. | 13:54.29 |
| chrisl | Why are they still running a server with the heartbleed bug?? | 13:56.02 |
| henrys | paulgardiner_lap: see the logs and email | 13:58.33 |
| | it seems they have major server releases and they donât fix the legacy ones but encourage folks to update to the major release. | 13:59.57 |
| Robin_Watts | because that's what responsible security based operations do. | 14:00.39 |
| Robin_Watts | is going to get dementia early, I can just feel it. | 14:01.54 |
| | http://www.telegraph.co.uk/science/science-news/10861276/Cynics-three-times-more-likely-to-suffer-from-dementia.html | 14:01.56 |
| chrisl | I reckon they've got some ulterior motive for that...... | 14:03.01 |
| henrys | ha that might be an occupational hazard of software development - writing code is a leading cause of cynicism ;-) | 14:04.08 |
| chrisl | *reading* code is a leading cause of cynicism...... | 14:04.32 |
| Robin_Watts | I reckon that if you're a credulous fool, it's harder to spot when alzheimers kicks in :) | 14:05.06 |
| pedro_pc | henrys> i've had a look and it doesn't look like too much hassle to upgrade. | 14:44.46 |
| | we do need to get them to move on Veracode though - we're nominally in a position to go with iOS and I think the android app will be at some point next week | 14:45.47 |
| | henrys> do you knw if they've been in contact with Miles about payment for the iOS/android versions yet? | 14:46.19 |
| Robin_Watts | miles was sent forms to fill in about payments, and has returned them, yes. | 14:47.14 |
| henrys | pedro_pc: Miles noticed that picsel apparently was billing them so his plan is to change stance quite a bit on paying Good | 14:47.59 |
| | specifically picsel billed Good 30K for the original integration with the server | 14:49.40 |
| pedro_pc | nods - they are certainly dragging their heels as far as getting this up and running goes. | 14:51.40 |
| henrys | miles just discovered this tuesday going through paperwork | 14:51.58 |
| pedro_pc | its not clear what benefit Artifex really get being a 'partner' rather than just building apps and releasing them as independent developers | 14:52.24 |
| | (especially now that there are a couple of other office viewers on Good, as opposed to the initial situation where Good paid picsel to put their app on good) | 14:53.50 |
| henrys | pedro_pc: miles associates value with being on their âprice sheetâ in my discussions with him, but I havenât seen hard numbers yet. | 14:53.51 |
| pedro_pc | fair enough - I shoudln't be worrying about that really - just curious, and keen that Artifex don't get stitched up here | 14:54.43 |
| henrys | brad said the customers donât like the other office products of course he could just be marketing, who knows. | 14:55.21 |
| | kens: so that was never reproducible on windows? even 9.10? | 14:58.02 |
| kens | henrys, no, not by me anyway | 14:58.14 |
| | Its the reason I was putting a 64-bit Linux VM together this morning | 14:58.32 |
| henrys | kens: he just wrote it exhibits in 14 | 14:58.34 |
| kens | Not for me, on 32-bit Linux | 14:58.49 |
| | Or WIndows | 14:58.53 |
| | I did reply and suggest he does a full clean and rebuild given your experience | 14:59.10 |
| henrys | kens: oh yes good thought | 14:59.42 |
| kens | I use Linux so infrequently that I pretty much always end up doing a full rebuild anyway | 15:00.29 |
| henrys | pedro_pc: I will shoot the request to miles and see if we are going to get billed more for any changes. I do know miles wants to keep the focus on layout bugs, so heâs not going to like this. That said it seems like something we should do. | 15:07.15 |
| pedro_pc | henrys: it basically just comes down to the fact that we can't upload the android app to Good until it has been through Veracode. I've no problem if we want to put it on the back-burner and focus on layout bugs for the moment though | 15:11.36 |
| henrys | pedro_pc: does the upgrade require another vericode run? | 15:13.12 |
| Robin_Watts | henrys: Might be worth you looking at skype. Joseph has an interesting suggestion... | 15:13.48 |
| pedro_pc | henrys: possibly not for iOS - I think they vaguely said that we 'may be able to do upgrade with minimal testing' - a bit non-commital | 15:14.21 |
| el_mendi | Robin_Watts: I did the commits you told me yesterday and I was writing my function to save the image, but I have some doubts | 15:14.39 |
| pedro_pc | for android it is a completely new app, so would need to go through Veracode | 15:14.43 |
| Robin_Watts | el_mendi: Go on... | 15:14.55 |
| el_mendi | In pdf_clean_page_contens, the argument "void *proc_arg" must contain my fz_image and the position where I want the image, does'n it? | 15:15.57 |
| Robin_Watts | The void *proc_arg has to contain all the information you need, yes. | 15:16.24 |
| henrys | skype is scrolling eternally , ah now itâs stopped | 15:16.35 |
| jogux_mac | chrisl / kens: fwiw, I had issues with the debian/ubuntu packaged valgrind giving false errors (with SO2); upgrading to the latest official upstream release fixed them. | 15:16.43 |
| Robin_Watts | Normally that kind of thing is a pointer to a structure that contains lots of information. | 15:16.46 |
| el_mendi | Ok | 15:17.15 |
| Robin_Watts | i.e. you define a struct that contains the fz_image *,and the positions, and any other data, and then you pass the address of that struct as the void *. | 15:17.29 |
| chrisl | jogux_mac: the weird thing here was they were actually in glibc, not in the gs code...... | 15:17.41 |
| el_mendi | And how I must define the function pdf_page_contents_process_fn()? | 15:17.56 |
| chrisl | jogux_mac: we've found valgrind has issues with unions and bit fields - both things the gs garbage collector uses quite heavily | 15:18.27 |
| el_mendi | I just creat a void function? | 15:18.31 |
| Robin_Watts | el_mendi: The type of the function is given in the header. | 15:18.45 |
| jogux_mac | chrisl: ah yes - the problem I had in SO2 was with bitfields. that one went away in the latest upstream valgrind. | 15:18.59 |
| Robin_Watts | typedef void (pdf_page_contents_process_fn)(void *arg, fz_buffer *buffer, pdf_obj *res); | 15:19.07 |
| | so: static void my_process_fn(void *arg, fz_buffer *buffer, pdf_obj *res) { ..... } | 15:19.30 |
| el_mendi | So I create a pdf_page_contents_process_fn type function? | 15:19.33 |
| | ook | 15:19.46 |
| kens2 | chrisl what's our current target for 9.15 release ? | 15:20.21 |
| chrisl | September | 15:20.42 |
| kens2 | ok thanks | 15:20.47 |
| jogux_mac | chrisl: oh, and, yeah, I've had quite a few issues in the glibc code too. usually in threading stuff though. I updated the supressions file we have in the SOT git so that valgrind doesn't keep telling us about them. :-S | 15:23.34 |
| chrisl | jogux_mac: this was in the glibc file handling code - which is a another place that uses bitfields and unions quite a bit! | 15:24.33 |
| jogux_mac | urgh :( | 15:25.14 |
| chrisl | But as they all disappear with the latest gs code, and Ubuntu updates, I'm burying my head in the sand, and hoping it's all nonsense | 15:26.03 |
| kens2 | customer says 'fixed with latest code' | 15:26.31 |
| | So I suspect it was one of the txtwrite bug fixes, and the valgrind warnings were surious | 15:27.02 |
| jogux_mac | sounds like a plan to me :-) | 15:27.46 |
| chrisl | :-) | 15:27.55 |
| | tor8: commercial 1.5 release now done, too. | 15:28.27 |
| jogux_mac | robin: my understanding is that heartbleed can also cause clients to leak private memory to servers. possibly that's harder to exploit, but there is a definate bug. | 15:34.10 |
| Robin_Watts | jogux_mac: Only if they make a persistent connection to the server right? Otherwise heartbeat wouldn't be involved. | 15:35.08 |
| | and presumably that would need to be a man in the middle attack? | 15:35.17 |
| jogux_mac | or a server side compromise. | 15:37.28 |
| | it wouldn't surprised me if the server can send a heartbeat request during or right after negotation (but I'm now guessing, I really don't know the details) | 15:37.48 |
| henrys | kens2: I donât know if all our customers will understand your appended humor on the email messages, sometimes it can confuse non western cultures at least. | 16:01.28 |
| kens2 | Possibly correct. I can suppress it, its not new though.... | 16:01.53 |
| henrys | probably not a big deal | 16:02.05 |
| kens2 | At least, I htink I cna suppress it.... | 16:02.17 |
| | I can't findit at the moment | 16:02.24 |
| | Let me see if that works, test coming | 16:03.46 |
| | Hmm, no that didn't work | 16:05.46 |
| el_mendi | Where are the parameters of the struct fz_matrix that set the postion? The parameters a and d set the width and heigth, but the coordinates? | 16:12.44 |
| | What* | 16:12.54 |
| kens2 | has to go | 16:13.00 |
| | Goodnight folks | 16:13.04 |
| | oh henrys somene needs to follow up on bugs 695297 and 695298 and see if these are actually on behalf of our customer, or questions from HCL themselves. | 16:14.49 |
| kens2 | ducks and runs | 16:14.59 |
| henrys | really donât want the big japanese printer customer getting the âwhen a cat is dropped â¦â missive. I donât thinks that would be good | 16:15.07 |
| chrisl | As long as Miles gets the patent in first.... | 16:16.54 |
| henrys | communication is already a huge challenge | 16:17.53 |
| | without cats and toast | 16:18.33 |
| Robin_Watts | I thought we agreed last time this all came up that HCL must send queries via the customer. | 16:19.19 |
| | We seem to have backtracked away from that position. | 16:19.33 |
| chrisl | Robin_Watts: I thought that, too - but what do I know......? | 16:21.49 |
| henrys | I didnât get the HCL thing, was it to support? | 16:21.52 |
| chrisl | They're bugs | 16:22.32 |
| el_mendi | Which of the params of a matrix defines the translation? e and f? | 16:22.45 |
| Robin_Watts | el_mendi: Yes. | 16:22.58 |
| henrys | my rss reader was dosâd and the attackers are demanding ransom. Itâs been down over 24 hours. | 16:34.55 |
| el_mendi | Ok thanks. When I create a new pdf_device I need the resources and the contents, but when I call my pdf_page_contents_process_fn() from pdf_clean_page_contents() it only has the reources variable. | 16:35.23 |
| | Do I put NULL in the contents argument? | 16:35.50 |
| Robin_Watts | el_mendi: Urm... | 16:36.06 |
| | Yes, you pass NULL as the contents. | 16:36.31 |
| | because you are passing a buffer param. | 16:36.37 |
| | i.e. the pdf_device is operating to a buffer, rather than to a contents object. | 16:36.52 |
| el_mendi | ok thank you! | 16:45.52 |
| | And I suppose that the argument pdf_document *doc is not the whole document but the page, isn't it? | 16:49.21 |
| Robin_Watts | el_mendi: No, it's the whole document. | 16:51.34 |
| el_mendi | Ok | 17:00.04 |
| | The ctm variable in the pdf_device is the matrix of the page? | 17:11.36 |
| Robin_Watts | the ctm passed to pdf_new_pdf_device is the initial page matrix, yes. | 17:14.16 |
| el_mendi | And it would be an Identity matrix? | 17:16.46 |
| | Or from where I can obtain that matrix? | 17:17.13 |
| Robin_Watts | Start with the identity. If you need to change it later we'll worry about it then. | 17:18.38 |
| el_mendi | ok | 17:19.41 |
| | In the fuction pdf_dev_fill_image the value of the alpha must be 1 or 0? | 17:35.46 |
| Robin_Watts | between 0 and 1 inclusive, yes. | 17:36.52 |
| el_mendi | But if I want the image completely opaque it must be 1? | 17:37.17 |
| | And how do I close the pdf_device? With fz_free_device(fz_device *dev)? | 17:41.24 |
| Robin_Watts | yes, 1 to close | 17:42.58 |
| | sorry, 1 to be opaque. | 17:43.34 |
| | Yes, fz_free_device | 17:45.33 |
| rayjj | mvrhel_laptop: do you have time for a discussion ? | 18:05.11 |
| mvrhel_laptop | rayjj: on phone you available in about 30 mintues | 18:05.32 |
| rayjj | mvrhel_laptop: sure. Thanks. | 18:05.46 |
| | mvrhel_laptop: If I don't respond here, please call me. | 18:06.14 |
| mvrhel_laptop | ok | 18:08.28 |
| el_mendi | Robin_Watts: How do I pass my function where I create the pdf device into the pdf_clean_page_contents function? It gives me error | 18:42.24 |
| Robin_Watts | el_mendi: Show me some code. In a pastebin. | 18:45.28 |
| el_mendi | ok | 18:45.54 |
| | http://pastebin.com/G332hNW9 | 18:46.57 |
| rayjj | pdf_clean_page_contents doesn't use a device AFAICT it just messes with the doc | 18:47.59 |
| Robin_Watts | Ok, so the problem that the C compiler will have is that when it reaches the pdf_clean_page_contents it doesn't know what my_process_fn is. | 18:48.22 |
| | so it'll throw a warning and assume it's an int. | 18:48.42 |
| | which doesn't match what the function is expecting and it will therefore error out. | 18:48.59 |
| rayjj | I see void pdf_clean_page_contents(pdf_document *doc, pdf_page *page, fz_cookie *cookie) | 18:49.01 |
| Robin_Watts | rayjj: He has changes that aren't in master. | 18:49.26 |
| rayjj | Robin_Watts: Oh, fun | 18:49.37 |
| Robin_Watts | el_mendi: So move my_process_fn up to be before MuPDFCore_saveImageInternal | 18:50.03 |
| el_mendi | hahaha ok | 18:50.10 |
| rayjj | or declare it | 18:50.25 |
| Robin_Watts | dislikes definitions for static functions unless it's unavoidable. | 18:50.49 |
| el_mendi | That made it | 18:51.28 |
| | But now: undefined reference to 'pdf_dev_fill_image' | 18:51.35 |
| Robin_Watts | el_mendi: Right. You don't call pdf_dev_fill_image. | 18:52.44 |
| | You call pdf_fill_image | 18:52.54 |
| | pdf_dev_fill_image is part of the implementation. It's not a public function. | 18:53.15 |
| | You call the generic fz_fill_image entry point (sorry, not pdf_fill_image!) | 18:53.34 |
| | and that redirects to pdf_dev_fill_image behind the scenes. | 18:53.47 |
| el_mendi | oh | 18:53.52 |
| | so I need to call fz_fill_image then? | 18:54.05 |
| Robin_Watts | yes. | 18:54.09 |
| el_mendi | yep!! that works | 18:55.16 |
| | now I need to make the android part | 18:55.41 |
| | thank you!! | 18:55.45 |
| Robin_Watts | np. | 18:55.50 |
| rayjj | mvrhel_laptop: I hope you don't mind that I poached the "Color Page Detection" bug (that may or may not be a customer bug). | 19:38.21 |
| | henrys: if that turns out to be work for the customer 534/535 then I'll provide more information. Otherwise, they can just read the docs :-) | 19:39.12 |
| henrys | rayjj: try not to answer hcl question we want them to go through support see my comment in the bug. My concern is they may have other clients we donât know about. | 19:39.16 |
| mvrhel_laptop | rayjj: ok. I don't mind at all | 19:39.59 |
| rayjj | mvrhel_laptop: are you off the phone now ? | 19:40.16 |
| damarusama | is there a book about ghostscript - just realizing how powerfull it is | 19:56.10 |
| rayjj | damarusama: no, but we just started working on an overview document. It'll probably take a few months to get fleshed out. | 20:01.07 |
| Robin_Watts | damarusama: If your interest is in postscript, then read "The Postscript Language Reference Manual" from Adobe. The 3rd edition is the latest, and is available as a free PDF download. | 20:04.15 |
| el_mendi | Robin_Watts: It doesn't work :S I get this error when I try the aplication in m device: http://pastebin.com/paFDuvrC | 20:32.59 |
| mvrhel_laptop | rayjj tried to call your phone | 21:09.22 |
| rayjj | mvrhel_laptop: sorry. I had it on vibrate | 21:16.01 |
| mvrhel_laptop | aha | 21:16.09 |
| rayjj | mvrhel_laptop: I was looking at a JEITA file (J10) that has LARGE patterns that end up being pattern-clist but we end up playing back the entire clist even though most of is outside the current band in the underlying device. That's because we write the pattern-clist in a single band. | 21:16.30 |
| | mvrhel_laptop: so I was thinking that it would be better to have the band height "near" the target device band height. | 21:17.09 |
| mvrhel_laptop | that is an interesting one | 21:17.11 |
| | you mean the band height of the pattern be near the band height of the target? | 21:17.36 |
| rayjj | mvrhel_laptop: then we'd *only* end up playing back 3 bands worth of info | 21:17.43 |
| | mvrhel_laptop: but statistically is there a better ratio to use ? GoldenRatio * target band height or target band height / 3 or something ? | 21:18.31 |
| | mvrhel_laptop: the way it is now works fine for relatively simple patterns that happen to be large spatially | 21:19.25 |
| mvrhel_laptop | rayjj: that is a great question. one that i suspect should be tested by trying out different cases and seeing what effect it has on a set of sample files. ones that have various sizes of patterns | 21:19.48 |
| | ray_laptop: simple in that the clist is small? | 21:20.10 |
| rayjj | mvrhel_laptop: here we are operating with a 128 target band height and the patterns are 1kx1k (or larger) images | 21:20.12 |
| | mvrhel_laptop: right. If the clist file size is small, then playing the whole thing back and letting it clip doesn't hurt | 21:20.48 |
| mvrhel_laptop | rayjj: I see. is there any disadvantage to forcing the banding for the small clist file ? | 21:21.19 |
| | that is forcing the band height to be the same | 21:21.32 |
| rayjj | mvrhel_laptop: not too much that I can think of. If it is a fairly complex path, the path will be decomposed into simpler paths for the bands | 21:22.27 |
| mvrhel_laptop | then I would go ahead and make that change | 21:22.41 |
| | rayjj ^^ | 21:22.50 |
| rayjj | mvrhel_laptop: but then the playback would be faster since it would be simpler paths when playing back the fillpath | 21:23.14 |
| mvrhel_laptop | right | 21:23.25 |
| rayjj | mvrhel_laptop: so any guess on what the ratio of target band height to pattern-clist band height should be -- the pattern will usually NOT be aligned to the target bands so we will always to a partial "before" | 21:24.41 |
| | if we chose the same band height | 21:24.57 |
| | if we choose 2x then we will only play back a single band (but it may have more info that we clip) | 21:25.46 |
| | hmm... I am thinking that 2x is probably best | 21:26.11 |
| mvrhel_laptop | rayjj: that is my guess if pushed, but I really would have to run some tests | 21:26.34 |
| | I am sure there are cases that can always be constructed | 21:27.04 |
| rayjj | mvrhel_laptop: yeah, testing would be nice. Which I can do once I get the selective band playback working :-) | 21:27.05 |
| mvrhel_laptop | rayjj: sounds good | 21:27.18 |
| rayjj | I've implelmented high resolution timers on Windoze (QueryPerformanceCounter) and will do that on linux as well. | 21:27.48 |
| | henrys: does Mac OSX have clock_gettime ? (POSIX) | 21:28.20 |
| | mvrhel_laptop: thanks for letting me sound out the concept | 21:29.04 |
| henrys | rayjj: from googling Iâd say no | 21:29.54 |
| rayjj | henrys: oh, well :-( | 21:30.07 |
| henrys | http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x | 21:30.15 |
| rayjj | henrys: Oh. An alternative. That may work. | 21:30.35 |
| henrys | what are you doing? | 21:30.44 |
| | or which problem are you working on? | 21:31.03 |
| rayjj | henrys: performance for cust 532 | 21:31.55 |
| | henrys: I don't really need mac OSX, but I was thinking about adding it for folks that wanted start-stop timing from C where profiling didn't work. | 21:33.16 |
| | henrys: in particular we can have PS level timers with better resolution than now | 21:33.57 |
| | but for now what I have on Windows works fine for me | 21:34.53 |
| mvrhel_laptop | using gsview, I see one other minor thing I want to fix. when you click on the search icon, the text box that you need to type in does not have the focus. its little things like this that you run into as you use it. other than that so far it has been working great | 23:27.52 |
| | henrys: don't worry I am working on the icc stuff for ken now | 23:29.19 |
| | just reading over the icc spec in a few different documents that I needed to search | 23:29.42 |
| | Forward 1 day (to 2014/06/13)>>> | |
IRC Logs